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, 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. > 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 program code from header files, which means that compiled binaries are frequently derivative works of the "library" (if glibc were GPLed, this would prohibit distribution of binaries generated from GPL-incompatible sources, as the GPL license on the glibc components would not permit this; it would be okay if the headers alone were licensed under the LGPL). Java has no comparable issue; a byte-compiled class contains nothing copyrightable taken from the class libraries that it was "compiled" against.  DERIVATIVE WORK - A work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'. -- from title 17 of the United States Code. Other jurisdictions are very similar.  I'm skipping the rationale for this; it's just a list of all the things involved in the creation of the work under discussion, and classification of whether or not their use can constitute copyright infringement. Implementation of a specification does not usually constitute copyright infringement of the specification, for example, because there's no copying/distribution involved. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Description: Digital signature