If Executive Committee members of the Java Community Process don't like how Oracle is handling Java and the JCP, then why don't they just vote no when big Java issues come up? Business reasons are key, but a recent olive branch from Oracle may have helped turn the tide in Oracle's favor.
First, let's look at 13-1 vote that approved the release of Java SE 7 this week and see how each member of the 16-member committee voted.
[Also see: 2011 IT salaries: region by region]
Taking care of the missing members first, Credit Suisse did not vote at all and Werner Keil submitted an abstain vote. Keil's comments pretty much sum up problems his fellow members are having:
"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...'"
Oracle's openness, or the lack thereof, still rankles with the members of the committee, but not all, at least publicly. VMWare, Intel, Eclipse Foundation, Inc. Hewlett-Packard, SAP AG, and Ericsson AB all voted yes, without comment. Oh, and Oracle, too, of course.
But the remaining six yes votes all had issues with "openness," "transparency," and Oracle's "opaqueness." Those voters were SouJava, IBM, Red Hat, the London Java Community, Goldman Sachs & Co., and Fujitsu Ltd. Fujitsu's comment was short and sweet: "Fujitsu's vote is based on the technical merits of this JSR, but not based on the licensing terms."
The single no vote was, as one might expect, from Google, which is currently locked in a legal battle with Oracle over alleged infringement of Java within Android's homegrown Dalvik Java machine. Officially, they too weren't thrilled with the way Oracle is handling the JCP. Google was less politic than the other commenters, though, and way more specific:
"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."
While Google didn't come out and mention them by name, this statement mirrors the reasons the Apache Software Foundation left the JCP late last year. Oracle, as the sustaining member of the JCP, had not granted a test compatibility kit (TCK) license to the ASF's own Java implementation, Project Harmony, due to specific incompatibilities in the TCK's license. Without the TCK, Harmony could not be tested and certified against the Java standard. This effectively reduced the potential user base for Harmony, which the ASF claims is likely the reason why Sun Microsystems, the original sustainer of Java, inserted the incompatible language into the Java license in the first place.
What's interesting here is that while all of these members seemed to vote in blocs, their motives were probably very different. IBM, for instance, would like to have Java under a more permissive license in general, so you know that's why they grumbled. But not too loudly, since they're working with Oracle on other things. Red Hat, like Google (and Apache), would like some leeway in the TCK so they aren't beholden to the whims of Oracle to get their Java work done. The London Java crew has been cautiously optimistic about Oracle of late, particularly with the latest proposals from Oracle to kick open the JCP a bit more.
So everyone has a reason to complain, but it's not enough to actually hold back the progress of Java SE 7. The collateral damage could be pretty significant if the JCP stymied Oracle's momentum. Oracle has a lot of partnerships with most of the other members of the JCP Executive Committee, and that's a lot of boats it could rock. These members don't think it's worth it to try to get Oracle to change their license now.
I suspect Oracle's new JSR proposals had a lot to do with that outcome. JCP.next JSR 1 (JJ1) is supposed to focus on changes to the JCP Process Document in the following areas: transparency, participation, agility and governance, while JCP.next JSR 2 (JJ2), will focus on modifying the Java Specification Participation Agreement (JSPA). These may have been the pressure release that swung the yes-with-comment members of the committee over to the yes side instead of blowing their tops and voting no. By giving the committee a ray of hope, Oracle may have staved off a rebellion. Without JJ1 and JJ2, more members of the committee may have calculated that now was indeed the time to make a stand.
Of course, JJ1 and JJ2 will have to satisfy the members' desire for transparency for this to ultimately work out for Oracle. Otherwise, the next vote might not go as easily for them.