Sun has lost a significant vote in the Java standardisation process, with the Java Community Process (JCP) document defining the next version of the Java language being voted down by other Java industry players. The key issue appears to be that with the contract for the Technology Compatibility Kit (TCK). The TCK is used to ensure that all implementations are compatible and that software can be written once to run anywhere, on any implementation of the Java technology on any platform. As it stands, the TCK contract appears to prevent full third party implementations of the Java technology being released under open source licences such as the Apache Licence and the GPL.
The issue came to a head when the Apache Software Foundation (ASF) wrote an open letter and a FAQ to Sun outlining to them frustration at the lack of progress on the issue. Members of the JCP Executive Committee also abstained from the most recent JCP vote. Red Hat, one of the JCP Executive Committee members, hinted that no further JCP vote would be supported until the issue was resolved.
There are some complex issues here, but what is clear is that Sun is being blocked from moving forward with it’s future Java plans by the other Java community members until it does what it has said it would do, and irons out the contractual issues as they relate to open source.
The impact of this on end-users in the short to medium term will be negligible, even if the dispute drags on for years, because the vote was for the next version of the Java language (version 6) and many end-users are only now getting up to speed with the very significant changes introduced by the current version (version 5). The impact on commercial technology partners may be more noticeably, since on-going difficulties with Java would enable alternative languages to increase their gains.
The impact of a resolution to this that allowed full open source implementations of the Java technology would be hugely increased support for Java on open source and POSIX platforms such as Linux, MacOS X and FreeBSD. In the medium to long term these implementations are also likely to prove cheaper and more robust alternatives to some of the commercial Java implementations, saving the commercial players money.
“irons out the contractual issues as they relate to open source.”
Actually, the ASF open letter is about contractual issues as they relate to all implementors and end users, not just open source implementations. This is not about licensing (closed, open or free) it is about restrictions that Sun are placing on the use of software that can claim to have passed the TCK for Java.
(Disclaimer, I am a Member of The Apache Software Foundation, but in this comment I represent my own views)
Note that this withdrawn JSR was proposing a new version of the Java EE (enterprise edition), while the current contractual dispute between the ASF and Sun is over the TCK license for Java SE (standard edition). This post fails to distinguish the two, but it’s a very important difference as Java EE is an extension to the core of the language which is Java SE.
It is also worth mentioning, to be fair with Sun, that the ASF already acquired a TCK license for a previous version of Java EE for the Apache Geronimo project that did not contain “field of use” restrictions.
(Disclaimer, I’m a member of the Apache Software Foundation, and member of the Harmony Project Management Committee, although in this comment reflect only my personal opinion and not that of the foundation or of the Harmony project).
There is a very clear Podcast explaining the dispute between the ASF and Sun at http://feathercast.org/?p=43
You are correct Stefano that I have glossed over a number of points (as indicated by “There are some complex issues here…”). Sorry if this was unclear.
As you point out, the vote was over the Enterprise version rather than the Standard version which is at the centre of the Apache/Sun dispute.
However, the comments from Red hat and Intel make it clear that they, at least, felt that the problems Sun had with this vote relate to the Sun/Apache dispute, even though the vote was not at on the software version at the core of that dispute.