Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
Hi Andrew,
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/
Reply to: