Google Foreshadows Legal Strategy in Epic API Copyright Case Against Oracle


That was the sound of the bell as two titans -- Oracle and Google -- came out of their corners on Tuesday to duke-out the final round in their epic legal battle over the latter’s usage of Java APIs in the Android operating system. Already, this final round lacked no shortage of star power as Google started by putting its CEO Eric Schmidt on the witness stand. His role? To answer questions about many of the assumptions that Google made at the time it decided to base key parts of the Android operating system on Sun's Java technology; a technology that now belongs to Oracle.

While I am not a lawyer, in questioning Schmidt on Tuesday, Google may have tipped some of its hand on where it intends to take this case -- a direction that was somewhat confirmed by Wednesday’s questioning of former Sun CEO Jonathan Schwartz and Android founder Andy Rubin.

The outcome of this lawsuit, known to many as the “API copyright case,” could potentially cast a dark pall across the entire software industry, not to mention the API economy, should it give rise to a new kind of intellectual property troll based on the copyrightability of APIs. After all, that’s what Oracle is doing; trolling Google for a share of the $42 billion in riches that it has allegedly generated from its authorship of the Android operating system.

For those of you not up to speed the history of this case, it has been bouncing around the US court system for a while. Mostly to vet the question of whether APIs are indeed copyrightable. In a series of prior decisions that have put the US court system and Oracle at odds with, well, pretty much anyone who knows anything about how software is developed, that question (over the copyrightability of APIs) is no longer in question. They are.

Now, the only legal question that remains is whether or not Google had the right to use those APIs according to the highly ambiguous area of copyright law known as “fair use.” Again, without descending into the murky semantics and precedents of the law, the basic question is, in building the Android operating system, did Google copy so much of Java that it should have gotten Sun’s blessing first? Or, did it borrow few enough parts that, under copyright law, it really wasn’t enough to rob Sun (and later Oracle) of the value it created in Java.

But, if Google has its way, by the time the trial is over, it may no longer be a question of fair use. Nor should it be. And from the looks of the first two days in this final round, Google will look to show that it was allowed to use the parts of Java that it did because it actually had a legitimate license to do so.

The courts, for their part, have made this into a case about fair use when, in my opinion, it’s very much about the latitude of the license to Java that Google already had at the time that Google made a decision to use the parts of Java that it did. While I am not a lawyer, I spent a significant part of my career covering the ins and outs of open source law and spent a good majority of that time writing about the ins and outs of licensing Java. Much of that reporting started with how Microsoft was found to have misappropriated Java and then the ongoing saga of how companies like Oracle and IBM were hoping to wrest control of Java away from Sun (see IBM Pressures Sun to Free Java for example).

Open source software law is extremely complicated. It took me years to truly understand it and even longer to understand exactly how Sun uniquely applied it to its licensing of Java. Open source software has to do with the source code behind the software; the lines of code that programmers write as a part of the process of producing software. When a programmer writes lines of code, those lines are like the lines of text in this article that you’re reading right now. They flowed from my brain, through my fingers, into a keyboard, and eventually into a document where my thoughts could be saved and later published. They are original thought. Unless I quote someone or some thing (like a website in the way that I'm about to quote ArsTechnica), they are my creation. They are the source code of the article.

When I create something like an article -- much the same way that a musician might arrange notes and chords to create a new song -- I own the copyright to that material unless I’ve assigned that copyright to someone or something else. In my case, I’ve assigned my copyrights to ProgrammableWeb.

So, source code (the source code that eventually results in software) is copyrightable in the same way that the text of my articles is copyrightable in the same way that the arrangement of notes that a musician used to create an original song are copyrightable. In fact, most source code, open source or not, will even have a copyright notice in it, specifying who or what organization holds the copyright to that source code. Even if it doesn’t have such a notice, it’s implied.

If you stopped here, you might think that Oracle has a solid case. The Java source code in question bore the copyright of Sun, which in turn accrues to Sun’s current owner; Oracle. But this is where it gets complicated because, in the case of Java, the source code was available under an open source license.

The open source software movement is, in part, based on the idea that it’s better for the world to share source code in a way that people can freely use it as is, "out of the box," or improve it. In order for anyone but the developer of the original source code to be allowed to do this requires what amounts to a special written exemption from the standard restrictions of copyright law; what is known as an open source license. One reason open source licensing is complicated is because of how many such licenses -- each a distinctly separate type of exemption from the others -- there are to pick from.

I am not sure how many open source licenses there were at the time that Sun decided to open source Java in 2006. But, if you are a software developer who is thinking about open sourcing your software today, there are 78 different open source licenses to pick from. Each of these licenses conforms to certain fundamental tenets of open source, one of the most important of which says “The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.”

Unless you have very deep pockets to pay a very good open source lawyer, you do not want to attempt to create yet another open source license. You would likely do as Sun did -- you would pick from the existing list. And in Sun’s case, it picked one of the most permissible and popular of the open source licenses; the GNU General Public License (GPL). The GPL is the same license that was used to open source the source code behind GNU Linux; the basis of the source code found in most distributions of Linux.

Once source code is open sourced in this fashion, everyone who might use that source code gets the same license unless they negotiate a different license with the copyright holders. So, while the Court has narrowed the question of the API copyright case to one of fair use, the question might actually be whether Google was within its rights -- rights established by the GPL open source license -- to not only use the few parts of Java technology that it did, but all of Java if it so desired. Theoretically, because of how Sun open sourced Java under the GNU General Public License, all of Java was fair to use.

Judging by yesterday and today’s testimony so far, Google’s lawyers appear to be looking to establish that the question of fair use is easily answered by the terms of the open source license that came with Java at the time that Google used the parts of Java technology that it did.

“Now David,” you may ask “why did you just call it Java technology instead of Java source code?”

Glad you asked because, as it turns out because this is one of the wrinkles. Google reproduced Java APIs, not the source code itself. If you read ProgrammableWeb’s article on What Are APIs and How Do They Work, then you’ll know that APIs are essentially an agreement (often referred to in API jargon as a “contract”) between two separate components of software on how they will communicate with one another. It’s like the agreement that the plug for your hair dryer has with the wall socket; the size of the prongs, the way the electricity flows, and the type of electricity that it is (voltage, frequency at which the current's direction alternates, etc.). When two pieces of software speak to one another, each piece has its own source code to manage that interaction. But the API itself consists of no source code. It’s just an agreement that sets the expectations of the two pieces of software.

As said earlier, the previous decisions of the Courts have determined (tragically so) that this agreement is copyrightable. There is no going back on that in the context of this case. One big question however, is whether those agreements -- those APIs -- wherever they exist in the open source implementation of Java (wherever two pieces of open source software are “talking” to one another), fall under the jurisdiction of the open source license that goes with the source code itself. Put another way, if, when a body of source code is open sourced in a way that Sun open sourced the source code behind its implementation of all the Java components, are the APIs (the agreements) that govern how those software components talk to one another open sourced as well, or must they be licensed separately?

Many, including me, would argue that those agreements -- copyrightable or not -- must be included. Otherwise, the open source code itself is useless. For example, imagine downloading some open source code that involves two software components talking to one another and finding out that, in getting your open source license to that code, the means by which they talk to one another is not included in the license. In other words, in order to not run afoul of the original author’s copyright, you must re-engineer both components to exchange the same information that they originally exchanged, but by way of a completely different agreement of your own making. Imagine if GNU Linux was originally distributed under this pretense. Linux would never have achieved the popularity it did and the number of distributions that it has. The entire computer industry would be very different than it is today (including Oracle which has built and extracted its own value and profit out of Linux). The amount of API re-engineering required would have stopped Linux dead in its tracks.  It would have been dead on arrival.

Like any other publisher of open source code, Sun would never have intended for the APIs to not fall under the open source license. In fact, similar to how Linux achieved the volume that it did, Sun was very explicit about its goal at the time it was open sourcing Java; volume. According to a ComputerWorld article dating back to 2006, Sun's then Chief Open Source officer Simon Phipps said "What matters to us is to create volume, and when we create volume, we'll create revenue. We made Unix available for free with OpenSolaris 10. But customers want services for patches and help. We find that most customers want that service and pay us for it. By giving it away, we have increased the use of Solaris in a large way and have gotten larger revenue for support."  

David Berlind is the editor-in-chief of You can reach him at Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.