[kaffe] Using kaffe(GPL2) with other DFSG-compat licenses

[Dalibor Topic]

hi Grzegorz,
--- Grzegorz Prokopski <gadek at debian.org> 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