[Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15 (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Sat Jan 28 11:42:02 CET 2006
- Previous message: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
- Next message: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
- Next message: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]