Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Grzegorz B. Prokopski wrote:
Your email messages do not contain calls to GPLed functions, do they?
Depends on the message :)
But that's not the point. The point is that the mere existance of a
chunk of non GPL-compatible memory within a GPLd proces' memory does not
necessarily constitute a GPL infringement. It depends on what the
program does. My text editor's GPL is not violated just because I happen
to load GPL inompatibly licensed files with it into its proces' memory,
edit them, and save them. Neither does that coexistance of GPLs and
non-GPLd works in the same process space let my GPLd text editor impose
its GPL on the files I edit with it, because no GPLd part of the editor
ends up in the files I save.
Brian was asserting that coexistance in process memory alone of GPLd and
non-GPLd works costituted a GPL infringement. That's certainly not the
case. It would be pretty hard to apt-get non GPL-compatibly licensed
packages, otherwise :)
It's quite a stretch to compare "dead data", like text, with something
as dynamic, as bytecode, which not only can be created, modified,
translated or interpreted by a JVM, but it can also explicitely make
use of JVM functionality (which happens to be GPLed in case of GPLed
An interpreter acts like a filter to its input. The GPL gives no hand to
the author of a GPLd interpreter to put restrictions on the data it is
used with. That interpretation of the GPL would render it non-DFSG-free,
by imposing a restrictions to running GPLd programs only on
GPL-compatibly licensed data. The GPL's text doesn't make such demands.
There is no such thing as "dead" data to an interpreter. Whatever data
you feed to Kaffe, for example, it does something lively with it, like
print an error message, crash (well, i haven't tested all possible data
streams, so I better assume it), or interpret it, depending on the data.
What sort of functionality of the GPLd interpreter is used by the
bytecode during its execution, is irrelevant to the fact that the GPLd
interpreter can not put restrictions on its input. No matter how
convulted a linking scheme the interpreter uses, it can't get
'Super-GPL-Powers' that would allow it to impose the GPL on its input
through the act of the input being run on it.
Any Java bytecode makes explicit use of JVM functionality through
sequences of small byecode-langiage commands like 'invokevirtual',
'add', 'sub', 'dup' and so on. The fact that the bytecode is run on a
GPLd interpreter does not let the intepreter impose the GPL on its data,
just because the implementation of 'add' in that interpreter is GPLd.