hi Grzegorz, --- Grzegorz Prokopski <[EMAIL PROTECTED]> wrote: > Q: "Kaffe is free implementation of Java Virtual > Machine and ClassLib > which are both available under the terms of GPL2 > license. How does > this affect possibility of using kaffe as > development and runtime > platform for other non-GPL licensed programs and > libs?"
> What are the objections? This is the position of the FSF: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > What are possible problems? (As I'm not educated in the finer points of copyright law, take my remarks with a grain of salt. And I speak only for myself etc.) In general, I don't believe that a GPLd interpreter can make requirements on the interpreted data, unless that data is "linking back" to the interpreter or using the interpreter to link to GPLd code. /* 2.1 */ The second case is quite clear, I think. Take a program explicitely using a GPLd library, for example a java program using Qt through JNI. In that case the license of the interpreter should not matter, as the code is explicitely linking to a GPLd library. /* 2.2 */ Take the case of a program explicitely using a GPLd library written in pure java, like jode: again the license of the interpreter should not matter, as the program explicitely wants to link against the GPLd library. /* 2.3 */ Finally take the case of a program that calls another GPLd program written in pure java, like kjc: again the license of the interpreter should not matter, as it is equivalent to a system() call in c: there is no linking if you are just calling a program to use its output. Now you could do this in two ways in java: using Runtime.exec or by calling the main method in the application class. The first method is clearly separated, as the interpreter is supposed to start a new native process. The second method requires the classes of the GPLd program to be loaded and eventually linked by the interpreter, but I don't think that makes the caller subject of GPL. It is not responsible for linking behaviour of the programs it calls. /* 1.1 */ Coming back at the first case, code linking back to the interpreter. I believe that all java class library API implementations link back to the interpreter, and I don't believe that you can implement the java API without some linking between the core classes and the interpreter. As far as I know, GNU Classpath requires the VM implementor to implement a few core classes to link with the virtual machine, for example, and they run on a few interpreters, so they should know ;) It should be clear that a class library implementation that comes with the interpreter should be licensed in compliance with the interpreter license, as far as it links directly to it. /* 1.2 */ What about the other core classes that don't link directly with the interpreter (i.e. pure java)? This is where opinions will greatly differ: mine is that the interpreter is interpreting the pure java libraries as data, and thus can not make requirements on their licensing according to the argument above. If they are GPLd, as are most libraries in kaffe, then that's great, but that shouldn't prevent interpretation of GPL-incompatible code/data, unless it is using explicitely the GPLd libraries. /* 1.3 */ Now of course one could argue that every java class is using java.lang.Object, but that's not at the program's disposition: as every java class must use it (at least the empty constructor), every java class executed on an interpreter will use it, no matter which license it has. The program does not explicitely ask to use the GPLd library, in fact any other implementation of java.lang.Object should do. /* 1.4 */ I believe that the same holds for any other class that is in the java API. So as long as the program/data is implementation agnostic, the GPLd interpreter should not be able to impose licensing restrictions on the data it runs. For example, I think a program that explicitely uses the GPLd kaffe.management.JIT class, should be subject to the GPL, as that class is a feature of kaffe's implementation, and not a part of the standard java API. On the other hand, a HelloWorld program that uses java.lang.System to print out a greeting message, should not have to be subject to the GPL to run it on kaffe. /* 1.5 */ the situation is a little different for gcj, I think, as gcj is able to compile the class libraries to machine code, and that means good old non-java linking. So the linking exception in the gcj license is necessary to allow one to use the compiled-to-machine-code libraries with programs that are not GPL compatible. > Where are the borders of usage of kaffe? > > For example, what if we had JVM from kaffe (GPLed) > but used it with > gnu classlib (GPL+linking exception clause)? Does it > change anything? The classes linking to kaffe would have to GPLd, I think, but the rest could keep the exception, in my opinion. (Note: look at the AUTHORS file, and then value my opinion accordingly. ;) > I and I think most of us, cc:ed know how GPL works > for non-Java stuff. > Does Java way of working differ the situation > somehow? Yes, because you have interpreters working on data. There is a certain data/code duality, that you don't have in C, for example. the FSF says that a GPLd interpreter can hardly make requirements to the interpreted data, and I believe them ;), but there is a lot of room for interpretation of linking in the context of an interpreter. As for my own small contributions, I am quite glad to see them under the GPL. I'm open for discussion, but I doubt that will lead far, with the major copyright holder, Transvirtual, being out of business. best regards, dalibor topic __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
