[Numpy-discussion] performance matrix multiplication vs. matlab

[Benoit Jacob]

2010/1/17 Benoit Jacob <jacob.benoit.1 at gmail.com>:
> 2010/1/17 Robert Kern <robert.kern at gmail.com>:
>> On Sun, Jan 17, 2010 at 13:18, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
>>> 2010/1/17 Robert Kern <robert.kern at gmail.com>:
>>>> On Sun, Jan 17, 2010 at 12:11, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
>>>>> 2010/1/17 Robert Kern <robert.kern at gmail.com>:
>>>>>> On Sun, Jan 17, 2010 at 08:52, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
>>>>>>> 2010/1/17 David Cournapeau <cournape at gmail.com>:
>>>>>>
>>>>>>>> There are several issues with eigen2 for NumPy usage:
>>>>>>>>  - using it as a default implementation does not make much sense IMHO,
>>>>>>>> as it would make distributed binaries non 100 % BSD.
>>>>>>>
>>>>>>> But the LGPL doesn't impose restrictions on the usage of binaries, so
>>>>>>> how does it matter? The LGPL and the BSD licenses are similar as far
>>>>>>> as the binaries are concerned (unless perhaps one starts disassembling
>>>>>>> them).
>>>>>>>
>>>>>>> The big difference between LGPL and BSD is at the level of source
>>>>>>> code, not binary code: one modifies LGPL-based source code and
>>>>>>> distributes a binary form of it, then one has to release the modified
>>>>>>> source code as well.
>>>>>>
>>>>>> This is not true. Binaries that contain LGPLed code must be able to be
>>>>>> relinked with a modified version of the LGPLed component.
>>>>>
>>>>> This doesn't apply to Eigen which is a header-only pure template
>>>>> library, hence can't be 'linked' to.
>>>>>
>>>>> Actually you seem to be referring to Section 4 of the LGPL3, we have
>>>>> already asked the FSF about this and their reply was that it just
>>>>> doesn't apply in the case of Eigen:
>>>>>
>>>>> http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html
>>>>>
>>>>> In your case, what matters is Section 5.
>>>>
>>>> You mean Section 3. Good.
>>>
>>> Section 3 is for using Eigen directly in a C++ program, yes, but I got
>>> a bit ahead of myself there: see below
>>>
>>>> I admit to being less up on the details of
>>>> LGPLv3 than I was of LGPLv2 which had a problem with C++ header
>>>> templates.
>>>
>>> Indeed, it did, that's why we don't use it.
>>>
>>>>
>>>> That said, we will not be using the C++ templates directly in numpy
>>>> for technical reasons (not least that we do not want to require a C++
>>>> compiler for the default build). At best, we would be using a BLAS
>>>> interface which requires linking of objects, not just header
>>>> templates. That *would* impose the Section 4 requirements.
>>>
>>> ... or rather Section 5: that is what I was having in mind:
>>>  " 5. Combined Libraries. "
>>>
>>> I have to admit that I don't understand what 5.a) means.
>>
>> I don't think it applies. Let's say I write some routines that use an
>> LGPLed Library (let's call them Routines A). I can include those
>> routines in a larger library with routines that do not use the LGPLed
>> library (Routines B). The Routines B can be under whatever license you
>> like. However, one must make a library containing only Routines A and
>> the LGPLed Library and release that under the LGPLv3, distribute it
>> along with the combined work, and give notice about how to obtain
>> Routines A+Library separate from Routines B. Basically, it's another
>> exception for needing to be able to relink object code in a particular
>> technical use case.
>>
>> This cannot apply to numpy because we cannot break out numpy.linalg
>> from the rest of numpy. Even if we could, we do not wish to make
>> numpy.linalg itself LGPLed.
>
> Indeed, that seems very cumbersome. I will ask the FSF about this, as
> this is definitely not something that we want to impose on Eigen
> users.
>

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

First, Section 5 of the LGPL is horrible indeed, so let's forget about that.

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
 4e) not applicable to you

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"

Again, IANAL.

Benoit