[squeak-dev] Re: Swazoo - LGPL or MIT?

Andreas Raab andreas.raab at gmx.de
Fri Mar 21 19:26:55 UTC 2008

Paolo Bonzini wrote:
> Andreas Raab wrote:
>> Paolo Bonzini wrote:
>>> If your changes are subclasses of something is clearly part of the 
>>> interface (you cannot use Swazoo without providing those subclasses, 
>>> and those subclasses are not important to other users of Swazoo), 
>>> adding your subclasses is not going to LGPL.
>> I have always been wondering about this. Where exactly in the LGPL 
>> does it say that?
> I think it is safe to interpret the LGPL in this way where it says:

I was going to argue that whether or not you can interpret the LGPL in 
this way depends on whether or not you consider subclassing to be 
creating a derivative work or not and was wondering whether the FSF has 
ever had commented on that when, much to my suprise, a quick Google 
search found the following statement in LGPL v3:

0. Additional Definitions.


An “Application” is any work that makes use of an interface provided by 
the Library, but which is not otherwise based on the Library. Defining a 
subclass of a class defined by the Library is deemed a mode of using an 
interface provided by the Library.

A “Combined Work” is a work produced by combining or linking an 
Application with the Library. The particular version of the Library with 
which the Combined Work was made is also called the “Linked Version”.


So it appears that this issue has been settled with a more lenient 
interpretation of subclassing than what I would have expected. The above 
says that when you subclass you create a combined work, not a derivative 
work. Section 4 of the LGPL still applies of course which effectively 
means you have to provide source code (or a "suitable linking 
mechanism") but you *can* use any license you want for your part of the 
combined work.

   - Andreas

> 1) "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, is called a "work that uses the Library"."
> 2) "It is not the intent of [Section 2] to claim rights or contest your 
> rights to work written entirely by you; rather, the intent is to 
> exercise the right to control the distribution of derivative or 
> collective works based on the Library".
> Item 1 is respected, because subclassing leaves a clear separation 
> between the work and the library.  You can say that (the source of) a 
> subclass does not contain derivatives of any portion of the library. 
> Item 2 makes it clear what the spirit of Section 2 is, and the fact that 
> "subclasses are not important to other users of Swazoo" (as I wrote 
> above) qualifies them as "work written entirely" by the user, that is 
> simply "designed to work with the Library".
> I also see a parallel with the equivalent of subclassing in C, which is 
> function pointers (and to vtables).  Overriding methods is basically 
> equivalent to passing a different function pointer table in a C library. 
>  Not overriding methods is equivalent to specifying a function exported 
> by the library in the table.
> This, in principle, does not even exclude adding support for adding new 
> HTTP header fields and adding a single method that allows you to 
> register new HTTPHeaderField subclasses.  In that case however I'd be 
> careful because you are walking a finer line -- in Smalltalk everything 
> exported must be public, but that's not necessarily the case in other 
> languages, and it could be seen as exploiting "weaknesses" of a language 
> in order to circumvent the license.
> If a package had a decent documentation, I think that could provide a 
> way to understand what is public just because of Smalltalk's lack of 
> private interfaces, and what is private.  Using private stuff or 
> subclassing it would be problematic.  *Modifying code always places the 
> result under the LGPL*.
> That said, IANAL and I don't think a case like this has ever been tested 
> in court, not even for other languages than C/C++.
> Paolo

More information about the Squeak-dev mailing list