GPL with the Classpath exception - clarification needed

Alon von Bismark at
Fri Mar 27 00:50:22 UTC 2009

2009/3/27 Wilson, Andrew <andrew.wilson at>:
> John Cowan [mailto:cowan at] 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

I doubt it.

For starters:



More information about the License-discuss mailing list