Q&A with Tim Bray
Q: [Ed] What is being announced today?
A: [Tim] The details will be coming out, but the essentials are: JVM and javac and JavaHelp and Java ME are pure GPL 2.0. The SE APIs/libraries are GPL 2.0 plus Classpath exception. Plus, we will continue to honor & make available the existing commercial licenses.
Q: What license will be used for the Java ME APIs and libraries?
A: GPL v2. The Classpath exception is not needed for Java ME, because it is impractical to distribute a Java ME implementation with applications. There would be no way to install and integrate such an implementation on a device. Java ME implementations must be integrated with hardware much more tightly than is true for Java SE implementations. Because the problem that the Classpath exception is intended to eliminate - the requirement for all source code to be licensed under the GPL when distributed with applications - does not exist in the case of Java ME, there is no need for the exception.
Q:Will GlassFish be re-licensed under GPL as well?
A: Yes. This is part of the announcement; the GlassFish Community reference implementation (GlassFish Java EE 5 application server) will have the GPL added to the original CDDL.
Q: Will the test suites be open sourced?
A: Good question, but that's still TBD; we just haven't had time to figure this one out.
Q: Will NetBeans be changed to GPL?
A: I don't know of any current plans. I think that CDDL is appropriate, given NetBeans' status as a developer tool rather than a central piece of core infrastructure.
Why GPL?
Q: Would it be fair to say that this was done to a) preserve the value of Sun Java licenses and b) to enable interoperability and code sharing with the GNU Classpath project?
A: This was done primarily to reduce barriers to adoption for the Java platform. Clearly we have existing licenses and we will stand by them, although those licensees will obviously have the option of changing to the open-source version at some future point. Item (b) is a nice benefit, but no, I wouldn't agree that it would be fair to say either (a) or (b) was a primary motivator.
Q: If GPL was picked primarily to "reduce barriers to adoption for the Java platform", how does GPL do a better job of that than the Apache, CDDL, or BSD licenses?
A: Many of those who have so far been unwilling to adopt Java are in the Free Software (as distinct from Open Source) community, and their definition of "Free Software" requires something with the characteristics of the GPL; thus it is uniquely effective at removing the observed barriers to adoption. In the particular case of Java, which is core, universal, cross-platform infrastructure, the behavior encouraged by the GPL - full sharing of all improvements with everyone - seems better-suited than that of a Mozilla-style license such as CDDL.
Q: What does this mean to the future of CDDL?
A: The world of Free and Open-Source software needs more than one license. I personally think that CDDL is the most polished and modern of the Mozilla-family licenses, and the world has a place for that kind of structure.
Q: Will some part of the stack (class libraries for example) be LGPL or GPL+exceptions instead of straight GPL?
A: Exactly. I'm not convinced there's really any material difference between LGPL and GPL + classpath exception, but the latter is the choice of the people currently working on OSS+Java implementations, so it seems more appropriate in this case.
Developer impact
Q: What are the implications for a small commercial non-GPL desktop app that uses Swing and bundles the JRE?
A: None that I can see, given the Classpath exception.
Q: Currently there are serious restrictions about how much a developer can pare down the JRE in order to distribute it with their application. Do these restrictions go away under the GPL?
A: Anything you distribute that is called "Java" must in fact be Java; that is to say, it must be a compatible implementation that has been shown to pass the appropriate TCK and has met the other legal and technical requirements necessary to bear the Java name. No changes of this policy are currently contemplated in relation to the open-sourcing work.
Q: Will Java be dual-licensed like MySQL?
A: We'll continue to offer the existing commercial licenses, of course.
Future/community
Q: Will you adopt GPL v3 when it comes out?
A: We can't really answer that until we see what the GPL v3 looks like. It seems likely that the Java project has a shorter time line than the GPLv3 project. This is perfectly appropriate, the GPL is important and getting it right should take as long as it takes. In the interim, the GPLv2 meets Java's needs.
Q: Will this give Sun any extra weight in guiding the changes for GPL v3?
A: We're already participating in that discussion. My impression is that this discussion is very much principles-driven, so I suspect that any particular open-source project's influence will not be that great.
Q: Will we see Sun be any more or less involved with Apache Harmony and/or GNU Classpath as a result of this?
A: That's up to them. Both projects have been doing good work and the whole Java community would benefit if we could bring that into the mainstream.
Q: Will Sun be taking up the GNU Classpath project offers to fill in the gaps on encumbered technology in the JDK?
A: In Open Source, code talks. Those gaps are going to need addressing and contributions of code to address them would be highly welcome. Having said that, my personal feeling is that the Classpath people have been doing great stuff and if they decided to focus on some of those problems, I'd be optimistic that they'd fill some of the gaps.
Q: Currently the GNU Classpath developers are required not to look at any alternative implementations, especially Sun's. Once Java is put under GPL, I assume that restriction will go away, is that true?
A: That has always been a rule of their own devising since Sun asserts that there is no issue here - the only rights violations that can happen are copyright violations if there is a direct and substantial copying of code.
Q: What kind of discussions did you have with FSF and Apache?
A: Sun is a key member of Apache, engaged in Derby, Roller, Jini and more and the original contributor of key packages such as Tomcat. We have extensive contacts with both organizations through both personal friendships as well as through inter-company contacts. You will see on Monday, we have excellent relationships with the FSF, including endorsement for the announcement from Richard Stallman.
Q: By endorsement, do you mean Stallman is going to make an appearance at the announcement Monday morning?
A: By video, yes.
Nitty gritty
Q: Will any code contributed to Sun Java need to have its copyright assigned to Sun? (For example, if the Classpath people wanted to fill some of the gaps mentioned above.)
A: As with many open-source project, contributors need to execute a contribution agreement which assigns joint copyright to Sun. Unlike some other SCAs, contributors give up no rights. This is necessary, among other things, to establish accountability for intellectual-property contributions. Recent litigation has made the importance of this clear.
Q: Under the terms of the new Java license, when does the Classpath exception apply?
A: It's quite OK per the GPL to distribute compiled GPL-licensed code (class files and jars) assuming the source code is readily available. Given the Classpath exception, it's also perfectly OK to distribute binaries of non-open-source code that the GPL Java Virtual Machine runs against the GPL+exception Java APIs. Having said that, the GPL is a legal document and corner cases should be interpreted by lawyers
Business model
Q: How is Sun going to make any money considering servers have to be priced competitively and software is given for free?
A: We're all about monetizing at the point of value. Download the software try the software, integrate the software, and when you're ready to put it to work, we'd like to sell you our maintenance and support services, which also come with intellectual-property indemnities to make your legal staff happy. If the application you're building is at all business-critical, we think the smart business decision is to run supported rather than unsupported, and we're quite cheerful about competing in the open market for the business of supporting the technology that we create. We also think that our uniquely-deep understanding of these core technologies will help us do well at building competitive computer, storage, networking, operating-system, and middleware products.
Q: Giving Solaris for free and earning revenue in service contracts sounds good in theory. But how is Sun going to combat Oracle's pricing of as low as $99 per system. Doesn't it undercut Sun's service contracts?
A: As I said, we're happy to compete on both quality and price in providing service offerings for technology that we built ourselves and understand better than anyone in the world.
Q: What is the idea behind open sourcing Java? What do you gain by handing over Java technology to a community where competitors will benefit?
A: Sun believes that a rising tide floats all boats. We think that the bigger the Internet gets and the better it works, the more business there will be, and we'll win our fair share and more, and we'll do well. The way to make money on the Internet is not through lock-ins or a proprietary hold on the market, it's by opening up everything as much as possible and then competing for the additional business this open-ness produces.
More details
For more information about today's announcement see: