Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
On Sun, Nov 02, 2003 at 11:40:59AM -0500, Etienne Gagnon wrote: 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 Please don't *ever* describe it in this fashion. The GPL makes no reference to linking, and all it does is (successfully, in this case) confuse the issue. It is not even generally appropriate to think in these terms for C; it is entirely wrong for java. It is the LGPL which discusses linking; people frequently confuse the two. The LGPL is not relevant here. (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). Firstly, in summary: (1) is not important. Kaffe is essentially a filter that takes java bytecode as input and emits program code on the fly (this is technically incomplete, but effectively equivalent for the sake of this argument). The input to a filter cannot be a derivative work of it; we don't *care* about the state of the output (which is also not a derivative work in this case, but I'll skip the reasoning). (2) and (3a) are the same thing; I'll deal with those below. (3b) is a variation on (1), and I think it is unimportant for the same reason, although I may have missed something here. The question that remains is presumably Is java bytecode a derivative work of the class libraries used for it? This is more or less a FAQ, albeit in a slightly different form; it's the old question about library interfaces and the GPL. Here's the rule of thumb that I use for software: If work A requires work B in order to function, A is a derivative work of B. This is actually *stronger* than the legal definition[0], so it should be safe (but you can't play lawyer-games with the wording - sane interpretations of requires only). Now, applying this to the kaffe class library: A given java program does not require this class library in order to function, because it will also work with a range of other class libraries from different vendors, and therefore is not a derivative work. Therefore, the GPL does not cross this so-called interface boundary. Note that this does not apply if the program uses features specific to kaffe. Assume we went along with your interpretation that all the specified class libraries are part of the VM, It is unreasonable and almost certainly invalid to reference arbitrary documents (sometimes called standards) here. Only real code counts[1]. 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. This would be a violation of the GPL. Their modified version of the kaffe class library is *clearly* a derivative work of the original kaffe class library, both under my rule of thumb and under the formal legal definition. Sun could license somebody to distribute a proprietary version of *their own* java class libraries with features which the kaffe one did not have. I don't see why this should concern you. They can also sell a proprietary application based on their own class library. Again, this has nothing to do with kaffe. They can also sell a GPLed application that requires and thusly is a derivative work of a proprietary application - this is in no sense specific to java. The GPL deliberately only works in one direction. One thing which they cannot assume they can do (a good lawyer might be able to wangle it, but you can't stop that) is to add a new feature to the kaffe class libraries, which is not present in any other class library, and then create a proprietary application based upon that. 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. glibc implements a great many unique features, that are not duplicated in any other C library. Historically, licensing it under the LGPL had some advantages for people working on proprietary systems; the FSF could justifiably shift to the GPL if they wished. As always, this would restrict the range of things that you could do with it; it is the choice of the copyright holder how much to permit. Also, C programs directly include copyrightable
Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
Andrew Suffield wrote: Kaffe is essentially a filter that takes java bytecode as input and emits program code on the fly (this is technically incomplete, but effectively equivalent for the sake of this argument). The input to a filter cannot be a derivative work of it; we don't *care* about the state of the output (which is also not a derivative work in this case, but I'll skip the reasoning). I can live with this view (even though an argument could be made about the fact that many VMs (I do not know specifically about Kaffe) internally use bytecodes from the class library to handle internal data structures [think of a just-in-time compiler written in Java; it would really be part of the VM, not merely processed input, IMHO]). So, we can ignore the issue. In all cases, this is not a problem that Debian has to care about in the case of Kaffe, its class library being under the GPL anyway. The question that remains is presumably Is java bytecode a derivative work of the class libraries used for it? Yes. I think I will not need to write a summary of the debian-java discussion as this question summarizes the problem. Your argument below addresses this question quite thoroughly. This is more or less a FAQ, albeit in a slightly different form; it's the old question about library interfaces and the GPL. Here's the rule of thumb that I use for software: If work A requires work B in order to function, A is a derivative work of B. ... A given java program does not require this class library in order to function, because it will also work with a range of other class libraries from different vendors, and therefore is not a derivative work. Therefore, the GPL does not cross this so-called interface boundary. OK. I can agree with this, as long as we keep the a range of other class libraries from *different* vendors statement. Otherwise, it would be too easy for a *single* party to simply modify similarly a few of GPLed Free VMs to declare a change in the interface boundary. [I am pretty sure that this could be seen as an obvious machination to go around the terms of the license and would be ruled as infrigement in a Canadian court. But IANAL. ;-)] The way I see it is: Debian should try to stay on the *safe* side of things, license wise. So, using the rule of thumb you proposed above seems quite reasnable to me. Is there a consensus on debian-legal about this rule? If yes, I would think the argument to be settled (unless some other debian-java people want to continue arguing). Note that this does not apply if the program uses features specific to kaffe. This is something debian-java should probably state in the java policy; package maintainers should also make sure to take this into account when looking at license compatibility of application/VM. Thanks a lot, Andrew, for this comprehensive answer. Repeating myself: as long as there is a consensus on debian-legal about the rule of thumb outlined above, I think the argument is settled. Could somebody confirm this fact? Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
[This is no longer particularly important] On Mon, Nov 03, 2003 at 09:37:49AM -0500, Etienne Gagnon wrote: Andrew Suffield wrote: Kaffe is essentially a filter that takes java bytecode as input and emits program code on the fly (this is technically incomplete, but effectively equivalent for the sake of this argument). The input to a filter cannot be a derivative work of it; we don't *care* about the state of the output (which is also not a derivative work in this case, but I'll skip the reasoning). I can live with this view (even though an argument could be made about the fact that many VMs (I do not know specifically about Kaffe) internally use bytecodes from the class library to handle internal data structures [think of a just-in-time compiler written in Java; it would really be part of the VM, not merely processed input, IMHO]). I considered this briefly, but the result of any such process is never copied or distributed[0], so copyright isn't directly applicable at all - we don't need to worry about it. The GPL doesn't place any restrictions on how you use works it covers, only on how you distribute them, so there's no possibility of trouble from that side. Freakish maybe-invalid licenses that try to place restrictions on use may have trouble here, but those aren't a concern as far as GPL compatibility is concerned; the worst case is that you have some non-distributable data in memory, where nothing will try to distribute it. We'll probably judge them to be non-DFSG-free in their own right, but that's an entirely separate issue. [0] Who wants to speculate on the legal status of core dumps? I don't think we can really do anything useful here, since it's all mixed up with the input fed to the process at runtime, but it might make an interesting diversion. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
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
Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
On Sun, Nov 02, 2003 at 07:51:37PM +0100, Dalibor Topic wrote: 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. I read Kaffe's (GPL and GPL incompatible Java software), not (Kaffe's GPL) and GPL incompatible Java software. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
