On Thu, 2005-13-01 at 23:42 -0500, Brian Thomas Sniffen wrote: > "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
