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.
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@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion