Driving Technology Directions on Cloud Computing Platform

Ezhil Arasan Babaraj

Subscribe to Ezhil Arasan Babaraj: eMailAlertsEmail Alerts
Get Ezhil Arasan Babaraj: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, Apache Web Server Journal, Java Developer Magazine

J2EE Journal: Article

Filtering the FUD from Java Politicking on "Open-Source Java"

Filtering the FUD from Java Politicking on "Open-Source Java"

  • Read "Let Java Go" - ESR Writes an Open Letter to Scott McNealy
    ·
  • Read "No Sun Is An Island," Says Javalobby Founder
  • Read Should Sun "Let Java Go"? Counter-Arguments vs Open-Sourcing Java
  • Read "Let's Collaborate on Open-Sourcing Java": IBM Writes Open Letter to Sun
  • Read Sun's Schwartz: IBM's Request "Seems a Little Bonky"

    Until recently,  the ongoing Sun-IBM "open" Java debate had been a quiet collaboration (witness the agreement to allow Apache a "scholarship" for certification of Geronimo). That quiet debate had the lid blown clean off it recently by a series of very public (some might even say grandstanding) moves by Sun and IBM. The results are less about who's right than they are about who can play the media trump card better.

    I've spoken with people from IBM and Sun over the past few weeks, as well as some of the other players in this developer melodrama. And here, best I can tell, is the gist of the ongoing thumb-wrestling match for world domination between the two:

    First of all, there are people within both companies who very much want to see a single, unified, open-source implementation of Java--without forks, without compatibility breakdown-- to help widen adoption of the technology (and get it in the same CD set with every Linux distribution).

    But Sun wants to continue to derive revenue from Java licensing; Sun spokespeople say that the Technology Compatibility Kit license fees barely support the organization that puts them together, so all of the actual money that Sun derives from Java (aside from the sale of its own Java products) is from licensing the source code to the reference implementation (including, on the J2EE side, the same source code that makes up the Sun Java Enterprise Systen application server).

    Obviously, IBM is less concerned about whether Sun will be able to continue to derive revenue from licensing the reference implementation. And it appears some business-side people at IBM see some advantage to following a different route to open source--one that leaves compatibility (and the need for them to continue to license Java code) out of the final equation.

    You can understand, at some level, IBM business managers' frustration. They've dumped a considerable amount of IP into Java, and they still have to pay license fees for it. About 80% of the original J2EE was written by IBM.

    On the other hand, you could see IBM's recent comments as a friendly push. At least that's how IBM sees it. "We've tried to be relentlessly cheerful about this," Bob Sutor, IBM s director of Websphere infrastructure software products, told me. "We're really trying to be positive and constructive about this. We're not saying tomorrow you have to do this. "We're saying,Java's big when you look at the whole thing, let's start s lowly, figure out what we're talking about, see how we can phase this thing in, what makes sense so all the stakeholders can get what they want out of this thing, and take it from there. "

    Regardless of the intent, the whole thing has taken what had been a very long, quiet conversation about the open source future of Java and turned it into something of a circus. Open-source true believers, like Eric Raymond, have been lobbing their own grenades from the sidelines, making the last month a very interesting one, in a Chinese-curse sense.

    The Build-up to This Week

    About a month ago, as the community surrounding the IBM-led Eclipse open-source development tool project prepared to attend EclipseCon, Sun's Rich Green issued an open letter to Eclipsites, detailing why Sun would not (for the moment) be joining the Eclipse. The letter got mixed reviews.

    Basically, Sun decided to not adopt Eclipse as part of its toolset, because the company didn't want to abandon its investment in netBeans, another (Sun-led) open source project. It wasn't a definitive, final blowoff to Eclipse. But it was clear that Sun wasn't going to work on something it wasn't planning on using. "Diversity" and all that.

    At the EclipseCon conference, Simon Phipps, Sun's technical evangelist was on hand, mostly to just speak about the importance of open source. But in the Q&A, members of the audience steered the conversation in a more specific direction. Here's a verbatim transcript of part of Simon's answer to questions about why Sun hadn't yet open-sourced Java:

    " If you're going to ask, 'Why hasn't Sun given its implementation to the open source community?', I would retort, 'Why hasn't IBM given its Java implementation to the open source community?' 'Cause I don't believe it has. I believe IBM has at least three clean-room implementations of Java; I don't recall IBM ever creating an open source community with any one of them. Why hasn't anybody else, who has a Java implementation, created an open source community? I think that's the real question to ask."

    Perhaps he meant to ask that in the future tense, considering who his audience was. Because in the present tense, that's an easy question to answer: the Java Community Process rules haven't let them, at least up until now. Under the new JCP rules (JCP 2.5), that got fixed. The existing implementations of Java were all set under older rules, which were not friendly to open-source implementations. Under the new rules--which govern Java 2 Standard Edition 1.5--open-source implementations don't have to pay for the Technology Compatibility Kits (TCKs) required to certify compatiblility with the Java standard. But no one could do an open-source reference implementation of any of the previous Java stacks because of the contractual rules that govern them--at least not without the cooperation of Sun and the other major JCP members.

    That's why only bits and pieces of Java have thus far made it into the open source realm; up until recently, the cost of compatibility was too high to justify a full-blown open-source Java implementation -- and those who have done them (anybody remember Lutris and Enhydra ?). It's something folks at IBM are well-aware of.

    Regardless of what Phipps really meant to say, IBM's Rod Smith used Phipps' Q&A comments as the launching pad for an "open letter" of his own, addressed to Rob Gingell at Sun:

    "Simon's comment appears to be an offer to jointly work towards this common goal. IBM is a strong supporter of the open source community and we believe that a first class open source Java implementation would further enhance Java's position in the industry by spurring growth of new applications and encouraging new innovation in the Java platform. Here is the offer: IBM would like to work with Sun on an independent project to open source Java."
    Of course, IBM execs probably knew all too well that Simon's comment was nothing of the sort. But Smith's letter was an open play not to Sun so much as to the press, and to the open source faithful, calling Phipps' bluff.

    Sun Is Forced to Respond

    It worked. It put Sun on the defensive. Jonathan Schwartz, Sun's VP of software, was forced to respond directly. He called Smith's letter and offer "bonky" or something like that, and reiterated Sun's open-source dealbreaker--while opening the door a little further for some actual progress.

    Schwartz said that Sun was concerned about Java code forking like Linux, eliminating compatibility. But he said Sun was open to giving control over certification of Java to a neutral third party, like KeyLabs.
    "Java licensing places an imperative on compatibility, unlike what's happening in Linux servers," Schwartz said. Without compatibility testing he predicted Java for Red Hat would become the defacto standard for Java on Linux in North America, where Red Hat is the dominant Linux platform distribution. (from CBROnline)
    Sun spokespeople stress that Sun wants to maintain compatibility with the Java spec across all implementations - they don't want anybody to be able to take the Java code and go down their own road to implementation because the whole reason for Java's existence is its promise of portability of code from one implementation to another. Innovation is great,they say, but Sun doesn't want innovation to break compatibility.

    Some folks at Sun believe that IBM management wants just the opposite - they want an open source license for the Java stack that frees them of having to develop new standards within the Java Community Process, in a more ad-hoc way with other vendors. In other words, they want their own Java, without a Sun veto vote, or compatibility requirements, hanging over their extension of the platform.

    For example, if Java were licensed under a straight Apache license, IBM (and everyone else) would be able to create derivative products from the source code, and develop those products down their own code branches without having to maintain anything more than core code compatibility. (There could be some form of Apache license that didn't allow for forks in Java, but that's a topic for a separate discussion in itself).

    What IBM Stands To Gain

    A Linux-like (and balkanized) Java plays right into IBM's business interests. With a market-leading J2EE server in WebSphere, and a preponderance of professional services business based on its Java implementations, IBM could create its own open-source splinter cell of Java and extend it however it liked, without concern for standards or compatibility. That would give it lock-in with its application customers, who wouldn't be able to take "pure" Java applications and simply package them for redeployment on a different Enterprise Java Beans container (like BEA, JBoss, or Sun ONE).

    Bob Sutor told me that IBM isn't even to the point where it's even thinking about what the licensing of an open-source Java should be. " I don't think truthfully that we've gotten to that level of discussion. There are a bunch of open source licenses - frankly, it's one of those things where you have to sit down and figure out what's the goal of what we're doing here, see if there are existing licenses that we can tweak. We haven't gotten that far yet."

    I'm not sure that I buy that - especially in the context of his comments on compatibility. " I'm very much in favor of interoperability and testing. But there's always the balance of doing it by law, or giving the market some credit. Customers will say, 'If you're doing something wildly different, I'm not buying it'. "

    That's assuming that the software market behaves like a classic free market. Of course, what the market chooses isn't always good for it.

    Sutor recently told an IDG reporter that IBM and Sun will be meeting to discuss open source (a statement a Sun spokesperson will not comment on). And when asked about Schwartz's concerns about the forking of Java code under GPL like with Linux, he said:

    "I think that's overstated. Yes, there are different Linux distributions, but there are main distributions, and the kernel tends to be very consistent," he said. "If you're doing 'bonky' things then the market will reject them very quickly, you have to give the market, and the customers, credit."
    Which is FUD. Yes, the kernel is consistent. But there's not binary compatibility between all the versions of Linux - which is why there was all that hoopla over "UnitedLinux" a few years ago before SCO turned into an IP lawsuit disguised as a software company. You can't take a SuSE implementation of something and just drop it on a Red Hat system and run it, for example. Even on the same processor with the same kernel, there are enough significant differences in things like library support and other supporting code to make a binary move of many applications a pipe dream.

    When I asked Sutor about the Linux comparison, and the problems with portability from, say, Debian to Red Hat, he said:

    "Yes, you start getting some library issues that you can work out, then there are all the packages ... but I could also throw that back and say that from version to version of Windows there's not complete interoperability. It's really not that hard to get around. (With Linux), the market ended up making that work."

    (Well, the market, and IBM's backing of Red Hat.)

    Some people might say the same is true of the current state of Java. Moving pieces of Java applications might not be overly painful, but taking an enterprise application from one inplementation of J2EE to another is certainly non-trivial.

    IBM has been historically slow to get certified on the current release of the Java standard, so it has almost by default created a fork in the Java code base on several occasions. And While Enterprise Java Bean portability is light years ahead of where it was a few years ago, the major Java application server vendors are doing their best to "innovate" in ways that make it tougher for customers to move.

    Sutor defends that approach (evident in the way IBM and BEA brought Service Data Objects and other recent JSRs to the table). "Sometimes there are things our customers want us to do , and we have to respond to them. We don't twiddle our thumbs and wait three years and say we'll all get around to it...Frankly, we make no apologies, because we're getting stuff out there and seeing if it works, and people are giving feedba... If it has to be changed, that's cool."

    If Java gets balkanized in open-source, IBM will be the clear winner: revenue from Java would shift from software licenses to consulting and services. And neither Sun nor BEA have significant professional services units (especially when compared to IBM).

    You can see why IBM is eager to get its way. Of course, there are ways for IBM to get what it is asking for and not get its way.

    Let's say, for example, that Sun decided that an open source reference implementation was a great idea, but wanted to preserve its ability to derive commercial value from it. How would the company be able to manage that? By using, ironically, the same license scheme used by the Linux kernel: the GNU Public License.

    b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

    So, an open-source implementation of Java would be freely available, as IBM claims it wants--an implementation compatible in licensing terms to Linux, which could be freely redistributed with Linux. It would pass the Open Source Definition, and make the open source community happy, presumably. But at the same time, the GPL version of the Java reference implementation would be a "dirty bomb" for anyone creating derivative products from it -- everyone who worked with the reference implementation would either have to distribute their own derivative products under GPL, because they had become contaminated, or jump through some major hoops to avoid code cross-pollenation, or purchase a separate commercial license.

    From Sun.

    Now, Sun couldn't do this with all of Java on its own. However, it's likely that Sun could do it with parts of Java--like Java 2 Standard Edition. Or even just the Java Runtime Environment (JRE).

  • More Stories By Sean M. Gallagher

    Sean Gallagher is technology editor, Baseline Magazine, and blogs as the dotcommunist at http://weblog.dendro.com.

    Comments (26)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.