On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote:
> > But was Kaffe _extended_ to provide such bindings for Eclipse 3.0?
>
> This FAQ entry discusses 2 cases. One is when we have an interpreter,
> that basically goes over the pseudo-code and purely "interprets" it
> (an old BASIC interpreter would fit here). No Java VM/interpreter
> _ever_ fits in this first, simple casse.
The FAQ discusses far more than 2 cases.
I imagine you're concerned about this part:
If a programming language interpreter is released under the GPL,
does that mean programs written to be interpreted by it must be under
GPL-compatible licenses?
When the interpreter just interprets a language, the answer is
no. The interpreted program, to the interpreter, is just data;
a free software license like the GPL, based on copyright law,
cannot limit what data you use the interpreter on. You can run it
on any data (interpreted program), any way you like, and there are
no requirements about licensing that data to anyone.
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.
> Second case is where the code being interpreted may request to access
> bindings provided by the JVM. In Java these are done thru JNI calls,
> so usually JVM itself is a JNI library that provides these bindings.
>
> So an interpreter has to be "extended" to provide these "bindings" to
> other facilities. In such case, as the FAQ states "the interpreted
> program is effectively linked to the facilities it uses through these
> bindings."
Is this relevant to Eclipse? I was under the impression that Eclipse
was pure java -- that it did not use JNI at all.
If Eclipse does use JNI, would still a question about whether or not
Kaffe's JNI implementation constitute some kind of extension designed
to work around the GPL or whether they are some kind of implementation
of some Java standard.
> > Or is Eclipse 3.0 using only the facilities which Kaffe provides for
> > arbitrary byte code?
>
> There is nothing in the FAQ that would suggest that these "facilities"
> have to be provided for a specific program.
There is nothing in the FAQ to suggest that a GPLed JNI implementation has
to be a problem for arbitrary code, though of course it does point out JNI
as a issue that can be a problem. But for problem resolution, the FAQ is
saying that certain things need to be released in a GPL-compatible way,
not that no release can happen.
> On the contrary. A Java Virtual Machine (Java interpreter) inevitably
> has to provide such bindings to support Java specification. In other
> words the interpreter itself has to be extended with a library that
> provides these bindings to support Java specs. There's plenty of these
> bindings required to exist in core java.lang.* classes.
>
> Hope this clarifies the issue,
You seem to be claiming that a JVM has to provide non-standard JNI
capabilities or it isn't a standard implementation of the JVM.
I'm not sure what that is supposed to clarify. I'm rather doubtful that
it's correct.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
