Re: New license wording

["Etienne M. Gagnon" <etienne dot gagnon at uqam dot ca>]

Hi Bryce,

You should probably send a message detailing your concerns to Richard Stallman 
<rms@gnu.org>; 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
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/