Re: [DotGNU]Changing pnetlib license to LGPL

[BioChem333]

Sorry... I keep forgetting to CC the lists lately.


-----Forwarded Message-----

From: BioChem333 <address@hidden>
To: Rhys Weatherley <address@hidden>
Subject: Re: [DotGNU]Changing pnetlib license to LGPL
Date: 12 Jul 2002 03:20:42 -0400

On Thu, 2002-07-11 at 22:12, Rhys Weatherley wrote:
> Could you please point out which section of the LGPL
> contains this so-called loophole?
> 
> My understanding of the LGPL has always been that changes
> to the implementation of the library must be redistributed,
> and it must be possible to re-link an application using the
> library with a new version of that library (usually solved
> using dynamic link facilities, which CLI has).
> 
> GPL+linking exception only requires the first, which makes
> it a weaker license than LGPL in some respects.

I'm sure Eben Moglen (the _one_ good lawyer on the planet) could really
help us all out on understanding all this a lot better than I ever
could, but I'll give it a shot. ;)

You are right, in that changes to the implementation of the library must
be redistributed, but this leaves open the ability to declare library
routines as native, and implement them outside of the library. In doing
so, only the declaration need be released. As for being able to re-link,
while you must distribute the library mods in source, the rest of the
app must only be provided in object code. It is stated explicitly in the
LGPL that it is understood that mods to that released version of the
library may make it impossible to relink it with the app; this, however,
is not considered a violation of the license. Only if the app's object
code and accompanying library source, as released, do not re-link, is it
a violation. Re-linking must also be possible with other versions of the
library, _only so long as_ those other versions are
"interface-compatible" with the library used in the original linking.

I think the most relevant sections, with respect to this issue, are 5
and 6 of the LGPL.


>>>>> 5. 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". Such a work, in isolation, is not a derivative work of
>>>>> the Library, and therefore falls outside the scope of this
>>>>> License.
>>>>>
>>>>> [...]
>>>>>
>>>>> When a "work that uses the Library" uses material from a header
>>>>> file that is part of the Library, the object code for the work may
>>>>> be a derivative work of the Library even though the source code is
>>>>> not. Whether this is true is especially significant if the work
>>>>> can be linked without the Library, or if the work is itself a
>>>>> library. The threshold for this to be true is not precisely
>>>>> defined by law.
>>>>>
>>>>> Otherwise, if the work is a derivative of the Library, you may
>>>>> distribute the object code for the work under the terms of Section
>>>>> 6. Any executables containing that work also fall under Section 6,
>>>>> whether or not they are linked directly with the Library itself.
>>>>>
>>>>> 6. As an exception to the Sections above, you may also combine or
>>>>> link a "work that uses the Library" with the Library to produce a
>>>>> work containing portions of the Library, and distribute that work
>>>>> under terms of your choice, provided that the terms permit
>>>>> modification of the work for the customer's own use and reverse
>>>>> engineering for debugging such modifications.
>>>>>
>>>>> [...]
>>>>>
>>>>> Also, you must do one of these things:
>>>>>     * a) Accompany the work with the complete corresponding
>>>>> machine-readable source code for the Library including whatever
>>>>> changes were used in the work (which must be distributed under
>>>>> Sections 1 and 2 above); and, if the work is an executable linked
>>>>> with the Library, with the complete machine-readable "work that
>>>>> uses the Library", as object code and/or source code, so that the
>>>>> user can modify the Library and then relink to produce a modified
>>>>> executable containing the modified Library. (It is understood that
>>>>> the user who changes the contents of definitions files in the
>>>>> Library will not necessarily be able to recompile the application
>>>>> to use the modified definitions.)
>>>>>     * b) Use a suitable shared library mechanism for linking with
>>>>> the Library. A suitable mechanism is one that (1) uses at run time
>>>>> a copy of the library already present on the user's computer
>>>>> system, rather than copying library functions into the executable,
>>>>> and (2) will operate properly with a modified version of the
>>>>> library, if the user installs one, as long as the modified version
>>>>> is interface-compatible with the version that the work was made
>>>>> with.
>>>>>
>>>>> [...]
>>>>>