Richard Green, the Sun Microsystems executive who will lead the company's effort to open-source Java, says a major issue with any such move is the longstanding fear that Java will fracture and follow a path similar to Linux. Despite that concern, Sun announced its Java open-source intentions plans this week at JavaOne, which the company said was attended by about 15,000 people. Green, Sun's vice president for software, said the company's default position will be to work through any problems raised by open-sourcing. Sun has not yet announced a timetable for the release or has how Java will be licensed as open-source.
Green spoke with Computerworld Wednesday.
Are there any caveats or 'ifs' to your plan to open-source Java?
I think the only caveats would be that if our findings, based on the feedback from the community, were overwhelmingly against it, we would certainly reconsider. And it's plausible, it is imaginable -- although unlikely -- that people would be concerned about risks of incompatibility as a byproduct of this. That evokes significant fear and risk in people, and that's the only thing I can foresee as a gating issue.
What will be the process for getting this community feedback, and at what point will you know whether you have that buy-in?
I can't give a date when we will know. But I think we established during the [conference] some of the means that we will be using, which is membership feedback, participation in a JCP [Java Community Process] and other things, the number of downloads of both the Net Beans tools as well as the Java implementations. The more activity and the more involvement that there is, the greater the likelihood that people will be understanding and compelled to rely on the branded and compatible versions of the open-source software to go do it.
So if you get negative feedback and people saying, "We have grave concerns about Java forking," you may drop the whole idea of open-sourcing Java?
I don't think 'drop the whole idea' is a likely possibility. I think we have to go sit down with representatives from the community and JCP and really understand the reasons for concern and see if we can put programs in place to overcome them. Our strong perspective is to proceed here, and if there is a matching strong reason in the community not to do so, our preference would be to try to work it out rather than just stop.
In the past Sun has been pretty clear about its fears that open-source might lead to a forking. What is prompting this shift on the part of Sun?
There [are] two big trends. In general, the open-source initiatives around the world -- a really good example that we're keying on is the Open Solaris initiative -- are demonstrating that additional contribution, additional use, produces better innovation, more rapid innovation, and doesn't seem to compel people to want to diverge. We certainly haven't seen that very frequently. There's another issue: Over time, the continuous growth of the portfolio of applications that have been written to a compatible platform exert pressure to remain compatible. If there are these applications out there that will run only on a compatible version, and if you were to come out and diverge with an incompatible version, you won't be able to run those apps. Who would do that? Why would you want to build an implementation of any software platform that could not run the application base out there. It's the mass. As the number of lines of code that use compatible Java continue to go up, there is increased force to ensure that implementations of the platform are compatible. Developers don't like to build apps that don't run.
What does "open-source" mean in the case of Java? Does it mean the same thing to you as open-source Apache or Linux?
In general, as I noted, it's a little early to state very clearly what licensing technique we would use, although a strong leaning to an existing, well-practiced licensed is likely what we will do. But without being able to specify the license, I can't answer that question in very great detail.
You released Solaris under the Common Development and Distribution License (CDDL). Why would you do it differently here?
It's as I said: It's the feedback from the community, it's examining what [the] goals are. I'm not sure yet. There is lot of open-source Linux out there under GPL [General Public License], etc., and that also seems to be a very interesting and successful model. I do want to make sure that there is no issue or question about Sun's intent when we go and do this. And so the licensing scheme not only has implications of the constraints of the license itself, but it also tends to impart some sense of industrywide sharing as you use more industry standard licenses. So we are going to be looking at both sides of this.
Both sides meaning what?
The implication of your comment in the context of CDDL is that this is a Sun-centric license versus different open-source licenses. So we are going to look at the continuum of licenses that we have used and others have used to figure out what the community wants.