Grzegorz B. Prokopski wrote:
If you at least went on and read next paragraph of the FAQ from which you took the above. http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL "However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way."
Which part of "other facilities" do you fail to comprehend?A GPLd intrepreter can not, because of what the GPL and copyright law actually say, instead of what you may wish they said, impose restrictions of the GPL unto the data it interprets. It can bind to *itself* until it gets blue in its face, but *the interpreter* still can't impose restrictions on its *input* or *use*.
The clause is there to state that even though a work A may be used on a GPLd interpreter, the GPL of the interpreter does not 'preempt'/fullfill the GPL of other works that A derives from. In simple words, for you, so that you can finally get it: You can't create a work that derives from a GPld work, and use a GPLd interpreter to work around the GPL of the work your work derives from, because the interpreter has no business in shielding you from it, even though it doesn't 'propagate' its own GPL on your work that you are using with it.
Confusing? That's probably why the FSF put it in a FAQ. I guess someone tried to circumvent the GPL using a GPLd interpreter to 'shield' them, and then the FSF had to make sure people understood how things work.
How Kaffe, the GPld interpreter, goes about loading GPLd parts of *itself* into memory, whether it uses JNI, KNI, dlopen, FFI, libtool, or other "bindings", or whether it asks the user to tilt switches on an array of light bulbs is irrelevant to the copyright law. The GPld interpreter still can't impose restrictions on its input or use. Just like a GPLd garbage collector going off in the background of my text editor when I'm composing a reply doesn't suddendly make this reply message GPLd.
Now, before you go off ranting about Kaffe's native libraries, please take a moment to let the fact sink in that while these native libraries are the result of Kaffe developers being a somewhat clever bunch at developing software and having heard about benefits of seperating one's program into sepearte modules, those modules are nevertheless *a part of the interpreter*, and as the copyright law law says, the GPLd interpreter can't impose restrictions on its input. They even get compiled in statically on Debian for debian's kaffe package.
Would you please, please stop regurgitating this nonsense. The FSF's FAQ is perfectly fine. It's your casual reading of it that it wrong.
cheers, dalibor topic