Re: Illustrating JVM bindings
On Thu, 2005-13-01 at 23:42 -0500, Brian Thomas Sniffen wrote:
> "Grzegorz B. Prokopski" <gadek@debian.org> writes:
>
> > These facilities include class loading, class instantiation,
> > synchronization, garbage collection (ie. you can trigger GC from within
> > your program), reflection (ie. you can ask VM "what are methods that
> > this class have?").
>
> Those are features of the interpreter. The fact that the interpreter
> happens to be written in C as well as in Java doesn't matter here.
> This is what I meant about you leaning too much on your knowledge of
> how JVMs tend to be built. But everything you've listed here is an
> accident of the implementation of the JVM.
>
> > It is not possible to have a JVM w/o these facilities.
> >
> > Now, the FAQ says:
> >
> > "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."
>
> What the FAQ is talking about is, for example, using JNI to access
> GNU Readline or GMP from a Java program using JNI. That is, it's
> pointing out that if you want to use the GPL'd Readline library, your
> application program must be distributed under the terms of the GPL.
> I'm not convinced the JVM does, but I suspect it's the case without
> the OS exception (which, of course, Debian can't use).
Your implementation creates a huge loophole in GPL, that I do not
believe is there. Let's continue your way of seeing "interepter
features" and see what would be the consequences.
An example. I am writing an app. A GPL-incompatible or even
closed-source one. I'd love to use this conservative garbage collector
library, but it's under GPL, so I cannot. I'd also love to use
libreadline, but I can't - for it's GPL.
According to what you've just said it would be enough to create own
intermediate langauge, and an interpreter that according to its own
specification should handle garbage collection and provide readline-like
functionality.
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.
You say I lean too much on my JVM knowledge. Let me show you another
very short, but real example of why a JVM is not only an interpter, but
also a library (example based on Kaffe code).
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.
What these two functions do has NOTHING to do with *interpreting* java
bytecodes. These two happen to convert compile-time-defined C strings
into java string and return them. And there is also plenty of such
methods in whole JVM (I am not Kaffe expert, but I am sure Dalibor could
show us more), which are exactly an additional functionality that
has nothing to do with the interpretation of the bytecode.
So let me just restate:
"To fullfill specification requirements a Java Virtual Machine provides
additional "bindings" to functionality that is not part of the
interpreter, but part of the JVM and its interface to java library."
Therefore only the second case mentioned in the FSF FAQ applies.
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."
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <gadek@sablevm.org>
SableVM - Free, LGPL'ed Java VM http://sablevm.org
Why SableVM ?!? http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS http://www.debian.org
Reply to: