JCP votes for Java EE 6: Apache says no in protest, SpringSource plays a deeper game
Submitted by Josh Fruhlinger on Fri, 03/06/2009 - 00:51.
Oh, hey, look, Java EE 6 has been approved by the JCP! Now it is all over but the shouting, and by "shouting" I mean "intensive work by IBM and Oracle and others to produce enormously complex and expensive implementations of the standard in their app servers." The approval of the standard did not really seem to be in doubt, but it's interesting to note (as you can on the above-linked page) who the naysayers were. The only no vote was from the Apache Foundation, which was not actually about Java EE 6 per se but rather about Apache's long-running dispute with Sun about the Java Compatibility Kit. This dispute is in important one that makes my head hurt every time I try to wrap my little brain around it; basically, Sun only lets you use the JCK (which is the tool that determines whether your implementation of Java actually meets the Java standard) for free if you're intending to license your implementation under the GPL; Apache licenses things under its own open source Apache License, and says that this policy of Sun's is violating the Java Specification Participation Agreement, which states that specifications should be royalty free and ... yeah, I know, it's complicated. (UPDATE: And, yes, I've managed to botch this explanation. See the comment below from Stephen Coleborne for a better version.) In this vote, the Apache Foundation specifically said that its "no" was "not a statement about the technical merit or quality of work done by the Expert Group to date, and if it were not for the unresolved non-compliance by Sun, Apache would most likely vote 'Yes'."
But SpringSource's reaction was more interesting -- they chose to actively abstain (as opposed to the Eclipse Foundation and Nortel, which simply didn't vote). The company offered its reasons -- no minimal Web profile, "as has become the choice of most enterprise Java users," JSR 299 is unproven, the end result doesn't match the original spec request. (Some of these complaints were also voiced by other committee members, like SAP, who nevertheless voted yes.) And yet this abstention -- not a yes, not a no -- intrigues me, and I'm trying to figure out what exactly it portends. Perhaps by not voting no, SpringSource's Rod Johnson, whose agreement to take a place on the committee was a turnaround on his part, is trying to show that he's not an obstructionist or an ideologue. And yet by not voting yes, he manages to keep SpringSource's distance from the latest Java EE standard. None of SpringSource's current products implement the Java EE standard; and now, with the absence of the lightweight Web profile SpringSource wanted, SpringSource senior vice president of engineering and product management Peter Cooper-Ellis says that the company will only implement the parts "that make sense," which as I read it means that you won't see the any of the SpringSource servers bearing the Java EE 6 certification anytime soon.
I don't mean to imply the SpringSource was being disingenuous throughout this process -- certainly Rod Johnson's gushing blog post from a year and a half ago on Java EE 6 was genuine enough. But I think that SpringSource believes that Java EE needs its ideas -- specifically, the concept that more lightweight app servers are the future -- more than SpringSource needs the Java EE seal of approval. Maybe SpringSource thinks it will make progress on its own while IBM and Oracle are doing all that heavy lifting.
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2008 Network World, Inc. All rights reserved.
"basically, Sun only lets
"basically, Sun only lets you use the JCK ... for free if you're intending to license your implementation under the GPL; Apache licenses things under its own open source Apache License, and says that this policy of Sun's is violating the Java Specification Participation Agreement, which states that specifications should be royalty free and ... yeah, I know, it's complicated"
Sadly, this summary is far from accurate. Firstly, its nothing to do with money - Sun is willing to give Apache the relevant code for $free. Secondly, its nothing to do with the Apache license vs the GPL - Sun's offer is equally invalid whatever license Apache Harmony used.
Basically, Apache produces many implementations of JSRs (Geronimo and Tomcat amongst them) and had no problem obtaining suitable testing kits. However, for Apache Harmony, and uniquely for Harmony, Sun chose to offer the testing kit under a license whereby the tested code wouldn't be open source. Obviously, Apache can't accept that. Further, the license offered for the testing kit is contrary to the agreements signed between Sun and Apache.
Many people think this is some minor, esoteric discussion of no importance. They couldn't be more wrong, but since the rest of the information in this dispute is private, I can't tell you why. I would point readers at the vote threads of JCP votes since the dispute started to see what other JCP companies think on the subject.
Stephen Coleborne
Member, Apache Software Foundation, speaking personally
oops...
Thanks for the correction, Stephen; I've added a note to the blog post and a link to your comment for more information.
I understand if you can't comment further, but: Is the nature of this dispute literally private? That is, has Sun's reasoning for its move regarding the kits for Apache Harmony literally not been made public anywhere, by agreement between Sun and Apache?
Privacy
You can trust that Apache would publish the details of the proposed license/contract if they could :)
[another Apache member, speaking personally]
Thanks for the correction.
Thanks for the correction.
Why No on EE over spat with SE
Apache is using its vote in the EE sphere to make known its displeasure in the SE world, I can't see how this can only hurt them. Right or wrong they will be perceived as petty or obstructionist in the process and only gives Sun a valid reason to push them out of.
open letter
Apache open letter about Java SE claimed that a confidential license for a required JCP test suite restricts how Independent Implementations of that JCP spec can be used.
________________
VirgilM part of cheap cigarettes team.
what about Red Hat?
what about Red Hat Middleware LLC?
they're part of the EG for JSR-316:
http://jcp.org/en/jsr/detail?id=316
Interesting how JBoss AS always gets "skipped" in JEE implementation discussions...
IBM’s vote is based on the
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 1Y0-A09 exam. 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.
The Spec Lead has told us there are no “field of use restrictions” on implementations for this particular JSR. The Apache open letter about Java SE 1z0-042 exam claimed that a confidential license for a required JCP test suite restricts how Independent Implementations of that JCP spec can be used. Licenses to test for JCP compatibility must not be used to limit or restrict competing, compatible implementations; licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates. For every JCP ballot 1z0-051 exam, we will ask the Spec Lead whether such restrictions exist in their license.
Re:
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.
bachelor degree business | get degree | online degree school
Re:
I can't see how this can only hurt them. Right or wrong they will be perceived as petty or obstructionist in the process and only gives Sun a valid reason to push them out of.
MBA degree | must university
Post new comment