Re: Illustrating JVM bindings
Grzegorz B. Prokopski wrote:
I would then just take the GPLed code of this GC library, GPLed code
of readline, cut out the pieces I need, integrate into my interepreter
and call it "interepter features". Thus, according to you, my
GPL-incompatible program would be able to use GPLed code thanks to
the simple virtue of my program being "interepted".
Voila! GPL is uselless.
GNU Bash (which uses readline) makes GPL useless because it doesn't
force all bash scripts to be GPLd? Wow. I'm sure the FSF will appreciate
your insight on GNU Bash and the usefulness of the GPL :)
Looking through the bash documentation, I can find no statement from the
FSF that says 'all your scripts are belong to GPL' or an exception for
I think your reasoning about a hole in the GPL is deeply flawed. The GPL
works as it should, it just doesn't work like a click-wrap non-free
license, like you think it does, and would presumably like it to do. It
would truely be useless if it did work the way you think it does, as
then the GPL would not be DFSG-free.
There exists java.lang.System.mapLibraryName() pure java method.
This method calls java.lang.NativeLibrary.getLibPrefix() and
java.lang.NativeLibrary.getLibSuffix() methods, but they are NATIVE
methods, and are implemented by ./libraries/clib/native/NativeLibrary.c
file, which is part of kaffe, and therefore available under the GPL.
Those libraries are *a part of the GPLd interpreter*, so they can not
magically let the interpreter impose the GPL on its input.
Therefore only the second case mentioned in the FSF FAQ applies.
"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."
There is no contradition between the first part of FSF's statement about
a GPLd intepreter not being able to restrict its input and this part.
The part you quote is not about the interpreter, it is about *other*
facilities that are bound to interpreted data.