[Numpy-discussion] performance matrix multiplication vs. matlab

[Robert Kern]

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.

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

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

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