Frank Sommers: In choosing the GPL, what constituents of the developer community were you trying to reach?

Tim Bray: The ones who [we] are most interested in in the short term, at least, are clearly the GNU Linux crowd. They have a strong cultural predisposition towards not just open-source, but free software. They have a high degree of familiarity and comfort with the GPL. Choosing the GPL simply removes the need to argue about licensing with those guys. The dialog goes like, "License?" "GPL." "OK." We hope that this licensing change will increase the attractiveness of Java in that crowd.

Long-term, we think that the GPL gives us the best prospect of increasing the penetration of Java just about everywhere, simply because it becomes a piece of the commons that anybody can try and improve. And the improvements have a chance of getting back into the mainstream, because of the nature of the GPL.

Frank Sommers: Why is the GPL a better choice for Java than Apache, Mozilla or some other open-source license?

Tim Bray: You are never going to get a consensus on that. There was a huge amount of argument on that [issue]. I see IBM issued a statement today, wishing that we had done Apache. You can name many reasons for choosing Apache.

I personally think that the GPL is a better choice, simply because Java has been given away for free for so long by us that the world owes Java something back. When people make improvements [to] Java these days, they should very well turn around and give that back to the community. So I'm really comfortable with GPL.

Frank Sommers: Can you explain the dual licensing model?

Tim Bray: We have lots of commercial licensees. The obvious major players, like IBM, BEA, and lots of others who take the Java code and improve it and put it in their products. In the area of Java ME, obviously a huge portion of the mobile phone industry in the world is a commercial licensee of that technology. We can't cancel those, those are contracts. It would not only be illegal to cancel them, it would be unethical to not offer to renew them when they expire.

For that reason, Java will go on being offered under the existing commercial licenses that we have offered. For those who have commercial licenses with us, when those licenses expire, they will have the option of dropping them and going with the open-source GPL'd version for free, of course. That will be their choice. I suspect that some will, and some won't. It's a complex set of trade-offs.

Frank Sommers: Will the license that developers currently agree to when downloading Sun's JDK be canceled?

Tim Bray: No, that's a license on the binary. The license on the binaries is the same. There is no reason to do away with that. Somebody who just wants to get the binaries, the current license is perfectly OK for that. Only the source license changes.

Frank Sommers: What exactly is being licensed under the GPL?

Tim Bray: The intent is that all of the pieces of the Java ecosystem—ME, SE, EE—will end up under GPL. One particular component, the APIs in SE, will also have the Classpath exception: Anybody can share commercial code on top of the GPL'd Java code without being infected by the GPL. People who want to go on with their existing closed source, will be fine.

What we dropped today, the actual code you can go and get, is the Java Virtual Machine, the Java compiler, and, somewhat to our surprise, the CDC and CLDC pieces of Java ME, which we hadn't actually expected to be ready yet.

Frank Sommers: What is the Classpath exception, and how does it come into play? On the surface, it sounds very similar to what the LGPL provides.

Tim Bray: These are very similar. I'm not convinced that there is any difference at all. Probably if we had chosen LGPL, the effect would be nearly identical.

There is an active community of developers in the GNU space who have been working on open-source Java. For their work, they have chosen the Classpath exception, and that decision has received good acceptance. To the extent that there is already an open-source Java community, that is the de facto licensing best practice. Rather than change it, we simply adopted their approach. But you are correct to note that it's probably the same as the LGPL.

What the Classpath exception means is that the code in the Java Virtual Machine is open-source under GNU. That means that if you take that, improve that, and publish it, you have to give the improvements back. Similarly with the code in the libraries: if you take the libraries and improve them, or add to them, you have to give the source code back.

But if you do what most Java developers do, write a business application that uses the JVM and the libraries, you are not infected by the GPL. You can be closed source, you can be proprietary, there is no expectation that you will provide your source code, or feel any other effect of the GPL.

The Classpath exception just means that if you are shipping your binary Java application, then you can just go ahead shipping your binary Java application, and nothing needs to change. It's about making it clear that applications that depend on Java, are not affected by the GPL that applies to Java itself. BEA's WebLogic, or IBM's WebSphere, or any other application, they can run Java without any involvement with the GPL.

Frank Sommers: What about open-source projects with a non-GPL license, such as Apache? Can they accept and use the Sun-contributed code?

Tim Bray: That is a vexed question, and one that's hard to get consensus on. It is the view of many in Apache, and I think it is the official view, that the Apache License and the GPL are incompatible. Our lawyers at Sun disagree, and don't see why that is a problem.

I think that it's a major pain that there are these two licenses, and there is this area of doubt about their compatibility. But this issue exists, and I don't think there is anything we at Sun can do to make it go away. If there is anything we can do to help, we probably would.

There is some talk that GPL 3 will remove this incompatibility. On the other hand, we haven't seen GPL 3 yet, so that is hypothetical. We can all agree that this is a problem. I don't see what the short-term solution is, but I hope we can find one.

Frank Sommers: What does the licensing change mean to projects on Java.net?

Tim Bray: The vast number of projects on Java.net simply run on the JVM, and link to the libraries. Due to the Classpath exception, they won't be affected in the slightest.

Frank Sommers: The JCP currently gives JSR project leads the freedom to release their output under any license. Do you anticipate that changing?

Tim Bray: There is no actual, immediate change to the JCP related to this particular open-sourcing move. The JCP manages the specification of Java, and what we're talking about now is open-sourcing the implementation of those specifications. The JCP is actually in the process of reforming itself again. There is a JSR [Editor's note: JSR 306] about that. That sort of reorganization makes sense, because the world changes. But the JCP and the Java implementation we're open-sourcing are on separate tracks.

Frank Sommers: The new project on java.net is called OpenJDK. It's not called Java. How does the licensing change impact the use of the Java name?

Tim Bray: That's a very good question. The source code is open-sourced under the GPL. Anybody can take the code, anybody can change the code, anybody can compile their changed version and ship it, or sell it even.

What they can't do is call it Java. You can't call it Java unless it passes the TCK and goes through all the usual TCK and copyright processes you have to go through to call something Java.

That's how we're keeping the compatibility promise to the world. We're not doing it through engineering means, we're doing it through business and legal means. If something is called Java, and has the Coffee Cup logo on it, that means that it has passed the TCK and it is, in fact, fully compatible Java.

In the past, there have been incidents of people trying to skate around that, to call something Java that really isn't. In the past, when that happened, we have taken them to court. Let's be totally clear on that: If somebody's trying to do that, they'll find themselves in court right away. We will be very aggressive about that.

For the business user who doesn't want to be fooling around with experimental open-source, all they need to do is look for the Java name and the brand [image], and they'll have real Java. Whether it's called Java in the administration panel, or the command line you type to run it, or however you normally access it, if it appears under the name Java, then it had better be Java, or that distribution is going to end up in court.

Frank Sommers: Will the TCKs be open-sourced as well?

Tim Bray: We haven't decided that yet. That's a complicated one. The TCK is kind of like the road test you have to take to get your driver's license. It's psychologically important that people have confidence in the integrity of the TCK. A self-administered TCK would not meet the market's needs, for instance.

There are a lot of marketing people and lawyers scratching their heads about this one right now, about what the right licensing structure is for the TCK to go with the open-source version of Java without compromising the integrity of the statement of having passed the TCK. We're still working on that one.

Frank Sommers: The TCK is available in source form, though. Does that mean that an open-source project can use that to claim that they've passed the TCK, providing that that's good enough for the market in which that open-source project operates?

Tim Bray: No, not at all. The TCK currently has to be administered and certified by Sun. I don't see that changing. If you are a commercial licensee, there is a cost to that, because it's expensive and is a lot of work. We offer scholarships to open-source projects [to defray that cost], for projects like Harmony and so on.

Frank Sommers: My final question is, Why now? The compatibility issues are the same they have been for many years, and the answers you talked about were available during all this time.

Tim Bray: You may have noticed that we have a new CEO. I think that's related.