Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
Hi Etienne,
let's have some non-lawyerish philosophical licensing discussion fun
again ;)
My first issue is with the subject line: Kaffe uses plain GPL, not some
special 'Kaffe's GPL'. It should be FSF's GPL, if you'd want to
attribute it someone special.
Etienne Gagnon wrote:
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.
It would have been nice if you had made the arguments of each side
clear, before attacking my position. The discussion has not taken place
on debian-legal, but on debian-java. I appreciate the way Gadek
presented both sides of the previuos argument.
The trouble is that in the rest of your mail you shed very little light
on the differing interpretations of what constitutes a derivative work,
but instead go on about a hypothetical case to prove your point. That is
a very bad way to present your case, in my opinion.
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? ;-)
http://www.kaffe.org says:
What is Kaffe?
* Kaffe is a clean room implementation of the Java virtual machine,
plus the associated class libraries needed to provide a Java runtime
environment. The Kaffe virtual machine is free software, licensed under
the terms of the GNU Public License.
[snip]
What is Kaffe not?
* Kaffe is not an officially licensed version of the Java virtual
machine. In fact, it contains no Sun source code at all, and was
developed without even looking at the Sun source code. It is legal --
but Sun controls the Java trademark, and has never endorsed Kaffe, so
technically, Kaffe is not Java.
</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.
Sun unilaterally decided and will decide what can be added to their
libraries. Why does that matter? Why does being able to buy a book
matter in order to interpret the GPL in this case?
So, here is a hypothetical situation, where Sun could abuse its powers
under
your interpretation of the FSF's opinion:
This is debian, it's not Sun. ;)
If you have a concern that Sun could abuse kaffe, take it to Sun or
kaffe, *when it happens*. There is not much point in discussing
hypothetical cases on debian-legal in my opinion, if they are not
related to debian at all.
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.
You're committing a classical fallacy: Appeal to Consequences of a
Belief [1]. The consequences of my interpretation do not matter when we
discuss whether it is correct or wrong.
The case is not much different that with binary modules in the kernel.
One copyright holder (Linus Torvalds) has expressed his interpretation
of the GPL, the FSF has expressed another, and everyone lives on
happily, and nobody is getting sued. I'm just one copyright holder of
many on kaffe. That's my interpretation, others may agree or not. They
don't have to, I don't run a copyright-assignment business like the FSF
does.
My interpretation does not create loopholes in GPL, that aren't there to
begin with. GPL, as any legal document, is open to interpretation
between the parties. Sometimes people interpret different things
differently, and in my opinion, the existance of numerous people
disagreeing with FSFs interpretation (like Linux Torvalds' school of GPL
interpretation), proves that the GPL is ambiguous in those cases. I
don't think the problem is my interpretation, the problem would be the
GPL allowing seemingly contradictory interpretations. But that's not a
problem for debian-legal, it's a problem for the FSF's GPL3.
Debian basically can say: we follow FSF blindly, and agree to FSFs
dogmas on any issue, or they can think for themselves, interpreting some
issues differently from the FSF. They have done so already ('free'
documentation license debate), and as Debian is independant from FSF, I
don't see Debian necessarily following the FSF's interpretation on
everything.
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.
That's my interpretation of 'interpeter' as well. Program that acts on
some data. So I think FSF has no point in their interpretation of
interpreters ;). But that's not what we were discussing specifically.
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".
I'm not FSF, I don't speak or think for them. I'm not a copyright holder
on GNU libc, so my interpretation is likely to be irrelevant in that
case. FSF can license libc as FSF wants without the need to consult me.
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.
I don't interpret FSF's position. I interpreted the GPL, in how I think
it applies to programms written in Java with respect to running them on
kaffe. I may be wrong, I'm not a legal scholar, other copyright holders
may disagree, and so on.
<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>
Yeah, that's a good rant I'd underwrite. But that's not what we are
talking about here, right? ;)
cheers,
dalibor topic
[1] http://www.nizkor.org/features/fallacies/appeal-to-consequences.html
Reply to: