Menu
▾
▴
jython-dev
|
From: Ben B. <be...@ac...> - 2001-07-01 19:45:29
|
Hi. I'm currently looking at packaging Jython for debian and I'm wondering what the current status is with the Jython license. At the moment it seems the Jython license is incompatible with the GPL. According to the FSF website (http://www.gnu.org/philosophy/license-list.html): The License of Python 1.6b1 and later versions, through 2.0 and 2.1. This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the State of Virginia, in the USA, and the GPL does not permit this. The license for Jython, as found on www.jython.org and in the CVS, currently contains this GPL-incompatible clause. CPython has recently altered their license to make CPython compatible with the GPL (http://www.python.org/2.0.1/). Is Jython likely to follow suit? Thanks, Ben. -- Ben Burton be...@ac... | ba...@de... http://baasil.humbug.org.au/bab/ Public Key: finger ba...@de... I don't have a computer. I stay away from the internet mainly because I don't want to know what color underwear I was wearing during sound-check. I just don't want to know. - Tori Amos |
|
From: <bc...@wo...> - 2001-07-01 20:47:23
|
[Ben Burton] >Hi. I'm currently looking at packaging Jython for debian and I'm wondering >what the current status is with the Jython license. At the moment it seems >the Jython license is incompatible with the GPL. Correct, I think. >According to the FSF website >(http://www.gnu.org/philosophy/license-list.html): > >The License of Python 1.6b1 and later versions, through 2.0 and 2.1. >This is a free software license but is incompatible with the GNU GPL. The >primary incompatibility is that this Python license is governed by the laws >of the State of Virginia, in the USA, and the GPL does not permit this. > >The license for Jython, as found on www.jython.org and in the CVS, currently >contains this GPL-incompatible clause. CPython has recently altered their >license to make CPython compatible with the GPL >(http://www.python.org/2.0.1/). > >Is Jython likely to follow suit? I somehow doubt it. Not only must CNRI be prepared to release their JPython-1.1 code with a changed license, but they must also be able to actually create a new release. It is not my impression that any of the fine people working at CNRI have the tools or experience to create a JPython-1.1.1 release. Even if is 10 times easier for jython to change license that it was for python, I still think it will be 100 times too much work for me to tackle. regards, finn |
|
From: Ben B. <be...@ac...> - 2001-07-02 17:25:50
|
Hi - thanks for your reply. > >Is Jython likely to follow suit? > > I somehow doubt it. Cool. One thing I should mention though is that there may be issues with readline support (org.python.utils.ReadlineConsole) - Bablok's wrappers are LGPL but they link with GNU libreadline which is GPL. Thus (according to my understanding which could be wrong), this would require jython - if built with ReadlineConsole - to be GPL-compatible. Sorry, not trying to nitpick here but in packaging jython up for Debian one must take care to ensure that everything is legal. :) Thanks, Ben. -- Ben Burton be...@ac... | ba...@de... http://baasil.humbug.org.au/bab/ Public Key: finger ba...@de... The man who sees both sides of a question is a man who sees absolutely nothing at all. - Oscar Wilde |
|
From: <bc...@wo...> - 2001-07-02 18:26:00
|
[Ben Burton]
>One thing I should mention though is that there may be issues with readline
>support (org.python.utils.ReadlineConsole) - Bablok's wrappers are LGPL but
>they link with GNU libreadline which is GPL. Thus (according to my
>understanding which could be wrong), this would require jython - if built
>with ReadlineConsole - to be GPL-compatible.
Perhaps, but that is not my understanding.
- ReadlineConsole is neither GPL or LGPL
- There is no LGPL or GPL code in the jython distribution.
- Jython only links with the readline (L)GPL code when option
python.console=org.python.util.ReadlineConsole
is enabled.
So in the distributed form, jython doesn't links with any (L)GPL code.
If anyone installs bablok's Readline class and libreadline and changes
the python.console option they are creating a derivative work which they
do not have the right to distribute.
>Sorry, not trying to nitpick here but in packaging jython up for Debian one
>must take care to ensure that everything is legal. :)
Absolutely.
I have somehow considered ReadlineConsole to be similar to CPython-2.0's
readline.c file. In itself readline.c did not require CPython to be GPL
compatible.
OTOH I'm all ears for input from the authors of the readline software or
from the FSF lawyers. If there is a real problem with including the
ReadlineConsole, I can easily rip it out.
regards,
finn
|
|
From: Ben B. <be...@ac...> - 2001-07-02 19:01:14
|
> - ReadlineConsole is neither GPL or LGPL http://www.bablokb.de/java/readline.html, first paragraph: "It is distributed under the LGPL." Although there should be no problem linking LGPL stuff with jython, it's the GPLed libreadline.so that gets linked along with it that concerns me. > So in the distributed form, jython doesn't links with any (L)GPL code. > If anyone installs bablok's Readline class and libreadline and changes > the python.console option they are creating a derivative work which they > do not have the right to distribute. So what's to stop me taking the GPLed fastlib.so, making a new proprietary library superfastlib.so that links to fastlib.so but contains my modifications, and then selling superfastlib.so but requiring users to download fastlib.so themselves; thus I'm not distributing the GPLed code myself but I still get the benefit of having a proprietary derivative work as such. i.e. I believe the claim you make defeats the purpose of GPLing a library. Of course I could be very much mistaken. I am not at all well versed in licensing details. I don't say any of this because I am confident that I'm correct; I merely say it for the purpose of opening (what I believe is necessary) discussion on the issues. http://www.fsf.org/copyleft/gpl-faq.html#GPLPluginsInNF This also suggests to me that the readline plugin to Jython cannot be used, i.e. sure, you can distribute support for the plugin but nobody should be allowed to use it (and hence there's no reason to distribute support for it). > I have somehow considered ReadlineConsole to be similar to CPython-2.0's > readline.c file. In itself readline.c did not require CPython to be GPL > compatible. As I understand it, at least the debian python2 release disabled readline support because of the GPL-incompatibility issue. IANAL, in fact I know very little about legal matters; these are just my thoughts that I'm throwing in. If you like I can raise the issue on deb...@li... and see what they have to say. Ben. -- Ben Burton be...@ac... | ba...@de... http://baasil.humbug.org.au/bab/ Public Key: finger ba...@de... I don't feel a part of any kind of sisterhood. Again, it's the most disappointing thing where I get criticized by women more than men on how I play the piano. They find it offensive. I'm just going, well, this is how I choose to express myself, so if you're truly a strong, independent woman, then how could you possibly find me being a strong, independent woman offensive? - Tori Amos |
|
From: <bc...@wo...> - 2001-07-02 19:54:51
|
[Ben Burton] >> - ReadlineConsole is neither GPL or LGPL > >http://www.bablokb.de/java/readline.html, first paragraph: "It is distributed >under the LGPL." Although there should be no problem linking LGPL stuff with >jython, it's the GPLed libreadline.so that gets linked along with it that >concerns me. No. The LGPL covers the Readline.java class and friends. It does not cover ReadlineConsole.java. That file is clearly based on a copy of some CNRI software and I don't believe Bablok have ever tried to put LGPL on something that was initially written by CNRI. It may not change the issue much but it does add another degree of separation. >> So in the distributed form, jython doesn't links with any (L)GPL code. >> If anyone installs bablok's Readline class and libreadline and changes >> the python.console option they are creating a derivative work which they >> do not have the right to distribute. > >So what's to stop me taking the GPLed fastlib.so, making a new proprietary >library superfastlib.so that links to fastlib.so but contains my >modifications, and then selling superfastlib.so but requiring users to >download fastlib.so themselves; thus I'm not distributing the GPLed code >myself but I still get the benefit of having a proprietary derivative work as >such. Note that we does not *require* people to download a GPL library. Jython works completely fine without. >i.e. I believe the claim you make defeats the purpose of GPLing a library. >Of course I could be very much mistaken. I am not at all well versed in >licensing details. I don't say any of this because I am confident that I'm >correct; I merely say it for the purpose of opening (what I believe is >necessary) discussion on the issues. > >http://www.fsf.org/copyleft/gpl-faq.html#GPLPluginsInNF > >This also suggests to me that the readline plugin to Jython cannot be used, >i.e. sure, you can distribute support for the plugin but nobody should be >allowed to use it (and hence there's no reason to distribute support for it). I though GPL only covered copying, distribution and modification. Maybe changing the python.console property is considered a modification? >> I have somehow considered ReadlineConsole to be similar to CPython-2.0's >> readline.c file. In itself readline.c did not require CPython to be GPL >> compatible. > >As I understand it, at least the debian python2 release disabled readline >support because of the GPL-incompatibility issue. Right. The same would surely be necesary in the case of Jython. There is absolutely no way a binary readline <-> jython combination could be released. Did the debian release include the source for readline.c? If it did then jython can surely include the source for ReadlineConsole.java. Maybe the binary version of ReadlineConsole.class is a violation of GPL. I'm not sure how GPL view the way java compiles and links between classes. Would using reflection to find and call two functions named "Readline.readline" and "Readline.initReadline" also be a violation? >IANAL, in fact I know very little about legal matters; these are just my >thoughts that I'm throwing in. If you like I can raise the issue on >deb...@li... and see what they have to say. I dunno. I'm not familiar with the S/N level on debian-legal. Also, I'm not all that interested in whether debian can include jython. I'm more interested in whether jython can include ReadlineConsole. I don't know if debian-legal is the right place to ask that question. regards, finn |
|
From: Ben B. <be...@ac...> - 2001-07-02 20:10:14
|
> No. The LGPL covers the Readline.java class and friends. Sorry, my mistake - I read ReadlineConsole as Readline. I actually realised this halfway through writing and thought I deleted that paragraph; it would seem not. :) > Right. The same would surely be necesary in the case of Jython. There is > absolutely no way a binary readline <-> jython combination could be > released. Did the debian release include the source for readline.c? If > it did then jython can surely include the source for > ReadlineConsole.java. Indeed, debian includes readline.c and the corresponding jython debian package would probably include ReadlineConsole.java since it's part of the sourceball. My concern is that I don't believe I would be able to include ReadlineConsole.class in the packaged jar. > I dunno. I'm not familiar with the S/N level on debian-legal. Sorry, what's S/N? I don't know if this answers your question but debian-legal is relatively low-traffic and tends to be almost all serious postings. Flamewars tend to stay on debian-devel. :) > Also, I'm not all that interested in whether debian can include jython. I'm > more interested in whether jython can include ReadlineConsole. My concern is the same as yours. Debian can certainly include jython regardless; its license is well within the bounds of the debian policy. My concern is whether I can include readline support in the jython package. And one would presume that the legality of packaging ReadlineConsole.class does not differ between debian and your official Jython installer. > I don't know if debian-legal is the right place to ask that question. They certainly wouldn't mind. And it wouldn't be off-topic because jython is being prepared for debian packaging. At any rate, the worst you will have is more input. :) I'd certainly trust what I read on debian-legal far more than what comes out of my own mouth. Ben. -- Ben Burton be...@ac... | ba...@de... http://baasil.humbug.org.au/bab/ Public Key: finger ba...@de... Courage is the power to let go of the familiar. - Proverb |
|
From: <bc...@wo...> - 2001-07-05 20:34:47
|
[Ben Burton] >> [...] I'm not familiar with the S/N level on debian-legal. > >Sorry, what's S/N? I don't know if this answers your question but >debian-legal is relatively low-traffic and tends to be almost all serious >postings. Yes, that answers my questions. The responses have answered it even better <0.3 wink>. >> Also, I'm not all that interested in whether debian can include jython. I'm >> more interested in whether jython can include ReadlineConsole. > >My concern is the same as yours. Debian can certainly include jython >regardless; its license is well within the bounds of the debian policy. My >concern is whether I can include readline support in the jython package. Right. >And >one would presume that the legality of packaging ReadlineConsole.class does >not differ between debian and your official Jython installer. Heh. That assumes that legal interpretation is somehow final. We all (should) know that it isn't. I still believe that 2.1a1 is within the acceptable use of LGPL/GPL code. Other people may believe otherwise and act accordingly. As always in human affairs there are approximately as many views as there are people. Some will believe that the intend of the GPL matters above all, others will believe that the letter of the GPL carries the final word. I think the answer is somewhere in between. I feel the current use of LGPL software is acceptable and in accordance with the letter but I'm open to input from the authors of the software and/or GPL. I'm also open to the public opinion; jython is part of the open source world and it should play nice with other free/open source projects. regards, finn |
|
From: <ba...@di...> - 2001-07-02 19:43:39
|
>>>>> "BB" == Ben Burton <be...@ac...> writes:
BB> The license for Jython, as found on www.jython.org and in the
BB> CVS, currently contains this GPL-incompatible clause. CPython
BB> has recently altered their license to make CPython compatible
BB> with the GPL (http://www.python.org/2.0.1/).
BB> Is Jython likely to follow suit?
The Python Software Foundation is trying to figure out a way to effect
the same licensing changes on Jython as were recently accomplished for
Python 2.0.1, 2.1.1, and 2.2. IOW, GPL compatibility.
It's way to early to tell (which is why I haven't mentioned it here,
or even to Finn yet), but suffice to say that it would be A Good Thing
if we could accomplish this. It might require Finn and Samuele to
sign some form of disclaimer to the PSF, but even that hasn't
determined yet.
Given the length of time it took to get a GPL compatible license for
(C)Python, I wouldn't expect anything any time soon. But I'm hoping
that it will eventually be possible, without much effort from Finn
(who should be left to manage the technical side of things and not
worry about this nonsense. ;). The goal is to eventually place Jython
under the same license as CPython 2.0.1, etc.
-Barry
|
