Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <gadek@debian.org> writes:
> On Thu, 2005-13-01 at 21:56 +0100, Måns Rullgård wrote:
>> "Grzegorz B. Prokopski" <gadek@debian.org> writes:
>>
>> > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote:
>> >> "Grzegorz B. Prokopski" <gadek@debian.org> writes:
>> >> > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed.
>> >>
>> >> No, it is being interpreted by an interpreter that is covered by the
>> >> GPL. Even the FSF admits that this does not create a derived work.
>> >
>> > You really should reread FSF FAQ:
>> >
>> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
>> >
>> > "However, when the interpreter is extended to provide "bindings" to
>> > other facilities (often, but not necessarily, libraries), the
>> > interpreted program is effectively linked to the facilities it uses
>> > through these bindings. So if these facilities are released under the
>> > GPL, the interpreted program that uses them must be released in a
>> > GPL-compatible way. The JNI or Java Native Interface is an example of
>> > such a binding mechanism; libraries that are accessed in this way are
>> > linked dynamically with the Java programs that call them. These
>> > libraries are also linked with the interpreter. If the interpreter is
>> > linked statically with these libraries, or if it is designed to link
>> > dynamically with these specific libraries, then it too needs to be
>> > released in a GPL-compatible way."
>> >
>> > Do you understand that an interpreter for Java IS such an interpreter
>> > that provides "bindings" to other facilities?
>>
>> The paragraph above concerns JNI interfaces to libraries *separate*
>> from the interpreter. For instance, one could imagine a JNI binding
>> to GNU readline. The use of such bindings is independent of the JVM
>> being used (bindings might not exist for all JVM implementations, but
>> that's irrelevant). The existence of a binding facility does not make
>> a program using them derived from the interpreter. In FSF logic, it
>> is derived from the bound libraries, no more, no less.
>
> It shows you have no idea how a JVM is organized. The "interpreter"
> part on which you're hanging so strongly is only part of a JVM. The
> part that actually gets to interpret the bytecode. But there's also
> a lot of functionality (think about it as a VM-specific library) that
> is being used from within java library, and via JNI bindings calls
> library functions of a JVM.
>
> Yes. A JVM migh be seen as an interpter + a library of native calls
> used by the java library. And in case we're discussing this native
> library is GPLed.
The license of the library does not matter. Eclipse is written to
work with any implementation of the standard Java API.
>> > Do you understand that a program being interpreted is effectively
>> > linked to these facilities it uses thru these bindings?
>>
>> Yes. Which bindings does Eclipse use?
>
> I told you. Plenty. And if we're making Eclipse Build-depend on
> a GPLed version of these, then we're explicitely forcing these bindings
> to be GPLed.
Guess what, Eclipse does not have a Build-depends on any GPLd JVM. It
has a Build-depends on j2sdk1.3 | j2sdk1.4, which are virtual
packages. Guess what else, Kaffe doesn't provide either of these.
Surprised? I'm amused.
>> >> > Please see Linus's email I cited in my other emails for more info.
>> >> >
>> >> > Would it have been compiled against a differently licensed library,
>> >> > this particular problem would be solved. Wouldn't it?
>> >>
>> >> It is compiled against an interface, not an implementation. Which
>> >> particular implementation was used while compiling is irrelevant.
>> >
>> > Ok, so please compile Eclipse agains an *interface* which is not its
>> > implementation (covered by GPL, in our case). Sure, if you use ie.
>> > some stubs covered by IPC-compatible license, I won't say a word.
>>
>> If the implementations are fully compatible, the compiled bytecode
>> should be bit-identical no matter which one was used.
>
> Does it matter? What however IS different is the fact which actual
> implementation you use as the interface against which you're compiling,
> and also with which implementation of library an app will be used.
> These informations are explicitely and clearly encoded in debian control
> files.
Oh, you are saying Debian can dictate what some program is derived
from simply by adding a Depends line?
>> > But in our case you're using an implementation that also at the same
>> > time defines the interface (this if functional equivalent of header
>> > files). You cannot simply take a GPL implementation, compile against it
>> > (never mind whether it's C, Java, Python or whatever), and they claim
>> > you just didn't create a derivative work of the implementation you used.
>>
>> That's precisely what I am claiming, and several court cases support
>> my claim.
>
> Voila! let's make glibc GPLed!
Go ahead. Let's have it tested in court.
>> > Please look at FSF FAQ once again, please try to understand what the
>>
>> Reading the same FUD over and over again isn't going to alter the
>> logic of the universe.
>
> The logic of _your_ universe, you wanted to say.
>
> See.
>
> * You're not capable of reading a simple, 15-lines long text written
> in plain English.
>
> * You're creatings things that were NOT written in it as if they were.
>
> * You're making this arguing useless, by having no (technical) idea
> what you're talking about.
>
> I am asking you once again. Please. Go away.
I do not respond to ad hominem attacks.
--
Måns Rullgård
mru@inprovide.com
Reply to: