|
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. SummarySometimes a picture tells the story clearer than text. Hopefully, these pictures will help illuminate you. If not, you can always read the legal agreement. 
10 comments:
|
|
|
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.