RetroSearch Browse

Sat Apr 22 02:58:44 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-April/064154.html

On 4/21/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
   ...
> > GMP is covered by LGPL, so must any such derivative work
>
> But the wrapper is just using GMP as a library, so
> it shouldn't be infected with LGPLness, should it?

If a lawyer for the PSF can confidently assert that gmpy is not a
derivative work of GMP, I'll have no problem changing gmpy's
licensing. But I won't make such a call myself: for example, gmpy.c
#include's gmp.h and uses (==expands) some of the C macros there
defined -- doesn't that make gmpy.o a derived work of gmp.h?

I'm quite confident that the concept of "derived work" would not apply
if gmpy.so only accessed a gmp.so (or other kinds of dynamic
libraries), but I fear the connection is stronger than that, so,
prudently, I'm assuming the "derived work" status until further
notice.

Alex

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-April/064154.html below:

[Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.