The Java IP Story

Every year, I teach the AMOS class, a lab course on “Agile Methods and Open Source” that combines lectures with a real software project that ideally turns into a startup (see the AMOS Project concept, in German). To explain open source, I have to introduce students to intellectual property rights, of which most have been blissfully unaware of until then. Nothing teaches concepts better than a colorful story, and so I have been using the IP strategies around Java to make this dry topic come alive. For fun, comments, and corrections, I’m providing the short version of my talk below, including commentary. (You can also download a PDF version of the talk, licensed as CC-BY 3.0. If you find this useful for teaching, please tell me.) Students at this point have a basic working understanding of intellectual property and exclusion rights. Please let me know what you think! Finally, IANAL.

Java is an important technology powering the modern web and in particular enterprise applications. It has a checkered intellectual property history, and with the recent acquisition of Sun, the Java creator and owner, by Oracle, things only stand to heat up. This slide set discusses some of the more interesting issues around Java intellectual property and its strategic use in business.

  1. What is Java?
  2. Short Java IP Story Time-Line
  3. Three Substories
  4. Java’s Challenge to the Windows Platform
  5. Microsoft and Java
  6. The OpenJDK Strategy (Open Core Model)
  7. Certification of Compatible Implementations
  8. Threats to Commercial Revenue
  9. Main Tools to Curtail “Competitors”
  10. Problems for Alternative Implementations
  11. Problems for OpenJDK Forks
  12. Thank you! and References

“Java” consists of multiple components [2].

  • Java, the programming language, which has been standardized
  • the JRE, which contains the necessary infrastructure to run Java applications
  • the JDK, which is the JRE including its libraries and runtime, plus some tools
  • in addition, there are many third party libraries and development tools

Java comes in multiple editions, which target different execution environments, most notably embedded, desktop, and enterprise systems.

Java, the programming language, is changing only slowly. However, the libraries are evolving at a rapid pace. To make them useful to industry, the JCP, the Java Community Process, defines specifications and develops reference implementations and compatibility test suites. The JCP was set up by Sun and brought together all relevant industry players with an interest in Java. To be allowed into the process, vendors have to sign the JSPA, the Java Specification Participation Agreement, which gives Java’s owner various rights to the specification output. The individual specifications are called the JSRs for Java Specification Requests.

Originally Sun, now Oracle, owns the following intellectual property rights:

  • the Java trademark; this allows it to stop labeling other parties software as “Java” in the domain of information technology
  • various JSR test suites; this output of the JCP serves to certify Java component implementations as specification compatible
  • many patents in the implementation of the core Java programming language and runtime

These property rights are being used in various scenarios.

To get started, lets review a few key events in Java’s history [1]. Java was released to the public in 1996 under a proprietary license. Developers could use Java, but it wasn’t open source. With fast-rising industry interest, Sun announced and formalized the JCP in 1998 to help move Java forward by involving other industry players.

Microsoft was one of the industry players that adopted Java on its platform early on. Already in 1997 Sun filed a lawsuit alleging that Microsoft was not playing by the licensing agreement, and in 2001 Sun won this lawsuit. Microsoft has since removed Java from its platform leaving the integration to 3rd parties.

A first open source implementation of the Java tools, runtime, and libraries was begun in 1998 as the GNU Classpath project; it has yet to reach completion. The project uses the GPL open source license with a modification, the classpath exception, that allows linking of applications so that they don’t fall under the GPL.

Another open source implementation of Java was begun under the auspices of the ASF, the Apache Software Foundation, in 2005, labeled “Project Harmony”. Sun offers the non-profit community free Java certification if it was willing to accept certain field-of-use restriction for its software. The ASF objected on principled (open source) grounds, preventing it from using the Java trademark.

Sun itself released most of the Java tools, libraries, and runtime in 2006, finishing it in 2007, under the GPLv2 open source license. Called the OpenJDK, this is still the only complete open source implementation of Java available today.

I am going to tell three stories, in which intellectual property and business strategy come together:

  • The Java vs Windows platform war
  • Generating Revenues with the Open Core Model
  • Curtailing Competition using Patents and Field-of-use restrictions

Questions of intellectual property and the legal system have a habit of boring one’s brain out; I hope this won’t happen in this case.

Java’s original marketing slogan (and promise) to software developers was to “write once, run anywhere” (WORA). It points to the most basic of industry strategies, the platform strategy.

In a platform strategy, a software vendor tries to make its software become the platform that everyone else builds on. By building applications on top of someone’s platform, these applications become dependent on the platform, and whenever a copy of the application is bought, a copy of the platform has to be bought too.

This is why Windows is so powerful and Bill Gates became so rich.

Java now challenged the Windows platform by completely hiding the Windows programming interface, the Win32 API, behind the Java class libraries. Thus, applications could be implemented using Java class libraries only without knowing whether these are run on a Windows or a Linux platform. This made applications portable across different operating systems and led to Java’s rallying cry of “write once, run anywhere”.

Of course, Java was simply trying to become the next platform to build on by hiding the underlying operating system, be it Windows or MacOS. Scott McNealy, the Sun CEO, probably wanted to become as rich as Bill Gates.

Microsoft didn’t like Sun’s Java strategy as it would reduce the lock-in of applications to the Win32 API and hence make application developers less dependent on Windows. Still, customers kept asking for Java on Windows. Eventually, Microsoft complied: Microsoft licensed Java from Sun and deployed it on the Windows platform.

According to a 1997 lawsuit by Sun, Microsoft did so only by violating the license agreement. Sun stated that Microsoft modified the JDK by omitting libraries that were needed to run Java well. This required application developers to go directly to the Win32 API. This strategic move was to maintain the lock-in to the underlying Windows platform that Java was trying to do away with in the first place.

Sun won the lawsuit in 2001, requiring Microsoft to pay damages. In the aftermath, Microsoft removed Java from its platform and introduced alternative technologies. Today, Java on Windows is provided by third parties only [3].

Knowing that Sun released Java as open source in 2007 and knowing that there were alternative implementations, you may be wondering how Sun ever intended to make money on Java. One answer to this is called the open core model today.

The release of the OpenJDK by Sun in 2007 gives developers a full Java development and runtime environment under the GPLv2 open source license. The license even comes with a modification called the Classpath Exception that allows software vendors to combine their application with the OpenJDK without having to open source their application code.

To not fully loose their (potential) revenue stream, Sun does two things, which taken together represent the core intellectual property strategy behind the open core model:

  • Sun maintains the full copyright and thereby ownership of the OpenJDK code base. Any outside contributors first have to sign a joint copyright agreement [8]. While this curtails code contributions, it ensures that Sun remains the owner of the JDK.
  • Sun then uses their ownership rights to offer the OpenJDK under a commercial license to those who don’t like the GPL (dual license strategy) while at the same time providing additional non-open-sourced functionality (open core model).

Thus, to get full service as well as enhanced features, Java application developers have to pay for the commercial license rather than use the open source license.

To win against Microsoft early on, Java needed to achieve rapid growth and industry buy-in during the 1990s.

Java could only grow as fast as it did, because Sun brought other major industry players on board. This was done through the JCP, the Java Community Process. In that process, companies like IBM, SAP, and anyone else who cares can influence the development of Java through library specifications and make sure it works well with their products.

One tangible output of the JCP is a stream of JSRs, the Java Specification Requests. Each JSR specifies a library or similar component. To each JSR specification belongs a TCK, the technology compatibility kit for the JSR. A TCK is effectively a test suite that checks a given implementation of the library for compliance with the specification. If the library passes, it is considered a compliant implementation. A Java TCK combines various JSR TCKs into a full test suite for a particular Java configuration.

Anyone with a Java implementation who wants a Java trademark license from Oracle first has to pass the matching Java TCK.

Rapid growth and the open core model meant that there could be serious business.

There was only one threat to those revenues: Alternative implementations. These are implementations of Java, including a JVM, tools, and class libraries. The first of these implementations, the GNU Classpath project, started as early as 1998 [17]. A later alternative implementation is the Apache Harmony project [16].

Because of the broad industry involvement, Sun and later Oracle couldn’t simply close off Java again after it grew to dominance as the leading enterprise programming language. Thus, Oracle today provides a defined way for industry to acquire a Java trademark license if it wants to label their Java implementation “Java”.

Today, Oracle makes the Java trademark license available in two main variants:

  1. For paying customers, a full trademark license is granted, if the Java implementation passes the relevant Java TCK
  2. For non-paying open source projects like GNU Classpath or Apache Harmony, a restricted license is granted

Option 1 works very well for Oracle, after all, it receives presumably appropriate revenues. Option 2 is not really an option for open source projects as we will see, but rather an attempt to prevent these projects from gaining traction.

With the OpenJDK, Oracle provides a full open source implementation of Java. However, in addition, Sun, now Oracle, made two strategic moves to curtail alternative implementations:

  • The choice of the (1991) GPLv2 license because of its poor coverage of patents
  • The field-of-use restrictions in the trademark license for open source projects

An open source Java implementation that wants to call itself “Java” has to pass the appropriate Java TCK. The use of the TCK and the Java trademark license is only granted for free, if the project (more precisely the organization behind it) accepts certain field-of-use restrictions for the project. As of today (2011), the main restriction is that the alternative implementation may not be used for embedded systems development. Enterprise applications, in contrast, are fine.

An example of an alternative implementation is the Apache Harmony project, which provides a comprehensive Java implementation under the Apache License 2.0.

The definition of Open Source Software requires that no field-of-use restrictions be imposed on the user. Oracle’s field-of-use restrictions are not acceptable to an open source project that wants to call itself that way [11] [12]. (And the same applies to free software.)

Game over for unrestricted free and open source Java implementations.

But what about forking the OpenJDK, wrestling it off the hands of Oracle?

In forking the OpenJDK, you face two options:

  • If you want to put the “Java” label on your fork, you’ll have to pass the TCK and accept Oracle’s field-of-use restrictions. Since you are required to keep the software under the original GPLv2 license, this may hand you a GPL violation lawsuit, after all, you just accepted field-of-use restrictions which are incompatible with the license.
  • If you don’t care about the “Java” label, you can forgo certification. However, without the certification, you don’t get a license to the software patents buried in the OpenJDK code. Thus, any patent owner who happens not to like you might decide to sue your customers who will turn back on you and will find you without patent defense.

One hope is Google’s Dalvik, once it digs itself out of the siege of patent lawsuits it is being buried under, but that will then be the Dalvik IP Story, not the Java IP story…

Game over, again.

For now.

[1] Oracle. The Java History Timeline.
[2] Wikipedia. Java (Programming Language).
[3] Microsoft. Microsoft Java Virtual Machine Support.
[4] Oracle. GNU General Public License, version 2, with the Classpath Exception.
[5] Wikipedia. GPL Linking Exception.
[6] Oracle. Oracle and IBM Collaborate to Accelerate Java Innovation Through OpenJDK.
[7] Oracle. Java SE at a Glance.
[8] Oracle. How to Contribute.
[9] Oracle. OpenJDK FAQ.
[10] Doug Lea. Email to JCP Executive Committee Members.
[11] Apache Software Foundation. Our Participation in the Java Community Process.
[12] Apache Software Foundation. Open Letter to Sun Microsystems.
[13] Paul Querna. Java Trap, 2010 Edition.
[14] Oracle. Java(tm) Compatibility Test Tools (Java CTT) Info.
[15] Wikipedia. Technology Compatibility Kit.
[16] Wikipedia. Apache Harmony.
[17] Wikipedia. GNU Classpath.
[18] Brian McCallister. The TCK Trap.

10 thoughts on “The Java IP Story

  1. Sir,
    This is a very good and very helpful overview and “legal history” of JAVA. I have a question relating to the Sun/Microsoft portion of the story, however. In your presentation you state:-

    “Sun stated that Microsoft modified the JDK by omitting libraries that were needed to run Java well. This required application developers to go directly to the Win32 API.”

    If I recall correctly (I am not a programmer), what Microsoft did was much more subtle than that. They provided a bytecode compiler and integrated JAVA into Visual Studio as Visual J++. The name was a Microsoft in-joke. Just as C++ means “extended C”, so J++ means “extended Java”. What Microsoft had done was create a standard implementation of the “language syntax” [so that source code could be ported], but the *output* from Microsoft’s J++ compiler would produce byte-code that would only run on the Windows platform.

    I have to be a little careful here as I am not completely sure what “only run on the Windows platform” meant in the real world: i.e. did it mean, not run at all on other platforms, run slowly, run with bugs, etc. However, from following the court case in the press at the time, I think this may be a more accurate representation of facts. Short of “Google”, I am not sure how to substantiate my claim, but I will look, and if I find something concrete, I will post an additional comment.

    Best Regards


  2. Interesting article, thanks.

    So what is the current lawsuit by Oracle against Java based on? Presumably not the Java trademark, because Google bypassed that by never calling their implementation Java.

    Is it thus for the patents in the OpenJDK? If so, do you have any info on these patents?

    1. The Oracle v Google lawsuit as about a handful of patents, but Oracle are also claiming copyright infringement.

      The copyright infringement is particularly interesting is that Google are only accused of copying Java API’s [1]. In short, Google used the same API’s as standard java for modules such as io and math. They did however write their own code for the actually implementation.

      It is generally believed that you cannot copyright an API, but Oracle are claiming otherwise.

      Last week the judge in the trial announced that it will be him, not the jury that decides whether API’s can be copyrighted.

      [1] Google are also accused of copying a small amount (I believe 9 lines of code) directly. The 9 lines are trivial and were only copied as a temporary measure as part of an implementation of timsort() which was a port from python of a Tim Peters sort algorithm.

  3. Nice overview. Some quibbles after a quick read-through:
    * We (at IBM) were definitely porting the Java source prior to licensing it from Sun for release in 1995, not 1996.
    * You don’t mention the implied patent license assumed for the GPLv2 — see e.g. — and I think it’s relevant in several places
    * Your claim it was the JCP that brought many players to the table is not true. The JCP was created to keep the table peaceful after we all turned up there and insisted on defining the menu.
    * Your treatment of the initial license as just “proprietary” doesn’t do justice to the clever and nuanced “open” strategy. It’s true, but it doesn’t explain why so many key players wanted Java in 1995 and 1996.
    * You speak of “field-of-use restrictions in the trademark license” but that’s not really accurate. It was the TCK license and although that led to a trademark license it was not itself the trademark license.

    It would be worth sorting these out as you’re very close! Happy to collaborate; you have my co-ordinates.

Leave a Reply