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
