IBM pressures Sun to free Java

IBM director of e-business standards strategy Bob Sutor is one of a handful of people at Big Blue who have a say in the company's policies regarding standards, open source, and Web services. One Web services technology that he wants to see open-sourced, and subsequently turned into a standard, is Sun's Java.

Java is many things to many people. Summed up in one sentence, it's a series of more than 190 specifications called Java Specification Requests (JSRs) that cover Java's implementation in everything from virtual machine-based application servers for enterprises (J2EE) to the desktop virtual machine (J2SE) to the commonly deployed CGI-like routines (servlets) used to interface those virtual machines with outside applications such as a Web server.

The fate of those JSRs lies with the working groups that make up the Java Community Process (JCP), an organization of hundreds of vendors. Although run by Sun, the JCP follows a largely democratic process; vendors involved in each of the JSRs (and the vendor list varies from one JSR to the next) have a lot of freedom to take those JSRs in whatever direction they see fit. For example, Sun leaves most development decisions for the many mobile Java specifications to companies like Nokia, Ericsson, and Motorola, who are in the best position to determine what Java in a cell phone needs to look like.

But despite the JCP's democratic look-and-feel, Sun, which owns the patents to Java, still retains veto power. Also, Sun's intellectual property stake in the technology allows the company to connect other requirements to Java and to those who want to profit from it. First and foremost of those are licensing fees that Sun collects from vendors who attach the Java brand to their products (i.e.: IBM's WebSphere or BEA's WebLogic). The actual fees that Sun charges to those vendors are one of the IT industry's best-kept secrets. Sun refuses to disclose what it charges Java licensees, and the licensees never tell.

But evidence suggests that not everyone pays the same price. Sources familiar with the licensing schedule say the players involved with the mobile JSRs pay more than vendors in the other JSRs, perhaps due to the prevalence of devices like cell phones. Oracle is rumored to have cut a sweetheart deal in exchange for pulling out of an IBM-led organization (openserver.org) that Sun perceived to be a threat to the Java brand. (Oracle's withdrawal from that effort precipitated that group's collapse.)

Compatibility requirement
Another requirement that Sun has attached to Java is compatibility. In order to benefit from the Java brand--a brand whose portability is based on a write-once, run-anywhere promise--the JSRs include compatibility tests that the various vendors' implementations (like IBM's WebSphere) must pass before they can claim to be certifiably Java compliant. In addition to the fees that licensees must pay, Sun also makes money on the compliance testing. In my interview with Sun's chief engineer Rob Gingell, Gingell joked about how it takes a rocket scientist to run these tests. Currently, most of those rocket scientists work for Sun. You get the picture.

So, when Sutor told me earlier this year that IBM wanted to see Java enter the public domain, the reasons seemed obvious. Any Java licensee, licensee-to-be, or licensee-wannabe would want to see Java in the public domain just to eliminate Sun's licensing and testing fees. Still, whatever IBM pays, it's probably a drop in the bucket for the technology giant. Perhaps another reason is Sun's veto power. I wonder whether, at some point, the JCP's so-called democratic process failed IBM. Maybe Big Blue requested specific changes to certain Java specifications (like J2EE), only to have them vetoed by Sun. Or maybe it's the prospect of a future veto that has IBM worried. With so much of its future riding on Java, Sun could play its veto card for no other reason than to stick it to IBM.

If any of these perfectly acceptable reasons for IBM wanting Java to be in the public domain were indeed IBM's reasons, Sutor wasn't going to admit it. Says Sutor: "IBM absolutely loves Java. We think we've done more work than anybody else on the planet in terms of Java's reliability and performance to make it enterprise ready. Moving forward, we want to be constructive. We don't want to get into a fight [with Sun] over this. We just think the whole way that Java is standardized can be done better. So, we're willing to use Sun's words to get this to happen."

Sutor is referring to Sun's positioning itself as a company devoted to competing on the implementation of royalty-free standards. Examples that Sun routinely hauls out to prove this point are the systems it sells, which are largely based on two standards: the IEEE P1754 standard for Sparc and the Open Group's Unix standards like the Unix 98 standard and X Windows that's been set by the Open Group. More to Sutor's point, however, has been Sun's recent reluctance to support non-royalty-free technologies--especially ones that have IBM's backing. For example, it wasn't until after the first security specification for Web services--WS-Security--turned royalty-free that Sun was willing to get behind it. So, in the case of some technologies, Sun has been true to its word. But not when it comes to Java.

While Sun and other companies refer to Java as a standard, Java is no such thing. Sun will argue that the involvement of hundreds of vendors in the JCP means that Java's fate is controlled by the same democratic process that controls standards coming out of the World Wide Web Consortium (W3C) or International Standards Organization (ISO).

In my book, a technology that has not received the imprimatur of an independent standards setting consortia like the W3C or ISO--especially a technology that's not royalty-free--is no more a standard than other technologies where prevalence gets confused with the term "standard" and royalties are charged for deployment (i.e.: Intel's x86 instruction set or Microsoft's Windows).

While Sun is certainly entitled to protect its intellectual property in the same way that Intel, Microsoft, and IBM do, Sutor wants Sun to look at Java the same way that Sun wants IBM and other vendors to look at Web services specifications like WS-Security.

"What Sun needs to accept about using the line of arguments they do is that it applies to them as well," says Sutor. "Sun is a competitor to us and is not a neutral body. What we want is an industry neutral body where no one company has too much power and that body has to have jurisdiction over all of the Java specifications."

Why was Sutor so adamant about the all-encompassing nature of this neutral body? What he said next made it clear: "If Java was an open standard, technologies like [Microsoft's] C# and the technologies it works with [like .Net] might not exist today."

With a substantial part of its software portfolio vested in Java, IBM would prefer not to leave anything to chance. Just as the Web grew on the backs of royalty-free protocols like TCP/IP, HTTP, and HTML, Sutor is arguing that liberation would stimulate Java's entrenchment and further growth, thereby greatly limiting .Net's chances of success. While dispatching Sun would be a tactical success, the endgame (as I've pointed out before) for IBM is not to beat Sun. It's to beat Microsoft.

While there's no telling what ubiquity Java might have achieved as an open standard, Sutor is probably right. Microsoft would likely have a more difficult time launching .Net against Java as an entrenched open standard than it would against Java as a proprietary technology. In fact, Sutor wonders whether .Net might have been launched at all: "What are C# and the Common Language Runtime virtual machine (CLR)? They're pretty much the same thing as Java. They're a language and a virtual machine with a few other differences. Maybe if Java was an open standard, Microsoft would have supported it instead of coming out with .Net."

In a post-.Net, non-standard Java world, that's a moot point. Now IBM wants the opening of Java--all of Java--fast-tracked. Opening up all of the JSRs would give Java at least one advantage over .Net. Currently, C# and the CLR are the only parts of .Net on target to become open standards. As .Net-based virtual machines go, the CLR is a heavily stripped down version of the full-blown .Net virtual machine. The CLR (and perhaps .Net) might not stand a chance against the fully open Java standard.

So, will Bob Sutor ever get his way? Is Sun going to open up Java? Certainly, Sun is moving in that direction. According to Gingell, Sun realized that it had to figure out a way to let open source organizations like the Apache Software Foundation license Java. Along those lines, Gingell says Sun intends to open-source Java, but that it's not a simple process because Sun doesn't own all the intellectual property in all the JSRs. For the same reasons it can't open source all of Solaris, Sun apparently can't legally open source all of Java either. The company is working on clearing the legal hurdles cleared.

Even if Java does get open-sourced, Sun remains unbending on the issue of compatibility. This is where that veto power comes in. If Sun doesn't keep a close watch on things, the company fears, the "write-once, run anywhere" promise of Java could be compromised. Its fears may be justified. Even with the current Java licensing structure in place, Microsoft went ahead and released a Java virtual machine (and the accompanying development tools) that gave the developers of JVM-based applications access to services in the Windows operating system. Technically, this made it possible to produce JVM-based applications that ran on Windows only.

That lack of portability, according to Sun officials, is evident to this day in the Java version of Yahoo! Instant Messenger (YIM). The Yahoo! client runs flawlessly in the old Microsoft JVM for Windows, but doesn't work at all in Sun's JVM for Windows. (Yahoo! was unavailable for comment.) Windows XP users have no way to run YIM for Java. Windows XP doesn't come with a JVM, the Microsoft JVM can no longer be downloaded from Microsoft's Web site, and Sun's JVM can't help either.

Sun sued Microsoft and the two companies later settled out of court.

But that wasn't the end of Sun's troubles. Last year, IBM established and donated a significant amount of code to eclipse.org (as in, "eclipse of the sun"), an open-source-based organization that oversees the development of the Eclipse integrated development environment (IDE). That IDE, according to Sun, also violates the spirit of Java's write-once, run-anywhere promise. Sun prefers that Java developers stick to the Sun-endorsed IDE, NetBeans.

Sun has a publicly contested the viability of Eclipse for other reasons. First, it claims that that there are strings attached to Eclipse's common public license (CPL). Second, Sun questions whether IBM is devoted to keeping Eclipse up to date. But according to the Free Software Foundation's Richard Stallman, IBM's CPL does indeed qualify as a free software license. And IBM just released an update to the Eclipse toolkit.

Eclipse.org isn't violating a Java license because it doesn't have a Java license. Sun is therefore powerless to do anything but wait and see if Java developers establish a preference for Eclipse over NetBeans. If they do, it could be a message to Sun that its grip on Java is too tight and that despite what Sun would like to see happen to Java, the developers would like tools that are a bit more flexible. Then again, any developer migration to Eclipse might just be the gravitational pull of the open source IDE with the most marketing muscle (IBM) behind it.

Either way, if Eclipse turns out to be the preferred IDE, it will be clear that developers are not nearly as concerned as Sun is about the threat Eclipse represents to Java's portability. To the extent that IBM is willing to go to great lengths to wrest control of Java away from Sun--from using Sun's own words against it to funding other open source efforts that undermine Sun's control of Java--I asked Sutor if IBM wasn't being a bit hypocritical, given the size of its own intellectual property portfolio. It was here, finally, that I found some common ground between Sutor and Gingell. Both men agree that intellectual property lawyers at their respective companies have their own understanding of how to protect a company's bottom line. The challenge for Sutor and Gingell is selling others in their respective companies on the notion that growth stimulated by open standards and open source could have an equal if not greater impact on a company's bottom line.

What do you think? Should Sun relinquish Java to a neutral body? Or, is Java best served when Sun is in control? TalkBack to me below, or write to me at david.berlind@cnet.com.