[kaffe] Re: kaffe's license

[Dalibor Topic]

Jim Pick wrote:
> The GPL license is somewhat undefined in terms of how it interacts with
> other code.

I'd somewhat disagree on that, in my opinion the GPL wisely defers to
copyright law terminology for many things, rather than getting mired in
specifics of yesterday's techniques for creation of derived works and/or
trying to invent new terminology to go with it. It's a pretty nice, good
read as far as software licenses go. See my blog for various critiques
of badly written licenses. :)

>  It's not a license I would have chosen for a virtual
> machine.  Some people say if you run an application on top of the VM,
> you would have to make that application GPL-licensed too.  Some people
> say that's nonsense (I tend to agree with that viewpoint).

My impression is that the GPL works pretty well, and allows GPLd
projects to easily integrate a lot of other, GPL-compatible software. I
am actually pretty happy with it, I think it has worked quite well so
far, as it sits on top of the licensing food chain. There is a great
article by David A Wheeler at
http://www.dwheeler.com/essays/gpl-compatible.html on the benefits of
using the GPL and making code GPL compatible, so I am putting some of my
energy into working with the Apache Software Foundation and the Free
Software Foundation to help bridge the misunderstandings, and
incompatibilities in their licenses.

I've spent a lot of time discussing licensing in various venues, and the
'you must run only GPLd software on a GPLd interpreter' claim is
invalid, for all I know about the GPL and copyright law. See FSF's FAQ
on a GPLd interpreter for details.[1]

As another explanation of why the claim is bogus, the freedom 0 of the
Free Software definition gives anyone the freedom run a GPLd program for
any purpose, even if the GPLd program is used for ethically questionable
purposes, like designing death stars, hunting ewoks or running non-free
software.

> To my knowledge, I'm not aware of any cases where somebody has been sued
> for running non-GPL code on a GPL'd virtual machine.  It's not a common
> scenario.  I think Transvirtual actually came to regret re-releasing the
> VM under the GPL, since they saw that people were actually using the
> GPL'd version for commercial developments, and were not coming to them
> for the proprietary version.

I think Transvirtual would have had a valid claim on people distributing
native binaries compiled against their commercial KaffePro offering
using their gcj fork, as in that case the actual binaries would have
contained copyrightable, verbatim sections of the class libraries.
(And/Or against people distributing gcj-ed versions of old, GPLd kaffe
class libraries). They would also have had valid claims against people
using non-standard extensions of Kaffe, and otherwise creating derived
works of the VM or the GPLd extension libraries.

In case of bytecode using standard Java APIs, a copyright infringement
claim would not really have a chance of succeeding, as the bytecode
files would contain only references to class files, and not contain any
coprightable parts of the GPLd (or GPL+exceptioned) class libraries, and
as bytecode using standard APIs is by definition VM independant, any
derived work claims would not work, as long as the works are clearly
distributed as separate works.

If someone really wanted to claim copyrights on strings like
java.lang.Object and try to enforce the GPL that way, they'd have a hard
time showing the copyrightability (for which originality is a
precondition) of those strings in face of the prior standardisation of
the exactly same strings by Sun Microsystems.

The major benefits of the linking exception in GNU Classpath are that it
allows ahead-of-time compiled use of class libraries without requiring
that the works incorporating those natively compiled class libraries are
licensed under the GPL, and that the exception makes the aforementioned
explanations about copyrightability, freedoms, and all that unnecessary.
In particular the latter is a pretty good reason to finish the class
library merge sooner, rather than later :)

> However, I cannot 100% guarantee that the whoever holds or buys the
> rights to the old Transvirtual stuff might not someday demand compliance
> with their interpretation of the GPL, and threaten to sue if that does
> not happen.  I suspect that this scenario is somewhat unlikely, since it
> would cost a lot of money to sue, the legal case probably isn't very
> good, and the amount of damages that they could get would probably be
> minimal.  I suspect the current owners of the old Transvirtual IP are
> aware that they own it, but they also realize that it would be extremely
> difficult to extract any value out of it using this method.

I doubt that would happen, as whoever ended up owning the Transvirtual
copyrights has not made any threats in the last three years since
Transvirtual went bankrupt, so I wouldn't assume that they would do so now.

There are also various counterexamples in the FSF licensed interpreters
that are under the GPL but nevertheless allow non-GPLd code to be ran on
them, even without specific exceptions in the license. See GNU bash, and
GNU CLISP for two pretty prominent ones.

If, though, sometime in the future some evil corporation (say, Microsoft
:) acquired copyirghts on Kaffe, and tried to use those to threaten
users, then their claims would be checked, and the code that they claim
be removed and replaced, and life would go on as usual. I think Linus
set a nice example how to deal with bogus threats in his handling of the
SCO attacks.

> So, if you absolutely can't take any legal risks, you might be better
> off just prototyping with Kaffe, and then choosing another
> Classpath-based virtual machine to actually put in your product.

In terms of chosing the legally safest alternative, I'd recommend gcj,
as it's copyrights are fully on file at the FSF, and the FSF has a very
good track record at dealing with funny people.

> If somebody was motivated, we could attempt to track down all the IP
> holders that have contributed to Kaffe, and attempt to relicense the
> project or get copyright assignment.  That may be difficult though,
> especially since some of them have died.  It would probably just be
> easier to direct efforts to some of the other virtual machine projects
> out there with cleaner licensing, especially since they now share so
> much with Kaffe (eg. the Classpath libraries).

Yeah, I don't think relicensing would make much sense, as it would cut
us off from the good work done in the various forks, and from other nice
GPLd code in GPLd VMs like cacao, jamvm, and others. Beside being a lot
of work :)

> That said, I personally don't think that Kaffe's somewhat unclear
> licensing situation is much of an obstacle for most uses, so I don't see
> any reason not to keep the project going.

I don't see the GPL as an obstacle, rather as an advantage, as it leaves
little room to accept GPL-incompatible restrictions when dealing with
the TCK license, for example, and the nice 'no single copyright holder'
situation is another wonderful way to ensure that relicensing requests
won't work.

In practice, I don't think that the GPL on Kaffe should rationally
prevent commercial use of Kaffe any more than it prevented commercial
use of GNU bash or GNU Linux: the GPL is a good mistress, if one knows
how she works.

Of course, there are some weird people: There is the Microsoft school of
It-is-an-evil-cancer GPL interpretation, and the SCO school of copyright
claims without regard for copyrightability, but both schools of thought
have more to do with wishful thinking, than with how the GPL or
copyright works in real life. :)

cheers,
dalibor topic

[1] Some people have misunderstood that FAQ entry in the past, which is
rather unfortunate, and led to various fascinating disagreements between
some Kaffe developers and them on some mailing lists and other forums of
communication.

If in doubt about the effects of GPL, the best advice I can give is to
ask the FSF. They provide a nice GPL compliance lab, where David Turner
is doing some really good work assisting people to comply with the
letter and the spirit of the GPL. If you are not familar with his work
for the FSF, check out his introduction to GPL compliance talk at
http://www.novalis.org/talks/compliance-for-developers/ , which I had a
chance to catch at FISL (in a slightly updated version).