Editor's Note: Recently, TheServerSide.com's Publisher, Floyd Marinescu, directly asked Bill Shannon, a Sun Distinguished Engineer and Spec Lead for the J2EE, and Karen Tegan, Director of J2EE Compatibility and Platform Services for Sun Microsystems the following question: "What is Sun's point of view in the debate over whether J2EE licensing restricts open source J2EE products?" Their reply may surprise you at first, but it seems to be the same status-quo from Sun. See what senior O'Reilly & Associates' Java editor Mike Loukides thinks of Sun's policy on this and its effects on JBoss and other open source J2EE projects out there (Jan. 30, 2002).
It's not a good idea to start out with a confession, but I will: I promised that I'd write this article several months ago. As with many promises, my good intentions exceeded my ability. But events of the past few weeks have made it even more important to get this article out.
I'm not referring to the terrorist attacks. I am referring to Sun Microsystems' opposition to open source implementations of J2EE. Earlier in the year, this opposition took a more subtle form: it was impossible for JBoss to go through the J2EE certification process. But more recently, Sun has told Lutris Technologies that they cannot release an open source version of their J2EE server, Enhydra.
First things first -- I'll talk about JBoss. Certification costs money. Lots of it. Open source projects like JBoss have tremendous access to development talent, but little money. Large certification fees shut them out of the process, and prevent them from playing on an equal field with commercial alternatives. While this might be convenient for corporate vendors like BEA and IBM, it certainly isn't fair to small open source developers, and certainly isn't in the interest of Java. I don't see how it could possibly be in Sun's interest, either; the best possible scenario for Sun would be the development of a fair and open market for third-party software, a market that includes all players, whether they are open source or commercial.
There are a number of solutions to this problem. I don't see any reason that Sun couldn't establish a set of sliding certification fees, where the fees were tied to anticipated sales. Or Sun could set up a certification foundation that would grant "scholarships," as it were, to organizations that had developed worthwhile implementations of Java standards, but that could not afford to go through the certification process on their own.
A Java certification foundation could be funded by donations. I would expect the donations to come principally from Sun, but I would also expect the donations to be fairly limited -- enough to fund a small number (say, two or three) of certification efforts per year. Sun has argued that certification is expensive, and that they don't want to bear the burden for certifying many implementations. That's fair; a certification foundation would allow Sun to limit its contribution, while validating the important contributions that open source developers make to the J2EE marketplace.
Why is Sun opposing true open source J2EE implementations, as evidenced by their current licensing policies and positioning? Sun says it supports open source J2EE. Does it, really?
Frankly, I don't think that there would be a huge rush of applicants; a few funded certifications per year would suffice. While there are many projects that have implemented part of J2EE, JBoss is the only complete implementation I can think of. And Sun's insistence that they will only certify complete implementations is reasonable.
Furthermore, the creation of a Java certification foundation would be an excellent public relations opportunity -- something that Sun could really use right now. It might ruffle feathers among the big commercial players, like IBM and BEA -- but that's irrelevant. If a software product complies with the J2EE standard, it has the right to be certified and stand on the same footing as all other products. Products like JBoss are certainly close enough to being compliant that they deserve the opportunity to go through the testing process and find out whether they are actually compliant, and, if not, fix any problems that remain.
It is in no one's interest to set up a certification process that is only open to large, well-funded companies. In another context, a BEA evangelist told me, "If J2EE wins, we all win." The best way for Sun to ensure that J2EE wins, and thus serve the best interests of all its partners, is to ensure that there is a level playing field for all J2EE developers, regardless of their financial backing. Anything less is destructive to the market for Java software and to Java's long-term success.
Sun apparently has some concerns that any open source product that is certified could somehow lead to the decay of the Java brand -- the scenario they have in mind is that a product like JBoss could be taken, modified, and reissued legally under the terms of its license, but still be presented as compliant. That objection doesn't really hold water, though. Yes, an open source product can be modified. But it's clear to me, and to any consumer of the software, that a certification mark only applies to the software as it was certified, and not to modified software. Furthermore, these days it's pretty easy to tell whether or not a software distribution has been modified. That's what cryptographic checksums and digital signatures are all about. It would be trivial for Sun to publish the MD5 hash of all software packages that pass a certification test -- in fact, they ought to do so, if they don't already.
Another problem -- and this leads us to the Lutris case -- is that Sun has taken the position that any licensee of the J2EE specification is privy to Sun's intellectual property, and can't legally release an open source implementation. (In particular, they have told Lutris that they may not apply an open source license to their Enhydra J2EE platform.)
I'm at a loss for what to say here. Sun certainly has the right to interpret their licenses any way they want or to make up any licenses they want. This move, however, strikes me as extraordinary bad faith -- and just plain stupid. Sun desperately needs the cooperation of the open source community. Telling developers that they cannot release open source implementations if they have seen the J2EE spec is certainly not going to earn Sun any friends. I can't think of any better way for Sun to destroy what it has accomplished with Java over the past few years.
When Sun first announced its Community Source License (SCSL), I thought it was an interesting approach to bridging the gap between open source and commercial software developers. It appears, however, that Sun wants the appearance of openness without the substance. They have the right to take that posture, but it's ultimately destructive.
The days in which Sun had a right to be concerned about Microsoft's attempt to pollute the Java standard have long passed. Microsoft tried that battle and lost. What Sun really needs to do now is consolidate developers of all sorts; they need to be making allies instead of enemies. And their natural allies are the developers of the open source community. If they had taken the courageous step of applying an open source license, like the BSD license, to Java two or three years ago, they would be the only game in town. Microsoft's .NET initiative would be late and irrelevant. Sun appeared to consider this option, but ultimately waffled, and now has withdrawn into its shell.
I really don't understand what Sun thinks is in its best interest. But it is very clear to me that it is in Sun's best interest to establish a level playing field for all developers who create J2EE implementations; it's in their best interest to encourage people to be as creative as they can about licensing terms for J2EE software, including open source licensing; and it's clear to me that they need to make allies of all software developers, rather than behaving in ways that can only be described as offensive. If they continue in the direction they've taken, Sun may succeed where Microsoft failed: in destroying the promise of Java.
Editor's Note: This editorial does not necessarily reflect the views of ONJava.com and its affiliates.
Mike Loukides is a senior editor for O'Reilly Media, Inc., with a focus on developing titles on Java, UNIX utilities and system administration.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.