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

Cheers,
   - 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