Physical file organisation of any bearing to LGPL?

Mark Wielaard mark at klomp.org
Wed Aug 4 17:25:22 UTC 2010


On Wed, 2010-08-04 at 09:53 -0700, Wilson, Andrew wrote:
> There is some discussion as to whether or not subclassing in Java creates a
> derivative in the copyright sense, which is presumably why FSF uses
> GPL+classpath exception rather than LGPL for their Java runtimes.
> I think most people believe that it probably does not, but
> if this is a matter of real importance to you then you might want to
> ask a real lawyer.  IANAL, TINLA.

The FSF has a page on LGPL and Java:
http://www.gnu.org/licenses/lgpl-java.html
"The only difference between Java and C from the LGPL's perspective is
that Java is an object-oriented language, supporting inheritance. The
LGPL contains no special provisions for inheritance, because none are
needed. Inheritance creates derivative works in the same way as
traditional linking, and the LGPL permits this type of derivative work
in the same way as it permits ordinary function calls."

The usage of GPL + Classpath Exception comes from when GNU Classpath and
libgcj were merged (back in 1999). libgcj used a GPL + Exception style
license because it was part of the GNU Compiler Collection (GCC) which
uses that kind of license to facilitate certain kinds of staticly build
embedded systems. The LGPL has some requirements giving the user the
freedom to replace the library with their own copy, which are sometimes
hard to obey in small embedded systems that don't contain a shared
library loader. This isn't an issue for traditional java-like runtimes.
But comes up when using GCJ as Ahead Of Time (AOT) static compiler on
java source code. Which is used a lot in the small embedded device space
to get something java-like to program against, but without the dynamic
java runtime parts. Before the merge of the projects GNU Classpath used
plain LGPL, now that it is (also) part of GCC it uses a similar kind of
license as other GCC runtime libraries (although most other runtime
libraries have been upgraded to [L]GPLv3 + exception, we are keeping GNU
Classpath on GPLV2+ for now to be compatible with Sun/Oracle OpenJDK
work).

Cheers,

Mark




More information about the License-discuss mailing list