Ding!
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."
Continued from page 1.
The volume that Sun was setting out to get would not be achievable unless the APIs were included as part of the open source license because the source code would have been unusable as is. In fact, "broken" is more like it. The source code, as Sun published it, would have been useless to almost anyone who downloaded it because they wouldn't have a license to the entire work of art. However, with no crystal ball at its disposal, Sun, like any other open source publisher, had no way of knowing how APIs would later be deemed copyrightable and how, if they were not explicitly covered in the open source license, there could be a legal challenge of the sort that Oracle has brought against Google.
So, Google’s legal team, for its part, will not only look to establish that Google had a right to do as it pleased with all of the Java source code that was open-sourced by Sun, but that even if APIs are copyrightable, that the APIs governing how the Java components talked to one another were included in that license.
Tuesday for example, according to Ars Technica, some of the testimony involving Schmidt and Google attorney Robert Van Nest went as follows:
Schmidt: We believed it was possible to implement the language, without a license from Sun.
Van Nest: And you believed you could use the APIs?
Schmidt: Yes, we believed it was permissible to do so.
Van Nest: And what was your basis for that?
Schmidt: Forty years of experience.
While the “forty years of experience” remark it sounds like a snarky response, it isn’t. Schmidt is basically acknowledging that, in viewing the APIs as permissible to use, he knows there are no explicit references to APIs in open source licenses. So, while there is no legal language that expressly gave Google the right to use the APIs, he had never seen in his 40 years of experience in the industry a situation where the APIs were not included as a part of any license, commercial or open source. And that’s probably because until this case came along, APIs were never thought to be the sort of copyrightable material that fell under the jurisdiction of software licensing.
The dialogue continues:
Van Nest: Was it a secret that Google was building Android with Java?
Schmidt: Certainly not.
Van Nest: Was [Sun CEO Jonathan Schwartz] made aware that these phones were shipping?
Schmidt: Yes.
Van Nest: Did he ever express disapproval about what you were doing?
Schmidt: He did not.
Van Nest: Did Schwartz ever suggest it was wrong or infringing for Android to use the APIs?
Schmidt: He did not.
Van Nest: Did he ever tell you, in meetings, discussions, or e-mails, that Google needed a license from Sun to use the APIs?
Schmidt: He did not.
This one requires some reading between the lines. Van Nest is establishing some historical facts that at some point, could be very important in that they create a scenario whereby Sun was both aware of Google’s implementation and that such implementations are in fact a potential outcome anytime a company decides to open source a large body of copyrighted material as Sun did. The fact that Schwartz never conveyed to Schmidt that a license was needed to use the APIs suggests a mutual understanding that the APIs were as accessible to Google (or any open source licensee) as the open sourced source code was.
Then came Wednesday's testimony which involved former Sun CEO Jonathan Schwartz and the founder of Android, Andy Rubin. The dialog -- at least most of the salient points of it -- were captured in Sarah Jeong’s most excellent live tweet stream. But what stood out for me were two comments in particular. The first is a quote from a Schwartz authored email:
“They take Java without attribution or contribution. That is why I love Screw-gle.”
And the second is a quote from a Rubin-authored email:
“If Sun doesn’t want to partner with us to support this initiative, we are fine releasing our work and not calling it Java.”
The significance of these two emails, both entered into evidence in the case, is not to be underestimated. It is true -- and in fact confirmed by Rubin’s email where he says “not calling it Java” -- that Java was taken by Google without attribution. However, as frustrated as Schwartz might have been about the situation -- calling Google “Screw-gle” -- he and everyone else at Sun knew the risks of open sourcing Java. Phipps even alludes to the "big risk" of open source licensing that Sun was willing to accept in the aforementioned ComputerWorld article. And, while such “contributions” are largely viewed as an important part of the reciprocity that is common to the open source culture, licensees are not required to altruistically contribute their innovations back to the original work of art.
Then comes the attribution part -- the part about Google not calling it Java or even giving credit to Java. And here again is where the open source nature of Java is complicated; perhaps more so than most open source software.
Sun had a rule about implementations of Java and it didn’t matter whether it was Google’s implementation, IBM’s, Oracle’s, or anybody’s. You could not call it Java without licensing the Java trademark from Sun and you could not get the Java trademark from Sun unless your implementation passed a battery of compatibility tests known throughout the Java world as the TCK or test compatibility kit. The objectives of this TCK and trademark licensing framework were fairly noble. For the benefit of Java users and customers, Sun was looking to guarantee the portability of anything that was written to run on Java. For example, if you purchased or developed something to run on IBM’s version of Java 2 Enterprise Edition (J2EE: the server-side enterprise edition of Java), that software would run unchanged on Oracle’s version (and vice versa) so long as both had the Java trademark on them. The trademark was like a Good Housekeeping Seal of Approval (well, of compatibility). The TCK was designed to guarantee this portability through a series of automated tests and the Java trademark’s licensing terms were designed to enforce it. Companies like IBM and Oracle could hardly compete in the then-booming market for Java application servers if they couldn’t say that their products were “Java application servers.” And they couldn’t say that unless they licensed the trademark (and they couldn’t license the trademark if they didn't pass the TCK).
To better understand how this labyrinth of licensing and testing worked, all you need to know is how Microsoft created a version of Java 2 Standard Edition (J2SE: the desktop version) that didn’t pass the TCK (not surprisingly for the era, Microsoft embraced and extended Java to include dependencies on Windows). But Microsoft called it Java anyway and Sun sued Microsoft for trademark infringement. The two companies eventually settled out of court in 2002 with Microsoft paying Sun $20 million (pocket change by today’s standards).
So, what’s the relevance of all this?
Google clearly didn’t care about having perfect compatibility, portability, or having the Java trademark on Android. It was prepared to enter the market with Android without referring to the technology inside as Java. Rather, developers just needed to know how to program in the Java programming language in order to program Android. It was a shrewd, but perfectly allowable move that enabled Google to tap into the skills of an existing and giant community of developers; ones that had Java skills. And this is what Rubin meant when he said “we are fine releasing our work and not calling it Java.”
Google, like any other open source licensee of Java, was free to take the code, fork it, and even do what Microsoft did to it (Microsoft did this before Java was open sourced). Just so long as it didn’t call it Java, which it didn’t.
In summary, based on the testimony so far, Van Nest is building the following arguments:
- Copyrightable or not, APIs are necessary for open source code to work unchanged as intended, and therefore it is implied that any APIs that are necessary for such code to work are therefore covered by the open source license to that code.
- Google didn’t call its implementation “Java” and was therefore not required to license the Java trademark. Google therefore satisfied its legal obligations as an open source licensee of Java, much the same way any open source licensee of Java would have to satisfy their legal obligations.
- If there is a fair use test to pass (because this is now, officially and legally a question of fair use), that Google’s usage of Java easily passes that test on the basis of the first two points.
There is clearly more testimony and revelations to come. But the person whose testimony may matter most is that of Phipps. There was perhaps no person that was more well versed on Sun’s intentions as it moved to become an open source company than Sun's former Chief Open Source Officer. If Sun open sourced Java with the expectation that its APIs were included, Phipps will not only be the one to say so, but he will be able to reflect on why that was a necessity for any open source software to be at-all useful to users and developers.
The challenge for Google’s legal team, will be to keep the complexity surrounding all the legalities of Java licensing simple enough for the jury to understand. Like I said earlier, it took me forever to really figure it out back when I was extensively covering Java. For a jury to learn it and then to be able digest the facts in the context of what they’ve learned -- all under the pressure of such a high drama trial -- is an extremely tall order.