Re: Python 1.6 released and GPL incompatible
On Fri, Sep 08, 2000 at 12:28:54AM +0200, Gregor Hoffleit wrote: Indeed. A dependency may also mean that the package is a binary extension module for the Python interpreter which will be linked dynamically with the interpreter (at some time, when the module is imported). In this case, if the module contains GPL code, I would currently stay away from distributing it with a dependency on Python 1.6. For the record: python-gnome, -gtk, -gdk-imlib and -glade are LGPL so should be okay with python 1.6 I presume. Note that the current packages are neither source nor binary compatible with a newer python. Thanks Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
Gregor == Gregor Hoffleit [EMAIL PROTECTED] writes: [...] Gregor 1) Ignore Python 1.6 and up, as long as the license is not compatible Gregorwith the GPL. That's probably the easiest way to go, but is it Gregorjustified ? Looks like a deliberate discrimination against a GregorDFSG-free license, only because it's not GPL compatible. Gregor 2) Include both Python 1.5.2 and 1.6 in woody/main. The 1.6 packages Gregorwould not satisfy the dependencies of existing packages; any maintainer Gregorwho'd make a package depend on Python 1.6 would have to make sure that Gregorits license is compatible with the Python 1.6 license. Gregor I think I'd prefer the second solution. What do others think ? Sound judgement, I'd say... and from what I gathered on c.l.py, 1.6 isn't that important anyway (they mainly did it because they promised CNRI they'd do 1.6 as a CNRI release). So, let's wait for 2.0 (final, or at least a beta with an improved license) and do that one. Bye, J -- Jürgen A. Erhard[EMAIL PROTECTED] phone: (GERMANY) 0721 27326 MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html Give a man fire and he will be warm for a day. Set a man on fire and he will be warm for the rest of his life. pgpOFPIE3NwTz.pgp Description: PGP signature
Re: Python 1.6 released and GPL incompatible
On Thu, Sep 07, 2000 at 10:47:01AM -0700, Joey Hess wrote: I don't see us making this kind of check for code written in perl, or code wirtten in C, or any other language. Perl is available under two licenses: GPL + Artistic. Not much room for a reasonable person to introduce conflict there. C runtime support (libraries) is typically available under very reasonable terms, for example, the LGPL. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
On Thu, Sep 07, 2000 at 10:47:01AM -0700, Joey Hess wrote: Gregor Hoffleit wrote: 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. Hm, I'm confused. Are you saying that you think that code written in pthon must have a license that is compatable with python's license? I don't see us making this kind of check for code written in perl, or code wirtten in C, or any other language. That's why I wrote that we have to check the packages that _depend_on_Python_ ;-) No need to worry, I don't want to open that can of worms with a discussion about the relation between interpreted code and the interpreter. I don't see this as an issue here. Still the issue is: A dependency on python-base either says that the package has code written in Python and therefore needs a Python interpreter to run. No problem here. Or are you really only talking about packages that dymanically or statically link with python? Indeed. A dependency may also mean that the package is a binary extension module for the Python interpreter which will be linked dynamically with the interpreter (at some time, when the module is imported). In this case, if the module contains GPL code, I would currently stay away from distributing it with a dependency on Python 1.6. Gregor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
Someone wrote this: I am disappointed that RMS is fighting over something as trivial as a company asking that legal issues be settled in their home state (country). This is common practice. I am not fighting, I am pointing out the situation as it exists. I don't believe the CNRI license is inherently bad. It is a reasonable free software license. I have no reason to want to fight. But I believe it is incompatible with the GPL, and that constitutes major practical problem. CNRI agrees that this would be a problem--they want to make it possible for GPL-covered programs to use Python. So we are not fighting, just disagreeing. Whether a given license A is compatible with another license B is not a decision, not a choice someone can make. It is a judgement about the nature of the situation, based on the facts and laws as they exist. I believe, and the FSF's lawyer believes, that these licenses are incompatible. I can't make the GPL and CNRI licenses compatible just because I wish they were, any more than I can make pi equal 3. However, law and its consequences are not as rigorous as mathematics. It is peculiar that their lawyers think the licenses are compatible. I suspect that they have missed some point about the GPL, but that is just a guess; I have not spoken with them and do not know their arguments. It is conceivable they saw something I and our lawyer missed. We are trying to arrange for him to talk with them. That should at least make it possible for one side to convince the other about whether the licenses are compatible. If they can convince us that the incompatibility we saw is not real, that would be fine--it would make the problem disappear. Alternatively (and I think more likely) our lawyer will show them the incompatibility they did not see. That too might be a step towards solving the problem, or at least I hope so. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
On Wed, Sep 06, 2000 at 11:37:17AM -0700, Sean 'Shaleh' Perry wrote: 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. i'd say it's justified because to do otherwise would cause significant disruption to the debian project - we aren't under any obligation to package free software just because it exists. the selection criterion are, and always have been: a) is it DFSG free?, b) are we allowed to distribute it?, and c) could someone be bothered doing the work to package it? in other words, python is Gregor's package - if he doesn't want to package 1.6 then he doesn't have to. if that's what he decides, then any other debian developer can choose to make python 1.6 packages (as long as they don't bugger up his packages). if nobody chooses to package python 1.6, then it's not in our distribution. no problem. if it was up to me, i'd just ignore the new versions of python until they have a license which is compatible with the GPL. anything else is going to be too much trouble. but it's not my package, and not my decision. 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 that we are going to see more and more cases of GPL incompatibilities as time goes on. we have perfectly good free software licenses already - we have the GPL for those who believe once free, always free, and we have the no-advertising-clause BSD and X11 licenses for those who don't care if their free software is made proprietary. there really is no need for any other free software licenses. there certainly is no need, indeed a compelling anti-need, for new licenses which are incompatible with any or all of these standard free software licenses. this proliferation of new free software licenses (mostly by companies who want the significant PR benefits of jumping on the open-source/free-software bandwagon, but without actually seriously committing to it) is causing significant damage. this practice has to be resisted at every turn. I am disappointed that RMS is fighting over something as trivial as a company asking that legal issues be settled in their home state (country). This is common practice. it's far from trivial. it's an extra restriction in the license, and ANY extra restriction is incompatible with the GPL, regardless of what it is. additional permissions are fine, additional restrictions are not. another significant issue is that the US state of Virginia has adopted the DMCA, so accepting that jurisdiction means accepting all of the onerous terms allowed (and enforced) by the DCMA. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
On Wed, Sep 06, 2000 at 11:37:17AM -0700, Sean 'Shaleh' Perry wrote: I think that we are going to see more and more cases of GPL incompatibilities as time goes on. Agreed; although market forces are driving many software development houses towards Open Source, they're still trying to squirm out of making things free software. I am disappointed that RMS is fighting over something as trivial as a company asking that legal issues be settled in their home state (country). This is common practice. I don't think it's trivial at all. Consider that UCITA is the law of the land in Virginia, which is where CNRI are trying to corral all interpretation of the Python license. If contracts are to be interpreted only by adjudicators that have already been bought by (or otherwise have some bias in favor of) one of the parties, then what you have is a letter of extortion, not a contract. On a far more pragmatic level, it may be impossible for citizens of the state of Iowa to become Python licensees under the terms CNRI and BeOpen have in mind, depending on the details of UCITA and the anti-UCITA measures passed by the Iowa state legislature. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO49486,00.html -- G. Branden Robinson |Murphy's Guide to Science: Debian GNU/Linux|If it's green or squirms, it's biology. [EMAIL PROTECTED] |If it stinks, it's chemistry. http://www.debian.org/~branden/ |If it doesn't work, it's physics. pgpRz6IVTJHGz.pgp Description: PGP signature
Re: Python 1.6 released and GPL incompatible
On Wed, Sep 06, 2000 at 10:49:20PM +0400, Alexey Vyskubov wrote: Pyhton 2.0 is released already. And it doesn't seems that 2.0 solve the license incompatibility... It's not a stable release. bye Christian -- Christian Surchi | [EMAIL PROTECTED] | [EMAIL PROTECTED] FLUG: http://www.firenze.linux.it | Debian GNU/Linux: http://www.debian.org - http://www.firenze.linux.it/~csurchi -- These days the necessities of life cost you about three times what they used to, and half the time they aren't even fit to drink. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
On Wed, Sep 06, 2000 at 09:50:07PM -0500, Branden Robinson wrote: On Wed, Sep 06, 2000 at 11:37:17AM -0700, Sean 'Shaleh' Perry wrote: I am disappointed that RMS is fighting over something as trivial as a company asking that legal issues be settled in their home state (country). This is common practice. I don't think it's trivial at all. Consider that UCITA is the law of the land in Virginia, which is where CNRI are trying to corral all interpretation of the Python license. If contracts are to be interpreted There's also the fact that IP rights work much better if you make an effort to enforce them. (IANAL, of course) -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
Gregor Hoffleit wrote: 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. Hm, I'm confused. Are you saying that you think that code written in pthon must have a license that is compatable with python's license? I don't see us making this kind of check for code written in perl, or code wirtten in C, or any other language. Or are you really only talking about packages that dymanically or statically link with python? BTW, welcome to slashdot and linuxtoday. :-P -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
On Wed, Sep 06, 2000 at 11:43:21AM +0200, Gregor Hoffleit wrote: 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. Yup, that sounds bad. 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. Install in a parallel tree (/usr/lib/python1.6, e.g) and use alternatives to manage /usr/bin/python, so that someone can install 1.5 and 1.6 side-by-side. This would be my favoured solution. Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
Gregor Hoffleit [EMAIL PROTECTED] writes: 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). [...] 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. 2) Include both Python 1.5.2 and 1.6 in woody/main. As long as all the Debian packages that depend on Python work with Python 1.5 I wouldn't put two Python versions into Debian. Also Python 2.0 will probably be released before the next code freeze and solve the license issues. In my opinion things should be kept as simple as possible. By the way, there's another problem. The modules socket, httplib and urllib may now be build with SSL support. What to do about these modules and the source package? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Python 1.6 released and GPL incompatible
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 that we are going to see more and more cases of GPL incompatibilities as time goes on. I am disappointed that RMS is fighting over something as trivial as a company asking that legal issues be settled in their home state (country). This is common practice. Anyways, back to the issue at hand. What are the chances that ignoring 1.6 for say, 3 months will result in a 2.0 that we can actually use? Python 1.5 is solid and usable, 1.6 is not going to change anything that drastically. Chances are that we won't freeze before then, so you could work out with the rest of the python packagers a coordinated upload. You will likely have to support python 1.5 thru this release and drop it for the next, so adding yet another version would not be too healthy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
Python 1.5 I wouldn't put two Python versions into Debian. Also Python 2.0 will probably be released before the next code freeze and solve the license issues. Pyhton 2.0 is released already. And it doesn't seems that 2.0 solve the license incompatibility... Am I wrong? I hope I am... :( -- Alexey Vyskubov (at home) Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
