Most Read Technology Reporter For More Than Two Decades

Maureen O'Gara

Subscribe to Maureen O'Gara: eMailAlertsEmail Alerts
Get Maureen O'Gara: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java Developer Magazine

Java Developer : Article

If Sun Released Java Under an Open Source License, What Type of License Might It Use?

The Case for "Open Source/Closed Standards"

Related Links:
  • Red Hat Says Sun Should Open Source Java
  • Is "Free Software" Dead?
  • What's New Under the Sun? Sun's John Fowler talks to LinuxWorld Magazine

    There's been some debate recently on the license-discuss list hosted by the OSI on how to release code as open source while still requiring that it be compatible with a test suite that must be distributed as part of the code.

    The initial discussion was kicked off by Bob Scheifler of Sun Microsystems. Bob's original post was:

    "For my personal edification, and hoping this is an acceptable inquiry, I'd like to understand if and specifically how the following informal license sketch conflicts with the OSD. Any and all comments appreciated.

    1. The licensed work consists of source code, test suite in executable form, and test suite documentation.
    2. A derivative work in executable form that has passed the unmodified test suite can be distributed under a license of your choosing.
    3. Any other derivative work can only be distributed under this license.

    Any such distribution must include the unmodified test suite and test suite documentation."

    The idea would be to somehow require that derivative versions of the code would pass the test suite distributed with the code. As long as the derivative work passed the test suite you could distributed the code under any license you wanted - but if your derivative work did not pass the test suite, you'd be required to distribute it with the test suite included under the above sketch license.

    One use for this type of license would be to release code that implements some sort of API under an open source license, while ensuring that no one can change the API itself. For example, if Sun were to want to release Java under an open source license, this may be the type of license it would choose.

    By requiring that any derivative works pass the test suite, Sun could ensure that no one could publish derivative versions of Java that were incompatible with their version. The open source community (and other companies) could freely publish implementations of the code that passed the test suite, but Sun (or at least the JCP) would remain in control of Java as a standard.

    Hence the phrase, Open Source/Closed Standard.

    So, is this a good idea? Can something be considered to be "open source" if some organization stays in control of the standards that the software implements?

    Personally, I believe this should be fine. It's to everyone's benefit to allow open source implementations of standard API's while preventing fragmentation of those API's.

    For a good example, just look back a few years ago at the mess caused by Microsoft delivering an incompatible version of Java. Microsoft took advantage of their Java license and created a JVM (the MSJVM) that implemented what they called 'improvements' to Java (can you say 'embrace and extend'?).

    This caused a huge lawsuit between Sun and Microsoft. Sun claimed it was anti-competitive behavior and that it fragmented the Java standard (and they were right on both counts). It was to no one's advantage (except Microsoft's) to include a version of Java in every instance of Windows that was incompatible with all the other JVM's that were available.

    (Originally published here under a creative commons license)

    Related Links:

  • Red Hat Says Sun Should Open Source Java
  • Is "Free Software" Dead?
  • What's New Under the Sun? Sun's John Fowler talks to LinuxWorld Magazine
  • More Stories By Kevin Bedell

    Kevin Bedell, one of the founding editors of, writes and speaks frequently on Linux and open source. He is the director of consulting and training for Black Duck Software.

    Comments (9) View Comments

    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.

    Most Recent Comments
    Robert Marcum 10/01/04 09:22:03 AM EDT

    Why would you have a license for a standard specification based software like Java where you would allow ANY version which does not pass the specification validation suite to be distributed? !!

    It seems to me you could make the source available under a license that says, "Make what ever changes you want. And, you may distribute your work under this license freely, but only if it fully complies with the specification and passes the validation suite."

    Derek Berube 09/28/04 11:16:22 AM EDT

    I'm a big Java fan and love the "Write Once Run Anywhere" mantra. As a developer, I'd rather maintain a single codebase and allow my customers to choose their runtime platform based on the merits of the respective hardware platform.

    From an open source perspective I can appreciate what Sun is trying to accomplish by preventing forking of the code. You can say it isn't likely to happen, but Microsoft inherently "forked" the code in their MSJVM implementation.

    I think that the open source community could vastly help improve some aspects of the Java platform - look at how the JDK has benefitted from the inclusion/use of the Apache XML parsers. As another example, the 1.4 release of the Mac JVM supported sharing resources across virtual machines thereby reducing memory footprint and startup times. That type of functionality is soon to be made available to the rest of the Java community in the J2SE 5.0 release.

    Above all, I want full support of the Java specifications that are produced by the JCP. Anything that doesn't meet this can't use the Java brand. JVM compatibility is extremely important to me as a developer of Java products.

    Dalibor Topic 09/28/04 06:33:00 AM EDT

    If Sun's legal team sees the OSD as a challenge to write the most ambiguous license that still meets the OSD criteria but subverts the right to fork, that's still going to go down in flames, and leave Sun with another PR debacle. If you read the discussion, you can notice how people are getting increasingly annoyed about speculative attempts to wiesel around the OSD in order to tie in significant restrictions that are contrary to the spirit of open source.

    If Sun really wants to open source their Java(TM) implementation, they could talk with the ASF, FSF and the Eclipse foundation on how to do it right, and *then* submit a license that has a fighting chance of meeting *both* the requirements and goodwill of the respective communities.

    dalibor topic

    JavaLover 09/28/04 04:43:50 AM EDT

    It is interesting how every discussion about the future of Java boils down to "how can we prevent Microsoft from just killing it". There just does not seem to be any other problem that could not be solved in more that one way. Sun cannot take Java into open source only because of the Microsoft threat. There is no other power on Earth that could, in practice, hijack Java. It seems that market forces, government and courts are just unable to deal check such a concentration of wealth and monopoly power.

    Maybe, it is time to recognize that some categories of software are so vital that they in fact represent infrastructure that needs to be regulated by independent bodies, users or maybe even government. The format of office productivity suites springs to mind. We should have some rights regarding the documents we create. At the moment these are Microsoft Intelectual Property (according to Balmer). Maybe Java, as a cross-platorm should also be regulated in such a way. There are many arguments against this (stifling inovation) but there does not seem to be any other option that $40bn will not neutralize.

    Gartner Group has just called Windows a perpetual beta test. Are we willing to live with such infrastructure? It seems that this is acceptable only in the software business and no other infrastructure (telephony, post, air transport, traffic) - everywhere else, we have standards that prevent companies from "innovating" to their heart's desire.

    We just do not seem to be aware that MS Office and J2EE are vital infrastructures of the modern economy.

    jdkane 09/27/04 10:55:41 AM EDT

    Can open source and closed standards work together?

    Yes, anything can work if you make it work, and Sun is a hard-working company. The other questions is: Do we want it to work?

    Why not. Sun has to maintain some kind of reign on the technology if they are to control it properly to compete against (for example) Microsoft and .Net.

    Kudos to them ... they're trying their best to serve the best of both worlds: their own, and the Open Source community. Maybe it doesn't look like it's giving as much control to some developers as they want, but it's better than nothing. And the two sets of interests do compete ... so - again - kudos to Sun for even trying this. At least they're trying something new and innovative instead of saying it cannot be done.

    reporter 09/27/04 10:02:46 AM EDT

    Open source can work with closed standards under 1 caveat: the open-source programmers may need to rename a variant on the closed standards.
    The situation is analogous to building a chip that runs an instruction set architecture (ISA) owned by a competitor. The ISA is a closed standard in the sense that the company owning the ISA has trademarked its name. For example, MIPS technology trademarked the name "MIPS". A competitor, Lexra, then implemented a subset of the MIPS ISA, omitting 2 instructions. Lexra said that its chip is MIPS ISA compatible. MIPS sued and won. If Lexra had, instead, labeled its chip "MIPS ISA flavored", not "MIPS ISA compatible", then there would be no legal problems.

    Another good analogy is Microsoft incorporating the Java runtime environment in its browser. The environment was not fully compatible with Sun's closed-standard for the Java runtime environment. Sun sued and won. If Microsoft had claimed that the browser was equipped with a "Java flavored runtime environment" or "JavaPlus[tm] runtime environment" (and trademarked "JavaPlus"), then there would be no legal problems.

    I do not see a problem here.

    Open source is now a credible movement. The open-source development lab (OSDL) and the free software foundation (FSF) have sufficient clout that if any team of talented programmers created a language called "JavaPlus", derived from and mostly (but not entirely) compatible with the closed-standard Java, there is the strong likelihood that JavaPlus would come to dominate the market for Java. Then, Sun would need to kiss OSDL's or FSF's ass. Sun would be forced to alter the Java standard to make it compatible with JavaPlus.

    Kris Holland 09/27/04 09:28:23 AM EDT

    "Can open source and closed standards work together?

    No they can't really, and even if it were possible why wouldn't people just use Eclipse?

    "Under such a scheme Sun could maintain control of the Java API but allow open implementations."

    Sun never learns. When they got into fight over Java with Mircrosoft the result was MS making .NET. When will Sun decide to open Java up when Java becomes as much as an underdog/hasbeen as Solaris.

    No one cares anymore Sun, the community is just routing around you and soon you will be insignificant.

    anonymous cowherd 09/27/04 09:16:36 AM EDT

    Sun should just take a lesson from the Python Software Foundation. Although I don't like how Python's current implementation basically acts as a de facto standard (there should be a real standard rather than just a reference implentation that doesn't really reference anything), Python's implementation and "standard" are both open. Anyone can take Python and fork it in incompatible directions. Just take a look at all the posts in comp.lang.python regarding Python-derived languages.

    How has this affected Python? Not a bit. If anything, it's encouraged innovation through the Stackless and IronPython projects.

    I think what Sun is really worried about is trademark dilution. If that is the case, why not just specifiy that any derivative works must be named something other than Java? The only practical effect this would have is to make the licence GPL incompatible, since most people will rename a fork anyway. However, it does preserve Sun's trademark.

    Sun could still certify implementations as Java compatible, giving them the right to use the phrase, too. If there were a reasonable fee involved for certification, then Sun wins another revenue stream. It's a win-win.

    orcmid 09/27/04 08:11:02 AM EDT

    A few things about this article. First, I think there is an important difference between problems like open-source software that implements TIFF or PDF in some way (both specifications being held as proprietary).

    Secondly, it is probably not appropriate to refer to a "closed standard" because it doesn't mean the same as "closed source." I don't have a better term.

    Third, which I think is the case here, has to do with specifications that embody interoperability agreements. How does one ensure that someone doesn't fork the interoperability and hi-jack it in favor of the direction taken by a given implementation variant. Obvious examples in the past have to do with Netscape/Microsoft competition over HTML and browser-extension mechanisms, and current prospects for similar variations.

    When we took ODMA and DMA to open-source (, there was some concern about disruption by forking of the middleware functionality, interfaces, and integration model. The worry for DMA was baseless (it has not been implemented in an interoperable way anywhere) and the concern for ODMA remains since its middleware is in use and people do have access to the middleware source code.

    However, the open-source license that you describe doesn't qualify under the freedom to use in any domain and application, it seems to me. The solution that I have looked at is the non-confusion principle. That is, you can't offer a derivative work as a version of the covered work unless you pass whatever the test is. It is a labeling and identification matter. You can't promote the fork or deviation as satisfying the specification and you can't name it in a way that would confuse or deceive adopters of it. That's clear enough but the gray areas create problems. I think one doesn't deal with those unless they come up. We usually worry too much about forking in the absence of an infraction.

    I remember being concerned with how "extensions" and "improvements" that do not preserve legacy compatibility are handled. Also, is the improvement one that can be removed if it is necessary to revert to something that is consistent with a reference implementation? Those are the cases that I wonder about: playing nice and always preserving the user opportunity to make substitutions and to cross backward to something that conforms to the specification is what matters to me. But the best restriction, I think, is that a specification-deviating derivative work must not be identified in any way which confuses it with a bona fide implementation. And the source code remains open-source software.

    Finally, there is no way to prevent an independent implementation that is equivalent to forking, since copyright simply doesn't handle that. Consequently, strong compliance with the specification can't be handled solely by a copyright license. It takes something else. I haven't looked at trademark requirements, but the organization that supports the specification might want to look at that. Tying to the open-source license with a non-confusion clause strikes me as an useful light-weight provision that might get enough of the job done, without worrying about the seriously adversarial provisions where the lack of goodwill undermines any license you can think of.