Score Another for Clarity and Transparency

One of the joys of my role at Sun is that it provides me a fabulous vantage point for observing the trends and patterns of our industry, while personally having earned the perspective of time to compare historic and current events, and thus to note the distinction between the relevant, the immaterial and the curious. I've also had the good fortune of being in a unique position during Java's decade-long journey of ever-increasing access, openness, transparency and opportunity.

Beginning in 1995, Java source code was made available under a research license. Shortly thereafter, Sun led the creation of the JCP—comprised of partners representing commercial, non-profit and academic interests—to share in directing the evolution of the Java platforms. And the rest, as they say, is history. Java is now the most popular and widely distributed software platform. And, despite the fact that we're all so accustomed to the following truth, that Java has earned that preeminent position in every aspect of the network computing universe—servers, desktops, laptops, mobile phones, set top boxes, embedded devices, smart cards, transactional systems and digital media, is all the more remarkable.

It was May of 2006 when Jonathan and I announced to the crowd at JavaOne that Sun would release Java technology under an open source license and, following words with deeds, Sun began doing so last November. We clearly defined the platforms—Java SE, Java ME, and Java EE, and the license—GPLv2, much to the delight and surprise of many, including the Free Software Community. This action was the culmination of a series of careful steps that Sun had been taking to open up our development processes—creating a community development process for the JDK and open sourcing our Java EE implementation under the CDDL license, which will remain under Project Glassfish as another license option for developers.

Throughout this journey, I've slept well at night knowing that Sun has done our utmost to balance the priorities of open source communities along with the responsibilities and obligations that we have with the myriad of enterprises, individual developers and consumers who have invested in the promise of "Write Once, Run Anywhere". The choice of the GPLv2 license was and is key to this balance, because it takes away the potential for a closed fork of the code, ensuring that we can all maintain compatibility. This simple, singular and unambiguous decision was made to protect the freedoms of all participants in the Java ecosystem, ensuring that innovation remains in the open, and creating a bridge between the existing Java ecosystem and the world of GNU/Linux. With these two communities working together, the scale of creativity and opportunity will lead to innovations that will no doubt dwarf those we have seen to date.

So today we're taking the next step—one I discussed at this year's JavaOne conference. Sun is making the Java SE JCK—the TCK compatibility tests that determine whether an implementation faithfully conforms to the Java SE specification—available to the Java GPL software community using a license that continues to protect the Java compatibility promise while respecting the values of free software. This means that OpenJDK implementors, including GNU/Linux distributions can test free Java implementations based on code released under the GPL in the OpenJDK community, and validate that their implementations are compatible with Java. We're empowering distributors of free Java implementations to be part of the "Write Once, Run Anywhere" promise, while fulfilling all of their obligations under the GPL.

The TCK is a conformance test. It’s the single authority against which everyone tests, and of course, a conformance test that could be altered would have neither value nor trust. So the tests are fully available for learning from the code, and running against OpenJDK-derived GPL’ed implementations, but the license doesn't allow for changing the tests. Anyone who flunked their first driver's exam probably wished then that they could change the test to conform to their mistakes, but the rest of us on the road are all glad that is impossible.

We knew when we chose the GPL and the free software model for Java technology that we couldn't satisfy everyone's desires. This is the case for the Apache Harmony Project at the Apache Software Foundation. The Harmony Project has applied for a license to use the JCK under the JCP's Scholarship Program for qualified not-for-profit organizations. Sun has offered Apache Harmony a license to use the JCK and the Java Compatible logo at no charge once their implementation passes the tests, and we’re even offering free support to help Apache run the JCK. But because the Apache code is not governed by the GPL, and does not require code sharing by any entity using or modifying Harmony, the terms of this license are the same terms under which Sun licenses the JCK to commercial entities that build their own independent implementations of the Java SE platform. As was made clear in their open letter to Sun, the ASF is not satisfied with these terms.

For what it's worth, I completely understand why there is disagreement. There are fundamental principles and goals that separately define the GPL and Apache Software Licenses. Unlike the GPL, the Apache open source license does not require innovation to remain in the open. Java technology governed by the Apache license could be altered by any organization—commercial or non-profit—and rendered both incompatible and inaccessible to the community. The trust and value of “Write Once Run Anywhere” could not be upheld.

And this is simply different from what we have articulated as a goal and a priority for the Java platform for more than a decade—because compatibility matters, and our communities expect us to keep their work in the open as Free Software.

But I would be remiss if I didn't clearly state the relationship between Sun's open source programs and our customer, employee and shareholder responsibilities. Sun is first and foremost an innovation company. It is what separates us from other organizations that vend commodities or directly leverage the innovation of others. I'm extremely proud of our accomplishments and take significant pride in ensuring that those associated with Sun realize the benefits of those virtues. No other large organization brings together the concepts of open source contributions, large-scale innovation, and rewarding shareholders. Sun is leading a grand scale change in the software industry—and I’m very pleased with the results. With Java as a prime example, we are making our software freely available, to individuals and institutions, both commercial and non-profit, under the clear terms of the FSF—the GPL. We believe that “copyleft” is both unambiguous and instrumental in fulfilling goals of both communities and commerce.

Sun believes it is of paramount importance to secure trust in all communities—be they open source or enterprise—by being absolutely clear about one’s plans, intentions and motivations. Thus we will have to agree to disagree on this point with the Apache Software Foundation.

So to be clear, anyone—yes, even Sun’s competitors—can use the Java GPL source code for anything—yes, even a fork—as long as they publish their modifications under the GPL—no other consideration required. They can use the TCK to prove to themselves and the community that their contributions do not alter the promise of compatibility. But access to the code, the tests and the ‘Java Compatible’ brand governed by any other OSS license is both outside of our pact with the community, and not in Sun’s best business interests.

In the 2002 letter that authorized the creation of the TCK Scholarship Program under which Apache Harmony has applied for their TCK license, Sun acknowledged the desire of the Java community, and the Apache Software Foundation specifically, to create independent, open-source implementations of Java standards under the auspices of not-for-profit open development communities. Apache and others have done just that over the intervening five years under the scholarship program. For example, Apache has successfully used the Java EE TCK to certify its Geronimo project and compete against others like the JBoss community and Sun's own Glassfish—Java EE Application Server. Let's not lose sight of the big picture—Java is free and open. Sun continues to contribute both code and development efforts to many Apache projects such as Tomcat, Roller, River (Jini), HTTPD, and Derby.

Sun has now fulfilled the dream of free, open and compatible Java. I'm passionate about the value and virtues of free software and we've proven it—our most valuable assets are now open source. The path is open for completely free and compatible versions of the Java platform to be shipped with operating system distributions of all kinds. I encourage everyone in the open source communities to look at the new OpenJDK JCK license and let the team know how well it works for you.



Good move, Rich! I'm pleased to see Sun take this additional step to foster the growth and health of the Java industry by simplifying Java compatibility testing. We both know there has been a ton of energy spent to preserve the meaning of the term "Java" as a sign of full compatibility with the platform specification. The TCK is right at the heart of keeping it that way. By making it easier to acquire and use the TCK, you are making it easier for Java to spread.

I, for one, like your choice to rely on the power of the GPL to keep things honest. It's probably a safe bet that someone would have a tough time subverting Java compatibility when they are obligated to have all their source code out in the open just like OpenJDK.

No doubt some folks will grumble that Sun didn't go far enough, or that Sun should have used some other license or granted exclusions. From my perspective it's clear that Sun has come very far, so I urge those who still find fault to focus on "progress, not perfection." Maybe in some future context their pet issues can still be more fully accommodated, but meanwhile there's a lot to like right here, right now.

Congratulations to all of you for getting this done.


Posted by Rick Ross on August 09, 2007 at 12:30 PM PDT #

The inner logic of this post is broken.
For example, there is no reasoning provided to back up the following statements
> GPLv2 license was and is key to this balance, because it takes away the potential for a closed fork of the code, ensuring that we can all maintain compatibility
> Java technology governed by the Apache license could be altered by any organization—commercial or non-profit—and rendered both incompatible and inaccessible to the community

and it is not surprising, as these statements just are not true.
The backup is provided in this very article: example of Apache projects shipping compatible software that has nothing to do with GPL.

Another important blunt in this article is
> a conformance test that could be altered would have neither value nor trust. ..., but the license doesn't allow for changing the tests.

Again, it is yet to see how the inability to distribute improvements is helping trust. The rules governing trademarks and logo usage are quite different from the issue of releasing JCK code under open-source license, theoretically allowing for having a single certification authority and open-source JCK at the same time. And of course, this kind of setting ultimately would be a win for the end users of Java platform, allowing innovation in the area of ensuring compatibility, as soon as authority governing JCK will start using contributions to improve JCK.

In the end, the actions of Sun are very much dictated by the complicated politics against potential competition, which is good by itself, and the hypocrisy surrounding it is just frustrating.

Posted by Salikh Zakirov on August 09, 2007 at 03:54 PM PDT #


Java technology governed by the Apache license could be altered by any organization—commercial or non-profit—and rendered both incompatible and inaccessible to the community. The trust and value of “Write Once Run Anywhere” could not be upheld.

1. is there anything that makes GPL forks resistant to becoming incompatible?
2. is there anything that prevents people to trust an authoritative organization ensuring that their signed executables pass TCK?
3. finally, is source code availability required to check an implementation against TCK?

So, I am assuming that in this article a false assumption persists that the freedom to create closed forks makes it impossible to check implementations against TCK and trust people who checked.

Just wanted some clarification.

Thank you.

Posted by Egor Pasko on August 09, 2007 at 04:58 PM PDT #


--- cut ---
Sun is making the Java SE JCK—the TCK compatibility tests that determine whether an implementation faithfully conforms to the Java SE specification—available to the Java GPL software community using a license that continues to protect the Java compatibility promise while respecting the values of free software.
--- cut ---

Let's be clear here: The "Java GPL software community" is not everyone that wants to implement the J2SE platform under GPL license. They are the ones that base their efforts on OpenJDK. Sun still does not allow fully independent implementations to license the TCK under these tems, does it?

Posted by Henning Schmiedehausen on August 09, 2007 at 06:03 PM PDT #


OpenJDK is the fourth most important contribution to open source after gcc, Linux
and Apache. While its predecessors came much before and were true open source efforts,
OpenJDK, 11 years after the first release is good. Much of the source was always
quite available for anyone who wanted it though.

Yet it is important to understand that others need to stay closed to build a business.
Truly open implies that I allow others to remain closed. Oracle, Microsoft, IBM and
VMWare are truly closed source companies that serve their employees, partners, shareholders and customers.

"Evangelical Open Source Communitarianism" should not be all about "Executive Feel Goodness". After all, how many of those lines of code did you really write?

Posted by Anonymous on August 10, 2007 at 12:59 AM PDT #

Quoting: How many of those lines of code did you really write?

I think you're confused somehow. Let me help you here: Did you really asked SCO?

Posted by Serge on August 10, 2007 at 02:55 AM PDT #

I have some bad news. GPL does not stop different versions of the JDK behaving differently.

1. There's nothing to stop me making a modified version of OpenGPL, and deploying across my F100 company, and as long as third parties dont get copies, I dont have to share my patches that add working proxy support, laptop-aware networking, and other things there isnt in the JDK. People who provide tools that run on the modified platform will have to field bugreps against it, just as today you have to handle bugreps against debian unstable. Add enough diagnostics and assertions on your code, and you can deal with a bit of instability.

2. If, after adding decent laptop support and working proxy code, I released it under GPL, there would be a different version of the JDK out there. Sun could take this code and fix their own JVM (hint: laptops move and network settings change when this happens), but as I would only license it under GPL, they wouldnt be able to dual license it and so probably be unwilling to use my code to fix their JVM.

3. You couldnt even add new 'test how the JVM works on a laptop' tests to the TCK to enforce the existing (Broken) behaviour as that would have to go through the standardisation process and only apply to new releases.

All this TCK announcement does is address the problem that without a test kit, making the source to one Java implementation is useless. Nobody could make a change, and the JDK team wouldn't want all the untested cruft coming back.

At the same time, keeping the JCK a secret is silly. The code is out -there is no longer anything sacred about the test suite.

-Steve Loughran, Author, Ant in Action.

Posted by Steve Loughran on August 10, 2007 at 05:39 AM PDT #

[quote]The trust and value of “Write Once Run Anywhere” could not be upheld.[/quote]

Err, I don't see how this follows. Whether the code is GPL'd or APL licensed, a given organization can create an incompatible fork and use it internally without Sun or the rest of the community ever knowing or caring. Conversely, whether the code is GPL'd or APL'd, Sun can require it to pass the TCK in order to be called "Java" if they want to distribute to the rest of the world.

There just isn't any connection between the license the implementation is released under, and the fact that Sun owns the Java trademarks and logos and what-not and can impose any conditions they want on implementors to call their stuff "Java." This suggestion that Harmony represents any danger to the "compatibility promise" of Java is plain and simply FUD in it's purest form.

Posted by Phillip Rhodes on August 10, 2007 at 04:53 PM PDT #

Rich, your arguments just don't hold water.

The license deliberately excludes to use the TCK on anything not derived from OpenJDK. That you mention the GPL is just window-dressing. OpenJDK happens to be GPLed, so the restriction to OpenJDK-based implementations just happens to encompass the GPL. Or, as others rightly put it, you are spreading FUD. The license prohibits to use the tests on a non OpenJDK-based, but GPLed Java implementation.

You also not only deliberately excluded GPL Java implementations except OpenJDK, you also deliberately excluded projects like Harmony. The license implies the only FOSS Java implementation that ever has a chance of gaining the right to claim "Java compatibility" is Sun's own OpenJDK. Hardly big news. Sun says Sun's Java is compatible with Sun's Java. WOW!

However, the license under which a product is available in no way relates to the product's adherence to a standard. Claiming otherwise is spreading FUD.

The license is politically and business motivated, but not technically motivated. Please stop making technical arguments for what is simply an attempt to keep the competition away.

Sun has every right to do this, but please keep the lipstick away from the pig.

Posted by Kauer on August 10, 2007 at 06:21 PM PDT #


Incredible FUD surrounding why Apache published the Open Letter to Sun.
The Open Letter does not address whether the TCK is licensed one way or the other, but that it contains Field of Use restrictions, which Apache claims are incompatible with the JCP agreements between its members.

The particular Field of Use restriction in question is that Harmony would need to require that downstream users don't use Harmony for anything but desktop computers, excluding all kinds of other devices.

Why don't you mention this?

Further, why on earth would the JCK license impose restrictions on what it is tested on? This should be a Trademark issue. "Hey, you want to call it Java. You can if it passes the TCK from http://....". The fact that the JCK imposes additional requirements, (that you can not test a non-GPL implementation) beyond the GPL itself, is AFAIU in conflict with the GPL itself.

I take this entire Blog entry as an outright lie. People who want to run the TCK are interested in the compatibility, WORA, principles that we all love. If I am interested in fracturing the Java platform, I go off and create dotOrg and wouldn't even bother with the JCK conformance tests.

Why is Sun trying so hard to portray a different picture? Why not tell the truth up front? I'm sure the community at large is mature enough to hear; "For commercial reasons, we are doing ...", "The business goals of the corporation is not compatible with..." and similar. The FUD and outright lies are a lot harder to swallow.

Unbelievable BS!

Posted by Niclas Hedhman on August 10, 2007 at 10:09 PM PDT #

Let me retract the misperception I had, that the JCK was licensed under GPL, as I thought after reading the blog the first round.

That still doesn't change that the rift with Apache is over Field of Use restrictions in the offered JCK license to Apache (Scholarship Program).

Posted by Niclas Hedhman on August 11, 2007 at 02:34 PM PDT #

This article claims to present an understanding of the ASF complaint, but it does not mention any of the \*real\* issues of freedom of use and Suns contractual obligations under the JSPA.

This article claims to be a "Score for Clarity and Transparency" yet it diverts attention away from the ASF complaints which are in no way related to open source licensing. The ASF is not concerned with telling Sun what licence to use for OpenJDK, it is only concerned with Suns lack of clarity and transparency in the JSP process.

It is no accident that the ASF were voted the JSP member of the Year [1] shortly after the publication of their open letter. Other members respect the ASF's willingness to stand up for clarity and transparency as can be seen in the comments on the award announcement page [1]: "The ASF has impacted the direction of the JCP program by consistently driving collaborative transparency while serving on the Java SE/EE EC."


[DISCLAIMER] I am a Member of the Apache Software Foundation, but in this comment I represent my personal views only

Posted by Ross Gardler on August 13, 2007 at 07:39 AM PDT #

Tom Goguen said Sun was considering licensing OpenSolaris under GPLv3 but he has since left your company. Would you be able to tell me if you consider GPLv3 licensing for OpenSolaris to be a good path still? If you do, when would you anticipate change and if you don't, why not?

Posted by Rob on August 14, 2007 at 02:26 AM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016