Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
Andrew Suffield wrote:
Kaffe is essentially a filter that takes java
bytecode as input and emits program code on the fly (this is
technically incomplete, but effectively equivalent for the sake of
this argument). The input to a filter cannot be a derivative work of
it; we don't *care* about the state of the output (which is also not a
derivative work in this case, but I'll skip the reasoning).
I can live with this view (even though an argument could be made about
the fact that many VMs (I do not know specifically about Kaffe) internally
use bytecodes from the class library to handle internal data structures
[think of a just-in-time compiler written in Java; it would really be
part of the VM, not merely processed input, IMHO]). So, we can ignore
the issue. In all cases, this is not a problem that Debian has to care
about in the case of Kaffe, its class library being under the GPL anyway.
The question that remains is presumably "Is java bytecode a derivative
work of the class libraries used for it?"
Yes. I think I will not need to write a summary of the debian-java discussion
as this question summarizes the problem. Your argument below addresses this
question quite thoroughly.
This is more or less a FAQ, albeit in a slightly different form; it's
the old question about library interfaces and the GPL. Here's the rule
of thumb that I use for software:
If work A requires work B in order to function, A is a derivative
work of B.
...
A given java program does not require this class library in order to
function, because it will also work with a range of other class
libraries from different vendors, and therefore is not a derivative
work. Therefore, the GPL does not cross this so-called "interface
boundary".
OK. I can agree with this, as long as we keep the "a range of other class
libraries from *different* vendors" statement. Otherwise, it would be too
easy for a *single* party to simply modify similarly a few of GPLed Free
VMs to declare a change in the "interface boundary". [I am pretty sure that
this could be seen as an obvious machination to go around the terms of the
license and would be ruled as infrigement in a Canadian court. But IANAL. ;-)]
The way I see it is: Debian should try to stay on the *safe* side of things,
license wise. So, using the rule of thumb you proposed above seems quite
reasnable to me. Is there a consensus on debian-legal about this rule?
If yes, I would think the argument to be settled (unless some other debian-java
people want to continue arguing).
Note that this does not apply if the program uses features specific to
kaffe.
This is something debian-java should probably state in the java policy; package
maintainers should also make sure to take this into account when looking at
license compatibility of application/VM.
Thanks a lot, Andrew, for this comprehensive answer. Repeating myself: as long
as there is a consensus on debian-legal about the rule of thumb outlined above,
I think the argument is settled. Could somebody confirm this fact?
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Reply to: