"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 21:56 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: >> >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]