Ronald Oussoren wrote:
> You have a point there.  I'm not entirely convinced though, the argument
> that Python would be a derived work of libffi's aclocal.m4 when libffi
> were included in the Python repository seems very weak to me.

The GPL says "contains or is derived from". Clearly, "identifiable
parts" of Python are not derived from aclocal.m4. However, the work
as a whole (i.e. the entire Python distribution) then becomes derived
work of libffi, and aclocal.m4.

> It is a good argument to just drop libffi's configure script and  integrate
> the functionality of it in the main python configure script. That would
> remove all possible doubt and shouldn't be too much work.

Several autoconf people have argued that this aclocal.m4 is a mistake,
and that the intention was that it shouldn't be GPL-licensed. So if we
cannot find a volunteer to rewrite the build process of libffi for
use in Python, that would also be a strategy (but one that probably
takes many months to complete).

I would personally drop the use of automake (and just rely on autoconf),
and then the need for aclocal would go away.

> BTW. The argument that the readline module should be GPL licensed seems
> rather stronger, it's designed to work with a GPL-ed library and doesn't
> work with a BSD licensed work-alike of that library.

This is the question what constitutes derivative work, and different
lawyers have said different things in the past. If we really want to
find out, we should ask a lawyer.

IANAL, and my understanding is that
a) we don't include readline in the Python distribution, so the
   Python source code cannot be derivative work. In U.S. copyright law,
   the term is apparently defined as

    "any . . . work [that] may be recast, transformed, or adapted. A
    work consisting of editorial revisions, annotations, elaborations,
    or other modifications which, as a whole, represents an original
    work of authorship, is a 'derivative work.'"

   http://www.chillingeffects.org/derivative/

   I would argue that Modules/readline.c does *not* represent the
   original work of authorship (i.e. libreadline).

   Of course, the GPL says "derived", not "derivative", and doesn't
   define the term, so you should ask your lawyer; ultimately, a
   court might decide what it means.

b) if we were to distribute binaries of Python, this issue would
   yet again be different: it seems that a binary readline module
   (builtin or not) is derivative work of the readline library,
   whether it is dynamically linked with that library or not.
   So anybody distributing such a binary might have to distribute
   it under the terms of the GPL.

   I say "might" because there is an exception in the GPL for
   major components normally distributed with the operating
   system. On those systems where Python's readline module is
   available, the readline library could be considered a part of
   the operating system. To be sure, ask your lawyer; ultimately,
   a court might decide whether this clause is relevant here.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to