GPL with the Classpath exception - clarification needed

[Wilson, Andrew]

John Cowan [mailto:cowan at ccil.org] wrote:

> 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.

With you so far.  Linking to an LGPL library creates a derivative work which
is governed by LGPL.

> Now subclassing a class plainly does not *modify* the class.  So programs
> that contain subclasses of an LGPLed class, or instantiations of an
> LGPLed interface, or what have you, are "works that use the Library"
> (LGPL 2.1) / "Applications" (LGPL 3.0) and may be under any license
> provided it is possible to replace the library.

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.
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.... The threshold for this
to be true is not precisely defined by law."

Andy Wilson
Intel open source technology center