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
IBM 131 and unstable?
Hi All, Hope everyone had a nice weekend. Just updated my system to the latest set of unstable packages, and for some reason Eclipse and my other apps are failing to start, with java core dumping in fact. This only happens with IBM JDK 131, 141 continues to work fine. A strace of running the SwingSet2 demo is attached. Anyone else experiencing this as well? Any ideas what the problem might be? Cheers, Marcus strace.txt.gz Description: GNU Zip compressed data
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: IBM 131 and unstable?
On Mon, Nov 03, 2003 at 11:29:10AM +0100, Marcus Crafter wrote: Hope everyone had a nice weekend. Just updated my system to the latest set of unstable packages, and for some reason Eclipse and my other apps are failing to start, with java core dumping in fact. This only happens with IBM JDK 131, 141 continues to work fine. A strace of running the SwingSet2 demo is attached. Anyone else experiencing this as well? Any ideas what the problem might be? Probably glibc; check the bug list at http://bugs.debian.org/src:glibc -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
familycornernews Help Message
The signoff email address is [EMAIL PROTECTED] and any message sent to that address will unsubscribe the sending email address. Once unsubscribed, you will not receive any more email. The change of address email address is [EMAIL PROTECTED] and any message must include your old email address in the Subject: line. For example From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [EMAIL PROTECTED] If you know your new email address ahead of time, you can also change it on this list with one command. From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [EMAIL PROTECTED] An acknowledgement message will be sent to both the new and old email address, when the change process has been completed. The signon email address is [EMAIL PROTECTED] and any message sent to that address will start the subscription process. Once subscribed, you will receive all messages posted to this list. If that is not so, please send all details to [EMAIL PROTECTED] name or description of the list causing you problems any other email addresses that you might be subscribed under copy and paste all relevant clues, especially the headers, and send to [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
