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

Paolo Bonzini bonzini at gnu.org
Fri Mar 21 17:21:00 UTC 2008


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:

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