[Numpy-discussion] performance matrix multiplication vs. matlab

[Robert Kern]

On Mon, Jan 18, 2010 at 09:35, Benoit Jacob <jacob.benoit.1 at 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