[Numpy-discussion] performance matrix multiplication vs. matlab

[Bruce Southey]

On 01/18/2010 10:46 AM, Benoit Jacob wrote:
> 2010/1/18 Robert Kern<robert.kern at gmail.com>:
>    
>> On Mon, Jan 18, 2010 at 10:26, Benoit Jacob<jacob.benoit.1 at gmail.com>  wrote:
>>      
>>> 2010/1/18 Robert Kern<robert.kern at gmail.com>:
>>>        
>>>> On Mon, Jan 18, 2010 at 09:35, Benoit Jacob<jacob.benoit.1 at gmail.com>  wrote:
>>>>
>>>>          
>>>>> Sorry for continuing the licensing noise on your list --- I though
>>>>> that now that I've started, I should let you know that I think I
>>>>> understand things more clearly now ;)
>>>>>            
>>>> No worries.
>>>>
>>>>          
>>>>> First, Section 5 of the LGPL is horrible indeed, so let's forget about that.
>>>>>            
>>>> I don't think it's that horrible, honestly. It just applies to a
>>>> different deployment use case and a different set of technologies.
>>>>
>>>>          
>>>>> If you were using a LGPL-licensed binary library, Section 4 would
>>>>> rather be what you want. It would require you to:
>>>>>   4a) say somewhere ("prominently" is vague, the bottom of a README is
>>>>> OK) that you use the library
>>>>>   4b) distribute copies of the GPL and LGPL licenses text. Pointless,
>>>>> but not a big issue.
>>>>>
>>>>> the rest doesn't matter:
>>>>>   4c) not applicable to you
>>>>>   4d1) this is what you would be doing anyway
>>>>>            
>>>> Possibly, but shared libraries are not easy for a variety of boring,
>>>> Python-specific, technical reasons.
>>>>          
>>> Ah, that I didn't know.
>>>
>>>        
>>>>>   4e) not applicable to you
>>>>>            
>>>> Yes, it is. The exception where Installation Information is not
>>>> required is only when installation is impossible, such as embedded
>>>> devices where the code is in a ROM chip.
>>>>          
>>> OK, I didn't understand that.
>>>
>>>        
>>>>          
>>>>> Finally and this is the important point: you would not be passing any
>>>>> requirement to your own users. Indeed, the LGPL license, contrary to
>>>>> the GPL license, does not propagate through dependency chains. So if
>>>>> NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be
>>>>> met when distributing NumPy, but NumPy itself isn't LGPL at all and an
>>>>> application using NumPy does not have to care at all about the LGPL.
>>>>> So there should be no concern at all of "passing on LGPL requirements
>>>>> to users"
>>>>>            
>>>> No, not at all. The GPL "propagates" by requiring that the rest of the
>>>> code be licensed compatibly with the GPL. This is an unusual and
>>>> particular feature of the GPL. The LGPL does not require that rest of
>>>> the code be licensed in a particular way. However, that doesn't mean
>>>> that the license of the "outer layer" insulates the downstream user
>>>> from the LGPL license of the wrapped component. It just means that
>>>> there is BSD code and LGPL code in the total product. The downstream
>>>> user must accept and deal with the licenses of *all* of the components
>>>> simultaneously. This is how most licenses work. I think that the fact
>>>> that the GPL is particularly "viral" may be obscuring the normal way
>>>> that licenses work when combined with other licenses.
>>>>
>>>> If I had a proprietary application that used an LGPL library, and I
>>>> gave my customers some limited rights to modify and resell my
>>>> application, they would still be bound by the LGPL with respect to the
>>>> library. They could not modify the LGPLed library and sell it under a
>>>> proprietary license even if I allow them to do that with the
>>>> application as a whole. For us to use Eigen2 in numpy such that our
>>>> users could use, modify and redistribute numpy+Eigen2, in its
>>>> entirety, under the terms of the BSD license, we would have to get
>>>> permission from you to distribute Eigen2 under the BSD license. It's
>>>> only polite.
>>>>          
>>> OK, so the Eigen code inside of NumPy would still be protected by the
>>> LGPL. But what I meant when I said that the LGPL requirements don't
>>> propagate to your users, was that, for example, they don't have to
>>> distribute copies of the LGPL text, installation information for
>>> Eigen, or links to Eigen's website.
>>>        
>> Yes, they do. They are redistributing Eigen; they must abide by its
>> license in all respects. It doesn't matter how much it is wrapped.
>>      
> Well this is where I'm not sure if I agree, I am asking the FSF right
> now as, if this were the case, I too would find such a clause very
> inconvenient for users.
>
>    

If you obtain the code from any package then you are bound by the terms 
of that code. So while a user might not be 'inconvenienced' by the LGPL, 
they are required to meet the terms as required. For some licenses (like 
the LGPL) these terms do not really apply until you distribute the code 
but that does not mean that the user is exempt from the licensing terms 
of that code because they have not distributed their code (yet).

Furthermore there are a number of numpy users that download the numpy 
project for further distribution such as Enthought, packagers for Linux 
distributions and developers of projects like Python(x,y). Some of these 
users would be inconvenienced because binary-only distributions would 
not be permitted in any form.

Bruce