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 JVMs).
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.
cheers, dalibor topic