Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
Hi Debian-legal, Egon and Dalibor,
The opinion of debian-legal would be highly appreciated by all involved in this
long running thread of discussion about the implications of:
1- Kaffe being licensed under the GNU GPL.
2- Kaffe's class library being licensed under the GNU GPL.
3- Differeing interpretations about what constitutes "linking"
(more precisely: combining of works to form a derivative)
between:
a) class libraries and applications,
b) class libraries and core VM (in the case of Java VM).
See below.
Dalibor Topic wrote:
The language is defined by the Java Language Specification.
<not very important comment>
But the virtual machine is defined by the Java Virtual Machine
specification [JVMS].
This specification is *different* from the JLS, as it is possible to write
valid bytecode sequences (according to the JVMS) that cannot be genereted
using a JLS compliant compiler. So, what is Kaffe? A Java interpreter, or
a Java virtual machine? ;-)
</not very important comment>
No, not really. Those packages are explicitely specified in the Java
Language Specification, first edition. In fact, for some classes, like
java.io.StreamTokenizer, the JLS 1st Ed. is the only place where the
semantics of some of the methods is specified at all.
Assume we went along with your interpretation that all the "specified" class
libraries are part of the VM, and that running a Java program does not
"combine" the application classes with the standard class library class ancestors
(like java.lang.Object)[1]. The current JDK 1.4 class libraries, for which
you cannot buy a written specification (in a book), contains all kind of
things like XML parsers & so on. Sun Microsystems can unilaterally decide what
can be added to the standard libraries.
So, here is a hypothetical situation, where Sun could abuse its powers under
your interpretation of the FSF's opinion:
Sun discovers a fantastic GPL software (Foo) that fills the needs of a very rich $$$
client. Sun makes a deal with this client (and thus gets many $$$$$) to change
the Java specification so that the class libraries include the functionality
of Foo, so that the client can then modify Kaffe by adding Foo to its class libraries.
Now the client can Foo develop and sell for many $$$$ a proprietary application
based on Foo, as long as Foo is accessed through Kaffe.
Sun has no obligation to implement all specified class libraries, and has proved to
do so in the past[3]. So, Sun could change the specification without having to
actually provide Foo functionality in its own products.
Now, if you think like me that no single "remote" body should decide about the interface
between a GPL interpreter and the programs running on top of it, that the decision should
rest in the hands of the interpreter developer, then you make an even bigger loophole. E.g.
in the example above, Sun's client could simply modify Kaffe and decide of the new interface.
It is important, in my view, that I can decide about what is a standard library class for
SableVM; I do not want Sun to have anything to say about it. SableVM is not called "Java",
so Sun has no trademark to stop SableVM to evolve in directions that are different from Sun's
strategic business plans. I think this is an important freedom to keep for free software.
So, in my opinion, your interpretation that class libraries are part of the VM would create
an important loophole in the GPL. If Kaffe wants to allow classes to be combined with its libraries
and wants to allow the class libraries to be combined with the core VM (to implement System.gc(), etc.),
it should provide an *explicit* exception to the GPL, as does Classpath, Guile, and other
similar GNU projects.
My interpretation would be that only the "bytecode interpreter" can be considered as
a software that receives .class files as input data and delivers execution as output,
thus, its license would have no relation to the data's license. Unfortunately, in
the case of Java, the VM/class library interface is less than well specified! [Even
the class libraries are badly specified, in any case!]
Also, according to your interpretation, GNU libc could be licensed under the GPL, instead
of the LGPL. I see no reason for the FSF to continue licensing GNU libc under the LGPL
(which the FSF dislikes) if using standard functions (ISO C, POSIX, etc) did not cause
"combining of application code with library code to form a derived work".
In conclusion, I think that your interpretation of the FSF's position is wrong, as it
does not conform to to the FSF's historical use of the GPL vs LGPL, and because your
interpretation would open a gigantic loophole in the GPL.
[1] I have real doubts about this; see my Shakespeare example[2].
[2] http://lists.debian.org/debian-java/2003/debian-java-200311/msg00003.html
[3] Have you ever tried to use the filerting functionality of FileDialog?
<rant>
I think that one important problem is the lack of:
1- Well written (or defined) specifications for Java, its VM, and its
class libraries.
2- A well defined interface between the above components
3- An independent body controlling the specification.
</rant>
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Reply to: