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

> Furthermore, we would still prefer not to have any LGPL code in the
> official numpy sources or binaries, regardless of how minimal the real
> requirements are. Licensing is confusing enough that being able to say
> "numpy is BSD licensed" without qualification is quite important.

I hear you, in the same way we definitely care about being able to say
"Eigen is LGPL licensed". So it's a hard problem. I think that this is
the only real issue here, but I definitely agree that it is a real
one. Large projects (such as Qt) that have a third_party subdirectory
have to find a wording to explain that their license doesn't cover it.

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
>