Hi! Below is the mail that I sent yesterday to debian-java NOT putting Cc: to d-legal as I thought the issue was really clear to me. After some duscussion that began after my email (see http://lists.debian.org/debian-java/2003/debian-java-200310/msg00107.html ) it was requested to bring it on to debian-legal.
There were some more voices w/ important matters - *please see* the d-j ML archive link given above to see what was said after my initial mail (I don't think copying them all here would make sense). It's mainly about - how far can we go w/ using GPLed java libs and on practical side - how far can we go using Kaffe or similar ones. W liście z śro, 29-10-2003, godz. 17:55, Grzegorz B. Prokopski pisze: > Hi all! > > Summary: Usage of GPLed libs to compile GPL-incompatible code makes > the result *undistributable*. [0] > > Affected java packages: Every package that contains GPL-incompatible > software which was *compiled* using GPLed libs. > > Examples: current Ant package apparently(!) has been compiled w/ Kaffe > libs which are GPLed. See for ex. unpacked current libant1.5-java: > http://www.gadek.homelinux.org/java-illegal/ant/META-INF/MANIFEST.MF > > More discussion (cleaned up IRC log from #kaffe): > http://www.gadek.homelinux.org/java-illegal/gpl-conflicts-log.txt > > Possible actions (no special order): > * Review what java packages (especially the ones that are in "main" > and contain GPL incompatible software) have been compiled with > * Filling RC bugs for packages that seem to be indistributable > * Finding a good way to check/assure what's the license of libs > a package has been compiled with > * Finding a good way to avoid such problems in the future (ex. by > putting some tests into packages' build scripts or by using > an improved version of findjava-like tool that understands > licenses...) > > Problems not touched: *execution* of GPL-incompatible code using > GPLed libs and/or GPLed JVMs is beyond the scope of this message. > > Cheers, > > Grzegorz B. Prokopski > > [0] AFAIK for the same reason KDE was once removed from Debian > completly as linking GPLed code w/ GPL-incompatible license > made it not only violate the license but also made the result > undistributable. There also have been an important reply to my email from one of Kaffe developers, Dalibor Topic which also could use some clarification from legal. W liście z czw, 30-10-2003, godz. 01:51, Dalibor Topic pisze: > Grzegorz B. Prokopski wrote: > > Hi all! > > Hi Grzegorz, > > > Summary: Usage of GPLed libs to compile GPL-incompatible code makes > > the result *undistributable*. [0] > > > > Affected java packages: Every package that contains GPL-incompatible > > software which was *compiled* using GPLed libs. > > > > Examples: current Ant package apparently(!) has been compiled w/ Kaffe > > libs which are GPLed. See for ex. unpacked current libant1.5-java: > > http://www.gadek.homelinux.org/java-illegal/ant/META-INF/MANIFEST.MF > > Well, I'd assume it only means it has been jar-ed with kaffe, but I > don't have deeper knowledge of ant's MANIFEST.MF contents. > > > More discussion (cleaned up IRC log from #kaffe): > > http://www.gadek.homelinux.org/java-illegal/gpl-conflicts-log.txt > > Since I'm one of the guys (dalibor) discussing this with Grzegorz > (gadek) on irc, I guess I should chip in with a comment or two. > > Since kaffe is a) GPLd and b) somewhat useable, people try to do many > things with it. One of them is running programs licensed under a GPL > incompatible license. I do it all the time myself, for example. That's > all fine and well under the scope of the GPL, as GPL doesn't bother > itself with execution, but only poses restrictions on distribution, > modification and copying of works. > > For whatever reason, we get one big 'How does Kaffe's GPL apply to Java > programs' IANAL-thread every 3 months. See for example [2] for the last > discussion (the time between those discussions decreases as kaffe > improves and becomes capable of running more apps). As debian is a > distribution, you have to interpret the GPL in one way or the other. > (And you usually have debian-legal for that ;)) > > There are basically two viewpoints on how GPL affects interpreters: > > A) The FSF[1]: > If a programming language interpreter is released under the GPL, does that > mean programs written to be interpreted by it must be under GPL-compatible > licenses? > > When the interpreter just interprets a language, the answer is no. > The interpreted program, to the interpreter, is just data; a free > software license like the GPL, based on copyright law, cannot limit > what data you use the interpreter on. You can run it on any data > (interpreted program), any way you like, and there are no requirements > about licensing that data to anyone. > > However, when the interpreter is extended to provide "bindings" to > other > facilities (often, but not necessarily, libraries), the interpreted > program > is effectively linked to the facilities it uses through these > bindings. So > if these facilities are released under the GPL, the interpreted > program > that uses them must be released in a GPL-compatible way. The JNI or > Java > Native Interface is an example of such a facility; libraries that are > accessed in this way are linked dynamically with the Java programs > that > call them. > > Another similar and very common case is to provide libraries with the > interpreter which are themselves interpreted. For instance, Perl > comes with > many Perl modules, and a Java implementation comes with many Java > classes. > These libraries and the programs that call them are always dynamically > linked together. > > A consequence is that if you choose to use GPL'd Perl modules or Java > classes in your program, you must release the program in a > GPL-compatible > way, regardless of the license used in the Perl or Java interpreter > that > the combined Perl or Java program will run on. > > B) me (and I guess a few others who are not lawyers, either): > As GPL only really talks about derived works, in order to decide if the > GPL applies to a work we must try to see if the new work is derived from > a GPLd work, or not. > > In my opinion a program that's using widely available APIs to accomplish > its goals is not bound by the license of the interpreter, as it does not > necessarily depend on the GPLd interpreter to run. The GPLd interpreter > is not necessary for the creation of a derived work. Many > GPL-incompatible java programs run just as fine (and sadly, still quite > often somewhat better) on non-free VMs like Sun's VM as on kaffe. > > The case is even weaker, in my opinion, for the point you're trying to > make: for compiling against GPLd widely available runtime APIs (i.e. > JRE). AFAIK, the compiled bytecode is equally well (if you're using the > JRE APIs) capable of running under a non-GPLd VM, whose runtime classes > implement that API. > > As a small test I wrote a 'Hello' test program and compiled it using > jikes against kaffe's rt.jar as the bootclasspath and against JDK > 1.4.2's rt.jar. There is *no* difference in the generated bytecode, > according to GNU diff. I think that an argument which uses copyright law > to allow the same sequence of bits to be licensed under contradictory > licenses depending on the components involved (note that I'm not saying > contained) in the creation of those bit sequences is contradictory in > itself. > > Beside, you have no means to differentiate between a bit-pattern > potentially violating the GPL in this way and the same bit-pattern not > violating the GPL. Is the (let's say ASL 1.1 licensed for the sake of > argument) Hello.class that I have attached to my mail volating the GPL > or not, i.e. has it been compiled against kaffe or not? > > > Possible actions (no special order): > > * Review what java packages (especially the ones that are in "main" > > and contain GPL incompatible software) have been compiled with > > * Filling RC bugs for packages that seem to be indistributable > > * Finding a good way to check/assure what's the license of libs > > a package has been compiled with > > * Finding a good way to avoid such problems in the future (ex. by > > putting some tests into packages' build scripts or by using > > an improved version of findjava-like tool that understands > > licenses...) > > * figure out how you want to interpret the GPL in this case. The rest > follows from that. > > > Problems not touched: *execution* of GPL-incompatible code using > > GPLed libs and/or GPLed JVMs is beyond the scope of this message. > > Here some more food for licensing flamewars bezound the scope of GPL: > > There is an interesting symmetrical case to be tried: provide a 'dummy' > GPLd libc, that does nothing. It would go to main, and you could compile > applications against it, though not run them. Then debian would have to > kick Apache's web server out of main, since it'd be a) incompatible with > the new alternative pure-gpl libc, but b) could be linked to it/would be > implicitely liked to it through a Depends: libc line. > > As another remark, if you think Kaffe's licensing implications are > complicated, take a look at mono: GPL interpreter and LGPLd runtime, X > licensed class library[3]. If the X licensed class library is linked > during runtime to the GPLd interpreter via LGPLd libraries, how come > Ximian is allowed to ship it under the weaker-thank-GPL X license, > thereby apprently violating FSFs position on GPLd interpreters? > > cheers, > dalibor topic > > [1] http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > [2] http://www.kaffe.org/pipermail/kaffe/2003-June/042838.html > > [3] http://www.go-mono.com/faq.html#licensing Best regards Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org
