Python 1.6 GPL incompatible?

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.