Since I am one of the guys setting Kaffe's policies, let me elaborate:
The new IP issues article talks about ominous IP issues wrt to independant implementations like 'fred'. Kaffe is a bit like that 'fred' implementation, since it steers clear from using Sun's trademarks. See the discussion on apache's legal-discuss list about that, and some other claims in the IP issues document.
It is clear that Sun would like to employ a carrot and stick approach to collaborate with the community outside Sun. The trouble is that historically, Sun has played the role of an IP bogeyman in that community, since they have never participated as part of it. And the simplest way to handle IP bogeyman is to avoid getting in their fangs. :)
So relying too much on a stick means people will avoid you, in particular if there is no carrot (JRL is GPL-incompatible, after all, so the code release under it is useless for Kaffe).
Obviously, this is a completely distorted characterisation of what Sun actually does and wants. Nevertheless, I hope that you can understand that as much as Sun fears that evil people will steal their precious IP if they do not closely guard it, I (and others) fear that Sun (or a successor) will run amok with wild IP claims, and the current set of Java technology licenses fails the 'tentacles of evil' test. Since the simplest way to avoid having to go to court over IP claims is to avoid dealing with code that might have IP issues attached to it, that's the recommendation that I give to people who want to participate. That's quite similar to how Mono handles Microsoft's shared source implementation of C#. It's normal practice, afaik.
Now, I think the progress you guys have made on licenses is to be commended. For example, by removing the requirement that all code implementing specs is legally a modification or the JRLd code, you've made it possible to draw clearer lines where a contribution from someone who looked at JRLd code is probably safe, and where it is a very difficult question. That will probably play a role in the way Harmony deals with contributions. I very much appreciate the attempts from your team to come up with a clearer, more precise non-free license for J2SE that does not create legal issues downstream. Thank you very much for that, I am sure that is to our mutual benefit. While the JRL still have various issues, it is improving from version to version, and Sun is doing some good work on dealing with the feedback they get from the community.
For example, people contributing fixes for Kaffe's build system probably can't violate the JRL since Sun's build system for all I know does not use the same tools that we do (autotools), so there can not be copyright claims from Sun's side (and patents or trademarks on configure scripts would be a funny claim). But that's a very special case. I have to give special consideration on a case by case basis, and I think hard about those since I want to stay out of courts, as you can probably imagine, so I prefer being conservative, rather than trusting that Sun or future owners of Java technology will always be benevolent.
In general, dealing with JRL is not a big issue since most people avoid it, and those that have agreed to the JRL can find other ways to contribute, like packaging, regression testing, etc. Then there is the economy of dealing with JRL-tainted contributions: dealing with developers who accepted the JRL for tiny contributions would be rather unproductive, since the case-by-case dissection would require a lot of effort. On the other hand, large contributions would require a thorough legal review to avoid copyright and patent issues, so they would likely result in even more effort, since I obviously can't touch JRL licensed code in order to avoid being bound by it, and that would make a review of the legal situation of, say, a new J2SE-5-like jitter pretty hard, to put it mildly. So practically, there are hard limits to what I can do with such contributions, no matter how well meant they are.
With free software, it is important that it stays free and one does not give up one's rights. So I need to avoid situations in which my rights to modify, distribute, study and use the software are put in danger or doubt. For example, with the reworded Residual Rights clause, the wording is much better. But there still remains a question whether someone using their Residual Rights is actually allowed to distribute their independant implementation, since the Residual Rights clause only says "creating or
contributing to an independent implementation", but nothing about distributing an independant impelementation, and III.C makes clear that the rights given under the JRL are all the rights one gets.
I am reasonably sure that Sun's intent of the Residual Rights clause is not to limit the redistribution of independant implementations, as long as those are free from Sun's copyrights and patents within the scope of the Residual Rights license, but the wording is hard to get right even for Sun's lawyers, without giving a 'free for all' distribution license on code that *might* infringe on Sun's copyrights and patents. I have a lot of sympathy for the task Sun's lawyers have at their hands there, as I know that writing good, tight software licenses is hard. All I can do is to tell you guys 'that's not good enough yet, and here is why:' until you arrive at the perfect non-free license.
One particular area of concern is that a lot of the code in some apis is reasonably trivial to implement, so we'll naturally end up with very similar implementations of, say, getters and setters. In order to avoid having to go to court over potential copyright infringement, that's again an area where being conservative simply means less trouble later. For how bad such things can go, see SCO's effort to claim copyright infringement on parts of linux kernel like errno.h: just because things look almost the same, does not mean that they are infringing or that it's possible to prove infringement or non-infringement in court without spending a lot of time and money. I am sure that it looked like a sure shot to SCO when they showed the BSD-derived malloc code to their lawyers, for example. I'd personally prefer to avoid having to spend a few years of my life in courts. James Gosling can surely relate to that.
That's why, I, personally, prefer to play it safe. I have no company, I don't make money off Kaffe, I don't get paid to hack on it, I don't have an army of lawyers at my disposal, so ... my interest in wasting my time and money by inviting potential legal issues is minimal. I prefer to avoid them as good as I can, and have fun hacking instead.
Of course, when Sun releases their implementation under a GPL-compatible software license, I'll enjoy sharing bit and peices with Sun and collaborating on actual source code, since I know a lot of bright people are working inside Sun, and it would be great to be able to work together. Until then, I think it's legally safest to go on separate ways, and wait until Sun starts gradually switching over to GNU Classpath, or relicensing their own code base under GPL-compatible terms. The Harmony golden bridge was something built with Sun in mind.
As far as Kaffe goes, I doubt that Kaffe will be very relevant in the future. It's mostly useful as a bleeding edge integration test bed for runtime technology and free software implementations of class libraries over dozens of different platforms. It will also serve us well to pave the way toward the first TCK-passing free implementation, once all of that gets rolling. But I'd expect Harmony to become the prevalent implementation over time, simply because the ASF has got a good relationship with Sun, there are bright people involved, and there is money to be made (IBM paying people), contrary to the more 'just for fun' linux-like attitude prevalent in Kaffe.
cheers,
dalibor topic
Posted by: robilad on September 27, 2005 at 01:43 PM
del.icio.us 
Digg 
DZone 
Furl 
Reddit
java.net RSS Feeds
