This blog explains the JCP IP process in pictures. And how Sun have managed to use it to block Apache Harmony.
IP in the JCP - how it should work
Within the expert group, a number of experts make contributions. Each member agrees, as part of the JSPA agreement, to grant their IP to the spec Lead. The spec lead will also add IP in the same way. This produces a 'pot' of collective IP owned by the spec lead on behalf of the expert group.
The expert group produces two outputs in addition to the IP - the specification itself and the testing kit.
An implementor of the specification uses the specification document (which may well include Javadocs) to develop the implementation. The implementor will probably have their own unit tests at this stage.
When the implementor feels that the development is nearly complete, they request the testing kit (TCK) from the spec lead. They then use that to test the implementation (and fix any bugs).
Once the testing kit has been passed, there is another stage that isn't found in a typical project. This is the stage of 'obtaining the collective IP' from the spec lead. This should be automatic if the testing kit is passed and the implementation is complete and valid.
Finally, the implementation can be released. It can now claim to be a compatible implementation of the JSR. And the collective IP has been granted to avoid any unpleasant surprises down the road for users.
What about Apache Harmony?
Well, its important to realise that Sun didn't expect that Harmony would succeed. They thought that the task was too big. As such, they assumed that they would never need to worry about providing a Java SE testing kit, even though they'd agreed to do so.
Instead of keeping to the agreement they had signed, Sun used its lawyers to come up with a cunning way of blocking Harmony:
What Sun did was add a 'Field of Use' clause (FOU) to the license for the testing kit. This clause infected the tested code, and thereby infected the release.
The precise details of the FOU are confidential at the behest of Sun, however in summary they state (rather absurdly) that the tested code cannot be run on a PC in an enclosed environment. Thus, you could run a tested version of Harmony on your PC providing it is running on your desktop. But if you pick the machine up and place it in an enclosed cabinet, such as inside an X-Ray machine, or an shopping mall information kiosk, then you would be breaking the FOU clause.
Sounds absurd? Well it is yes.
But remember, Sun didn't need something sensible. They just needed something, anything, to stop Harmony.
By adding this clause, it meant that the tested code would need to contain an additional clause over and above the standard Apache license. A clause that would be invalid for any open source software as defined by the OSI. To be clear, this FOU clause would be an issue for any open source group trying to implement the Java SE specification.
Since Apache only releases open source licensed code, Sun could therefore effectively block the release of Harmony. And in the meantime, it could spend all its efforts fooling everyone that Java is an open standard using the Open JDK initiative - an open implementation, not an open standard.
Summary
Sometimes a picture tells the story clearer than text. Hopefully, these pictures will help illuminate you. If not, you can always read the legal agreement.
As you said, the picture definitely cleared as to where the community. The big question is what can the community do to break the year(s) old deadlock with Sun Microsystems.
ReplyDeleteBTW - how do we have IBM JDK and JRockit JDK implementations of Java? Is that somewhat different? Sorry for my limited knowledge.
I wish all standards bodies (and the JCP) had illustrations of their processes as clear as these pictures.
ReplyDeleteEnclosed sounds a lot like mobile. Maybe they are trying to protect the biggest cash cow they have from java. Interesting.
ReplyDeleteI understand what you described and think it is unfortunate. I sometimes wonder why other vendors create their own JDKs. Can you tell me who has expressed interest in using Apache Harmony? Personally I'm not interested in anything but the Sun JDK and wouldn't use Harmony even if it passed TCK.
ReplyDelete@Sandeep: Both IBM and JRockit pay Sun to commercially license the class libs.
ReplyDelete@Ryan: I think that IBM contributes heavily to Harmony, perhaps in hope of having a truly free impl one day. Android uses Harmony pretty heavily, too.
Wish we had you explaining such things several years ago. Clear, precise and to the point.
ReplyDeleteTake that you bloated, grandiose Sun FUD :)
Now that the word is out, how can we effectively use Digg and Twitter the change the issue?
ReplyDelete@Sakuraba: You ask how to change the issue. Part of the problem is that the TCK (and now opensourced OpenJDK implementation) cost some money for Sun in order to pay salaries of a lot of people. Sun has to find a source of income. IMO Apache can't ask to a company to give any of its core value: for Sun, that could mean a major opensource contributor would close the door.
ReplyDeleteSo I have an idea for Apache. If Apache pay for the TCK just like IBM and BEA (jrockit) probably did, it would smooth the deal. Ok Apache is not for profit, but with some dedicated donations from people around the world and from IBM/Oracle, Apache would have money to pay the man hours of Sun. And two major opensource contributors and their employees would be happy.
(IMO there is a problem for IBM selling websphere and RAD for a lot of money and investing heavily in harmony: http://www.ibm.com/developerworks/java/jdk/harmony/, and then for harmony to ask from Sun to give something for free).
@evernat, There is a formal process, agreed in 2002, by which Sun sponsors open source projects to pass the tests of the JCP. Sun have been fully willing to give the testing kit to Harmony for $free.
ReplyDeleteThe problem is (whether paid for or not) that the license for the testing kit "poisons" the tested code, and means that it ceases to be open source.
I believe that the field of use clause violates antitrust law due to its anti-competitive nature. A field of use clause not only affects open-source independent implementations of Java SE, but also closed-source independent implementations of the JDK. Such a field of use restriction prevents competitors from licensing a Java SE implementation that passes the JDK for use in X-ray machines, kiosks, or similar applications.
ReplyDelete