Dalibor Topic <[EMAIL PROTECTED]> writes:
Brian Thomas Sniffen wrote:
Måns Rullgård <[EMAIL PROTECTED]> writes:
It is compiled against an interface, not an implementation. Which particular implementation was used while compiling is irrelevant.
Can you support this assertion? The program, including its libraries, which the developer intends to put on end-user systems appears quite relevant to me.
For a file written in Java, all that ends up in the compiled bytecode file from a library its compiled against are a bunch of strings denoting class, interface, field and method *names* that are used from the library, if any, but not the actual content of the library, i.e. actual expressions of data structures or methods as they exist in the library. That's a major difference between Java classes and C headers.
But what ends up on the user's Debian system when he types "apt-get install eclipse; eclipse" is a program incorporating a JVM and many libraries. Debian's not just distributing Eclipse or just distributing Kaffe -- the idea is that we'll be distributing the Debian OS which includes both, linked together.
Given that a GPLd interpreter can not impose restrictions on the data it is used on, there is no GPL violation in the act of running taking place, so much for the 'running eclipse' part. See GPL clause 0 :
"Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does."
For the apt-get install eclipse part, it depends on whether there are actually copyrightable pieces of/derived from a GPLd work, i.e. Kaffe's interpreter or other GPLd files in Kaffe, distributed together with GPL-incompatible works in a, still hypothetical, official eclipse3 debian package.
So far, none have been pointed out, and I'd be surprised if there were any, i.e. if Eclipse's source code was derived from GPLd parts of Kaffe, or the result of the build process could be shown to incorporate any copyrightable, GPLd part of Kaffe. If you happen to find such pieces, please send me an e-mail with the names of specific GPLd and non-GPLd files and the line numbers of the lines which you believe to be incorporated into the eclipse package, why you believe that a GPL violation is taking place, and either I or someone else will investigate such claims along with the packager, if necessary.
Finally, let's deal with a 'Depends: kaffe' line. Since the Eclipse source code is not a derivative work of Kaffe, for all I know about derivative works and Eclipse, as it does not incorporate any GPLd, copyrightable part of Kaffe is its copied, modified or derived form, Eclipse's source code is not bound by Kaffe's GPL.
Whether binary files in the eclipse package incorporate any GPLd, copyrightable part of Kaffe is a different story, that has already been dealt with for 'standard Java using' bytecode on debian-legal. In case of native libraries from eclipse using JNI, kaffe's jni.h file is published under exactly the same permissive license as GNU Classpath, which is the GPL with a very broad linking exception:
"As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version."
Therefore, I assume that no copyrightable, GPLd parts of Kaffe end up in eclipse debian package. Not any other than from gcc, javac, make, bash, or other tools used during the build process, anyway.
So you now have two independant works whose licenses conflict if you wanted to do a work that derives from them both. Does the Debian OS do that? Nope, unless we assume that the Debian OS is derived work of all its packages in general. Then Debian OS would be undistributable, unfortunately, unless all of it is licensed under GPL-compliant licenses. Which would be fine for Kaffe, but sad for Debian, I think :)
Does the 'Depends:' line turn an Eclipse package that's not a derived work of Kaffe into a derived work of Kaffe, its modification or copy? Nope, because no part of one work ends up in the other that wasn't there *before*. Just like me saying "eclipse" and "kaffe" in this e-mail does not magically turn eclipse into a derived work of kaffe, or create an undistributable e-mail, for all I know. Wishful thinking doesn't make a work dervied work of another one, or SCO would own debian :)
Does a download of Eclipse via apt-get leading to a download of Kaffe constitute a derived work covered a both licenses? Nope. Otherwise debian would be in deep trouble for distributing all sorts of incompatibly licensed code 'linked together' to people all over the place that do a 'apt-get update; apt-get dist-upgrade' :)
Are we done?
cheers, dalibor topic
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
