[squeak-dev] Re: Swazoo - LGPL or MIT?
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
> 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++.
More information about the Squeak-dev