[Numpy-discussion] performance matrix multiplication vs. matlab

[Benoit Jacob]

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.

>
>> The only requirement, if I understand well, is that _if_ a NumPy user
>> wanted to make modifications to  Eigen itself, he would have to
>> conform to the LGPL requirements about sharing the modified source
>> code.
>>
>> But is it really a requirement of NumPy that all its dependencies must
>> be free to modify without redistributing the modified source code?
>
> For the default build and the official binaries, yes.

OK.

>
>> Don't you use MKL, for which the source code is not available at all?
>
> No, we don't. It is a build option. If you were to provide a BLAS
> interface to Eigen, Eigen would be another option.

OK, then I guess that this is what will happen once we release the BLAS library.

Thanks for your patience
Benoit