Open source Java SE by year end
'Lawyers finish job' – well, nearly
Agentless Backup is Not a Myth
There is now a timescale in place for the Standard Edition of Java, Java SE, to go open source.
Sun chief open source officer Simon Phipps said licence changes would occur in a sequence of updates to the code starting towards the end of this year.
As outlined here, making Java open has been something of a mare's nest of legal investigations and research, but now enough of the work has been done to start introducing open source-licensed code.
"We are still working on who owns what," Phipps said. "It is a problem that particularly stems from company acquisitions over the years, where it is difficult to ascertain whether we explicitly own the rights to change the licences."
He indicated that there are still some areas of the Java SE code base where the company is not certain it has sufficient legal rights to move the code to open source licensing, and the company may resort to using either its own engineering muscle to work round the problem areas, or work with others such as the Apache Harmony Project Group.
The company has been working with the Harmony and GNU Projects to build a greater Java SE community, and has already launched a portal as a community resource.
One of the markets where Java has been particularly successful has been in embedded systems, particularly in the mobile devices area, and Phipps noted that open source was now also having a significant impact in that marketplace.
With that in mind, he said the mobile edition, Java ME, is also expected to be launched with open source licensing at the end of this year. The next target after that will be Sun's extensive portfolio of middleware.
The primary issue with a switch to open source licensing is, of course, the fundamental change this brings in the way software vendors monetise their products. Phipps sees the change as a move to monetise at the point of value to the user and away from the point of acquisition from the vendor. He calls it the move from Software Model Version 2 to Version 3.
This still raises some unresolved questions, however, for he admitted that Sun execs are still deliberating over what mechanisms will be needed to determine what constitutes a "point of value" for a user, what happens when that point is reached, quantifying that value, and billing for it. In practice, Phipps sees monetising coming down to two main factors: the componentisation of products and the sale of expert services.
The former simply takes a previous "product", sold as a complete package, and breaks it down into components that can be purchased as required, so if you don't want the documentation you don't buy it. The latter is based on Sun gaining revenue from selling the expertise of its development staff to users, as and when they need it.
Phipps' own take on the background to the arrival of open source Java SE can be found in his blog. ®
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
In reply to: Not just licencing issues
The Java SE source is already available for you to download and have a look (good, bad, ugly - you be the judge), over here:
http://download.java.net/jdk6/
If you don't like the current license terms, then you will need to wait for the Lawyers to finish hammering out the details of an 'open' source license. In the mean-time, I claim the source is out there for all interested parties to see.
So, take a look and decide for yourself.
No wonder
Well, if that reasoning was genuine, and this is the typical response of someone from 'the community', it is absolutely no wonder people are loath to open up their projects.
Open up an Office compatible Office suite - something that the pure open source community had failed to produce in it's own timescale - and all you get is someone criticising your code for being dodgy.
Yep, that's exactly the kind of attitude that is going to encourage proprietary vendors to join the world of software engineering pedants.
Not just licencing issues
No doubt "licencing issues" will be cited as the reason why the transition of Java to Open Source is taking its while.
I strongly suspect that this is not the whole story.
Having attempted to work with the OpenOffice.org source code {which originated as the closed source StarOffice} and seen what thoroughly awful techniques people thought they could get away with because they never thought anybody was ever going to see the source code, I can say it's more probably because Java is riddled with embarrassing bits that Sun want to get rid of before letting anyone else see the code!

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring