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-incompatiblesoftware 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
Attachment:
Hello.class
Description: application/java-vm