GPL with the Classpath exception - clarification needed

[Lawrence Rosen]

I've been reading this thread with some frustration. Everything said so far
has been about the technological differences between C++ links and class
references, yet there isn't a single pointer to the law of derivative works
that could help a judge decide how this license is to apply or help
companies understand why a different license than the LGPL is needed. And
almost none of the technical distinctions being drawn here, interesting
though they are to a former programmer like me, are actually reflected in
the words of the license itself.

Why "yet another license" (GPL+Classpath) when OSL 3.0 already handles this
case correctly under copyright law?

/Larry



> -----Original Message-----
> From: Philippe Verdy [mailto:verdy_p at wanadoo.fr]
> Sent: Thursday, March 26, 2009 8:01 PM
> To: 'Wilson, Andrew'; license-discuss at opensource.org
> Subject: RE: GPL with the Classpath exception - clarification needed
> 
> > De : Wilson, Andrew [mailto:andrew.wilson at intel.com]
> > The reasoning in the FSF link provided by Roger
> > (http://www.gnu.org/licenses/lgpl-java.html)
> > is that instantiating a class is exactly like making a function call.
> > Well, maybe.  I'm sure there are other technical experts who
> > would say it's more like doing an #include and expanding the
> > macros -- perhaps even you.  Certainly, deriving a class has
> > macro-like qualities.
> 
> Certainly not. At least not with compliant Java VM that requires a
> complete
> isolation of separately compiled classes (all of them being compilable
> without the source of the referenced class or interface), with the
> mandatory
> support for Reflection and for full replacability of the implementation
> (i.e. the strict isolation through the visible interface which is the one
> accessible through reflection).
> 
> The only allowed direct inclusion of source elements or compiled element
> from one class to an other is the copy of the value of constants defined
> with non-object types as final static fields in a referenced class or
> interface, and their use for static compilation of another class or
> interface, but this only uses the defined value as seen from the
> reflection
> interface; this is not permitted for non-final or non-static fields or
> fields with object types (i.e. reference fields). It is anyway only
> including the precomputed value, but not the name and not even the
> syntaxic
> source form or comments attached to this constant.
> 
> There's no #include in standard Java (and in fact no need for it), just
> imports. There's no preprocessor that will mix parts from multiple sources
> into a single compilable unit (there's no need for it, not even for
> conditional compilation, thanks to JIT compilation at runtime based on
> actual usage profiles with branch prediction and automatic elimination of
> dead code within the VM.
> 
> Java imports do not include any line of source from the referenced classes
> (so even the 10 lines of source tolerance is not needed, it could be
> zero):
> everything is read from another compiled class through the reflection API
> that gives everything that is needed to allow interoperability between two
> classes or interfaces, without importing any thing from its associated
> source.
> 
> The VM, or even the Java compiler itself, just use the summary info
> offered
> by reflection, and this info depends on what your locally running class
> loader (outside of the proprietary application written in Java and the
> used
> LPL'ed library of packages, classes or interfaces), and no view avout the
> code itself (which is visible only by the VM itself ot its instanciator,
> which are independant of the application and of the library). If you have
> the list of classes or interfaces that your Java source depends on, you
> can
> just import them without having any of their sources, if all you have is
> their binary compiled form, and without any change to your LGPLed source,
> you can compile your new source.
> 
> You cannot do the same with C or C++ because you stll need the sources of
> the delcaraion of your classes or functions, and some parts of their
> implementations (notably the source of all inline functions or méthods nd
> their own list of linking dependancies). The reason about this is that C
> or
> C++ do not enforce a strict reflection mechanism (so proving some source
> code within pulicly disclosed header files remains needed, the situation
> being even worse in C++ with its templates and with inline methods or
> non-object inline functions, that not only need to disclose the
> interoperability information but also the sources of their implementation,
> except for the simple case of template specializations that may be
> precompiled without exposing the implementation of these specifializations
> or of the generic code within public headers.
> 
> As a consequence type type of "usage" permitted of another class or
> interface in Java is much more restricted than in C++ or C, that do not
> define sostrict policies. That's why I do think that the GPL+CP was not
> needed at all and LGPL is in fact simpler and is much less difficult to
> analyze and check for the validation of full conformance to the terms of a
> licence: Java has a much more strict model for the separation of entities
> and responsabilities, and already requires the mandatory reflection API
> that
> every compiled class must expose in order to be executable in the VM and
> stiull usable to compile any other classes needing it or to run other
> classes that are also precompiled.
> 
> Java offers everything that will also allow debugging up to the level f
> the
> Reflection-visible API within stack traces and the names of public or
> protected elements (there may be optional debugging information, e.g.
> local
> variable names, line numbers) in compiled classes, that may be dropped
> without affecting the interoperability for the existing oter classes in
> the
> complete application, or its maintenance and replacement with alternate
> implementations exposing the same reflection. These cleaned classes will
> still work identically in the VM