I'd like to propose a compromise to the Executive Committee of the Java Community Process.
JCP compromise proposal
Firstly, a reminder. I do not speak on behalf of the Apache Software Foundation (or anybody else). This proposal is not endorsed by the ASF, nor do I have any indication that they would accept it. However, were Oracle and other members agree, I would recommend it to the ASF in my capacity as a member.
The compromise is around precisely what the JCP is, and what participants care about.
1) The JCP is a department of Oracle. It is not an independent body, and all legal agreements are between the member and Oracle (previously Sun). The dispute has caused grave mistrust in all other parties to the JCP, as Oracle has been shown to have all the power.
2) The JSRs, expert groups and development of specifications in Java EE, those built on Java ME and other non-core areas are functioning pretty well and still produce viable specifications. I call these the "ecosystem" specifications. Very simply, the JCP acts as neutral territory where multiple competing parties can lay down their weapons, talk, resolve conflict and produce results that benefit them all.
3) The JCP also hosts a few JSRs that are targetted at the very core of the platform. This includes the Java SE, ME and JVM specifications. I call these the "core" specifications. In each of these, Sun (now Oracle) has always and will always take the lead. They put in the vast majority of the money and act as the final decision maker. Oracle have made it clear that for these key areas they intend to retain that absolute power, while still listening to the community for advice and guidance.
4) The difference between the JSRs and approach in the core and those in the ecosytem is clear and absolute. Within the core everything is controlled and the community has only ever made requests of the company in power. Within the ecosystem neutrality and trust is vital, and here the community and vendors have done fantastic work.
5) The entire Apache Harmony dispute arises because the JCP places the management of the core and the ecosystem in one organisation and tries to apply the same rules. Both Sun and Oracle have refused Apache the TCK for Harmony because doing so crosses the red line between ecosystem and core. The problem is that the red line isn't explicit. (There are a whole heap of complexities and who said what to whom on top, but at its heart the red line is the issue.)
6) Therefore, I propose that the JCP should be divided in two.
Firstly, Oracle would publicly state that it is removing the core JSRs from the JCP and bring them in house. It would setup a separate formal body to provide advice and guidance on the core, but all participants would understand the limitations to their contributions. Clearly, the Java SE work would be focussed around OpenJDK as in Oracle's current plans. As part of this, there would be no vote on Java SE 7, as it would no longer be a JSR controlled by the JCP.
Secondly, Oracle would set the ecosystem part of the JCP free as a fully independent standards body organisation funded by all its members. The new organisation would be expected to produce clear membership rules including the ownership and management of IP.
A message for Oracle
Forcing though a Java SE 7 vote in the existing JCP doesn't solve your problems with the other vendors or the community. The real issue is the pretence that the JCP members have any control over the core specifications. Pretending that they do is a fraud, Apache Harmony exposed that red line and its time to break the JCP in two to solve it.
I strongly believe that you (Oracle) need the neutral ecosystem part of the JCP. It is in your interest to maintain and enhance that (as those ecosystem specifications are where you really get value). But an ecosystem standards body relies on trust with other vendors and community members. That trust is very low right now, and going to be non-existent if you force through the Java SE 7 vote. Just because you can win the vote doesn't mean that it is in your interests to do so. I'll also note that there is nothing stopping ecosystem participants creating their own standards body and excluding Oracle if they conclude that the loss of trust is fatal.
I believe that this compromise is very much in your (Oracle's) interests as it provides enough clean fresh air to get everything moving again while retaining control in the area you really care about.
A message for the Apache Software Foundation
This is a compromise and it means accepting that Apache Harmony cannot be an independent Java SE implementation. But pretending that there is any way for it ever to be one is at this point seems delusional. The gain on offer in the compromise should be clear - a clean functioning, independent body for Java ecosystem standards with sensible membership rules and IP management. This is a huge win compared to the current position.
I strongly believe that you (Apache) must not take that position that it requires Java SE to be an open specification in order to build useful code in the wider ecosystem. The C#/.NET platform is tightly controlled by a single vendor yet it can be used. The hardware isn't exactly open either. One might even argue that Linux is a similar very tightly controlled core with an open and thriving ecosystem on top. Its time to recognise that the core is frequently heavily controlled. And for good reason.
I believe that this compromise is very much in your (Apache's) interests as it finally clears up the rules and red lines in the world of Java.
A message for other EC members
I strongly believe that this compromise serves the needs of all parties better than being strong-armed. If you think it does, then ask Oracle and Apache to consider it before the Java SE 7 vote. After the vote will be too late.
Summary
The proposal is to split the JCP in two to finally be honest with everyone (vendors and community) as to the core that Oracle controls and the ecosystem standards body that everyone shares.
If you're a community member or vendor and like this compromise proposal please retweet or blog using #splitjcp.
Stephen Colebourne
Apache Software Foundation member, speaking personally
Oracle Java Champion, speaking personally
Not a committer on Harmony or OpenJDK
