Andrew Suffield wrote:
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]).
I considered this briefly, but the result of any such process is never copied or distributed[0], so copyright isn't directly applicable at all - we don't need to worry about it.
When you distribute the VM *and* the class libraries, most of the time the VM does really depend on the class library to be able to do its job (which is executing bytecode programs), so from a copyright law point of view, one could argue that the vm core and the class libraries form a combined work. I know of few jvm's that can use different class libraries (for core java classes) published by various providers interchangeably; so if you apply your "rule of thumb", kaffe and its class library do form a combined work. Of course, if you modify Kaffe so that it has a well defined "class-library/vm interface" and get it to work with various class library implementations (e.g. kaffe-class-lib and gnu-classpath), then they can be considered independent works. [In fact, Dalibor seems to be working on making Kaffe+classpath working together; ... but I do not know if he does it in a way that the interface is really well defined, making Kaffe independent of its class library. ;-)]
As for a JIT, the same applies; OpenJIT (I think that is its name) was developed to be jvm independent, but usually *most* JITs are really tied to a specific jvm.
So, if you distribute a jvm which has its own jvm-specific JIT written in Java, applying your rule of thumb we can deduce that the JIT is not merely *input* to the jvm, as in fact, the JIT *does* depend on this specific vm, so they form a combined work[0]. If such a jvm was licensed under the GPL, it would be necessary for the JIT to be license compatible.
In other words, all I am suggesting is to apply uniformely your rule of thumb (RoT), and let aside the fact that JIT is "executed" by the vm or not (as we let aside "linking") as not to abscure the discussion with irrelevant issues. So, some JITs are a derivative work of the JVM, and some others are not (based on your RoT).
Have fun[1]!
Etienne
[0] In fact, a jvm could *also* be dependent on the JIT if it fails to start execution when the JIT (written in Java) is missing.
[1] FYI, I do not intend to pursue this thread of argumentation for long, as it is currently irrelevant to Debian, and I (as you) have more important things to do than argue about hypothetical situations. :-)
-- 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]