[Numpy-discussion] performance matrix multiplication vs. matlab

[Robert Kern]

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.

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