GCJ vs. Kaffe linking [was: Re: Eclipse 3.0 Running ILLEGALY on Kaffe]
On Sat, 2005-15-01 at 22:37 +0000, Dalibor Topic wrote:
> Brian Thomas Sniffen wrote:
> > Again, this isn't about the copyright holder's right to control
> > production of derived works. This is about the copyright holder's
> > right to control copying and distribution of copies. Reading GPL 2b,
> > I cannot see permission to distribute a CD with Eclipse and Kaffe on
> > it, such that Eclipse runs on top of Kaffe when I insert the CD.
> Bullshit. There is no GPL violation in Eclipse, no violation in Kaffe,
> no violation in running Eclipse on Kaffe, no violation in distributing
> Eclipse, no violation in distributing Kaffe, so there can be no GPL
> violation in distributing these sperate, independant works on the same
> medium as separate works.
> As Eclipse never was a derived work from Kaffe in the first place, it
> can't become one just because Brian Thomas Sniffen closes his eyes and
> wishes for it to happen. GPL does not work like pixie dust. Something
> copyrightable, GPLd from Kaffe has to end up in the copy of Eclipse
> *that is being distributed* for your claim to have any merit, and it
> doesn't, as has been thoroughly explained in this thread.
> It doesn't concern Eclipse any more than distributing the Linux kernel,
> gcc, bash, or anything else under the GPL does, because to all these
> programs, Eclipse is a bunch of data, just like for Kaffe.
Thanks, we all have heard that before. But your synthesis of facts
seems to be quite selective at times. For example, I wonder, but in
> The exception is there because GNU Classpath is a set of class
> libraries that is also used by ahead-of-time compilers for Java,
> like gcj.
> Since the FSF doesn't think that every program compiled with an
> ahead-of-time compiler and GNU Classpath needs to have the GPL
> slapped on it, they added an exception to GNU Classpath, just like
> for bison, autoconf, and so on.
After which Brian Thomas Sniffen wrote:
> I would assume that the same applies to Kaffe.
And apparently Brian was right, and you too would see that (or you
had and you decided not to show that to us?) if you fully read the
GNU Classpath exception you had been explaining so clearly.
Particularly the first paragraph (see:
" Linking this library statically or dynamically with other modules
is making a combined work based on this library. Thus, the terms
and conditions of the GNU General Public License cover the whole
The difference between Kaffe and GCJ is that in one case linking is
dynamic, while in the other it is static. The type of linking does
not affect the creation of combined work, which takes place in
_both_ cases. (and is especially visible if we have the combined
work distributed later by Debian)
And I just want to remind that parts of Kaffe's class library are
purely GPL, so there is NO linking exception applying to them,
therefore clearly we have a violation of GPL while combining a
GPL-incompatible code with it. [*]
Grzegorz B. Prokopski
[*] Not to mention that at runtime the program being interpreted is
effectively linked to purely GPLed native parts of Kaffe, which again
is creation of combined work, again, clearly documented by Depends:
in Debian packages.
Grzegorz B. Prokopski <email@example.com>
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