GPL with the Classpath exception - clarification needed

[Philippe Verdy]

Wilson, Andrew [mailto:andrew.wilson at intel.com]  wrote:
> Philippe Verdy [mailto:verdy_p at wanadoo.fr] wrote:
> 
> > I have always disliked C++.
> >
> > And even if I use C++ today, I strictly NEVER use the STL, 
> but prefer 
> > using much more portable frameworks that do not enve use 
> the multiple 
> > inheritance, and can use C++ templates only in a limited 
> (but largely 
> > sufficient) way, like it is done in Java, C# or other 
> languages that 
> > can support variant types, introspection and modeling with 
> interfaces 
> > and separation from the implementation (with lots of 
> advantages in terms of choices of deployment).
> 
> Philippe, just a gentle reminder, this list is 
> license-discuss, not language-discuss.
> 
> > But remember that we were speaking about Java when speaking 
> about the 
> > Classpath exclusion. Where does the LGPL affect 
> Java-written libraries 
> > so that it would not work or would render an application using it 
> > fully GPL licenced with all its requirements?
> 
> OK. If you derive a Java class from a base class which is 
> LGPL licensed, under what rationale do you claim your derived 
> class is not also a derivative work under copyright, and is 
> not subject to LGPL?

I used the expression "using a library", which covers all kind of usage, not
just derivation. GNU has made it clear that derivation of a class is not
different from a traditrional call of a function.

If you can use a LGPL library within a proprietary program without giving
the sources of this program, but just the source of the library (eventually
the modified sources if you are distributing the library in compiled format
long with your compiled proprietary application), and you allow reverse
engineering to discover how your program interacts and interoperates ith the
library or a modified version of it, so that the libary can still be
modified without needing any change in the proprietary program that will
continue to work, then you are compliant. You can also distrobute your
proprietary program without the LGPL library (users can install it
separately from any other providers that distributes just the sources or the
precompiled code with a free access to the sources).

The same is true for Java: the classpath is not different from the include
path for headers and library path in a C-written library, as wel as its
documentation or man pages (which may be generated from the sources wiht
JavaDoc in Java, or Doxygen in C and C++, or from UML design diagrams ht are
used to structure and model the library or the service).

In fact the LGPL will work well also for network services (including the web
itself that supports RPC services through communication protocols and
transfer syntaxes like XML and SOAP, or even just HTML). The whole Web itelf
has an API based on its protocols and URLs.: many programs are connected to
it that do not need any prior licencing afreement to work together, despite
they are covered by different incompatible licences. The LGPL looks better
than GPL+CP as it also covers this case. There is still the freedom of
choosing the LGPL library implementation, the freedom of modifyoing it, even
if there are many other proprietary programs interacting with it or offering
services from the LGPL library or taking services from them.

There's no reason to separate the case of object-oriented derivation or
interface implementation in Java from the case of function calls in C. So
you can use a Java written library licenced under LGPL within proprietary
code, either through object-oriented derivation (which is not creating a
"derived work" even if the term "derived" takes another meaning here in
terms of legal licencing instead of OO programming) or instanciation (which
is exactly similar to the call of a construction function call in C). What
was said about Java will also be completely equivalent about C#, or other OO
programing languages like PHP, Python, and so on, that also have colletions
of free libraries used in proprietary programs (with various usge mechanisms
that may be modeled differently in higher level design layers, but
effectively doing the same thing as classic function calls (direct through
dynamic loading at load and run time, or indirect with contextual linking).

It's only when the static linking is used that problems are the most serious
(in C and assembly languages notably, for which reverse engineering is un
avoidable to change the implementation of the linked library). But for Java
and most OO programs that don't use static linking, it's much easier to keep
the separation and avoid the reverse enginnering of the prprietary
application.

The LGPL still allows such investigation if this is still needed to
understand the interactions between the LGPL library and the proprietary
program (notably the frequently undocumented bynamic behavior and timing
issues or the denepdant or expected order of events, or expected context
that should occur at runtime in order to get the expected results (tis is
needed if not all preconditions and postconditions and changes of internal
states of objects that are not all documented). However the LGPL does not
still gives rthe right to get the sources of this proprietary program or the
right to get support on how to reverse engineer the program. What the LGPL
provides is the protection of those trying to reverse engineer the
proprietary part of the program using the LGPL library, including the right
to emulate it or or less in order to create a LGPL derivative work not
depending on the proprietary program, but not the right to copy this
proprietary code that remains conditioned by its separate licence that the
LGPL does not alter, rstricts or extends.

So "extending" a new derived class in Java from a base class in a LGPL
library, or implementing within a new class an interface defined in that
libary, or instanciating in a new class another class dedined in that
library is not creating a derivated work under the licencing definition of
the GPL: this is the essence of the LGPL exclusion. 
Don't be abused by the legal meaning of the concept of derived work bsed on
another work and the meaning of the OO concepts above that just appear to
use (traditonally only, but not normatively) some common terms.