Level: Introductory Robert McMillan (bob@linux-mag.com), Editor-at-large, Linux Magazine
01 Apr 2002 If you were following JavaOne a few weeks back, you probably heard about how Sun and the Apache Software Foundation have resolved their difficulties over the way open source software could participate in the Java community process but if you were like the majority of Java developers, the precise issues were probably a bit of a mystery. To clear things up, and find out exactly what these changes will mean for open source developers and the Java community, developerWorks caught up with Apache's representative on the Java Community Process, Jason Hunter, and asked him to explain what's going on.
Jason Hunter
Best known as the developer of the JDOM Java XML modeling libraries, Jason Hunter volunteered a good part of his life over the past year to making it easier for open source projects to participate in the Java standardization process.
developerWorks: How did you get involved in all of this?
Hunter: I'm Apache's representative to the JCP [Java Community Process]. Most of the issues Apache was concerned about had come up as Apache has tried to participate in the JCP by providing open source implementations of JSRs [Java Specification Requests], helping host open source RIs [reference implementations] and TCKs [Test Compatibility Kits], and by hoping to lead JSRs which would have open source RIs and TCKs. In trying to work within the JCP we discovered there were legal issues, confidentiality issues, and test availability issues. The issues affected my own project, JDOM, as well. I submitted JDOM as JSR-102 because a lot of people were interested in having JDOM in the core JDK or J2EE, and the best way to allow that is to run JDOM through the JSR process. That brought up a lot of legal issues on whether the JCP allows open source RIs and TCKs. The answer from Sun legal seemed to be that it was illegal, but the opinion seemed to depend on which lawyer you asked and how they squinted at the document.
dW: So when was this?
Hunter: Over a year ago. I knew that the ability to do open source-independent implementations had been somewhat hindered -- that was well known -- but I thought that at least a spec lead should have the choice of saying, "Here is my reference implementation; it's open source; feel free to build on it." That's the Apache way: "Here's the Apache Web server; it's very good, but feel free to build a commercial thing on top, with support and features."
dW: So you were the spec lead on the JSR that you were trying to implement?
Hunter: Yes. It's surprising that as a spec lead you could work with people; you could all agree that you wanted it under this license; and then you'd be told, "You cannot." And a lot of it is because anything that's subject to legal interpretation doesn't always have a yes or no answer. The document is very long and complicated. It's a patchwork of legal wording added over the years. Because it's so hard to understand, we're glad to see Sun's legal interpretation has been posted publicly (see Resources), saying that open source RIs and TCKs are allowed. The legal murkiness is a continual source of problems for open source developers who don't have in-house counsel. It requires that they make guesses about probabilities of outcomes; it's like quantum physics.
dW: What stood in the way of open source JSR implementations?
Hunter: There were three main things that stood in the way. One was the specification license that Sun was using on JSRs saying essentially, "This is copyrighted and if you are implementing it, you are creating a derived work, and therefore we have the ability to dictate some aspects of the license terms on your derived work." Their license terms were that you had to ensure compatibility through your copyright license, which was then standing in the way of an open source license, which cannot do such things. This is being addressed for Sun's future JSRs and key JSRs in the past. The second thing was the existence of something called "shared code." It still exists to some extent. A shared code requirement says, "You cannot implement this JSR unless you use within your implementation this exact code." Swing and the Java verifier are two examples. Shared code has been used for things that are difficult to test, and so the only way that you could ensure compatibility was by using the same codebase. That's understandable, but the license on the shared code dictated the license under which you released your quasi-independent implementation. So if you wanted to implement a JSR having shared code, this would stand in the way of doing an open source implementation. The JSPA [Java Specification Participation Agreement] draft currently underway ensures the shared code copyright license does not prohibit an Apache-style open source license. The third thing was that you had to get access to the Test Compatibility Kits, and in order to do that, you had to negotiate a license with Sun. They had terms which, in order to get the TCK, would prohibit an open source implementation.
dW: The Test Compatibility Kits, did they come from the JSR leads or from Sun?
Hunter: They come from the leads, and Sun has been the lead on everything that we care about... probably not everything, but up to this point, a vast majority of the important JSRs have been Sun-led. That's why Sun's license terms are so important.
dW: And that is still a gray area. Even with the agreement with Sun, it doesn't seem clear whether or not some of the other JSR leads are going to provide support for open source project testing.
Hunter: I fully expect that we will see support. In communication on these issues, nearly everyone that I've been in touch with has been supportive of the position, except we had to work through the issues with Sun. Compatibility versus openness
The discussion continued to focus on the issue of compatibility versus openness.
dW: What was Sun's concern?
Hunter: I think there was a misunderstanding, to some extent, that if you had an open source TCK, for example, that meant that anyone could change the TCK and you wouldn't have a TCK. So there had to be some education.
We needed to work with Sun to show you could have open source implementations without sacrificing compatibility. The changes that are planned, we believe, will help compatibility. Wider availability of TCKs and wide availability of solid JSR implementations should be a boon to Java portability. There's a difference between a code base and a binary. It's the spec lead's role to release a TCK binary that is the "Golden" TCK -- the binary against which you run your implementation. The code base to that TCK may
be open source, but that doesn't let anyone remove tests from the TCK, for example. I've done a lot of classes on open source and I'll ask, question #1, "Who can change the Apache Web server?" People will say, "Only Apache people." So I'll say, "But isn't it open source? Can't anyone change it?" That appears convincing so most people say, "OK, everyone can change it." Then I'll ask, "How do we have any security, then, if anyone can change the Web server?" Brains spin, and we're ready for the class. The answer is that there's an Apache Software Foundation, which maintains the Apache code tree and releases builds of the Apache Web server. They restrict (through a meritocracy based on voting) who has access to the code tree, and all changes are peer reviewed. It's true you can download the source and you can change it on your machine, but then you're not creating Apache anymore and the license prohibits you from calling your server Apache. It's the same way with the TCKs. There can be a trusted group that maintains the TCKs, and the spec lead has the authority to create official builds. Improvements to the code may come in from people who find bugs in the TCK, but they won't make it into the official tree without passing the rules for that code tree, and they won't make it into the official build without the spec lead accepting them in the build.
 |
Opening up the Java platform
The interview wrapped up with Jason's thoughts on what this all means to the Java community.
dW: One of the interesting things about this whole change is the impact it will have on the broader Java community. Will it encourage other projects or companies to release open source code?
Hunter: I'm sure there have been cases where people wanted things done as open source, but weren't able to do it; corporations don't like taking legal risks The notion that a spec copyright can impact the license on an implementation of that spec is questionable. It's never been tested in court and of all the lawyers I've spoken to, only those employed by Sun believe that it could hold up, or at least say so publicly. But if you're a corporation, you'd rather not take that risk. Open source groups are relatively immune to such litigation, but corporations aren't. It's exciting that there may be increasing corporate support for open source implementations.
dW: If these changes do take effect, do they make the Java platform open enough?
Hunter: You can theorize that if you can have open source implementations of JSRs and at some point of even the core JDK, then groups will be doing that. If groups do that, Sun may have an interest in making it so that their reference implementation is open, rather than having a third party's implementation be the open one, because an open source implementation is likely to gather a lot of mindshare and marketshare. Some people have pictured an open source Java as being something where, if I have an API change I want to make, it gets voted on, and then Bingo! It's in. I don't think there's much support for that. And in my opinion, that's all right. I don't mind the fact that there's a review process and it's done more like a specification with an implementation. It would be beneficial if you could have the core of Java open sourced to the extent where you could have trusted people making it perform better and identifying bugs, because there are a lot of bugs that are of great importance to people. But people don't have access to the code to go and make the fixes. The notion of SCSL [Sun Community Source License] has not been a large success. You have to download a big tarball, and it's a lot different from having a real CVS to read and track the changes, because by the time you're making changes, somebody else has already changed something. There's never been an interest in breaking the compatibility. There's always been an interest in being able to be compatible. And so, because there were those three things that were barriers, the open source developers would not worry about the spec license aspect of it; not worry about the shared code, which is a possible compatibility issue, and not have access to the TCK because Sun wouldn't license it. That hurt compatibility. Now giving them access to these things will help compatibility. So there was a concern before, but we clearly see that there's going to be a benefit to compatibility to have these open source interests. Now, just because the implementation is open source doesn't mean that you can break compatibility with impunity. Sun still has the notion of their copyright license being used to enforce compatibility, and they're free to go after an implementor -- open source or not -- who is deviating. And we may see it tested in court; and see if it holds up. There's a non-zero chance that it would.
dW: So Sun has pledged to change the licensing terms on about a dozen JSRs because they affect Apache. Are there others beyond that?
Hunter: We worked with Sun to come up with a short list of what was most important to Apache. Sun actually added some JSRs that are likely to be important to other groups as well. We tried to work with them to say, "These JSRs, at minimum, need to be changed right away, because of our legal situation."
dW: Why wouldn't they commit to changing all the JSRs that they're the lead on?
Hunter: They have said that they would do that for future JSRs. For the previous JSRs, I suspect that it's just a matter of them having limited capacity. They'd rather change the JSRs in the past that are highest visibility, and if something's about to be revved, to just let the next rev take care of that. If Sun takes action beyond the list already given, that'll be seen as a very good sign. If
they truly follow through on all the JSRs in the future, there's the possibility that the license terms will be such that they're not very clear. If they're clear, that's another good sign. If they're murky, then we'll be concerned. One of the most important actions Apache will be looking for is a licensing of J2EE 1.4 to allow independent, compatible, open source implementations. If it's like, "Well one of the JSRs inside J2EE has not yet been changed, so therefore you can't implement J2EE 1.4," any of that gamesmanship would be seen as a bad sign.
dW: So does this mark the end of your involvement in the Java Community Process?
Hunter: I think this marks the end of my headaches caused by our involvement. Once the agreement has been fully enacted, I can take the role that I wanted to play at the beginning, which is to help evaluate proposals, evaluate community review drafts, and watch over the technology. Help propose and lead JSRs. Help implement JSRs. That's what Apache is all about: creating technology and implementing standards. I don't want to talk to lawyers if I don't have to. I don't think anyone does.
Resources
About the author  | | |
Robert McMillan is a freelance journalist and editor at large at Linux Magazine. You can contact Robert at bob@linux-mag.com. |
Rate this page
| 
