The open road ahead
Is Java open enough for the rest of the open source world?
It all began with a simple question. Jason Hunter, Apache developer and Java guru, wanted to create an open source reference implementation and Technology Compatibility Kit (TCK) for his Java standard, currently under parlance with the Java Community Process (JCP). The standard — Java Specification Request (JSR) 102: JDOM 1.0 — is based on his Java-based document object libraries. Though Apache had been an active JCP participant and a member of the Executive Committee since 2000, Hunter knew some incompatibilities existed between Apache’s open source license and JSR 99: Java Specification Participation Agreement (JSPA) — Sun Microsystems’ legal agreement that defines how Java standards are developed. But nobody at Apache was fully aware of the underlying issues.
So, in an effort to see what would happen if an open source project tried to participate in JSR creation, Hunter asked the JCP group at Sun Microsystems if he could release an open source reference implementation as well as an open source TCK for JSR 102. As the JSR’s spec lead, Hunter felt it only right that he be able to create an open source reference implementation and TCK.
Sun’s response: “No.” The JSPA dictated that JSRs use a copyright license that enforces compatibility. Unfortunately, enforcing compatibility is not permitted under an open source license, so the two licenses could not co-exist.
That was just the beginning. The further Hunter looked into the JCP, the more problems and incompatibilities he found. Though the Sun-led Tomcat JSP (JavaServer Pages) server was widely viewed as a successful example of an open source reference implementation of JSP, the JCP requirements had changed since Tomcat was first released. As the JCP had become more formalized, the JSPA rules had changed, making it now technically illegal to create another Tomcat.
“[The JCP] had become more confidential, more restricted,” says Hunter, “We were better off four years ago.” And worse, because the servlet standard implemented in Tomcat had been absorbed into the umbrella J2EE (Java 2 Platform, Enterprise Edition) standard, it now technically violated the J2EE JSR 151 to implement a standalone servlet engine — something that dozens of commercial companies were already doing.
There were more problems: Any project that wanted to test JSR compatibility needed to run a complicated TCK, supplied by the spec lead on the related JSR. Because of the complexity of these TCKs, most required tens of thousands of dollars in engineering support before you could properly interpret their results. Not a problem for the Hewlett-Packards (HP) and BEAs of the world, but a definite barrier for noncommercial open source projects like Apache. Further, these TCKs could not be released under an open source license. Finally, some parts of Java are so difficult to test — Swing and Java’s bytecode verifier, for example — that the JSPA dictates that implementers must simply use the code defined in the particular JSR. Hunter found that this shared code’s license was incompatible with an open source license.
With JavaOne approaching in March and Sun dragging its feet to solve these issues, the Apache group decided to go public with its grievances. Just before JavaOne, it voted to give Sun 90 days to resolve the most important issues or it would follow the letter of the law and stop implementing Java standards. This would have essentially ended Apache’s participation in the JCP. On March 22, Sun wrote a letter of intent promising to address Apache’s major concerns. Hunter then posted a note, “The Day Java Opened Up?,” to his Servlets.com Website.
Open source pipes
So has Java really opened up? Sun has agreed to make all future JSR licenses open source compatible. This, along with the increased availability of shared code and test kits to open source projects, could make the platform more open. Companies working on plumbing-level Java technology should be among the first to take advantage of the new changes, according to Apache cofounder Brian Behlendorf. “You want to release plumbing,” he says. “Maybe companies will collaborate on these projects rather than compete.” One such plumbing area, the JVM, could be the first to benefit, he says. “There has to be 100 JVMs out there,” says Behlendorf. “Most of them are not the main product that any one company sells. I predict you’re going to see a whole lot of open source JVMs out there.”
But in all likelihood, it will be 2003 before these open source VMs begin to emerge. That’s when Java 2 Platform, Standard Edition (J2SE) 1.5, a.k.a “Tiger,” is expected; Sun has pledged it will release Tiger under open source-compatible terms. Though IBM and HP have no comment on whether or not they plan to implement open source JVMs, BeUnited, the open source BeOS standards group, has been following the Apache situation and has its eye on J2SE 1.5. BeUnited President Simon Gauvin says he has been in touch with the Sun engineer in charge of the upcoming Tiger release about the changes. He adds that if his group were to develop an open source JVM, then the changes made to J2SE “would matter a great deal to BeUnited.”
Since Sun has yet to actually deliver on any of its promised changes, it is too early to see which, if any, open source projects outside of the Apache umbrella will benefit. One outstanding issue is that not all existing JSRs are covered in Sun’s letter of intent. Sun has promised to change the license restrictions on all future JSRs, as well as 11 current JSRs that directly affect the Apache project, including JavaServer Faces, JavaServer Pages, and several JAX (Java XML) specifications. But that leaves the vast majority of Java open source projects incompatible for the time being.
Nowhere is this more strongly felt than in the J2EE space. Theoretically, future J2EE revisions will be open source compatible, and will even come with TCK access to some open source projects, but Sun is not saying when exactly this will happen. Because of the promised changes, HP, for example, says it expects companies to now collaborate much more freely on the “commodity implementations of standard APIs.” But, when it comes to HP’s J2EE software, the company is noncommittal on expressing whether or not Sun’s changes will matter. For example, HP’s free-of-charge J2EE application server, HP-AS, could theoretically be a candidate for an open source release, but according to HP’s Competitive Strategies Manager Robert Gadsdon, Sun’s changes, thus far, appear to be “very specific to the requirements of the Apache Web server” and “unlikely at this time to have a significant impact” on whether or not HP opens HP-AS.
Lutris Technologies, a former open source J2EE vendor that took its code proprietary when it couldn’t get J2EE certification, says that it has no plans to re-open its Enhydra app server as a result of the changes. “I wish this had happened six or nine months ago,” says Lutris Chief Evangelist David Young. “We’d still be open source if it had.”
Wooing the broader open source world
The most vocal proponent of an open source-compatible J2EE is JBoss founder Marc Fleury, who fears that opening up J2EE may happen too late. “We need the whole of J2EE to be compatible [with open source], and we need it to be now,” he says. Fleury, who has also founded the JBoss Group consulting company, claims that although his project is essentially J2EE’s reference implementation, its adoption is hurting because, due to its open source license, it cannot get J2EE certification. That lack of certification is causing some potential JBoss users to turn to Microsoft, simply because JBoss doesn’t have a trusted brand like J2EE. “If you don’t have J2EE certification, you don’t have a level playing field,” he says. “We have a problem fighting .Net because we don’t have the brand.”
Sun says it’s aware of JBoss’s issues and that it is working to resolve Fleury’s concerns. “It’s going to take awhile to get it right,” says one Sun executive familiar with the situation. “[Fleury’s] basic problem is that the project that he started was in violation of a specification license.” Also according to the Sun executive, JBoss is in a different position from Tomcat “because [Sun] asked Tomcat to do what they’re doing.” JBoss is also in a different position because Sun is extremely concerned with maintaining compatibility for the J2EE platform, and it views open source as a potential threat to that compatibility. As Karen Tegan, director of Sun’s J2EE compatibility and platform services, said in a TheServerside.com interview earlier this year, the “J2EE Compatible brand has achieved significant momentum over the past two years, and we want to make sure that any open source efforts don’t impact the viability of that effort.”
But outside of strong standards like Servlets, J2EE, and J2SE, Sun has an even tougher row to hoe: It needs to convince open source developers that there is value in spending their energies in the JCP. Java logging is a case in point. Though a de jure Java logging standard has been defined through JSR 47, the de facto logging standard is the popular, open source Log4J utility, which is part of the Apache project. Barred from legal participation in the standards process to date, the Log4J developers don’t see much gain in participating at this point. “Why should we implement an inferior API?” asks Log4J developer Ceki Gülcü. He says that while the J2EE standard is strong enough that JBoss can actually lose users because of its lack of certification, Log4J is a different case. “We don’t want to be compatible with the standard, because the JSR 47 standard is so weak.”
Matt Baldree, a developer on the popular open source project WebWork J2EE Web application framework, agrees that the real trick will be to convince developers of popular open source projects to enter the fold. “What I haven’t seen is how Sun/Apache plans to cast a large net and try to get the best and brightest to contribute,” he says. “I think that’s the challenge.”
