Subject: Python 1.6 released and GPL incompatible
Date: Wed, 6 Sep 2000 11:43:21 +0200
From: Gregor Hoffleit
To: debian-devel@lists.debian.org
Python 1.6 was released finally today (for an announcement, see
http://www.python.org/1.6/), and it was released under the discussed
CNRI license. This license was intended to be compatible with the
GPL, but RMS says he thinks it's not (cf. the announcement).
Moments later, Guido and BeOpen's PythonLabs released Python 2.0b1,
under the same license terms so far.
AFAIK, there were consultations until the last mintue between CNRI,
FSF (i.e. RMS and his law consultant Prof. Moglen) and BeOpen,
moderated by Guido, but they were not able to settle the question in
time for a timely release of Python 1.6. Therefore, Guido decided in
order to not delay the work on 2.0 (which is supposed to come out
later this year), that 1.6 would be released under this imperfect
license, and 2.0b1 as well.
The consultations will go on, and there's still hope that a
settlement between RMS and CNRI will be found that produces a
license that's compatible with the GPL. If this succeeds, Python 2.0
would be released under this license.
This opens the question what Debian should do with Python 1.6:
I'll ask debian-legal for a comment about the CNRI license. AFAICS,
it's a fair DFSG-free license otherwise, so we could include Python
1.6 in woody/main.
Still, if 1.6 were to replace 1.5.2, we had to check all packages
that depend on Python, if we think their license is still compatible
with the new Python license, and remove them if it's not. I'd opt
against this.
That leaves me with two possible solutions:
1) Ignore Python 1.6 and up, as long as the license is not compatible
with the GPL. That's probably the easiest way to go, but is it
justified ? Looks like a deliberate discrimination against a
DFSG-free license, only because it's not GPL compatible.
2) Include both Python 1.5.2 and 1.6 in woody/main. The 1.6 packages
would not satisfy the dependencies of existing packages; any
maintainer who'd make a package depend on Python 1.6 would have to
make sure that its license is compatible with the Python 1.6
license.
I think I'd prefer the second solution. What do others think ?
Gregor
For more
information on the CRNI license, see here.
Guido van Rossum of PythonLabs responds to Python licensing
issues.