[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New license wording

From: Etienne M. Gagnon
Subject: Re: New license wording
Date: Wed, 23 Jan 2002 10:44:12 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020121

Hi Bryce,

You should probably send a message detailing your concerns to Richard Stallman <address@hidden>; he is the main person behind the wording of the exception. [Please put me on the CC list.]

See my comments below.

Bryce McKinlay wrote:

I'll try to answer this one.  "Based on" means that you included some
of Classpath's source code ("as is" or modified ) in your application.
The simple act of linking with a library is considered "using" the
library.  Linking, here can be interpreted as "binary linking"
(runtime) or even some form of compile-time linking like using
Classpath as the class library for compiling your application to
bytecode using Jikes.

But what about static linking? Being able to create a statically linked binary which includes components of libgcj is, I thought, a very important feature of this license.

Static linking is no different from dynamic linking, in our context. The Classpath exception says "...give you permission to link...". There's no special treatment for "static" linking.

> The LGPL also says the following (the LGPL is not applicable here

because it is a completely different license, however the definition it provides makes me nervous about the wording of our license):

[A "work based on the Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language. ]

This would imply to me that static linking is not allowed under the new license, in which case I would argue for this change to be reverted or, at least, for the "based on" bit to be changed or deleted.

Under your reasoning, if Classpath was licensed under the LGPL, then linking an application with Classpath would require licensing the whole application under the terms of the LGPL! But the LGPL was specifically designed so that would not be the case... I think the problem is that you are forgetting that both the LGPL and the Classpath license have exceptions (LGPL section 6 + Classpath exception) that give you an explicit permission to "link" without applying the terms to the combined work. So, if you agree with this, all that is left is to agree on the definition of "independent module".

I think that it is generally accepted that a "normal usage" of a library consists of "depending on its API" (application programming interface) [or "external/exported interface"]. Consequently, if your modules only depend on the API exported by Classpath, then they will match the definition of "independent module" [using a library is different from being "based on it"; just replace Classpath by another library exporting the same API... Would you then say thet your module is based on "all possibile" libraries exporting this same API? No.]. Of course, if you start using "implementation" code from Classpath into your modules, then they will not be independent anymore [replacing the library won't remove Classpath's code from your modules].

[I just hope that you agree that "inheriting" from a library class is a normal "library usage"... This is really something I would personally testify to, as an expert in the field, in front of a juge.]

This seems pretty intuitive to me, but maybe it isn't? If you are really worried, please write to Richard S. I think it will lead nowhere to continue this discussion on developer mailing-lists.

Etienne M. Gagnon          

reply via email to

[Prev in Thread] Current Thread [Next in Thread]