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

Note that this does not apply if the program uses features specific to

> 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

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

Java has no comparable issue; a byte-compiled class contains nothing
copyrightable taken from the class libraries that it was "compiled"

[0] 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.

[1] 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/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature

Reply via email to