[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Python 1.6 released and GPL incompatible



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


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: