The implication of the Supreme Court’s refusal to hear Google’s appeal in Oracle v. Google
by Inayat Chaudhry
Timeline setup for the initiation of the suit:
1) Java, a popular programming language, was developed by Sun Microsystems circa 1991.
2) In 2003, Android Inc. was founded by Andy Rubin, Rich Miner, Nick Sears, and Chris White.
3) In 2005, Google purchased Android and continued developing the platform.
4) In November 2007, Google released a beta version and announced that it would use some of Java’s technologies in its version of android. Sun CEO, Schwartz congratulated Google and Google released the Android software development kit (SDK) later on that same month.
5) In January 2010, Oracle purchased Sun.
Google and Sun negotiated with each other about possible partnerships and licensing deals but nothing tangible came out of the discussions. When it implemented Android, Google wrote it’s own version of Java using some of its Application Programming Interfaces (APIs). Google’s implementation of Android used the same names, organization, and functionality as Java’s APIs because Google wanted to allow developers to write their own programs for Android for the sake of interoperability. In August 2010, Oracle brought suit against Google claiming copyright (specifically, 37 Java packages of computer source code) and patent infringement. The case was assigned to District Judge, the honorable Judge William Aslup who concluded,
Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines. Oracle must resort, therefore, to claiming that it owns, by copyright, the exclusive right to any and all possible implementations of the taxonomy-like command structure for the 166 packages and/or any subpart thereof — even though it copyrighted only one implementation. To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands. No holding has ever endorsed such a sweeping proposition.
The central issue in the case was whether Java’s APIs were copyrightable. And, on this central issue the district court found that though the structure, sequence, and organization [“SSO”] of the Java API packages is creative and original, it is a “system or method of operation . . . and, therefore, cannot be copyrighted” under 17 U.S.C. § 102(b).
Following the District Court’s ruling, Oracle appealed the literal copying claim to the Federal Circuit Court of Appeals and Google filed a cross-appeal. Unfortunately, the appeals court reversed the district court on the central issue of the case, holding that the SSO of the Java API packages is copyrightable. The Court of Appeals rationalized its holding by addressing the district court’s holding in the following way:
Although [the district court concluded] the SSO is expressive, it is not copyrightable because it is also functional. The problem with the district court’s approach is that computer programs are by definition functional—they are all designed to accomplish some task. Indeed, the statutory definition of “computer program” acknowledges that they function “to bring about a certain result.” See 17 U.S.C. § 101. If we were to accept the district court’s suggestion that a computer program is uncopyrightable simply because it “carr[ies] out pre-assigned functions,” no computer program is protectable. That result contradicts Congress’s express intent to provide copyright protection to computer programs, as well as binding Ninth Circuit case law finding computer programs copyrightable, despite their utilitarian or functional purpose.
First of all, I take issue with the appeals court’s “no computer program is protectable” language it attributes to the district court. This is NOT what the district court was advocating for in its holding. In fact, note Judge Aslup’s language in his conclusion:
It does not hold that the structure, sequence and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act.
Second of all, instead of “this result” [i.e. the district court’s well-reasoned holding] contradicting Congress’s express intent to provide copyright protection to computer programs, it actually complements it. Congress recognized the tension at the heart of the copyright doctrine and by setting up § 102(b) left it for the courts to resolve on a case-by-case basis through the development of case law, which is adaptive. For example, much of cyber law’s doctrine today did not exist a mere 50 years ago.
In October 2014, Google petitioned the United States Supreme Court [SCOTUS] to hear the case. However, on June 29th, 2015, the Supreme Court declined to hear the case. Now while this does not mean that Oracle won the lawsuit, it means that the case will return to the district court for a trial limited to Google’s fair use defense. Implications? Copyrightable APIs means less interoperability for programmers, almost all of whom use APIs to make their software work with other software. Less interoperability in turn means less innovation. In fact over the past 20 years, in light of landmark software copyright cases such as Computer Associates v. Altai (1992) and Lotus v. Borland (1996), programmers had come to understand that copyright did not protect program elements necessary for “interoperability,” based on which they freely copied these elements, which in turn encouraged tremendous innovation in this area.
Aside: Open source software development is a way of life for some developers. In fact, the world wide web as we know it today was largely created because of open-source software development with Tim Berners-Lee contributing his HTML code development as the original platform upon which the internet is now built.
Now, let’s dive into why the district court’s ruling made more sense than that of the appeals court:
1) The 37 Java APIs should not be copyrightable because they constitute a system, process, procedure, or method of operation foreclosed from protection by 17 U.S.C. § 102(b). Lotus v. Borland is a United States Supreme Court case that tested the extent of software copyright which established that copyright does not extend to the text or layout of a program’s menus. In Lotus, the court said:
We think that “method of operation,” as that term is used in § 102(b), refers to the means by which a person operates something, whether it be a car, a food processor, or a computer. Thus a text describing how to operate something would not extend copyright protection to the method of operation itself; other people would be free to employ that method and to describe it in their own words. Similarly, if a new method of operation is used rather than described, other people would still be free to employ or describe that method.
This train of thought can be extended to the Google v. Oracle case. Java’s APIs helps programmers operate software, therefore copyright protection should not be extended to these APIs.
2) Notice the district court’s reasoning: “Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines.” And, if that wasn’t enough for Google to win the case, add to this the court’s holding in Lotus:
The fact that Lotus developers could have designed the Lotus menu command hierarchy differently is immaterial to the question of whether it is a “method of operation.”
This line of reasoning when applied to our case translates into the following: even if Google had decided to write its own version of Java for these 37 APIs, they would still be considered a “method of operation” which takes us back to #1 above. It also leads us back to the issue of interoperability. Without knowledge of the API, or the ability to reverse engineer it, the “interoperability” of programs will undoubtedly be limited. Therefore, as past precedent as held and as is applicable in this case, if specific words (or in this case a system of tools and resources in the operating system) are essential to operating something, then they are part of a “method of operation” and, as such, are unprotectable. See Lotus.
3) Article 1, Section 8, Clause 8 of the United States Constitution provides that Congress has the power to:
promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.
In a landmark copyright case, Feist v. Rural Telephone Service Co., the court explained:
The primary objective of copyright is not to reward the labor of authors, but to promote the Progress of Science and useful Arts. To this end, copyright assures authors the right to their original expression, but encourages others to build freely upon the ideas and information conveyed by a work.
This last part about copyright encouraging others to build freely upon the ideas and information conveyed by a work goes back to the idea of innovation discussed above. If the court of appeals’ ruling in this case is taken as the rule of thumb in all future cases that deal with the same issue, then not only will this ruling severely limit innovation, it will so so at the expense of hurting smaller business models such as start-ups who cannot afford to litigate and defend on fair use grounds like Google can.
4) In Lotus, Circuit judge, Boudin, concurred with the majority and added another well reasoned line of thought into the mix:
If we want more of an intellectual product, a temporary monopoly for the creator provides incentives for others to create other, different items in this class. But the “cost” side of the equation may be different where one places a very high value on public access to a useful innovation that may be the most efficient means of performing a given task. Thus, the argument for extending protection may be the same; but the stakes on the other side are much higher.
In this case, Java is a well known programming language and its APIs are widely used by programmers. In fact, as mentioned before, the very reason that Google decided to leave the 37 Java APIs unaltered was because it wanted the developers to write their own programs for Android for the sake of interoperability. Indeed the stakes are much higher when you take this interoperability away.
5) Finally, I will concede that it is true that any use of Java’s APIs by Google deprives Oracle from a portion of its profits. However, this aspect of “reward for the labor of the creator” is just one aspect of copyright. But it is not the only one, given that according to Congress, copyright encourages other to build freely upon the ideas and information conveyed by a work.
TL;DR = Java’s APIs should NOT have been held copyrightable as they constitute a system, process, procedure, or method of operation foreclosed from protection by 17 U.S.C. § 102(b). The Supreme Court’s refusal to hear Google’s appeal based on the court of appeals’ decision has tremendous potential to negatively affect innovation and interoperability as it relates to software development.