Grzegorz B. Prokopski wrote:
Yet, if you *package* this program together with a JVM, so that when the user says "I want to build this package" or "I want to run this package" the user gets your program with a specific JVM, then it's not a mere aggregation, but these two are explicitely bound together.
a) it's not packaged together as Kaffe does not end up in the Eclipse package, and no *copyrightable* parts from Kaffe either, afaik, because Eclipse is not a derived work from Kaffe.
It's the 'HelloWorld' example over again:
public class HelloWorld {
public static void main(String [] args) {
System.out.println("Hello World!");
}
}
This is an extremely complicated Java program written against the J2SE
1.0 API. Is this work a derived work of Kaffe?
I think it's quite obvious that it is not.Compiling this with a Java bytecode compiler against Kaffe's class library and Sun's class library fascinatingly results in exactly the same bytecode sequence. Is that class a derived work of Kaffe, then?
Nope. For a copyright based license to work its 'derived/copied/modified work' magic, there needs to be something copyrightable in a work that's created from the GPLd work. Remeber that the original work in source code for HelloWorld was not a derived work, so something GPLd, copyrightable needs to be added to the output of the translation between the source code and the byte code for a derivation claim to hold.
Most of the content in the HelloWorld.class file is dictated by external factors, like the Java class file format. There are a couple of strings in the class file that are present in both Sun's and Kaffe's class library, like 'out', 'println', or 'System', though. Do these strings support a derivation claim?
Nope. They are from the non-GPLd source code, actually. The ones that are not, are in there because of 'scenes a faire' of the java byte code format, and the compilation to it. They are not copyrightable expressions. No copyrightable expression from Kaffe's handful of GPLd class libraries that implement the standard Java apis ever ends up in the bytecode compiled against them, afaict from writing the ocassional java bytecode compiler in my youth. :)
Unfortunately, apparently emulating a failed Unix(TM) vendor helplessly attacking a different GPLd project, you refrain from telling which file and line specifically in which class in the Eclipse packages where and how you believe to infringe on which GPLd file and line in Kaffe. That is kind of funny, since your theories about how copyright works appear to be quite similar to SCO's understanding of it. SCO, among many other funny things, claimed that Linux was shamelessly stolen from it, because it contained 'int a;' somewhere in it.[2]
b) Using a GPLd program to process data does not restrict the user in any way regarding the license of the data to process. So much for the generic claim about Kaffe's GPL propagating through using it to build something with it.
c) GPL allows users to run GPLd programs for any purpose without letting the GPL'd program impose restrictions on its data. So much for the claim about running.
cheers, dalibor topic[1] No, just because there is a string 'java.lang.Object' in a class file, it does not make it a derived object of Kaffe. That's because GPL is a copyright-based license, so 'Scenes a faire', abstraction, filtration, and all that nice stuff from copyright law play quite a bit of a role. While non-free, click-wrap licenses often contain clauses where the copyright holders make claims that go beyound what copyright law gives them, GPL is not such a license, and it shouldn't be interpreted accordingly.
Kaffe's copyright holders couldn't claim copyright on that string any more than they could claim copyright on the strings 'URL', 'http://' or 'stdio.h'. All these strings are part of Kaffe, afaik, but that doesn't mean that they are original, copyrightable work of Kaffe authors. You can't enforce a copyright-based license on something that's not copyrightable, like the string 'int a;'.
Otherwise, it could equally be argued, using Gadek's theory of copyright without regard for copyrightability of an expression, that if SableVM contained single words from the JVM specification in its source code or binaries, like 'IllegalMonitorStateException', it was a derived work from it, and wrath of the spec's creator hung over its head and those that distributed its packages.
Which would be, in my opinion, utter bullshit. But then, my understanding of copyright law is obviously different from Gadek's.
[2] 'How Kaffe stole UNIX from SCO' in http://www.advogato.org/person/robilad/diary.html?start=56