GPL with the Classpath exception - clarification needed

[Philippe Verdy]

> 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