The ripple effect of a GPL'd Java will reach far and wide

The ripple effect of a GPL'd Java will reach far and wide

Summary: It's official. Despite some saying it couldn't be done, not only is Sun open sourcing Java, it's doing it under version 2 of the Free Software Foundation's GNU General Public License (GPLv2) using an FSF-endorsed footnote known as the "classpath exception.

SHARE:
TOPICS: Open Source
17

It's official. Despite some saying it couldn't be done, not only is Sun open sourcing Java, it's doing it under version 2 of the Free Software Foundation's GNU General Public License (GPLv2) using an FSF-endorsed footnote known as the "classpath exception." The FSF's classpath exception gives developers a bit more latitude than just the GPL itself by allowing developers to tie Java libraries into their executable code without forcing those final executables to conform to the GPL which is the normal GPL practice. The exception text states the following:

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

The FSF's classpath exception was originally created to go along with FSF's GNU Classpath. GNU Classpath was a set of developer libraries that the FSF community was working on to build a free software (not just open source) version of Java much the same way GNU Linux represents free software versions of many of the utilities found in Unix. In open source fashion, essentially, the free software community had been working to produce a free software clone of Java.

Now that Sun has open sourced Java using precisely the same licensing terms that the FSF had applied to GNU Classpath, the FSF will have no trouble endorsing the code as true free software essentially springing the so-called Java trap that FSF patriarch Richard Stallman had, in a 2004 essay, accused Sun of setting. In fact, during today's press conference, Sun played a video of Stallman not just saying that "the Java trap won't exist anymore" (as it applies to Java), he gave a stunning endorsement of Sun's behavior and contribution (as the largest contribution of its kind to the free software community). It was a complete 180 degree turn in disposition for the leader of the free software world. Sun's open sourcing of Java means that efforts to continue cloning it (in GNU Classpath) should probably be supplanted with efforts to migrate. Over at the Classpath.org web site, after praising Sun's move,  open source developer Roman Kennke wrote:

.....this is from my developer POV only. The fact is that now there is really no hard need for the GNU Classpath project anymore. But I want to raise two aspects here: 1. Many projects are built around GNU Classpath right now. It won’t be exactly easy and trivial to port them over to Sun’s libraries. Surely, it can and will be done, but for the time beeing GNU Classpath is still needed. (And could IMO provide a migration path). 2. The development environment of GNU Classpath is much more flexible right now. This spirit of hack - test - commit is part of what makes GNU Classpath attractive for developers, including me. I don’t think that this will be possible with Sun’s code, and rightly so. So, what I really would like to see would be a development process on Sun’s (and our) side that would allow hackers to hack on whatever project they like, and let one project include code from the other. Now, that is not an easy task and might not be possible at all. But let’s dream for a moment (man, those endorphines seem to be high today :-) ). So, I think both codebases will peacefully coexist for a while, and most likely converge too quite a great degree....

Kennke also wrote that by open sourcing Java, Sun can expect to see resolution to some of the platform specific dependencies that interfered with with Java's write once run anywhere promise (specifically on the mobile front).

Of important note is the fact that not all of Java will be going open source overnight. According to Sun's chief open source officer Simon Phipps, the first parts of Java to be open sourced will be a reference implementation of Java Enterprise Edition (JEE) and the Connected Device Configuration (CDC) piece of the mobile version of Java otherwise known as Java Mobile Edition (JME).

The reference implementation of JEE being open sourced under the GPL is the same one that was released under the name Glassfish using the Sun-authored CDDL open source license. Last week, Sun and Canonical, the outfit that distributes the Ubuntu distribution of Linux, announced that  Glassfish would be included in Ubuntu Linux. Ubuntu Linux was the first version of Linux to be certified to run on some of Sun's UltraSparc T1 "Niagara"-based servers and more recently was certified to run on the company's Opteron-based servers and workstations

In my opinion, having that sort of hardware support is a key element that Sun needed to have in place in order for the open sourcing of Java to make sense to the company's investors. One of Sun's talking points when it comes to explaining why it makes sense to open source Java is how open sourced ecosystems attract more participants which in turn should mean added traction for the company's hardware. But, with Linux being the most popular deployment platform for JEE-based applications (and Linux often perceived to be "water" when matched Sun's hardware "oil"), Sun needed demonstrable proof that its hardware platforms -- particularly its higher margin N1 gear -- are certifiably legitimate targets. 

On the mobile Java front, JME CDC JME CLDC is found in many cell phones and is one of many fragments of Java known as Java Specification Requests or JSRs, all of which are tracked and maintained under the auspices of the Java Community Process (to which many vendors contribute).

According to Phipps, CDC's immediate release will be followed by the release of the JME Connected Limited Device Configuration (JME CDC) which should be ready in the next couple of weeks. Set-top boxes and Blu-Ray DVD systems are examples of the types of devices that CLDC is used in. [Update: During the press conference regarding Sun's announcement, Sun's Richard Green announced that instead of being spaced out, CDC and CLDC would both be released immediately.]

Although JEE is often talked about as "big Java", the real big Java is probably Java Standard Edition (aka Java SE).  Not only does Java SE run at the heart of the version of Java found on many desktop and notebook computers, it's also the kernel that Java EE runs on. According to Phipps, the code behind Java SE is going to take a bit longer to publish as open source.  Perhaps six months.  Said Phipps:

At the moment all the code kept internally in a control system known as Teamware that's very old and it (the control system) is not open source.  We're going to move all the code from Teamware over to Mercurial, a distributed version control system. It's a process that's going to take some time. I don't quite know if will be released incrementally or if we'll wait to release it all in one big bang.

In the bigger picture, Sun's open sourcing of Java has also sorts of implications. Not just for Java itself and Sun, but for other companies and open source projects. For example, now that Java has been open sourced under the GPL, both IBM and Microsoft may have some recalibrating to do. 

IBM -- one of Java's biggest proponents and one of Sun's biggest licensees -- has long called for Java to be open sourced. Over the years, IBM has complained about a variety of issues ranging from the licensing fees it has had to pay to the fact that Sun had too much veto power over the what happens at the Java Community Process. But it already appears as though open sourcing Java under the most widely deployed open source license is still not enough to assuage IBM. Now, according to CNET News.com's Martin Lamonica, IBM is voicing concern over Sun's selection of the GPL versus that of Apache's open source license. IBM has been a supporter of a variety of open source Java efforts taking place at the Apache Software Foundation. Wrote Lamonica of a statement issued by IBM today:

"In light of the Apache projects, we have discussed with Sun our strong belief that Sun should contribute their Java technologies to Apache rather than starting another open-source Java project, or at least make their contributions available under an 'Apache friendly' license to ensure the open-source Java community isn't fragmented and disenfranchised, instead Sun would be bringing the same benefits of OS (open-source) Java to this significant and growing open source community," the statement said.

Although I'm not sure about disenfranchising part (how could anyone say that a large contribution to the FOSS community under the GPL will disenfranchise it), in reality, Sun had no choice but to make a fragmenting choice. By choosing to go with the GPL, the move equates to legal alienation of the Apache community. Had Sun gone with the Apache license, it would have legally alienated the GNU Classpath community. Sun had to make a choice. During today's press conference, via instant messenger, I noted IBM's comments and asked Sun executives why not pick Apache instead. In response, Sun's software chief Richard Green said "There is no perfect choice. We chose what we thought was best for Java and for the community." In the back of my mind, I was wondering whose endorsement was more important for Sun? Stallman's or IBM's? I think the answer is obvious.

But, in what was an obvious reference to the proprietary nature of IBM's JEE offering (Websphere), Sun CEO Jonathan Schwartz said "It would not surprise me in the least to see a growing number of proprietary software companies see this as a threat."

There's an obvious reason that proprietary software companies prefer the Apache license over the GPL.Via telephone earlier today, Larry Rosen, the open source lawyer who literally wrote the book on open source licensing, told me:

The Apache license allows you to take the software [distributed under it], create derivative works of that software, and distribute those derivative works under any license you want [including proprietary ones] whereas the GPL requires derivative works to be distributed under the GPL. The Apache license is compatible with proprietary software where as the GPL is not.

Even so, I can see why this was a tough choice for Sun. In choosing which direction to go, Sun had to make a choice to be more compatible with GNU Linux (licensed under the GPL), or more compatible with Apache. In terms of percentages, I'm willing to bet that a higher percentage of Java installations run side-by-side with Apache than they do with Linux.

But, in finally answering IBM calls to open source Java, there's no doubt in my mind that Sun knew exactly the sort of indigestion that selecting the GPL would cause to IBM. In doing so, much the same way it's probably best for the existing GNU Classpath project to be wound down, it probably doesn't make a lot of sense to continue redundant investments in other open source clones of Java at this point. With the selection of the GPL, Sun may have completely neutralized the enourmous investment that IBM has so far made into open source Java. Especially now that Sun's selection of the GPL paves the way for Red Hat, Suse, and others to include Java with their Linux distributions.

In fact Schwartz came right out and said that Sun consulted with Red Hat (which is rather amazing, in and of itself). In other words, the issues aren't just legal or technical. There will be a certain amount of gravity in existing market channels that could make redundant investment completely impractical.

If and how multiple but legally-incompatible open source Java projects can ever be reconciled, I have no idea. But just to throw another twist in the rub between IBM and Sun (perhaps fodder another post), open sourcing Java could shake things up a bit in NetBeans vs. Eclipse land. Personally, I think the news is more favorable to Eclipse than NetBeans given that Sun's beef with Eclipse has always been the extent to which it marginalizes Sun's write once, run anywhere promise. But the developer community behind Eclipse is big enough to say that Sun's arguments have been rejected to the point that a merger of Eclipse and NetBeans should be reconsidered. Now that Java is has open sourced, much the same way some write-once run anywhere problems may end up getting solved by open source developers, new ones, along the lines of the things that Eclipse originally did (and that enraged Sun) will spring up. Now, Sun has no choice but to go along with that sort of innovation and continued adherence to the party line would be somewhat hypocritical. But legal challenges. remain. Eclipse is not licensed under the GPL. 

Over in Microsoft land, some .Net folks may need to reach for the Pepto as well. After years and years of downplaying the legitimacy of the open source model and GNU Linux, I don't think anybody at Microsoft is under any illusion about the realities of operating system commoditization. Despite Microsoft's insistance that the open source model was incapable of producing a worthy operating system alternative to Windows, it did just that in Linux. Over the years, independent developers and commercial vendors alike have come forward with contributions that have caused the Linux ecosystem to hockey stick at the expense of Windows and proprietary Unix. By open sourcing Java (which was already off to a big head start over .Net), Microsoft could be in for a repeat of what happened with operating systems, but this time, with middleware instead. 

Where might the impact on .Net be felt first? Well, there are millions of developers out there all working with different languages most of which are not compatible with either Java or .Net. That's right. Compared to the number of languages that work with one or the other, there are many more that do not. Now that Java is being open sourced, the way has been paved for developers who want to connect their favorite language to the Java Virtual Machine to actually scratch that itch. In other words, in the past, it may have taken an act of Sun in order to get dynamic language support for some languages the way it has for Ruby. And, if there's one thing that can really put an open ecosystem on turbo-chargers, it's dynamic language support. Microsoft's .Net, by the way, offered dynamic language support long before Java did. But now, it will be far easier for the Java community to marshall the resources of the open developer community to cultivate a wider range of dynamic language support.

It was probably not a moment too soon that Sun open sourced Java. In my opinion, whereas Java has long been the platform of choice for enterprise-class networked applications, the dot com revolution along with the shift to Web services-based compositing of applications and the proclivity of startups to use lighter weight platforms such as PHP or Rails for rapid to market development are all trends that were well positioned to permanently marginalize Java so long as it remained a "closed" ecosystem. PHP and Rails may not have the industrial strength that Java has. But that would have been like saying years ago that MySQL will never drive mission critical applications (or evolve to the point that it can) or that JBoss can't be considered in situations where BEA's Weblogic or IBM's Websphere might normally be applied.

Real work actually gets done on lesser-capable platforms and over time, those platforms mature anyway. Ironically, the opening up Java could stimulate the sort of innovation that makes it just as viable in lighter weight situations as it always has been in the industrial strength ones. 

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

17 comments
Log in or register to join the discussion
  • Just anther language

    added to the heap. And not a good one at that. But I imagine the open source folks will love it, they have a penchant for half baked things.
    No_Ax_to_Grind
    • More than a language

      The whole Java platform stack is being open sourced, not just the language. Software that runs on everything from mobile devices to servers is affected. I especially think this plus the move to Linux on mobile devices will have a long lasting effect on how programs are written for phones and pdas. And a devastating effect on Windows PocketPC/Mobile/CE, Palm, and maybe even Symbian.
      Ed Burnette
      • I'd be upset

        [i]And a devastating effect on Windows PocketPC/Mobile/CE, Palm, and maybe even Symbian.[/i]

        The prospect would worry me if I hadn't become resigned to Palm's [i]seppuku[/i]. The others aren't worth the keystrokes to curse them.
        Yagotta B. Kidding
      • Time will tell

        Myself I find Java programing to be tedious and full of pit falls.

        But hey, to each their own.
        No_Ax_to_Grind
      • hitting the Kool-Aid again?

        All of the Java tools were available before and yet we still have all of the Palm/PocketPC/Symbian platforms. Cell phone OSs are picked by the manufacture, not some bored geek with too much time on their hands. When was the last time that you tried to replace your cell phone OS with a hacked Java OS? It doesn't happen. Most consumers treat their cell phone like their toasters, they use it as it is and do not change it, they only want it to work. As cell phones are used more and more for electronic payment there is even less chance that people are going to want their cell phone hacked.
        balsover
  • Odd premise.

    Quoting:

    Over in Microsoft land, some .Net folks may need to reach for the Pepto as well. After years and years of downplaying the legitimacy of the open source model and GNU Linux, I don't think anybody at Microsoft is under any illusion about the realities of operating system commoditization.

    Yes, the operating system is not commoditized. Microsoft has no illusion about that at all. The company is expecting $ billions in Vista sales because it's Vista, and will receive them.

    And the unique capabilities of Vista will be used by many developers for applications that run on Vista. And XP, so that there's a huge market immediately.

    The operating system doesn't look commoditized to me. The Windows ecosystem and the many people and organizations that live there aren't bothering with second worksites.

    So how will Sun's sacrifice have an impact on .Net? Doesn't change the software, but just reduces costs to a number of large companies and gives them all the control that they want. Poor Sun. But IBM is happy.

    Microsoft's consideration of this choice may be limited to accepting that the company's money provided to Sun was a bad idea. Money advanced to a self-destructive person (or company) is always at risk.
    Anton Philidor
    • I don't think IBM is happy...

      Licensing under the GPL is a sign that Sun has no intention of giving up any control over Java.

      Why?

      Because Sun is going to have to retain all the IP in Java in order to continue selling it under non-GPL licenses, which just about every commercial vendor that was annoyed at Sun for charging them fees will still have to buy.

      If Sun had used the Apache license, IBM would have renamed it the "WebSphere Virtual Machine" (or something of the sort), gave Sun the finger, and proceeded to fork Java and call it something else.

      So Sun can keep on charging IBM as long as it gets all contributors to sign over their IP to Sun as a condition of contributing. Kinda sneaky, huh?
      Erik Engbrecht
  • telcos should be very afraid

    JME + Mobile Linux + WiFi + Google
    fricker
    • = so what?

      Why should telcos be very afraid?
      balsover
  • Java ME correction

    There's a slight error here regarding Java ME. CLDC is the version of Java typically found in cell phones, and was open sourced today. CDC is the version found in TV (including Blu-ray) and other more advanced devices, and was originally to be open sourced in a follow-on release, but was also made available today. So both branches of the Java ME family are available.
    BillShepp
  • More diversity means more division

    I was a Java programmer for years and the one thing I found was that every element in the process required a choice. Which J2EE server do you use (if at all-- Spring anyone?). Which XML parser? Which UI framework (Swing or something else)? Which web server will host your web app? Jeez, it took about 6 months for a company to make this decision. meanwhile, I could have already written the darn thing and been off playing World of Warcraft.

    Anyway, I had to go to soo many meetings just to decide on things like which database and which server, blah, blah, blah, and the reality most of that didn't matter. It was really someone who had some bug about some open source piece of code he spent way too much time exploring and thought it would be good for everyone to adopt. And it wasn't just one guy, but just about all the guys had some different pet framework they wanted to use.

    Java has its benefits, but too many cooks spoil the broth. I'd say about 90% of the time a standard solution will get you by just fine (some basic J2EE) and there should be some cheap system to put it into place. But the cheap solutions still have crappy tools with them. Stop building frameworks and start building tools if you want to be ligit in my opinion.

    Anyway, MS doesn't do anything the best, it just does everything universally good. And every developer who uses their solution understand each other. Every C-level guy in a company worth his salt will tell you a solution that minimizes communication hastles is worth the effort. Software is still darn cheap compared to people (unless maybe some Chinese kid chained to a PC by the government and whipped into coding-- type, Woo, type!)

    Less framework changes. More universally accepted tools. Then you'll compete with Microsofr. Otherwise, its just mainly doing things to be different (like white socks with a black suite).
    agramont9
  • Will this allow MS to release new versions of MS java?

    Provided, of course, that MS releases it under GPL.
    XP user
  • correction on dynamic languages

    The article stated that .Net had dynamic language before Java. Although MS officially recognised the need and supported IronPython, I was using JPython (the precursor to Jython, created by the same guy who made IronPython) before .Net was even created.

    Unfortunately, it never became an officially supported SUN thing. Imagine if it had...

    Andrew
    AndrewMcVeigh
  • RE: The ripple effect of a GPL'd Java will reach far and wide

    You have so much knowledge about this issue,Your blog provided us with valuable information to work with It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as ?hereditary.? So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL.
    <a href="http://www.essayhelppros.co.uk/essay-writing-help.php">essay writing help</a> - <a href="http://www.essayhelppros.co.uk/uk-essay-writing.php">essay writing uk</a>
    daniswalker
    • RE: The ripple effect of a GPL'd Java will reach far and wide

      Applications use Java's ?import? functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link.the free software community had been working to produce a free software clone of Java.This is a very informative article.I was looking for these things and here I found it.
      <a href="http://www.customessayhelp.com/write-my-essay.html">write my essay</a> - <a href="http://www.customessayhelp.com/analysis-essay.html">analysis essay</a> - <a href="http://www.customessayhelp.com/">essay writing</a>
      frankhoggard
  • RE: The ripple effect of a GPL'd Java will reach far and wide

    Eventually i come here but want to say you that I used the linux system and excellent warmest congratulations to the person who i think because for that programe i take my job every day.The topic of your blog is very informative and rich in information one think which i want to say you that keep continue this sharing of information with your blog readers so java is GPL now.
    <a href="http://www.easyessayhelp.com">essay writing help</a> <a href="http://www.easyessayhelp.com/analysis-essay.php">analysis essay</a>
    tionnewatkins
  • RE: The ripple effect of a GPL'd Java will reach far and wide

    Thank you, I would really appreciate the efforts you all have made here to make this page more informative. Thanks again??? <A href="http://www.allegromedical.com/wound-care-c541/wound-dressing-c3775.html">wound dressings</a>
    alanfl