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