Re: Eclipse 3.0 Running ILLEGALY on Kaffe
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.
> > 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.
> > Do you understand that in case we're discussing these facilities are
> > released under the GPL?
>
> We are discussing the case where the interpreter is released under the
> GPL, nothing has been said about third-party library bindings.
As I said, JVM is not a "pure interpreter". Much of its functinality is
exported in form of JNI bindings used from java library.
Actually FSF FAQ says (could you *PLEASE* finally READ IT WITH
UNDERSTADING?):
"...other facilities (often, but not necessarily, libraries)"
There's NOTHING about "thrid-party", they don't even have to be
"libraries".
> >> > 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.
> > 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!
> > 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.
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <gadek@sablevm.org>
SableVM - Free, LGPL'ed Java VM http://sablevm.org
Why SableVM ?!? http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS http://www.debian.org
Reply to: