GPL with the Classpath exception - clarification needed

[Roger Fujii]

John Cowan wrote:
>  Wilson, Andrew scripsit
> > Not quite with you here. Agreed subclassing does not *modify* the
> > base class.  However, are there possible circumstances where a
> > subclass is a derivative in the copyright sense?  If the answer is
> > yes, the rest of your analysis is moot.
>  I don't see how it could be a derivative work, any more than a
>  function that calls your function is a derivative work.

Assuming you agree that a "C" Program A, calling a non-system GPLed "C" 
library L,
means that Program A must be GPLed, under what logic do you think this 
works by?

>  To be sure, the resulting executable as a whole is a derivative work,

huh?  how could it be?  if it were, it must be *GPLed.  AFAIK, all 
copylefts basically
say "if you are a derivative work, you must use license X (where X is 
the copyleft
license).   But, under conditions X, Y, Z....., you do not create a 
derivative work, thus
you are free to do as you like." (ok, to be complete, some add "well, 
there's some
things which might be derivative works, but we won't count it).  Pre v3, 
the GPL
is quite explict about what what is, and what is not derived and is 
"work based on".

>  but the subclass itself is not, and so out of scope for the LGPL.

Not sure what you mean by "out of scope".   To me,  using a net service 
is out of
scope for a traditional license.

> > Such a subclass, or instantiation, is not a "work that uses the
> > Library."  It is a "work based on the Library," and it is LGPL. The
> > only exception for a derivative under copyright is the familiar
> > #include rule.
> > As LGPLv2.1 helpfully notes, "the object code for the work may be a
> >  derivative work of the Library even though the source code is
> > not.... "
>  Quite so.  Under the GPL, a derivative executable work must be
>  distributed with full source.  Under the LGPL, you only need to
>  distribute the LGPLed source.

Not exactly - the correct phrase is that you have some legal obligations
for the LGPL code/objects that you distribute.   I am not required to
distribute the source for glibc, for example (assuming that you aren't
distributing glibc).

> The relevant distinction for LGPL purposes is not whether something is
> a derivative work or not: every program that incorporates the library
> into itself is a derivative work.  The question is whether the derivative
> work is a "work based on the Library" (LGPL 2.1) / "Modified Version of
> the Library" (LGPL 3.0) or not.

This is utterly incorrect.  With LGPL 2.1, how can you say that 
"derivative work" is irrelevant
when "worked based on the Library" is DEFINED to be "A program that 
contains no derivative
of any portion of the Library, but is designed to work with the Library 
by being compiled or
linked with it"?  Using your definition, nothing can be a "work that 
uses the Library".   It is
worth noting that LGPL3 does not use the word derived anywhere.

> In Java, or any language
> normally delivered either in source form or in component-by-component
> binary form with run-time linkage, this is very easy, meaning that the
> LGPL and the GPL+CP are essentially equivalent.

It is *not*.    Since the classpath exception exempts only "independent 
modules" and
"|An independent module is a module which is not derived from or based on
this library", your ability to use the exception depends on whose definition
of "derived" you are using.  So, App A -> LGPL B -> LGPL C can have
different implications than App A -> LGPL B -> GPL+CP D.
|

> The GPL+CP matters
> only for a library written in a language where delivery by way of static
> executables is the norm, and replacement would require the proprietary
> part of the application to be delivered as .o files or something similar.

I think you meant LGPL here.   There are other subtle differences 
pending on the
application.

Alon von Bismark wrote:
> 2009/3/27 Wilson, Andrew <andrew.wilson at intel.com>:
> > As LGPLv2.1 helpfully notes, "the object code for the work may be a derivative
> > work of the Library even though the source code is not.... The threshold for this
> > to be true is not precisely defined by law."
>
> I doubt it.
>
> For starters:
>
> http://www.usfca.edu/law/determann/softwarecombinations060403.pdf

Pages 43-45 doesn't generate any confidence on your position.
Being told "oh, the courts will probably go your way" isn't the certainly
that most people want on such things.



Philippe Verdy wrote:
 > > De : Wilson, Andrew [mailto:andrew.wilson at intel.com]
 > > 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

This has no bearing on whether or not the classes are derived or not.  I think
what Andrew Wilson was saying is if you say:

class my_class extends LGPL_class {
}

people (like the FSF) can say that my_class is a derivative of LGPL_class.
How exactly the JVM does things is irrelevant to the discussion, as the pre
v3 licenses have C notions embedded in it (library, header files) and it's
unclear how a court will map those functions in a java context.


Wilson, Andrew wrote:

 > I'm just weighing to suggest that developers should always look at LGPL
 > carefully and not just blithely assume it is GPL with a linking 
exception,
 > because it is not; it is a very nuanced license.

Agreed.   I came to the conclusion that pre v3 *gpl was terrible in the 
java context
because of the uncertainly on what "derived" meant.   LGPL was better than
GPL+CP (for java) because there's at least something you could point to (the
lgpl faq link) that would support the rational notion of derived.   Not 
sure about
LGPL3 - what is  required by section 4e is a little unclear.

-r