Thursday 9 June 2011

JCP - Bonn meeting October 2010

In writing my last blog entry I realised that I never wrote up details of the Executive Committee meeting in October 2010. Thus, this post is is mostly for the historical record, but it could be a useful pointer for the Google/Oracle lawsuit.

Why is this still relevant?

The Apache Harmony case can seem like an odd one to write about today. After all aren't we all happy that Oracle is investing in Java and Java SE 7 will be released soon? But in achieving this there has been collateral damage that cannot be resolved until the Oracle Gooogle lawsuit is resolved.

Apache only joined the JCP once it had established the right for any JSR to be implementable by Open Source in general, and Apache in particular. When Sun signed up to the JSPA legal agreement, they knew they were signing up to something that would allow another implementation of the Java SE specification.

When Apache Harmony began, Sun said nothing about restrictions that would prevent it completing. Only when Apache asked for the testing kit did Sun say something (or as I would say, change the rules).

The timeline is important. Legally important. In May 2005 we have this:

Part of the reason these Apache projects are possible is that the JCP has been working over the last few years to clarify the role of open source projects and also to improve overall transparency. For example there were changes to the intellectual property rules in JCP 2.5 specifically designed to allow open source implementations. There have also been a number of transparency improvements in JCP 2.6 to allow earlier access to specification information. In addition to those JCP updates, Sun created a scholarship program under which we have provided Apache (and other not-for-profit groups) with free access and free support for Sun's Java compatibility test suites.
...
The licensing rules for J2SE 5.0 were carefully designed to allow independent, compatible open-source implementations of the J2SE specification. Personally, I am not entirely sure if the world really needs a second J2SE implementation, but at the same time I am also glad to see that all the effort we put into getting the rules and the licensing issues straightened out is actually proving useful!

Graham Hamilton's blog VP and Fellow at Sun responsible for Java at the time, written May 7, 2005.
(My emphasis)

And lets look at how that was reiterated in the business terms for Java SE 6:

JSR 270: JavaTM SE 6 Release Contents
...
2006.10.24:
2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
...
7. Nothing in the licensing terms will prevent open source projects from creating and distributing their own compatible open source implementations of Java SE 6, using standard open source licenses. (Yes, you can create your own open source implementation of Java SE 6 if you really want to. But we're also doing everything we can to make it easy for you to use the original RI sources! See http://jdk6.dev.java.net.)

JSR-270
(My emphasis)

These two passages create a clear intent that Sun would not do anything to block Apache Harmony as an open source project under the Apache license. With the JSPA legal agreemnet and these additional statements, Apache acted, only to later be blocked.

I said "Legally important", because there is probably an element of estoppel here (but IANAL!).

Basically estoppel prevents a party (Sun) from promising one thing, causing another party (Apache) to act on the promise, and then changing its (Sun's) mind to its own advantage. Its still legally important today because a key plank of Google's defense against Oracle is that Apache Harmony would be a valid implementation of Java. To balance this, I must point out that Google wasn't directly involved in the Apache-Oracle battle (its a third party), so estoppel would only apply if Google could justify it acted based on the same promises (remeber IANAL!).

5th/6th October 2010 face to face JCP Executive Committee meeting

So, back to the JCP EC meeting. This meeting was the key event where Oracle announced its final decision on Apache Harmony. This was before Doug Lea, Tim Peierls and the Apache Software Foundation left the JCP, and before IBM moved from Harmony to OpenJDK.

The JCP had been debating the issue since 2007 (with private efforts to resolve the situation being made by Apache and Sun before it came to the JCP and before it became public). Oracle had originally (with everyone else) sided with Apache. Until Oracle took over Sun.

The first part of the meeting minutes show a vote:

Prior to this meeting Doug Lea proposed and Tim Peierls seconded the following motion:

It is the sense of the Executive Committee that the JCP become an open independent vendor-neutral Standards Organization where all members participate on a level playing field with the following characteristics:

* Members fund development and management expenses.
* A legal entity with by-laws, governing body, membership, etc.
* A new, simplified IPR Policy that permits the broadest number of implementations.
* Stringent compatibility requirements.
* Dedicated to promoting the Java platform.

Furthermore, the EC shall put a plan in place to make such transition as soon as practical with minimal disruption to the Java Community.

* Apache – yes
* Credit Suisse – yes
* Eclipse – yes
* Ericsson – yes
* Fujitsu – abstain
* Google – yes
* HP – abstain
* IBM – yes
* Intel – yes
* Werner Keil – yes
* Doug Lea – yes
* Oracle – did not vote
* Tim Peierls – yes
* RedHat – yes
* SAP – yes
* VMWare – yes
The motion was therefore carried.
EC meeting minutes

Clearly, most EC members viewed the correct solution to be an independent JCP. We also note two of the "quieter" JCP members avoiding voting Yes (HP and Fujitsu).

Patrick reported that Steven Chin replaces Wayne Carr as Intel's primary rep
EC meeting minutes

Wayne Carr was a strong supporter of Apache. He was replaced at the key moment in the debate, right before the key (first) vote on Java SE 7. I'll leave readers to speculate on why that change was made.

Don Deutsch reported that Oracle has spent several months in consultation with EC members, with developers, and with Java customers trying to work out a way forward. They have looked at a wide range of options and discussed various working arrangements, and finally concluded that Apache Harmony sets the stage for an inevitable fork. Even if Apache Harmony itself strictly complied with the TCK there is no ability to enforce compliance downstream (Apache cannot guarantee that either Apache communities or downstream users will strictly comply with compatibility requirements.) Consequently, Oracle has concluded that they cannot grant Apache a TCK license. Don stated that this decision is final - it will never change. He said that Oracle doesn't believe that the Java community fully understands the risks and consequences of a fork, noting that the Google Android situation is analogous to that which caused Sun to take legal action against Microsoft several years ago.
EC meeting minutes (my emphasis)

This is the key paragraph. The argument is couched in terms of a fork and references Android directly. No mention is given of Java EE where competing implementations are deemed positive, not negative. More specifically, Oracle state that their decision is final. Personally, I disagree with the notion that the Android case is analagous to the Microsoft case.

Don acknowledged that the community is frustrated by the lack of technical progress caused by this licensing dispute and said that Oracle plans to move forward with delivering new Java technologies through OpenJDK. Developer reaction to the plans announced at JavaOne was very positive. He said that Oracle will submit umbrella JSRs for Java SE 7 and Java SE 8 shortly after this meeting and that Mark Reinhold will present details of their contents later today. The JSRs will be presented with similar license terms as previous umbrella JSRs.

Don stated that the developer community did not want a licensing dispute to halt the evolution of the Java platform, and argued that it was in the interests of both Oracle and the community to move forward. Oracle very much wanted to make progress within the JCP, but if this was not possible it would be necessary to find another way to advance the platform.

Don concluded that it is in Oracle’s interest to have partners who increase their use of Java. He said that Oracle wanted to make OpenJDK more collaborative and more useful to licensees, since other Java vendors have a vested interest in moving forward with Oracle. He said that all partners are welcome to join Oracle, and emphasized that Oracle wants to enter into long-term and stable contracts with licensees to reduce the risks to both parties. He promised that Oracle will be a trusted and stable Java partner and reiterated that Oracle's primary economic interest is in furthering Java rather than in extracting revenue from it.
EC meeting minutes (my emphasis)

The second of these paragraphs indicates that there was a clear statement that Oracle would proceed with Java SE 7 with or without the blessing of the JCP. (Apparantly it was stated more clearly in person)

As stated, the JSRs for 7 and 8 were released a few days later, and contained the same restrictions.

The last paragraph is interesting when you look at timing again. The paragraph provides a welcome to other partners to join OpenJDK. An offer made on the 5th October. One week later on the 11th October, IBM abandoned Harmony and joined OpenJDK. Would the Oracle and IBM reps at that table have known about that upcoming deal?

Jason Gartner said that IBM was disappointed with this decision - it wasn't what they wanted. He expressed the hope that if he was in Don's position he would be giving a different message, but of course he was not. He argued that Oracle is not Sun, and will not change their minds. The important question was what to do next. He pointed out that the JCP had been in stalemate since 2007, and it was necessary to be constructive and to move forward. He said that he was looking forward to hearing about the plans for Java SE 7 and SE 8.
EC meeting minutes

Would IBM therefore have been a better steward of Java? IBM believe so, perhaps unsuprisingly. But this also suggests that IBM is looking forward, beyond the dispute.

Scott Jameson said that the topic under discussion was licensing and Field of Use (FOU). He noted that FOU restrictions were the root cause of the dispute, and asked Don to comment on whether or not FOU restrictions violate the JSPA. Don responded that Oracle intended to continue to offer licenses on the existing terms.

Doug Lea pointed out that there is no Java 7 JSR because the EC believes that members should conform to JSPA. He argued that FOU-restricted licenses violate the JSPA and suggested that the JSPA be changed. Josh pointed out that Oracle is on record as saying that FOU restrictions violate the JSPA. He asked whether they still feel that way. Ken Glueck responded that Oracle came to talk about the Apache issue. He pointed out that Don had been straightforward and candid. Doug responded that EC members accept Oracle's determination not to grant Apache a license, but argued that they cannot vote to approve a violation of the JSPA. He argued that if Oracle wished to withhold a license from Apache it must be on different grounds or the JSPA must be changed.

Mike DeNicola asked whether Oracle was saying that they wouldn't grant a license to Apache under any circumstances or whether - like Sun - they ware saying that they wouldn't grant a license except with FOU restrictions. Ken Glueck confirmed that Oracle's position is the same as Sun's. Geir Magnusson said that this was the impression that he also had. Don Deutsch confirmed Oracle's position was that no unencumbered license would be offered to Apache.

Doug asked Oracle to acknowledge that it was asking the ECs to condone breaking the JSPA rules. He said that if he was put in a position where he had to condone breaking the rules he would have to resign. Ken said that he understood, and would regret it if Doug resigned, but pointed out the importance of allowing the conversation to go forward. Josh Bloch asked again whether Oracle, who were on record as saying that to deny Apache a license without FOU restrictions is a violation of the JSPA, still feel that way. Ken Glueck responded that Oracle were not prepared to answer a legal question. Josh responded that Oracle had been willing to vote on this matter twice in the past. Ken responded that this is the situation now. Tim Peierls noted that Oracle has had plenty of time to prepare an answer. Ken pointed out again that the platform is stuck and we need to move forward.

Doug Lea suggested that Oracle propose JSPA changes to legalize the situation, making it possible for ECs to approve the SE JSRs since they would no longer be in violation of the JSPA. He argued that this would be a simple matter, and should be done as part of the JCP.next proposal. The JSPA could be changed so that Oracle is no longer obliged to grant Apache a license. Ken thanked Doug for his constructive suggestion, noting that the JCP.next discussion hadn't yet happened. He asked others for their thoughts on this matter. Several members pointed out that modifying the JSPA was a more complex task than Doug had suggested, and might take months or even years.
EC meeting minutes (my emphasis)

In the first highlighted part, Doug Lea links Java SE 7 to the dispute, confirming my original blog in 2009.

In the rest of this passage, Oracle effectively blocks questions about why they changed their mind on the JSPA. In the second and third highlighted parts, Josh Bloch pushes the point - Oracle agreed that Sun's action was in violation of the JSPA, yet now they were doing the same. The point was batted away.

Personally I believe that Sun's reason for denying Apache Harmony was to protect Java ME licensing revenue (Sun was broke), while Oracle's reason was the Google lawsuit (which is clearly higher priority than a vibrant Java community). Corporately, Oracle must feel very strongly about attacking Google, because they were willing to change their minds on this issue in a way that looks incredibly stupid, especially with no attempt to justify it (because its at the heart of the lawsuit against Google...).

EC members also called for the JSPA to be changed as they could not condone breaking it. This proposal to change the JSPA is essentially from a similar vein as my Split JCP proposal. Doing so would have greatly lessened the damage to the JCP, but Oracle chose not to do so (perhaps because doing so would be a tacit admission of fault in a document key to the Google lawsuit).

Mike DeNicola addressed the question of why the EC was focusing on licensing given its supposed charter. He noted that the JSPA requires the submission of a JSR and that the ECs were the Expert Group for the JSR that defined the JSPA. They wrote the rules (he was involved.) This is how they got involved in licensing. When the FOU issue was first raised EC members said "when we wrote the current version of the JSPA we intended to move towards standardized open licenses. We removed restrictions from the spec license, but we overlooked the TCK license." Sun lawyers had argued that the JSPA didn't restrict what could be written in TCK licenses but EC members disagreed. Oracle's lawyers now seem to have reached the same conclusion as Sun did. He argued that it was necessary to move forward and that this discussion was not constructive. Lawyers should review the JSPA and if necessary they should suggest changes to clarify its intent.
EC meeting minutes (my emphasis)

In this later passage, we have some history on how the mess happened. It is suggested that the testing kit was an oversight and that the lawyers of EC members and Sun (now Oracle) disagreed over whether the JSPA did or did not allow testing kit restrictions.

But if you look at the statements at the top of this blog, you'll get a different set of opinions, suggesting Sun's legal opinion was a later thought to wiggle out of a contract they no longer liked.

Josh read the resolution recently proposed by Doug Lea (as recorded at the beginning of these minutes.). He noted that it was passed without objection, but without a vote from Oracle. He had asked why Oracle didn't vote. Don Deutsch asked why Josh was raising this again. Josh responded because he still hoped to see an independent organization. Don responded that he had originally proposed this motion back in 2007, and expressed his surprise that Josh cast Google's vote in favor of the motion since the wording included a statement about the importance of compatibility, which Google did not seem to care about. He pointed out that nobody had offered to pay for the Java assets, nor for the very significant ongoing expenses of developing the Java platforms. Oracle did not vote on the resolution because it was orthogonal to the issues the EC was addressing. Later in the discussion Josh responded that Google does care about compatibility - when they build something that they claim is standards-compliant they work hard to make it so.
EC meeting minutes

In this later revealing section, Google and Oracle clash. Oracle says "Google doesn't care about compatability". Google says "we do when we claim it is compatible" (ie. we didn't claim Android is compatible).

Don's comments about Java assets prompted a discussion about the difficulty of forming an independent organization without control of the Java brand and without ownership of the core assets of the Java platform. (Josh Bloch and Geir Magnusson argued that it would not be necessary for an independent organization to own the Java assets.) Jason Gartner pointed out that Oracle owns the Java brand and will not give it up. EC members could still work to influence Oracle. There was general agreement (if not approval) of this situation.
EC meeting minutes

And here is the final part of that section. An independent JCP is meaningless without the Java brand, but Oracle will not give it up. The final sentence rather suggests the EC members were beginning to give up, which they formally did when they passed the Java SE 7 JSR into being at the expense of Doug Lea, Tim Peiels and Apache leaving the JCP.

Summary

As I said, I'm no longer here to change minds. But as this blog effectively acts as a record of the dispute it only seems right to documnet a missing piece. (I didn't write about this at the time because these meeting minutes were, unsurprisingly, delayed in publication).

And I have pointed out, this dispute is clearly referenced by Google as part of their defence against Oracle.


Stephen Colebourne
Apache Software Foundation member, speaking personally
Oracle Java Champion, speaking personally
Not a committer on Harmony or OpenJDK

Tuesday 7 June 2011

Java SE 7 passes in the zombie JCP

So in the end, there is a "Java SE 7". The vote at the JCP Executive Committee passed. But since I first started following this story back in 2009 its been a long road with a huge political fallout.

The Yes vote today happened because Oracle made a decision to kill Apache Harmony. A decision that was a continuation of Sun's policy, but one that Sun was not strong enough to make happen. Oracle's decision was to tell the JCP that it would proceed with version 7 no matter what the Executive Committe voted.

The cost of this decision was that Doug Lea, Apache and Tim Peierls left the Executive Committe. As such, I view the JCP as a zombie and under no circustances an Open Standards body, as promised in 1996.

You cannot claim to be an Open Standards body if you do not allow implementations of the specification.

So, this vote today is realy the end of a very long story - see below for the full history of blogs. As always in the JCP votes, the Yes/No vote is only half the story. The comments tell you the rest:

On 2011-05-31 VMWare voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-05-31 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-01 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-01 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-02 IBM voted Yes with the following comment:
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
------------------------------------------------------------------------------
On 2011-06-02 RedHat voted Yes with the following comment:
Red Hat's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. Red Hat would prefer a licensing model that creates an open arena for everyone, including those not members of the JCP and removes any ability for one individual or vendor to exert undue control over a standard. We are an open source company and hence would like to see such a licensing model for JCP contributions. Note however, that this comment is not necessarily directed at the license terms for this JSR, but is a statement of Red Hat's preferred licensing model.
------------------------------------------------------------------------------
On 2011-06-02 SAP AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-02 Google Inc. voted No with the following comment:
While Google supports the technical content of this JSR, we are voting no because of its licensing terms. As per the JCP resolutions of 9/25/2007 and 4/7/2009, "TCK licenses must not be used to discriminate against or restrict compatible implementations of Java specifications by including field-of-use restrictions on the tested implementations. Licenses containing such limitations do not meet the requirements of the JSPA, and violate the expectations of the Java community that JCP specs can be openly implemented."

The proposed license clearly violates this requirement (see Exhibit A, Section II). Oracle was duly reminded of this when JSR-336 was first proposed, but has done nothing to address the issue. It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license, as this clearly violates the JSPA, by Oracle's own admission. Google does not want to slow the progress of this release, but we do believe it is critical that this issued be addressed, in order to comply with the JSPA and to preserve the openness of the Java platform.
------------------------------------------------------------------------------
On 2011-06-05 Keil, Werner voted Abstain with the following comment:
While I wish new and improved versions of Java to be released as soon as possible, given multiple delays in the past, the lack of transparency both in this Umbrella JSR and relevant components (especially Project Coin) fuel my decision to abstain here.

Not only have other EC members expressed their discomfort with this situation and confirmed some of these developments behind closed doors they demanded being opened, haven't been. The Spec Lead has also publicly admitted he wished, more of the SE-related activities were open and transparent than they were so far.

Given the efforts for more transparency by JSR 348 were just accepted by a larger majority than even this JSR or most others in SE/EE, I hope some more existing JSRs respect this and become more open especially if related projects even use names like "Open..."
------------------------------------------------------------------------------
On 2011-06-05 London Java Community voted Yes with the following comment:
The LJC votes Yes to the JSR for SE 7 based on its technical merit and our very strong desire to get Java moving again.

We note that the archives for some of the Expert Groups that comprise this JSR have not yet been made public, despite a promise from Oracle to do so. We do not feel that this is appropriate for a public and open standards body. In particular, Oracle's silence as to why the archives have not been made public is harmful to community participation, i.e. the community has no access to historical technical discussions, which are vital for participating in future Java language initiatives.

Going forward, we are unlikely to support any JSRs that do not meet minimum standards of transparency.
------------------------------------------------------------------------------
On 2011-06-06 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-06 Goldman Sachs & Co. voted Yes with the following comment:
Goldman Sachs votes Yes on JSR 336 based on its overall technical merit and our support for moving the platform forward

This umbrella JSR suffers from an overall lack of transparency compounded through inclusion of other JSR's as components which in turn are opaque. We clearly need to improve the transparency of the constituent parts and ensuing that the community has a clear understanding of what is coming. We are hopeful that JSR 348 (JCP.Next) starts to address these issues
------------------------------------------------------------------------------
On 2011-06-06 SouJava voted Yes with the following comment:
SouJava votes yes on this JSR based on its technical merits. Our members are satisfied with the evolution of the technology, but are unhappy with how the licensing terms in this proposal discriminates against open source implementations, and how this can negatively affect or influence other JSRs. We also have concerns about the lack of transparency of some of the JSRs involved in JSR 336, and how it has negatively impacted the Public Review process. We urge the Spec Lead to rectify this immediately, long before the Final Draft is presented.
------------------------------------------------------------------------------
On 2011-06-06 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-06 Fujitsu Limited voted Yes with the following comment:
Fujitsu's vote is based on the technical merits of this JSR, but not based on the licensing terms.

------------------------------------------------------------------------------

Considering this is a major release of Java, a platform used by more than 8 million developers, those comments are not a ringing endorsement.

Specifically, the comments note that Oracle's promises to have open and transparant JSRs have not been fulfilled.

More broken promise then. Why am I not surprised.

As I said, there used to be a Deal. Where the owner of Java makes a large investment and the community makes it relevant. By constantly thumbing its nose at the Java community, Oracle is harming its own interests. But I don't think they care anymore.

And yet, it could still be fixed - <tounge-in-cheek>Apache OpenJDK anyone</tounge-in-cheek>?

Stephen Colebourne
Apache Software Foundation member, speaking personally
Oracle Java Champion, speaking personally
Not a committer on Harmony or OpenJDK


This is the history of my blogs on the topic. I've starred my favourite entries:
No more Java 7 * - March 2009 - the first article linking Java SE 7 and Apache Harmony
A question of IP - March 2009 - a decription of how IP works in the JCP
Sun, Apache & IP - in pictures! * - March 2009 - a pictorial view of how IP works in the JCP
Shedding new light on No Java SE 7 JSR * - March 2009 - the first analyis of the JCP Executive Committee meeting minutes
The ASF perspective - April 2009 - the first analysis of the Apache Software Foundation meeting minutes
The JCP doesn't exist * - April 2009 - showing how the JCP is a department, not an organization
The Oracle perspective - April 2009 - discussing what Oracle might do now they were taking over Sun
US DOJ investigation - June 2009 - pointing out that the DOJ could intervene
JSRs submitted over time * - October 2009 - graph of the submission of JSRs over time
Power corrupts. Absolute power corrupts absolutely. * - August 2010 - Oracle chose to sue Google and break the community
The end game - October 2010 - Oracle entices IBM from Harmony to OpenJDK
Does Oracle have enough votes - October 2010 - analysis of voting intentions in the first vote on Java SE 7
Pragmatism or bust * - October 2010 - voting Yes rewards the bully, but voting No would end the JCP
Split JCP proposal * - October 2010 - IMO, still the best approach for the future of the JCP
Stacking the JCP election - October 2010 - where I claimed Oracle was manipulating the JCP election
My election choices - October 2010 - my choices for the JCP Executive Committee election
Bablyon 5 & the Great War of Java * - October 2010 - a look at the big picture using Bablylon 5 as an analogy
Four viewpoints of War - October 2010 - analysis of the comments of four major players
JCP election result - November 2010 - summary of the JCP Executive Committee election
Premium JVM thoughts - November 2010 - a premium JVM scared people but proved to be a non event
ASF ready to leave the JCP - November 2010 - the ASF announces that the Java SE 7 vote could result in it leaving the JCP
Oracle replies to the ASF - November 2010 - I decode the Oracle press statement to mean the exact opposite of what it appears to say
Java SE 7 and 8 JSRs published * - November 2010 - detailed analysis of the licensing mess that Java SE works under
Devoxx whiteboard votes - November 2010 - developer votes referring to the issue
First Java SE 7/8 votes pass - December 2010 - brief analysis of the voting, noting Intel's change of view and representative
Is the JCP dead * - December 2010 - questions the viability of the JCP once Doug, Tim and Apache left
The Deal * - December 2010 - my take of the deal between Sun and the community that Oracle doesn't understand
What about JSR-310 - December 2010 - my choice to continue JSR-310, using the JCP as a tool rather than a standards body
JCP Bonn meeting - June 2011 - notes on the decisive JCP meeting in October 2010