Re: [Numpy-discussion] performance matrix multiplication vs. matlab
Hi,
I while back, someone talked about aigen2(http://eigen.tuxfamily.org/). In their benchmark they give info that they are competitive again mkl and goto on matrix matrix product. They are not better, but that could make a good default implementation for numpy when their is no blas installed. I think the license would allow to include it in numpy directly.
It is licensed under the LGPLv3, so it is not compatible with the numpy license.
Hi, I'm one of Eigen's authors. Eigen is indeed LGPL3 licensed. Our intent and understanding is that this makes Eigen usable by virtually any software, whence my disappointment to learn that LGPL3 software can't be used by NumPy. Just for my information, could you tell my why NumPy can't use LGPL3-licensed libraries? I found this page: http://www.scipy.org/License_Compatibility It does say that LGPL-licensed code can't be added to NumPy, but there's a big difference between adding LGPL code directly into NumPy, and just letting NumPy _use_ LGPL code. Couldn't you simply: - either add LGPL-licensed code to a third_party subdirectory not subject to the NumPy license, and just use it? This is common practice, see e.g. how Qt puts a copy of WebKit in a third_party subdirectory. - or use LGPL-licensed code as an external dependency? FYI, several BSD-licensed projects are using Eigen ;) Thanks for your consideration Benoit
On Sun, Jan 17, 2010 at 2:20 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
Couldn't you simply: - either add LGPL-licensed code to a third_party subdirectory not subject to the NumPy license, and just use it? This is common practice, see e.g. how Qt puts a copy of WebKit in a third_party subdirectory. - or use LGPL-licensed code as an external dependency?
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. - to my knowledge, eigen2 does not have a BLAS API, so we would have to write specific wrappers for eigen2, which is undesirable. - eigen2 is C++, and it is a stated goal to make numpy depend only on a C compiler (it may optionally uses fortran to link against blas/lapack, though). As I see it, people would be able to easily use eigen2 if there was a BLAS API for it. We still would not distribute binaries built with eigen2, but it means people who don't care about using GPL code could use it. Independently of NumPy, I think a BLAS API for eigen2 would be very beneficial for eigen2 if you care about the numerical scientific community. David
2010/1/17 David Cournapeau <cournape@gmail.com>:
On Sun, Jan 17, 2010 at 2:20 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
Couldn't you simply: - either add LGPL-licensed code to a third_party subdirectory not subject to the NumPy license, and just use it? This is common practice, see e.g. how Qt puts a copy of WebKit in a third_party subdirectory. - or use LGPL-licensed code as an external dependency?
Thanks for the reply! First of all I should say that I was only talking about the raised licensing issue, I'm not saying that you _should_ use eigen from a technical point of view.
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. Since NumPy's users are presumably not interested in modifying _Eigen_ itself, I don't think that matters. I understand that they may want to modify NumPy's source code without releasing their modified source code, so the BSD license is important for NumPy, but having Eigen in a third_party directory wouldn't affect that.
- to my knowledge, eigen2 does not have a BLAS API, so we would have to write specific wrappers for eigen2, which is undesirable.
That's true. FYI, a BLAS API is coming in Eigen 3, https://bitbucket.org/eigen/eigen/src/tip/blas/
- eigen2 is C++, and it is a stated goal to make numpy depend only on a C compiler (it may optionally uses fortran to link against blas/lapack, though).
Ah OK. Well, once the Eigen BLAS is implemented, it will be usable by a C compiler.
As I see it, people would be able to easily use eigen2 if there was a BLAS API for it. We still would not distribute binaries built with eigen2, but it means people who don't care about using GPL code could use it.
I see. I'd quite like to see this happening! Maybe, just give a look at where Eigen is in 1 year from now, the BLAS should be ready for that.
Independently of NumPy, I think a BLAS API for eigen2 would be very beneficial for eigen2 if you care about the numerical scientific community.
So do we, that's why we're doing it ;) see above. Benoit
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 is technically non-trivial. In addition, binaries containing an LGPLed component must still come with the source of the LGPLed component (or come with a written offer to distribute via the same mechanism ... yada yada yada). These are non-trivial restrictions above and beyond the BSD license that we, as a matter of policy, do not wish to impose on numpy users. -- 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
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.
In addition, binaries containing an LGPLed component must still come with the source of the LGPLed component (or come with a written offer to distribute via the same mechanism ... yada yada yada).
Since you would presumably be using vanilla Eigen without changes of your own, it would be enough to just give the link to the Eigen website, that's all. Just one line, and it doesn't have to be in a very prominent place, it just has to be reasonably easy to find for someone looking for it.
These are non-trivial restrictions above and beyond the BSD license that we, as a matter of policy, do not wish to impose on numpy users.
The only thing you'd be imposing on NumPy users would be that somewhere at the bottom of, say, your README file, there would be a link to Eigen's website. Then who am I to discuss your policies ;) Finally let me just give an example why this is moot. You are using GCC, right? So you use the GNU libc (their standard C library)? It is LGPL ;) It's just that nobody cares to put a link to the GNU libc homepage, which is understandable ;) Cheers, Benoit
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. I admit to being less up on the details of LGPLv3 than I was of LGPLv2 which had a problem with C++ header templates. 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. 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. -- 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
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
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. -- 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
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
2010/1/17 Benoit Jacob <jacob.benoit.1@gmail.com>:
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.
Sorry for continuing the licensing noise on your list --- I though that now that I've started, I should let you know that I think I understand things more clearly now ;) First, Section 5 of the LGPL is horrible indeed, so let's forget about that. If you were using a LGPL-licensed binary library, Section 4 would rather be what you want. It would require you to: 4a) say somewhere ("prominently" is vague, the bottom of a README is OK) that you use the library 4b) distribute copies of the GPL and LGPL licenses text. Pointless, but not a big issue. the rest doesn't matter: 4c) not applicable to you 4d1) this is what you would be doing anyway 4e) not applicable to you Finally and this is the important point: you would not be passing any requirement to your own users. Indeed, the LGPL license, contrary to the GPL license, does not propagate through dependency chains. So if NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be met when distributing NumPy, but NumPy itself isn't LGPL at all and an application using NumPy does not have to care at all about the LGPL. So there should be no concern at all of "passing on LGPL requirements to users" Again, IANAL. Benoit
On Mon, Jan 18, 2010 at 09:35, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
Sorry for continuing the licensing noise on your list --- I though that now that I've started, I should let you know that I think I understand things more clearly now ;)
No worries.
First, Section 5 of the LGPL is horrible indeed, so let's forget about that.
I don't think it's that horrible, honestly. It just applies to a different deployment use case and a different set of technologies.
If you were using a LGPL-licensed binary library, Section 4 would rather be what you want. It would require you to: 4a) say somewhere ("prominently" is vague, the bottom of a README is OK) that you use the library 4b) distribute copies of the GPL and LGPL licenses text. Pointless, but not a big issue.
the rest doesn't matter: 4c) not applicable to you 4d1) this is what you would be doing anyway
Possibly, but shared libraries are not easy for a variety of boring, Python-specific, technical reasons. 4d0 would be easier for the official binaries (because we provide official source). But that would still force people building a proprietary application using numpy to rebuild a binary without Eigen2 or else make sure that they allow users to rebuild numpy. For a number of deployment options (py2app, py2exe, bbfreeze, etc.), this is annoying, particularly when combined with the 4e requirement, as I explain below.
4e) not applicable to you
Yes, it is. The exception where Installation Information is not required is only when installation is impossible, such as embedded devices where the code is in a ROM chip.
Finally and this is the important point: you would not be passing any requirement to your own users. Indeed, the LGPL license, contrary to the GPL license, does not propagate through dependency chains. So if NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be met when distributing NumPy, but NumPy itself isn't LGPL at all and an application using NumPy does not have to care at all about the LGPL. So there should be no concern at all of "passing on LGPL requirements to users"
No, not at all. The GPL "propagates" by requiring that the rest of the code be licensed compatibly with the GPL. This is an unusual and particular feature of the GPL. The LGPL does not require that rest of the code be licensed in a particular way. However, that doesn't mean that the license of the "outer layer" insulates the downstream user from the LGPL license of the wrapped component. It just means that there is BSD code and LGPL code in the total product. The downstream user must accept and deal with the licenses of *all* of the components simultaneously. This is how most licenses work. I think that the fact that the GPL is particularly "viral" may be obscuring the normal way that licenses work when combined with other licenses. If I had a proprietary application that used an LGPL library, and I gave my customers some limited rights to modify and resell my application, they would still be bound by the LGPL with respect to the library. They could not modify the LGPLed library and sell it under a proprietary license even if I allow them to do that with the application as a whole. For us to use Eigen2 in numpy such that our users could use, modify and redistribute numpy+Eigen2, in its entirety, under the terms of the BSD license, we would have to get permission from you to distribute Eigen2 under the BSD license. It's only polite. -- 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
2010/1/18 Robert Kern <robert.kern@gmail.com>:
On Mon, Jan 18, 2010 at 09:35, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
Sorry for continuing the licensing noise on your list --- I though that now that I've started, I should let you know that I think I understand things more clearly now ;)
No worries.
First, Section 5 of the LGPL is horrible indeed, so let's forget about that.
I don't think it's that horrible, honestly. It just applies to a different deployment use case and a different set of technologies.
If you were using a LGPL-licensed binary library, Section 4 would rather be what you want. It would require you to: 4a) say somewhere ("prominently" is vague, the bottom of a README is OK) that you use the library 4b) distribute copies of the GPL and LGPL licenses text. Pointless, but not a big issue.
the rest doesn't matter: 4c) not applicable to you 4d1) this is what you would be doing anyway
Possibly, but shared libraries are not easy for a variety of boring, Python-specific, technical reasons.
Ah, that I didn't know.
4e) not applicable to you
Yes, it is. The exception where Installation Information is not required is only when installation is impossible, such as embedded devices where the code is in a ROM chip.
OK, I didn't understand that.
Finally and this is the important point: you would not be passing any requirement to your own users. Indeed, the LGPL license, contrary to the GPL license, does not propagate through dependency chains. So if NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be met when distributing NumPy, but NumPy itself isn't LGPL at all and an application using NumPy does not have to care at all about the LGPL. So there should be no concern at all of "passing on LGPL requirements to users"
No, not at all. The GPL "propagates" by requiring that the rest of the code be licensed compatibly with the GPL. This is an unusual and particular feature of the GPL. The LGPL does not require that rest of the code be licensed in a particular way. However, that doesn't mean that the license of the "outer layer" insulates the downstream user from the LGPL license of the wrapped component. It just means that there is BSD code and LGPL code in the total product. The downstream user must accept and deal with the licenses of *all* of the components simultaneously. This is how most licenses work. I think that the fact that the GPL is particularly "viral" may be obscuring the normal way that licenses work when combined with other licenses.
If I had a proprietary application that used an LGPL library, and I gave my customers some limited rights to modify and resell my application, they would still be bound by the LGPL with respect to the library. They could not modify the LGPLed library and sell it under a proprietary license even if I allow them to do that with the application as a whole. For us to use Eigen2 in numpy such that our users could use, modify and redistribute numpy+Eigen2, in its entirety, under the terms of the BSD license, we would have to get permission from you to distribute Eigen2 under the BSD license. It's only polite.
OK, so the Eigen code inside of NumPy would still be protected by the LGPL. But what I meant when I said that the LGPL requirements don't propagate to your users, was that, for example, they don't have to distribute copies of the LGPL text, installation information for Eigen, or links to Eigen's website. The only requirement, if I understand well, is that _if_ a NumPy user wanted to make modifications to Eigen itself, he would have to conform to the LGPL requirements about sharing the modified source code. But is it really a requirement of NumPy that all its dependencies must be free to modify without redistributing the modified source code? Don't you use MKL, for which the source code is not available at all? I am not sure that I understand how that is better than having source code subject to LGPL requirements. Benoit
On Mon, Jan 18, 2010 at 10:26, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
2010/1/18 Robert Kern <robert.kern@gmail.com>:
On Mon, Jan 18, 2010 at 09:35, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
Sorry for continuing the licensing noise on your list --- I though that now that I've started, I should let you know that I think I understand things more clearly now ;)
No worries.
First, Section 5 of the LGPL is horrible indeed, so let's forget about that.
I don't think it's that horrible, honestly. It just applies to a different deployment use case and a different set of technologies.
If you were using a LGPL-licensed binary library, Section 4 would rather be what you want. It would require you to: 4a) say somewhere ("prominently" is vague, the bottom of a README is OK) that you use the library 4b) distribute copies of the GPL and LGPL licenses text. Pointless, but not a big issue.
the rest doesn't matter: 4c) not applicable to you 4d1) this is what you would be doing anyway
Possibly, but shared libraries are not easy for a variety of boring, Python-specific, technical reasons.
Ah, that I didn't know.
4e) not applicable to you
Yes, it is. The exception where Installation Information is not required is only when installation is impossible, such as embedded devices where the code is in a ROM chip.
OK, I didn't understand that.
Finally and this is the important point: you would not be passing any requirement to your own users. Indeed, the LGPL license, contrary to the GPL license, does not propagate through dependency chains. So if NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be met when distributing NumPy, but NumPy itself isn't LGPL at all and an application using NumPy does not have to care at all about the LGPL. So there should be no concern at all of "passing on LGPL requirements to users"
No, not at all. The GPL "propagates" by requiring that the rest of the code be licensed compatibly with the GPL. This is an unusual and particular feature of the GPL. The LGPL does not require that rest of the code be licensed in a particular way. However, that doesn't mean that the license of the "outer layer" insulates the downstream user from the LGPL license of the wrapped component. It just means that there is BSD code and LGPL code in the total product. The downstream user must accept and deal with the licenses of *all* of the components simultaneously. This is how most licenses work. I think that the fact that the GPL is particularly "viral" may be obscuring the normal way that licenses work when combined with other licenses.
If I had a proprietary application that used an LGPL library, and I gave my customers some limited rights to modify and resell my application, they would still be bound by the LGPL with respect to the library. They could not modify the LGPLed library and sell it under a proprietary license even if I allow them to do that with the application as a whole. For us to use Eigen2 in numpy such that our users could use, modify and redistribute numpy+Eigen2, in its entirety, under the terms of the BSD license, we would have to get permission from you to distribute Eigen2 under the BSD license. It's only polite.
OK, so the Eigen code inside of NumPy would still be protected by the LGPL. But what I meant when I said that the LGPL requirements don't propagate to your users, was that, for example, they don't have to distribute copies of the LGPL text, installation information for Eigen, or links to Eigen's website.
Yes, they do. They are redistributing Eigen; they must abide by its license in all respects. It doesn't matter how much it is wrapped.
The only requirement, if I understand well, is that _if_ a NumPy user wanted to make modifications to Eigen itself, he would have to conform to the LGPL requirements about sharing the modified source code.
But is it really a requirement of NumPy that all its dependencies must be free to modify without redistributing the modified source code?
For the default build and the official binaries, yes.
Don't you use MKL, for which the source code is not available at all?
No, we don't. It is a build option. If you were to provide a BLAS interface to Eigen, Eigen would be another option. -- 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
2010/1/18 Robert Kern <robert.kern@gmail.com>:
On Mon, Jan 18, 2010 at 10:26, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
2010/1/18 Robert Kern <robert.kern@gmail.com>:
On Mon, Jan 18, 2010 at 09:35, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
Sorry for continuing the licensing noise on your list --- I though that now that I've started, I should let you know that I think I understand things more clearly now ;)
No worries.
First, Section 5 of the LGPL is horrible indeed, so let's forget about that.
I don't think it's that horrible, honestly. It just applies to a different deployment use case and a different set of technologies.
If you were using a LGPL-licensed binary library, Section 4 would rather be what you want. It would require you to: 4a) say somewhere ("prominently" is vague, the bottom of a README is OK) that you use the library 4b) distribute copies of the GPL and LGPL licenses text. Pointless, but not a big issue.
the rest doesn't matter: 4c) not applicable to you 4d1) this is what you would be doing anyway
Possibly, but shared libraries are not easy for a variety of boring, Python-specific, technical reasons.
Ah, that I didn't know.
4e) not applicable to you
Yes, it is. The exception where Installation Information is not required is only when installation is impossible, such as embedded devices where the code is in a ROM chip.
OK, I didn't understand that.
Finally and this is the important point: you would not be passing any requirement to your own users. Indeed, the LGPL license, contrary to the GPL license, does not propagate through dependency chains. So if NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be met when distributing NumPy, but NumPy itself isn't LGPL at all and an application using NumPy does not have to care at all about the LGPL. So there should be no concern at all of "passing on LGPL requirements to users"
No, not at all. The GPL "propagates" by requiring that the rest of the code be licensed compatibly with the GPL. This is an unusual and particular feature of the GPL. The LGPL does not require that rest of the code be licensed in a particular way. However, that doesn't mean that the license of the "outer layer" insulates the downstream user from the LGPL license of the wrapped component. It just means that there is BSD code and LGPL code in the total product. The downstream user must accept and deal with the licenses of *all* of the components simultaneously. This is how most licenses work. I think that the fact that the GPL is particularly "viral" may be obscuring the normal way that licenses work when combined with other licenses.
If I had a proprietary application that used an LGPL library, and I gave my customers some limited rights to modify and resell my application, they would still be bound by the LGPL with respect to the library. They could not modify the LGPLed library and sell it under a proprietary license even if I allow them to do that with the application as a whole. For us to use Eigen2 in numpy such that our users could use, modify and redistribute numpy+Eigen2, in its entirety, under the terms of the BSD license, we would have to get permission from you to distribute Eigen2 under the BSD license. It's only polite.
OK, so the Eigen code inside of NumPy would still be protected by the LGPL. But what I meant when I said that the LGPL requirements don't propagate to your users, was that, for example, they don't have to distribute copies of the LGPL text, installation information for Eigen, or links to Eigen's website.
Yes, they do. They are redistributing Eigen; they must abide by its license in all respects. It doesn't matter how much it is wrapped.
Well this is where I'm not sure if I agree, I am asking the FSF right now as, if this were the case, I too would find such a clause very inconvenient for users.
The only requirement, if I understand well, is that _if_ a NumPy user wanted to make modifications to Eigen itself, he would have to conform to the LGPL requirements about sharing the modified source code.
But is it really a requirement of NumPy that all its dependencies must be free to modify without redistributing the modified source code?
For the default build and the official binaries, yes.
OK.
Don't you use MKL, for which the source code is not available at all?
No, we don't. It is a build option. If you were to provide a BLAS interface to Eigen, Eigen would be another option.
OK, then I guess that this is what will happen once we release the BLAS library. Thanks for your patience Benoit
On 01/18/2010 10:46 AM, Benoit Jacob wrote:
2010/1/18 Robert Kern<robert.kern@gmail.com>:
On Mon, Jan 18, 2010 at 10:26, Benoit Jacob<jacob.benoit.1@gmail.com> wrote:
2010/1/18 Robert Kern<robert.kern@gmail.com>:
On Mon, Jan 18, 2010 at 09:35, Benoit Jacob<jacob.benoit.1@gmail.com> wrote:
Sorry for continuing the licensing noise on your list --- I though that now that I've started, I should let you know that I think I understand things more clearly now ;)
No worries.
First, Section 5 of the LGPL is horrible indeed, so let's forget about that.
I don't think it's that horrible, honestly. It just applies to a different deployment use case and a different set of technologies.
If you were using a LGPL-licensed binary library, Section 4 would rather be what you want. It would require you to: 4a) say somewhere ("prominently" is vague, the bottom of a README is OK) that you use the library 4b) distribute copies of the GPL and LGPL licenses text. Pointless, but not a big issue.
the rest doesn't matter: 4c) not applicable to you 4d1) this is what you would be doing anyway
Possibly, but shared libraries are not easy for a variety of boring, Python-specific, technical reasons.
Ah, that I didn't know.
4e) not applicable to you
Yes, it is. The exception where Installation Information is not required is only when installation is impossible, such as embedded devices where the code is in a ROM chip.
OK, I didn't understand that.
Finally and this is the important point: you would not be passing any requirement to your own users. Indeed, the LGPL license, contrary to the GPL license, does not propagate through dependency chains. So if NumPy used a LGPL-licensed lib Foo, the conditions of the LGPL must be met when distributing NumPy, but NumPy itself isn't LGPL at all and an application using NumPy does not have to care at all about the LGPL. So there should be no concern at all of "passing on LGPL requirements to users"
No, not at all. The GPL "propagates" by requiring that the rest of the code be licensed compatibly with the GPL. This is an unusual and particular feature of the GPL. The LGPL does not require that rest of the code be licensed in a particular way. However, that doesn't mean that the license of the "outer layer" insulates the downstream user from the LGPL license of the wrapped component. It just means that there is BSD code and LGPL code in the total product. The downstream user must accept and deal with the licenses of *all* of the components simultaneously. This is how most licenses work. I think that the fact that the GPL is particularly "viral" may be obscuring the normal way that licenses work when combined with other licenses.
If I had a proprietary application that used an LGPL library, and I gave my customers some limited rights to modify and resell my application, they would still be bound by the LGPL with respect to the library. They could not modify the LGPLed library and sell it under a proprietary license even if I allow them to do that with the application as a whole. For us to use Eigen2 in numpy such that our users could use, modify and redistribute numpy+Eigen2, in its entirety, under the terms of the BSD license, we would have to get permission from you to distribute Eigen2 under the BSD license. It's only polite.
OK, so the Eigen code inside of NumPy would still be protected by the LGPL. But what I meant when I said that the LGPL requirements don't propagate to your users, was that, for example, they don't have to distribute copies of the LGPL text, installation information for Eigen, or links to Eigen's website.
Yes, they do. They are redistributing Eigen; they must abide by its license in all respects. It doesn't matter how much it is wrapped.
Well this is where I'm not sure if I agree, I am asking the FSF right now as, if this were the case, I too would find such a clause very inconvenient for users.
If you obtain the code from any package then you are bound by the terms of that code. So while a user might not be 'inconvenienced' by the LGPL, they are required to meet the terms as required. For some licenses (like the LGPL) these terms do not really apply until you distribute the code but that does not mean that the user is exempt from the licensing terms of that code because they have not distributed their code (yet). Furthermore there are a number of numpy users that download the numpy project for further distribution such as Enthought, packagers for Linux distributions and developers of projects like Python(x,y). Some of these users would be inconvenienced because binary-only distributions would not be permitted in any form. Bruce
participants (4)
-
Benoit Jacob -
Bruce Southey -
David Cournapeau -
Robert Kern