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