[Numpy-discussion] performance matrix multiplication vs. matlab

[Benoit Jacob]

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.

Benoit

>
> --
> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>