[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New license wording
Etienne M. Gagnon
Re: New license wording
Wed, 23 Jan 2002 10:44:12 -0500
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020121
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 http://www.info.uqam.ca/~egagnon/