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

Re: Pyton 1.6's license



>>>>> "KK" == Ken Kinder <kkinder@tridog.com> writes:
    KK> I'm a little worried about Debian not packaging Python 1.6
    KK> because RMS feels so strongly (it's RMS) that it isn't
    KK> compatible with GPL. I release Python GPL code and don't feel
    KK> it's incompatible, but it could be damaging to either Debian,
    KK> Python, or both if it can't be packaged.  Can't Python 1.6 be
    KK> licensed under more than one license like Perl?

    
Just a word of clarification from the Debian Python maintainer:


The Python 1.6 license is completely fine for Debian; it's perfectly free
software (RMS admits that, too).

The point is that it's different than the old Python license, and therefore
some things that were fine with the old Python now seems to become illegal
(at least that's what RMS's impression is).

Debian has no big war chest. If some author claims that he regards
distribution of binaries of his GPL code linked code under the new Python
license as illegal, then this is a kind of legal threat that we have to take
seriously. Debian doesn't want to get involved in a legal action on this
ground, and therefore I think our safest bet is to stay away from
distributing GPL code linked with Python 1.6 code. At least as long as the
issue is settled (which I still have hope will happen with before the
release of 2.0).

Based on this, that leaves us with three options:

1.) Replace Python 1.5.2 with Python 1.6 in the Debian development tree
  ("woody").

  Then we had to remove all packages that might be troublesome,
  license-wise. Among them are python-gdbm, python-gtk, python-gnome,
  python-glade. Would also affect codecommander, solfege, bg5ps, icepref,
  routeplanner, gimp-python and so on. I.e. quite some work to check and
  discriminate among all of them.

2.) Stick with Python 1.5.2 and ignore Python 1.6 and up until this issue is
  settled.

  The easiest solution. Many propose that.  

  Anyway, if the issue is not settled in the near future, that would more or
  less automatically mean a fork of Python at some time, a VERY bad thing.
  
3.) Stick with Python 1.5.2 and package Python 1.6 as optional packages
  (something like python1.6-base etc. pp.) that could be installed parallel
  to Python 1.5.2.

  All existing packages would continue to depend on Python 1.5.2, with no
  license trouble.

  Maintainers and users would have to decide if their application/package is
  compatible with the new Python license.


You see that Debian has nothing against the new Python 1.6 license; it's
just a matter of labour involved to implement the consequences of the new
license in our distribution.


OTOH, a resolution of the discussion about the compatibility of the licenses
would help us very much.

  
Based on the experience with KDE, I'd request that authors of GPL code that
think that it's fine to link the code with code under the Python 1.6
license, do add a short note to their copyright plate that declares that the
code is licensed under the GPL with the amendment that it's ok to link the
code with Python 1.6 code. Don't ask me how to spell this in a legally
meaningful way ;-)

    Gregor
    


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


Reply to: