In case you missed the most recent chapter in one of the most important power plays taking place in the computer industry, last week IBM sent an open letter to Sun urging the company to turn Java over to the open source community. To Sun, the company that gave birth to Java, the letter must have seemed like a Trojan horse.

The letter was sent via e-mail by IBM's Rod Smith, vice president of emerging technology, to Sun's chief engineer Rob Gingell, and it earned the "open" classification because the press was copied on the note.

To the untrained eye, it appears as though Smith is asking Gingell to make Sun practice what it preaches. The note quotes a question posed by Sun chief technology evangelist Simon Phipps during the most recent gathering of Eclipse supporters: "Why hasn't IBM given its implementation of Java to the open-source community?" In the letter, Smith goes on to characterize the Phipps quote by saying, "Simon's comment appears to be an offer to jointly work toward this common goal." I'm rather sure that wasn't the gist of his comment. Although I wasn't present to hear the quote, I suspect that it was a rhetorical question posed by Phipps in an entirely different context than the one Smith suggests in his letter. So far, Sun has been unavailable for comment.

Let's forget for a minute that as important as Gingell is inside Sun (he is responsible for the overall technical architecture and direction of Sun's product line), such business decisions are not made by one person and certainly not by Gingell alone. By copying the press, the letter subtly suggests that hypocrisy worth investigating is afoot. It paints a picture of an IBM with its arms extended in hopes of spreading the Java love. If Sun doesn't play ball, it could be perceived as defiantly resisting the combined wills of the Java and open source communities.

But if there's one tiny clue to the letter's disingenuous nature, it's the inclusion of Gingell's e-mail address. Such a faux pas in "public" e-mail etiquette is commonplace for newbies to email, but not for someone like IBM's Smith. As a continuation of IBM's almost four-year-old pursuit to wrest control of Java away from Sun, it was a good chess move by IBM. No doubt Gingell's inbox is overwhelmed with inquiries.

With Gingell and Sun both mum (as IBM knew they would be), the press coverage may have unwittingly played right into IBM's hands. All sorts of anti-Sun verbiage is sprouting up. Some say that Sun, and not the other JCP members, is preventing Java from being truly open, or that IBM wants to invest in an independent, open-source Java implementation for the benefit of all. Rick Ross, a Java developer, said that Sun accounts for only about 5 percent of the Java industry, yet it has control of the platform positioning and is not promoting it enough.

Sun had little choice but to look like the bad guy. If you ask me, the real wolf here is IBM.

Since May of 2000, when IBM tried to organize a Java-licensee walkout just before Sun's annual Java lovefest (JavaOne) under the auspices of an organization called openserver.org, BigBlue has relentlessly been pursuing the freedom of Java.

For IBM, Java plays a starring role in its WebSphere product line, which aims to deliver real-time data anytime, anywhere and to ease the cost and complexity of integrating disparate systems. Many riches and spoils await the leading provider of the glue that brings together all of the moving parts. For IBM, Java is that glue.

For Microsoft, .Net is the glue. Thanks in part to all of the collaborative work that IBM and Microsoft have done in the area of Web services (much of it without the blessing of Sun), the same roads that connected the two types of glue also make substitution of one for the other possible. Knowing that Microsoft itself is licking its chops at the prospect of supplanting Big Blue's big iron with .Net-based systems, IBM can ill afford to let another company control its fate. The last time IBM put itself in that precarious position with Microsoft and OS/2, it nearly destroyed the company.

Since the demise of openserver.org (Oracle backed out at the last minute), IBM has used every weapon in its vast arsenal to pry Sun's fingers off of Java. The most visibly successful of these maneuvers so far has been the creation of the aptly named Eclipse project. From the tools used to build applications for WebSphere, IBM extracted and open sourced an integrated development environment (IDE) for Java that, much to Sun's chagrin, invited developers to violate of one of Java's chief tenants--universal portability from one vendor's certified, compatible Java runtime to the next. Many of the third-party tool makers that supported the incumbent IDE NetBeans at the time rushed to support the IBM-backed project as well. The move drove a stake about as close to the heart of the Java community as IBM could get without running afoul of its Java license.

In addition to Eclipse, Big Blue, along with BEA, took another swipe at Sun with J2EE extensions. IBM and BEA, which combined have a controlling share of the market for Java-based application servers (known as J2EE), waited until precisely the day after the most recent J2EE standard was published by the Java Community Process (the organization which oversees Java standardization) to announce joint support for three proprietary J2EE extensions. Later, after the extensions had been turned over to the JCP for eventual incorporation as Java standards, Jonathan Schwartz, Sun executive vice president for software, discounted the move as a desperate response to Sun's own offering a free J2EE-based application server.

To me, the message to Sun was crystal clear: If Sun isn't willing to share control of Java with IBM, then IBM will figure out ways to take matters into its own hands. Smith's letter is a subtle hint to Sun that there's still a way to resolve their differences peacefully by giving up Java.

IBM's desire to see Java open sourced has many people confused. After all, given the way Java licensees can contribute to the evolution of Java, the Java Community Process bears many resemblances to the way open source software is developed. Two complaints that IBM has had over the years is that it has to pay to play, and even after paying there are no guarantees. Sun has the controlling veto vote over the specifications (known as Java Specification Requests or JSRs) that matter most to IBM.

However, IBM is hardly in a position to complain about either. After all, in 2003 IBM passed BEA for the top spot in J2EE market share. With the largest intellectual property portfolio in the world (said to command some $3 billion per year in revenues), IBM is hardly one to talk about having to pay for the use of someone else's invention.

As far as the veto power is concerned, no JCP member has ever come forward with evidence of a Sun veto having taken place. That said, there have probably been hundreds if not thousands of new ideas for Java that have never seen the light of day simply because the person or company who thought of them knew Sun would never allow them.

If there are any clues to IBM's pain point, they can be found in a 2002 interview I conducted with Sun's Gingell. Commenting on the open sourcing of Java, Gingell said: "We've practically open sourced [Java] anyway. The only difference between JVM licensing and open source is that we say you have to stay compatible. An open source license says that you don't have to stay compatible. Compatibility is actually what the Java community cares about. So if you're going to use our stuff you have to stay compatible. Otherwise, there's no difference between it and an open source license….The reason open-source zealots don't like the Sun Community Source License is because it requires that you stay compatible. When they say, 'We'd just rather you delete that phrase,' we say no."

To understand why this conflict comes down to compatibility, and who the arbiter of it is, look at what has happened in the Linux community. As Gingell has said, and as the different distributions of Linux have proven, there are no compatibility requirements in the open source world. Despite the existence of a single Linux kernel, there are a sufficient number of incompatibilities between the different distributions of Linux to say that they are not only incompatible, but also difficult to substitute for one another.

In my LinuxWorld interviews of two IT executives from Midwestern banking giant, The Northern Trust, I learned that the company had gone so far down the Red Hat path in their Linux deployments that there was no going back, even if an alternative distributor like Novell (SuSE) offered a better safety net (Red Hat offers none) in the event that the bank was sued by SCO. The Northern Trust's situation exemplifies how, at least in the U.S., Linux compatibility isn't necessarily defined by the open source community, but rather by the vendor with the largest market share. This situation makes it difficult for other distributions to compete, and more importantly, for customers to have greater freedom of choice.

It's precisely for this reason--compatibility--that IBM is hoping to see Java open sourced, but Sun has so far refused to budge. As a Sun Community Source Licensee, IBM is obligated to not only make WebSphere compatible with other J2EE implementations, but to warn developers should they venture down the path of proprietary extensions that effectively eliminate any chances of portability without reprogramming.

If Sun relinquishes control as the arbiter of compatibility by open sourcing Java, it leaves the door open for IBM's WebSphere to become the Red Hat Linux of J2EE--the defacto standard J2EE by which all others are measured. Much the same way Red Hat's proprietary extensions to Linux keep the competition at bay, and customers from switching, WebSphere would be assured of market dominance no matter what secret sauce its competitors come up with. More importantly to IBM, it can respond immediately to any threats from the .Net world with little or no interference because of overidding compatibility concerns.

As long as there's an official standard that all licensees (including IBM) must conform to, no single vendor is assured of a lock on the J2EE market or can be put in the position of establishing a de facto standard including proprietary technologies that are not freely available to competing vendors (as is the case in the Linux market).

Despite IBM's current lead, it is precisely this "standard effect" that poses the biggest threat to Big Blue, particularly from free implementations of J2EE like JBOSS and Sun's own Application Server 8.0. With free versions of certifiably compliant J2EE-based application servers floating around in the market, IBM has a challenge on its hands that it might not otherwise have if WebSphere were the defacto standard.

You can look at JBOSS to understand the real context of the question that Simon Phipps originally asked at EclipseCon. As most Java watchers know, JBOSS is an open source implementation of J2EE. Although it may appear as subtle, there's actually a big difference between an open source implementation of a Java specification like J2EE, and turning over development of the specifications to which those implementations must conform to the open source community. If I read Phipps' question correctly, he was challenging IBM to release the source code behind WebSphere itself to the open source community - something that, based on the precedent set with JBOSS, IBM would be allowed to do.

As it turns out, Sun has been gradually paving the way for open source implementations of JSRs to exist since 2002. In August of 2002, Sun broke an open-source logjam with the Apache Software Foundation, and since then has been slowly bowing to the pressure of the open-source community. According to Gingell (in my earlier interviews), allowing open-source implementations of Java specifications is not as simple as throwing a switch and magically saying Java is now officially open source. Since most of the existing Java specifications contain contributions from other vendors that were made under an earlier intellectual property policy of the JCP that had no allowances for open source licensing, it's not within Sun's rights to turn around and open source all the Java specifications any more than its within its right to turn around and open source Solaris (which depending on who you believe, now contains intellectual property that belongs to Novell, SCO, or no one). In the 2002 interview, Gingell spells this issue out when he said: "The process by which Java evolved came with a set of terms that effectively prohibited anybody from using an open-source license. But that's not our intention. The way the JCP is built is that the person who does the work has the right to decide how it is they're going to make it available. After all, they did the work. Whether that's open source or some variant of open source or not open source at all, they can do whatever as long as the terms are not rejected by the Java community. The change we made recently was to make one of those options open source." That change is what paved the way for existing specifications to be colored by open source language on their next revision and for new ones to be colored with it from the get go.

Evidence that Sun was making good on that promise surfaced in November, when shortly after version 1.4 of the J2EE JSR was ratified by the JCP, The Apache Software Foundation and JBOSS Group were given the go ahead to not only produce J2EE 1.4 compliant implementations of Geronimo and JBOSS (respectively) but to seek compatibility certification for them as well.Should IBM wish to open source WebSphere, there would be little Sun could do to prevent it now that the cat is out of the bag.

This of course is a long explanation to my final reason for suspecting why Smith's response to Phipps' EclipseCon comments appears to be a wolf in sheep's clothing. Thinking no one would pick up on the subtle difference between turning over the Java specification process to the open source community and allowing for open source implementations of those specifications, Smith used Phipps' very carefully worded quote in his open letter to purposefully confuse the two issues for the press who was copied. "Why hasn't IBM given its implementation of Java to the open-source community?" Whereas Smith attempted to expose a hypocritical Sun, he actually ended up exposing a hypocritical IBM.

Finally, the last bit of evidence casting doubt on the motives of IBM and Smith is his well-known relationship with Gingell. If the letter were really an olive branch, the correspondence would have started with a phone call, and the press might never have known.

We may see a lot of changes in the JCP over the coming years. But, I very much doubt that one of them will be a relaxing of Sun's commitment to compatibility and portability. That not only protects other Java licensees, it protects you.

You can write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.