2010/1/17 Robert Kern <robert.kern@gmail.com>:
On Sun, Jan 17, 2010 at 13:18, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
2010/1/17 Robert Kern <robert.kern@gmail.com>:
On Sun, Jan 17, 2010 at 12:11, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
2010/1/17 Robert Kern <robert.kern@gmail.com>:
On Sun, Jan 17, 2010 at 08:52, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
2010/1/17 David Cournapeau <cournape@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.h...
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@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion