New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
IBM's Response to Open Source Java under GPL
Posted by Floyd Marinescu on Nov 20, 2006
In general, we are pleased about Sun's announcement that they intend to open source Java and are very supportive of the move.IBM has since 2003 been pressuring Sun to open source Java. On every JSR passed by the JCP since 2003, IBM has included the following clause in its vote (excerpted from the final ballot votes of any JSR):
IBM supports all the OSI approved open source licenses. Having said that, there already is an important existing open source effort working with Sun to create a Java compatible implementation of Java SE in the Apache Foundation – namely the Harmony project. In addition, there have been some very recent announcements that companies active in the Java ME space will be contributing key Java technologies to the Apache Foundation to jumpstart Java ME projects.
In light of the Apache projects, we have discussed with Sun our strong belief that Sun should contribute their Java technologies to Apache rather than starting another open source Java project, or at least make their contributions available under an “Apache friendly” license to ensure the open source Java community isn't fragmented and disenfranchised, instead Sun would be bringing the same benefits of OS Java to this significant and growing open source community.
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.Infact in IBM's open letter to Sun from Jan 2004 Rod Smith declared IBM's willingness to "work with Sun on an independent project to open source Java." IBM has also been a backer of Apache Harmony and with Intel has a made many contributions to the project, including full time employees. It's clear that Harmony would have been IBM's preferred vehicle for open sourcing Java.
Also at issue is the license and governance. IBM would have preferred ASF style license, which would give the ability to for anyone to modify Java and re-distribute under their own licenses, including commercial. GPL forces modifications to also be licensed under GPL and released as open source, which might make certain commercial business models impossible. However, as Sun officials mentioned in the Second Life briefing, existing Sun commercial licensing mechanisms will still be in effect, so any company can still license Java SE directly from Sun on customized terms (as IBM is doing today for it's custom operating systems and hardware).
The selection of GPL means that Harmony cannot include and redistribute OpenJDK code whereas the reverse is true. The Harmony project however will continue, according to Geir Magnusson.
In David Berlinds must read "the ripple effects of GPL'd Java", David clarifies:
Sun had no choice but to make a fragmenting choice. By choosing to go with the GPL, the move equates to legal alienation of the Apache community. Had Sun gone with the Apache license, it would have legally alienated the GNU Classpath community. Sun had to make a choice... But, in finally answering IBM calls to open source Java, there's no doubt in my mind that Sun knew exactly the sort of indigestion that selecting the GPL would cause to IBM. In doing so, much the same way it's probably best for the existing GNU Classpath project to be wound down, it probably doesn't make a lot of sense to continue redundant investments in other open source clones of Java at this point. With the selection of the GPL, Sun may have completely neutralized the enourmous investment that IBM has so far made into open source Java. Especially now that Sun's selection of the GPL paves the way for Red Hat, Suse, and others to include Java with their Linux distributions.
A few comments...
by
Geir Magnusson Jr
Posted
The licensing chosen is potentially Apache friendly
by
Dalibor Topic
Posted
-
First, your unnamed source at IBM is incorrect. There's been no announcements of anyone contributing "key Java technologies" to jumpstart ME projects at the ASF.
Also, I think that David is mistaken. If his theory had any basis, the WebSphere, WebLogic, JBoss, Geronimo and JOnAS teams would have thrown in the towel long ago since Glassfish is open source. But amazingly, it turns out that competition is good, and allowing compatible innovation in the ecosystem is very healthy. Sure, putting their implementation under the GPL opens the door to more Java in the Linux ecosystem (which is really good, btw) but don't forget there now is an incredible motivation by the Linux community to find an alternative to Mono as a result of the Novell-MSFT deal. Linux distros have no problem shipping software under the Apache License - try to find one without httpd, the Apache web server. Sun releasing under GPL is certainly very timely for them (of course, it helps that the software is well-proven).
Java is a big tent - there's plenty of room for more than one implementation of Java SE. We've had at least 3 closed-source implementations to date : Sun's, IBM's and BEA's. There's no reason why multiple open source communities, especially ones targetted at different subsets of the Java ecosystem, won't thrive.
geir -
It used to be a matter of policy at ASF not to distribute code under copyleft licenses like LGPL, EPL, CDDL, GPL+classpath exception.
That's changing now under the new third party license policy, which explicitely allows weak copyleft code to be included in Apache projects. There is currently a very blurry line in that policy drawn to include CDDL and EPL as permissible, but to exclude the GPL+classpath exception.
But I guess that's just one of those semantic-vs-syntactic issues that will sort themselves out eventually when someone has enough interest to look at them closely.
2 comments
Watch Thread Reply