On Mon, Feb 05, 2001 at 04:45:57PM -0500, Andrew Kuchling wrote:
> A more critical issue might be why people haven't adopted 2.0 yet;
> there seems little reason is there to continue using 1.5.2, yet I
> still see questions on the XML-SIG, for example, from people who
> haven't upgraded. Is it that Zope doesn't support it? Or that Red
> Hat and Debian don't include it? This needs fixing, or else we'll
> wind up with a community scattered among lots of different versions.
Sorry, I only got aware of this discussion when I read the recent python-dev
summary. Here's the official word from Debian about this:
Debian's unstable tree currently includes both Python 1.5.2 as well as 2.0.
Python 1.5.2 things are packaged as python-foo-bar, while Python 2.0 is
available as python2-foo-bar. It's possible to install either 1.5.2 or 2.0
or both of them.
I have described the reasons for this dual packaging in
/usr/share/doc/python2/README.why-python2 (included below): it's mainly
about
(a) backwards compatibility and
(b) the license issue (the questionable GPL compatibility of the new
license).
The current setup shows a preference for the Python 1.5.2 packages:
python1.5.2 is linked to /usr/bin/python, while python2.0 is linked to
/usr/bin/python2; a simple upgrade won't install Python 2.0, but will stick
with Python 1.5.2.
Furthermore, python-base is now a "standard" package in Debian woody (will
be installed by default on most systems!), while python2-base is only
"optional".
I made this setup to enforce maintainers of other packages to check if their
package was compatible with Python 2.0, and--important as well--if they
thought that the license of their package was compatible with the new Python
license.
(a) is clearly only a temporary issue (with Zope being a big point
currently) and will go away over the time.
(b) is much more difficult, and won't simply vanish over time.
I know that most of you guys are fed up with license discussions. Still, I
dare to bring this back to your attentions:
Most people seem to ignore the fact that the FSF considers the new Python
license incompatible with the GPL--the FSF might be wrong in fact, but I
think it's not a fair way of dealing with licenses to simply *ignore* their
words.
If somebody could give me a legal advice that the Python license is in fact
compatible with the GPL, and if this was accepted by the guys at
debian-legal@lists.debian.org, I would happily adopt this opinion and that
would make (b) go away as well.
Until this happens, I think the best way for Debian to handle this situation
(clearly not perfect!) is to use a per-case judgement--if there's GPL code
in a package, ask the author if it's okay to use it with Python2 code. If he
says alright, go on with packaging. If he says nogo (as the FSF did for
readline), do away with the package (therefore python2-base doesn't include
readline support).
Gregor
README.why-python2:
------------------
Why python2 ?
-------------
Why are the Debian packages of Python 2.x called python2-base etc. instead
of simply replacing the old python-base packages of version 1.5.2 ?
Debian provides two sets of Python packages:
- python-base etc. provides Python 1.5.2
- python2-base etc. provides Python 2.x.
There are two major reasons for this:
1.) The transition from Python 1.5.2 to 2.0 is not completely flawless.
There are a few incompatible changes in 2.0 that tend to break applications.
E.g. Zope 2.2.5 is not yet prepared to work with Python 2.0. By providing
both packages for Python 1.5.2 (python-*) and Python 2.0 (python2-*), the
transition is much easier.
2.) The license of Python 2.0 has been changed, and restricted in some ways.
According to the FSF, the license of Python 2.x is incompatible with
the conditions of the General Public License (GPL).
According to the FSF, the license of Python 2.x doesn't grant the licensee
enough freedoms to use such code in a derived work together with code
licensed under the GPL--this would result in a violation of the GPL.
Other parties deny that this is indeed a violation of the GPL.
Debian uses a significant portion of GPL code for which the FSF owns
the copyright. In order to avoid legal conflicts over this, the python2-*
packages are set up in a way that no GPL code will be used by default.
It's the duty of maintainers of other packages to check if their license
if compatible with the Python 2.x license, and then to repackage it
accordingly (cf. python2/README.maintainers for hints).
Jan 11, 2001
Gregor Hoffleit <[EMAIL PROTECTED]>
Last modified: 2000-01-11
