[Numpy-discussion] Solaris Sparc build broken

[Robert Kern]

On Wed, Nov 18, 2009 at 23:39, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Robert Kern wrote:
>> On Wed, Nov 18, 2009 at 22:52, David Cournapeau
>> <david at ar.media.kyoto-u.ac.jp> wrote:
>>
>>> René Dudfield wrote:
>>>
>>>> pygame is also LGPL... as are a number of other libraries.  (pyqt is GPL btw).
>>>>
>>>> LGPL basically means you can link to the library source, but if you
>>>> make changes to the library you should give them back.  Users should
>>>> also be able to change the library if they want... either through
>>>> source or relinking.
>>>>
>>>>
>>> It is far from being that simple, because the notion on whether you are
>>> allowed to use the library with proprietary software is based on
>>> derivative work, not "link to the library source". For compiled code, it
>>> is generally admitted that if you use the library as a shared library
>>> (dynamic linking), the program you link to is not derivative, and hence
>>> can be any license you want.
>>>
>>
>> Not at all. The FSF and a large proportion of GPL users claim otherwise.
>
> I thought we were discussing about the LGPL here. What I said previously
> only applies to the LGPL, and is certainly wrong for the GPL. But I
> don't think the GPL causes any issue for python code (I have encountered
> very little python LGPL code, but there is plenty under the GPL).

Ah, I see the confusion. The term "derivative work" is a term from
copyright law and is independent of any license under consideration.
The FSF considers an application that links to a library in the same
process space, either dynamically or statically, a derivative work of
the library whether the library is GPLed or LGPLed.

If you're talking about the distinction that the LGPL makes between
linked code that can be proprietary and must not, you're still wrong,
though. The LGPL does not make a distinction based on the linking
technology. One can have a proprietary application statically linked
with an LGPL library. The only detail there is that, in order to
satisfy the "user must be able to relink the application with a
modified Library" requirement, the distributor must provide object
files for his proprietary code and the appropriate tools such the user
can relink against a modified library.

Rather, the distinction between code that can be proprietary and code
that must be LGPLed is whether the code uses the interface exposed by
the library or if it makes deeper modifications. The LGPLv3 makes
things pretty explicit:

"""
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.
"""

For Python libraries, I think the only gray area would be some deep,
deep monkeypatching, but mostly I suspect that a reasonable line that
most people would agree to is that if you import an unmodified LGPL
module, you are just using its interface no matter what you do with
the objects you get from it. If you edit the files of the LGPLed
Python library, those modifications must be LGPLed.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco