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/
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
