First published in Redline on 31 July 18. Copyright 2018 Sean Hogle, licensed under CC-BY-2.0. This article is reposted here in light of the US Supreme Court’s decision (15 Nov 19) to grant certiorari (ie agree to hold a review) in the Oracle v. Google appeal, a surprising and welcome development.

 

The Court of Appeals for the Federal Circuit’s long-awaited ruling in the appeal of the Oracle v. Google fair use jury verdict has arrived. Oracle America Inc. v. Google LLC (Fed. Cir. 2018) (“Oracle II”).  The court’s second opinion in this legal clash of tech titans is the latest culmination of nine years of furiously fought litigation. Once again, Google lost this round; the Federal Circuit tossed out the jury’s verdict in favor of Google on its fair use defense to Oracle’s copyright infringement claim relating to Java application programming interfaces (APIs).

A detailed summary of the facts and procedural history of the case can be found here. In short, Google replicated 37 of Oracle’s Java APIs for use in Google’s Android operating system for smartphones, in order to enable easier and faster application development in a popular programming language, Java. By using the same declarations as are used in the Java programming language, Google made developing Android applications dramatically easier and faster, and in the process appreciably boosted the popularity of the Java programming language and unleashed a massive proliferation of Android applications in short order. Oracle didn’t see it that way, and since 2010 has been pursuing Google for patent and copyright infringement, resulting in two jury verdicts and two appeals.

This post analyzes the latest ruling of the Federal Circuit (CAFC) and offers a critique of its reasoning, focusing on whether Google’s use of the Java APIs was “transformative”, a crucial factor in the fair use inquiry. The inexorable logic of the CAFC’s decision is that the use of APIs for interoperability purposes can never be fair use as a matter of law. Such a ruling cannot be squared with the law of the Ninth Circuit, which the Federal Circuit was bound to apply, and threatens software competition and innovation.

This is the second appeal in the case. In the first round, the district court (Judge Alsup), ruled that the APIs at issue were not copyrightable. Oracle America Inc. v. Google Inc. (ND Cal. 2012). On appeal, the CAFC disagreed, overruling Judge Alsup in an opinion that was remarkable for its factual and legal flaws. The appellate court’s API copyrightability ruling was, essentially, that APIs are always copyrightable as a matter of law, so long as they are expressed in a “creative” and “original” manner. “[W]e conclude that a set of commands … may contain expression that is eligible for copyright protection,” the Federal Circuit proclaimed, “as long as the author had multiple ways to express the underlying idea.” In so deciding, the CAFC effectively nullified section 102(b)’s “process, system, or method of operation” copyrightability exclusion as it applies to software.

Congress added Section 102(b) to the US Copyright Act in 1976 specifically because of heightened concerns about extending copyright protection to software, a means of controlling computer functionality. The CAFC failed to acknowledge the historical context of Section 102(b), and failed to realize that Section 102(b) defines the scope of copyright protection for software.

In its 2014 decision reversing the copyrightability determination, Oracle America Inc. v. Google LLC (Fed. Cir. 2014) (“Oracle I”), the appellate court nevertheless recognized the potential viability of Google’s fair use defense on interoperability grounds, and consequently remanded the case to the district court for a new trial. “[W]hile we have concluded that it was error for the trial court to focus unduly on the functional aspects of the packages, and on Google’s competitive desire to achieve commercial ‘interoperability’ when deciding whether Oracle’s API packages are entitled to copyright protection, we expressly noted that these factors may be relevant to a fair use analysis.“ Oracle I (emphasis added).

On remand, a jury of ten people (eight women, two men) did in fact find these factors relevant, and ultimately ruled in Google’s favor after deliberating for three days and hearing two weeks’ worth of evidence. The jury heard extensive testimony concerning Google’s interoperability arguments, market impact, and developer reaction. The jury’s verdict was unanimous.

To grasp the significance of the verdict, it’s helpful to recite Judge Alsup in his opinion denying Oracle’s post-trial motion to set it aside:

Oracle has portrayed the Java programming language as distinct from the Java API library, insisting that only the language itself was free for all to use. Turns out, however, that in order to write at all in the Java programming language, 62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise, the language itself will fail. The 62 “necessary” classes are mixed with “unnecessary” ones in the Java API library and it takes experts to comb them out. As a result, Oracle has now stipulated before the jury that it was fair to use the 62 “necessary” classes given that the Java programming language itself was free and open to use without a license ….

Oracle America Inc. v. Google Inc., Order Denying Rule 50 Motions (June 2016) (“Order”) (emphasis added).

Oracle’s appeal of the pro-Google fair use jury verdict was heard by the same three-judge panel that heard the 2014 reversal of the district court’s decision that copyright protection does not extend to the Java APIs in question. In a ruling that surprised many, the Federal Circuit completely disregarded the jury’s verdict, flatly contradicted its 2014 ruling, and held that Google’s use of the Java APIs was not fair as a matter of law.

The Federal Circuit’s fair use decision is flawed and harmful in many respects. Others have already ably addressed the shocking repudiation of a Silicon Valley-sophisticated jury’s well-supported evidentiary findings, and the rather obvious results-oriented nature of the court’s decision. Here’s an illustrative example, from the TechDirt blog, of the reaction the court’s decision engendered, particularly its complete 180-degree reversal from its earlier 2014 opinion:

In 2014, [the CAFC] … made it clear that a new trial was necessary on fair use because of “the limit of our appellate function” (to make determinations on matters of fact). But here, once the jury came back with a result that the same judges disliked, it miraculously started arguing that, well, really, we can review the jury’s decision because we can and because juries are “advisory only.” …

This clearly is the same three judge panel completely moving the goalposts from their earlier decision in the same case because they don’t like the outcome.

CAFC in Oracle v. Google, 2014
“We cannot say that there are no material facts in dispute on the question of whether Google’s use is “transformative,” even under a correct reading of the law.”

CAFC in Oracle v. Google, 2018
“Google’s use of the API packages is not transformative as a matter of law…”

….

CAFC in Oracle v. Google, 2014
“[R]easonable jurors might find that [the functional aspects of an API] are relevant to Google’s fair use defense under the second and third factors of the inquiry.”

CAFC in Oracle v. Google, 2018
“Although it is clear that the 37 API packages at issue involved some level of creativity–and no reasonable jury could disagree with that conclusion–reasonable jurors could have concluded that functional considerations were both substantial and important…. The Ninth Circuit has recognized, however, that this second factor ‘typically has not been terribly significant in the overall fair use balancing.’”

Another fun one. In 2014, the court pointed out that perhaps the 2nd factor (the nature of the work — in this case, the fact that it’s an API that is functional rather than expressive) could weigh heavily on the fair use analysis. In 2018 when the jury did exactly what the CAFC suggested it might, but which the CAFC obviously hoped it would not, it suddenly poo-poos the idea that the 2nd factor really matters at all.

Mike Masnik, TechDirt, The Federal Circuit’s Judicial Hypocrisy In Overturning Jury Concerning Java API Fair Use Question (emphasis in original).

As egregious as that was, by far the worst aspect of the court’s ruling is that its opinion and its logic lead regrettably to the conclusion that replicating APIs for interoperability purposes can never be fair use, as a matter of law.

For use to be considered fair, the most significant factor is whether the use in question is “transformative”, meaning that it “added something new, with a further purpose or character, altering the first with new expression, meaning, or message.” In the words of the US Supreme Court, transformative works “lie at the heart of the fair use doctrine’s guarantee of breathing space within the confines of copyright, and the more transformative the new work, the less will be the significance of other factors, like commercialism, that may weigh against a finding of fair use.” Campbell v. Acuff-Rose Music Inc. (US S Ct 1994).

The Federal Circuit held that Google’s use of the Java APIs was not transformative as a matter of law for the following four reasons:

Google’s use of the API packages is not transformative as a matter of law because: (1) it does not fit within the uses listed in the preamble to § 107; (2) the purpose of the API packages in Android is the same as the purpose of the packages in the Java platform; (3) Google made no alteration to the expressive content or message of the copyrighted material; and (4) smartphones were not a new context.

Each reason will be addressed in turn.

“Not in the preambles list”

With respect to the first reason given, the list of permissible purposes in the preamble to the fair use section of the Copyright Act (17 USC § 107) consists of “criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research.” Interoperability is not mentioned here, admittedly; but it’s a non-exhaustive list (the list is prefaced with, “the fair use of a copyrighted work … for purposes such as ….”). Under such logic, Ninth Circuit precedent (which the Federal Circuit was bound to apply in this case) would be otherwise. See Sega Enterprises Ltd. v. Accolade, Inc. (9th Cir. 1992) (intermediate copying as an integral part of reverse engineering is fair use if the point of that effort is to discover the unprotected interfaces needed for compatibility); Sony Computer Entertainment, Inc. v. Connectix Corp. (9th Cir. 2000) (“Connectix’s intermediate copying and use of Sony’s copyrighted BIOS was a fair use for the purpose of gaining access to the unprotected elements of Sony’s software.”).

The CAFC did not, in fairness, rely solely on the fact that Google’s use failed to fit neatly in the section 107 list. In rejecting Google’s arguments on the transformative nature of Android, the court sniffed that Google’s achievement was not even “modestly” transformative, and dismissively characterized Google’s actions as, simply, “copy code verbatim to attract programmers to Google’s new and incompatible platform.” (quotations omitted).

As noted by others, the CAFC seems unable to distinguish between code and APIs. See Mike Masnik, TechDirt, Insanity Wins As Appeals Court Overturns Google’s Fair Use Victory For Java APIs (“CAFC once again shows that it still doesn’t understand why APIs and code are not the same thing ….”). Undisputedly, the Android platform’s use of the Java APIs was sufficient to enable a non-trivial degree of cross-platform compatibility at the developer level. Java applications can easily be migrated to Android, and vice versa.

This fact however was lost on the court. As was evident in the 2014 decision as well, the CAFC’s apparent interoperability demands are absurd; they expected Google to magically render applications written for a platform originally developed for desktop computers (Java) to run perfectly without alteration on a platform for mobile devices (Android). Because Google couldn’t achieve the impossible, interoperability imperatives fell on deaf ears in both section 102(b) and fair use CAFC analyses. What’s more, in neither the 2014 or the 2018 opinion does the Federal Circuit deign to hint as to what its decision would have been if perfect compatibility had in fact been achieved. The bar is left guessing as to how or to what extent compatibility is required or even relevant.

“Purposes are the same in both Android and Java”

Regarding the second reason, the Federal Circuit ruled that Google’s use of the APIs mirrored that of Oracle’s use, in that both are used as declarations for software functionality. Where the use “is for the same intrinsic purpose as [the original copyright holder’s],” the court noted, ”such use seriously weakens a claimed fair use,” citing for this proposition cases that had nothing to do with software, APIs, or compatibility.

Of course, the entire point of the exercise for Google was to use the identical declarations as Oracle used to mitigate development incompatibilities. As Judge Alsup wrote in his opinion denying Oracle’s motion to set aside the jury verdict:

It should go without saying (but it must be said anyway) that, of course, the words copied will always be the same (or virtually so) in a copyright case — otherwise there can be no copyright problem in the first place. And, of course, the copied declarations serve the same function in both works, for by definition, declaring code in the Java programming language serves the specific definitional purposes explained above. If this were enough to defeat fair use, it would be impossible ever to duplicate declaring code as fair use and presumably the Federal Circuit would have disallowed this factor on the first appeal rather than remanding for a jury trial.

Order (emphasis added).

“Google made no alteration to Oracle’s APIs”

The court’s third rationale for overruling the jury’s transformation verdict is that Google made no alteration to the APIs, leaving intact the APIs’ “expressive content or message”. In the words of the CAFC: “While Google’s use could have been transformative if it had copied the APIs for some other purpose—such as teaching how to design an API—merely copying the material and moving it from one platform to another without alteration is not transformative.”

Google adopted the Java APIs in order to maintain a target level of compatibility between the Android development platform and the Java development platform, a move that has boosted the popularity of the Java programming language more than anything Oracle has ever done. Google was required to use the 37 Java APIs in question verbatim in order fulfill the entire purpose of the enterprise. The declarations must be the same to achieve the same functionality.

“Smartphones are not a new context”

The fourth factor relates to Google’s use of the Java APIs for Android-based smartphones as a new context. The court simply noted that the Java platform had already been implemented in smartphones, and that a “mere change in format (e.g., from desktop and laptop computers to smartphones and tablets)” is not transformative.

In so holding, the court casually tossed aside the considerable evidence the jury relied on in support of its verdict; namely, that previous efforts at porting Java to mobile operating systems had not proven particularly attractive to application developers, and that Google had overcome many previously daunting technical hurdles to enable widespread Java application development on a mobile device platform.

As one prominent practitioner observed, “The court overlooked the evidence that Android, unlike Java, was designed to operate on smartphones, and its features were optimized to function in that confined environment. When dealing with functional works, a court should treat optimization to function in a different environment as a new context.” Jonathan Band, Project Disco, The Federal Circuit Blows it Again in Oracle v. Google.

Ninth Circuit Precedent

The facts of Sega Enterprises Ltd. v. Accolade, Inc. (9th Cir. 1992) should be familiar to followers of the Oracle v. Google proceedings. In the early nineties, Sega manufactured video game consoles and game cartridges that could be used only with the Sega console. Sega licensed the code necessary to produce Sega-compatible game cartridges to game publishers. Accolade, an independent game publisher, attempted to negotiate a license with Sega, but could not accept Sega’s demand that Sega be the exclusive manufacturer of all games produced by Accolade. Accolade therefore reverse engineered the Sega console and game cartridges in order to discover the “interface specifications”—that is, the APIs or, in the terminology of the Ninth Circuit’s opinion, “header files”—that enabled Accolade’s Mac and PC games to run on—that is, interoperate with—the Sega console platform. Intermediate copying as an integral part of reverse engineering, the Sega court held, is not actionable and is fair use if the point of that effort is to discover the interfaces needed for compatibility. (The more recent Sony Computer Entertainment, Inc. v. Connectix Corp. (9th Cir. 2000)  decision is in accord. “Connectix’s intermediate copying and use of Sony’s copyrighted BIOS was a fair use for the purpose of gaining access to the unprotected elements of Sony’s software.” Notably, the fact that Connectix failed to achieve perfect compatibility was not material.)

One would have expected that the CAFC would attempt to distinguish or at least explain away the Sega decision, given that the court was bound to apply Ninth Circuit law. Accolade’s actions were quite similar to those of Google: both companies replicated interfaces—ie APIs—in order to achieve some level of interoperability: between the Mac/PC platform and the Sega platform, in the case of Accolade, and between the Java platform and the Android platform, in the case of Google. In both cases, a target level of compatibility was achieved. Accolade copied the Sega APIs in the same way that Google has copied the Java APIs, and that use was held to be fair under binding Ninth Circuit precedent. Charitably, it’s difficult to square the CAFC’s holding with Sega.

And yet, in its opinion, the Federal Circuit cited the Sega decision only twice; once for the proposition that, “[T]he 1980 amendments to the Copyright Act unambiguously extended copyright protection to computer programs,” and again for the proposition that, “some uses can be fair.”

___

Just as with its 2014 decision, the CAFC failed to understand the implications of Google’s conduct and the extent of compatibility achieved at the developer level, and as a result, use of interfaces can never be held to be fair use—unless the Ninth Circuit steps in. Copyright protection for APIs, even for content that is expressive, original or creative, must be denied if that same content constitutes nothing more than a description and classification of functionality.

The software industry, and indeed every industry that relies on software, has thrived for decades without the encumbrances of proprietary claims over APIs. Because the Federal Circuit’s decision destroys the balance between copyrightable expression and uncopyrightable ideas in software, it threatens competition and innovation. The Ninth Circuit [OR THE US SUPREME COURT: CERT GRANTED 15 NOV 19.] should repudiate it at the earliest opportunity.

______________________________________

Sean spent part of his career as Assistant General Counsel at Sun Microsystems, responsible for Java platform licensing and alliances in the Asia-Pacific region as an expat in Tokyo. The views expressed in this article are Sean’s alone and do not necessarily represent the positions of Sean’s former employers, law firm or clients. 

 

 

[First published in the Winter 2015 edition of New Matter, the quarterly journal of the Intellectual Property Section of the California Lawyers Association. Copyright 2015 Sean Hogle, licensed under CC-BY-2.0; reposted here in light of the US Supreme Court’s decision yesterday (15 Nov 19) to grant certiorari (ie agree to hold a review) in the Oracle v. Google appeal, a surprising and welcome development.]

In 1995, Sun Microsystems released the Java platform and programming language.¹ The Java language, released for free use by all, is one of the most popular programming languages in the world today, taught in university computer science departments worldwide.² Developers have published thousands of Java applications for servers, personal computers, and smartphones.

¹ James Gosling, Bill Joy, Guy Steele, Gilad Bracha, and Alex Buckley, The Java Language Specification: Java SE 8 Edition(2015).

² “All agree that Google was and remains free to use the Java language itself.” Oracle America, Inc. v. Google Inc. (“Oracle I”), 872 F. Supp. 2d 974, 978 (N.D. Cal. 2012) (passim). Java is both an application execution platform and a programming language to write applications that will run on this platform. Java is “designed for the distributed nature of the Internet.” TechTarget Search SOA, Java Definition. Sun sought to disseminate the platform as widely as possible in order to promote the objective of “write once, run anywhere” Java application portability. See infra n. 39.

In 2007, Google launched the Android operating system for mobile devices, and released the source code of that system under a royalty-free and permissive open source license for free use by device manufacturers.³ To promote partial interoperability between the Java and Android platforms, Google copied a subset of the collection and organization of names, or the application programming interfaces (“APIs”), that Sun used for labeling and classifying certain functions in the Java language and platform, and included these interfaces in Android for use by application developers.

³ See Welcome to the Android Open Source Project!, Google; Android (operating system), Wikipedia.

Oracle acquired Sun in 2010, and in that same year, Oracle sued Google for copyright and patent infringement in the United States Northern District of California. After a jury trial in which Oracle’s patent claims were rejected, Judge Alsup ruled that the Java APIs Google copied in order to promote interoperability between the Java and Android platforms constitute an uncopyrightable method of operation under Section 102(b) of the U.S. Copyright Act (“Section 102(b)”).⁴

⁴ Oracle I, 872 F. Supp. 2d at 974.

Oracle appealed this decision to the U.S. Court of Appeals for the Federal Circuit (“CAFC” or the “Federal Circuit”). Because Oracle’s case included patent claims, the CAFC had jurisdiction over the appeal, and so Oracle was able to avoid review by the U.S. Court of Appeals for the Ninth Circuit. The CAFC, purportedly applying Ninth Circuit case law, reversed Judge Alsup, and held that the Java APIs are copyrightable.⁵ The CAFC ruled that considerations of interoperability are relevant only with respect to the question of whether Google’s adoption of the Java APIs was fair use, and remanded to the district court to resolve the fair use issue.

⁵ Oracle America, Inc. v. Google Inc. (“Oracle II”), 750 F.3d 1339 (Fed. Cir. 2014) (passim).

In June of 2015, the U.S. Supreme Court declined to hear an appeal from the Federal Circuit, leaving the CAFC decision intact.⁶ The precedential power of the Federal Circuit’s decision, however, is limited; the CAFC was constrained to follow Ninth Circuit precedent, and the Ninth Circuit can readily reject the CAFC’s reasoning in future cases. The Ninth Circuit should do so at the earliest opportunity.

⁶ Google, Inc. v. Oracle America, Inc., No. 14-410 (U.S. June 29, 2015).

The Federal Circuit’s decision is deeply, dangerously flawed. The CAFC failed to grasp the significance of what Google copied and why Google copied it. The court labored under a misapprehension of the facts regarding the nature and significance of the Java APIs in question, and the level of interoperability between the Java and Android platforms. Further, the appellate court erroneously dismissed Google’s interoperability objectives as a fair use concern, failing to realize that interoperability is the key to understanding whether APIs constitute an uncopyrightable “method of operation” under Section 102(b) of the Copyright Act.

What exactly did Google copy and why did it copy it?

Google designed software that uses the same “declaring code” that Sun used, so that Android applications, seeking to invoke a set of defined functions, could call those functions using the same labels that Sun used for Java applications. This made things significantly easier for Java application developers writing new applications for, or migrating existing Java applications to, Android.

To be precise, Google copied the following naming convention used by Sun:

java.package.class.method()

A package is a set of classes, and each class contains a set of methods, within which are sets of functions; an example of a declaration following this format is java.lang.Math.max, and an example of code that would call this function, using this declaration convention, is:

int a = java.lang.Math.max (2, 3);

This command returns the greater of two inputs (the “max”). It directs the program, as Judge Alsup explained, to “find the max method under the Math class in the java.lang package, input ‘2’ and ‘3’ as arguments, and then return a ‘3’, which would then be set as the value of ‘a.’”⁷

⁷ Oracle I, 872 F. Supp. 2d at 972, 981.

Google’s platform included only these declaration names that Sun used, and not the Sun/Oracle implementing code to which the functionality applied.⁸ In other words, Google developed functionality from scratch, but made that functionality available to Android applications using (in part) the same declaratory convention that Sun used.

⁸ Oracle I, 872 F. Supp. 2d at 978. Note that Google did literally copy nine lines of code in the “range.check” package and eight decompile security files (which never found its way into the Android platform). Id. at 983; Oracle II, 750 F.3d at 1351. This fact was not material to the copyrightability analysis at either the district or appellate court level.

Why would Google copy only the labels that Sun used to describe and invoke functionality that Google developed on its own? “Google believed Java application programmers would want to find the same … functionalities in the new Android system callable by the same names as used in Java.“⁹ As Google explained in its briefing to the CAFC, “Google supported use of the [Java programming language (“JPL”)] by Android developers because the JPL was widely taught in universities and was the best environment for software development.”¹⁰

⁹ Oracle I, 872 F. Supp. 2d at 978 (emphasis added).

¹⁰ Brief for Google Inc. as Appellee and Cross-Appellant at 18, Oracle America Inc. v. Google Inc., No. 13-1021, 1022 (Fed. Cir. May 23, 2013).

Section 102(b) defines the scope of copyright protection for software

By virtue of Section 102(b) of the U.S. Copyright Act, copyright does not extend to “any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.”¹¹ Such systems and methods should be free for anyone to use unless patent law applies to protect them. Admittedly, Section 102(b) has always posed a bit of a dilemma for software, as each one of a computer program’s instructions can readily be described as a “procedure, process, system or method of operation”. Nevertheless, clear lines were well-drawn and well-understood in this context since at least the time of when Section 102(b) was added to the Copyright Act in 1976.

¹¹ 17 U.S.C. §102(b).

Section 102(b) is a codification of the venerable U.S. Supreme Court decision of Baker v. Selden,¹²  in which the Court ruled that the author of a book describing a new accounting system could not use copyright law to prevent others from using that system. In connection with the 1976 amendments to the Copyright Act, Congress added Section 102(b) specifically because of concerns about extending copyright protection to software, as the House and Senate report to the 1976 Copyright Act amendments reveal:

¹² 101 U.S. 99 (1879).

¹³ H.R. REP. No. 94-1476, at 56-57 (1976), reprinted in 1976 U.S.C.C.A.N. 5659, 5670. Congress enacted Section 102(b) “as a result of the debate over the copyrightability of computer programs,” in order to prevent overprotection of computer software. See United States Copyright Office, General Guide to the Copyright Act of 1976at 3:3–3:4 (Sept. 1977). See also Pamela Samuelson, Why Copyright Law Excludes Systems and Processes from the Scope of Its Protection, 85 Tex. L. Rev. 1921, 1929-30 (2007).

Per the recommendation of the Congressionally-established National Commission on New Technological Uses of Copyrighted Works (“CONTU”), Congress amended the Copyright Act in 1980 to include a definition of “computer program” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” The CONTU report to Congress explained how expressly extending protection to software is reconcilable with Section 102(b):

Section 102(b) is intended … to make clear that the expression adopted by the programmer is the copyrightable element, and that the actual processes or methods embodied in the program are not ….

The way copyright affects games and game-playing is closely analogous: one may not adopt and republish or redistribute copyrighted game rules, but the copyright owner has no power to prevent others from playing the game.¹⁴

¹⁴ Oracle I, 872 F. Supp. 2d at 986 (quoting NAT’L COMM’N ON NEW TECHNOLOGICAL USES OF COPYRIGHTED WORKS, Final Report 20 (1979)) (emphasis added).

Section 102(b) has defined the scope of copyright protection of software for decades.¹⁵ The history of software and computing since its enactment validates the efficacy of the balance that Congress struck in this regard. IBM’s circa-1980s operating system powering the first mainstream generation of personal computers became the dominant computing paradigm of its time because of the open and non-proprietary nature of the APIs for this operating system.¹⁶  Other personal computer manufacturers were able to emulate the IBM basic input/output system (BIOS) without fear of copyright liability, paving the way for numerous PC clones.¹⁷

¹⁵ Similarly, the European analogue to Section 102(b), also established for decades, is the 1991 EU Software Directive, which states, “[i]deas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright ….” (emphasis added). Art. 1(2), Council Directive 91/250/EEC of 14 May 1991 On the Legal Protection of Computer Programs.

¹⁶ Corrected Brief for Computer Scientists as Amici Curiae Supporting Defendant-Cross Appellant at 4-25, Oracle America Inc. v. Google Inc., No. 13-1021, 1022 (Fed. Cir. May 30, 2013); Brief for Intellectual Property Law Professors as Amici Curiae Supporting Defendant-Cross Appellant, at 7-10, Oracle America Inc. v. Google Inc., No. 13-1021, 1022 (Fed. Cir. May 30, 2013).

¹⁷ Corrected Brief for Computer Scientists as Amici Curiae Supporting Defendant-Cross Appellant at 4-25, Oracle America Inc. v. Google Inc., No. 13-1021, 1022 (Fed. Cir. May 30, 2013).

An explosion of innovation took place in a legal environment where everyone was free to implement the same APIs as utilized by IBM, Microsoft, Apple, HP, Sun and a myriad other enterprises, standards, and projects, as methods of operation clearly excluded from copyright protection by virtue of Section 102(b). A legal regime that fostered unfettered software interoperability resulted in robust competition and innovation in a bewildering array of computing platforms and applications.¹⁸  It’s no exaggeration to say that Linux, MacOS, the C programming language, cloud computing, the Internet, and even the Java platform, owe their existence in part to the historically open and non-proprietary nature of APIs.¹⁹

¹⁸ See Jonathan Band & Masanobu Katoh, Interfaces on Trial 2.0 (2011), at 31 (“[P]reventing interoperability invariably stifles creativity; new firms cannot introduce new products for the locked-in base, and the monopolist has little incentive to innovate—and innovation is the ultimate goal of the intellectual property system.”)

¹⁹ Corrected Brief for Computer Scientists as Amici Curiae Supporting Defendant-Cross Appellant at 4-25, Oracle America Inc. v. Google Inc., No. 13-1021, 1022 (Fed. Cir. May 30, 2013). See also Brief for Hewlett-Packard Company, Red Hat, Inc., and Yahoo! Inc. as Amici Curiae Supporting Petitioner at 6-14, Google Inc. v. Oracle America, Inc. No. 14-410 (U.S. Sup. Ct. Nov. 7, 2014). The Java platform itself owes its success to the non-proprietary nature of APIs. See infra n. 39.

As a consequence of this decades-long history, free reusability of APIs in furtherance of unhindered and widespread interoperability has become the sine qua non of the idea-expression dichotomy in the software context, allowing software to build upon software, platform upon platform, feature upon functionality, in a dynamic competitive environment producing unparalleled innovation.

Section 102(b), and its concomitant interoperability imperative, is one of the only meaningful dividing lines between patents and copyrights with respect to software. The ideas—the methods of operating software functions—should be subject to private ownership and control only if the rules of patent grant such protection. Entitlement to a patent requires proof of eligibility before a government gatekeeper, to assess whether the matter to be patented is sufficiently novel and inventive. No such gatekeeper exists in the copyright realm, as copyright protection is automatic. Patent protection lasts 20 years; copyright protection can endure for more than a hundred years, and is trivial to secure.

Lotus v. Borland: a method of operating software cannot be protectable, even if expressive and creative

The Java APIs are the rules of a game, the instructions that developers must follow to create and run Java-compatible programs. They articulate how to organize functions in the hierarchical structure of packages, methods and classes. They are the equivalent of the accounting system at issue in Baker v. Selden.  These labels, and the way Sun classified them within the package/class/method directory structure, are “a process, system, or method of operation” of organizing and labeling software programming functions.

Impressed by the length, originality, and creativity of the Java APIs, the Federal Circuit nevertheless ruled, as a matter of law, that methods of operation that are expressive, creative, or original are entitled to protection. “[W]e conclude that a set of commands … may contain expression that is eligible for copyright protection,” the Federal Circuit proclaimed, “as long as the author had multiple ways to express the underlying idea.”²⁰

²⁰ Oracle II, 750 F.3d at 1367.

In so ruling, the CAFC had to confront directly conflicting precedent, the 1995 Lotus v. Borland decision, in which the First Circuit Court of Appeals held that even expressive and creative software interfaces are nevertheless uncopyrightable methods of operation.²¹  In that case, Borland had copied the commands the Lotus spreadsheet used so that end user-developed macros (i.e., mini-programs) written for the Lotus spreadsheet program could be readily deployed for use with the Borland spreadsheet program,²²  much like Google emulated a subset of the Java APIs to make it easier for Java applications to be ported to Android. The First Circuit denied copyright protection for these commands, ruling that even “expressive” command structures and labels used in a software application that must be adopted in order to secure interoperability with that software nevertheless constitute a method of operation.²³

The fact that there may be … many different ways to operate a computer program using a set of hierarchically arranged command terms, does not make the actual method of operation chosen copyrightable; it still functions as a method for operating the computer and as such is uncopyrightable.²⁴

²¹ Lotus Dev. Corp. v. Borland Int’l, 49 F.3d 807 (1st Cir. 1995), affirmed without opinion by an equally divided Supreme Court, 516 U.S. 233 (1996).

²² Lotus, 49 F.3d at 810.

²³ Id.

²⁴ Id. at 818.

The “expressive choices” Lotus made in writing those commands were deemed irrelevant. “The fact that Lotus developers could have designed the Lotus menu command hierarchy differently”, the Lotus court held, was “immaterial” under Section 102(b).²⁵ Because there is no meaningful difference between the “hierarchically arranged command terms” in the Lotus spreadsheet program and those contained in the Java platform, the Federal Circuit was compelled to explain how Lotus is not applicable.

²⁵ Lotus, 49 F.3d at 816.

The CAFC attempted to distinguish the Lotus case on three grounds. “First, while the defendant in Lotus did not copy any of the underlying code,” the court stated, “Google concedes that it copied portions of Oracle’s declaring source code verbatim.”²⁶  Google and Borland copied the same thing. Borland copied the labels and command structures of the Lotus spreadsheet program. Google copied the labels and command structures of the Java platform. Just as in the Oracle case, “Borland [read, Google] did not copy any of Lotus’s [read, Sun’s] underlying computer code; it copied only the words and structure of Lotus’s [i.e. Oracle’s] … command hierarchy.”²⁷

²⁶ Oracle II, 750 F.3d at 1365.

²⁷ Lotus, 49 F.3d at 810.

“Second,” the CAFC continued, “the Lotus court found that the commands at issue there … were not creative, but it is undisputed here that the declaring code and the structure and organization of the API packages are both creative and original.”²⁸  This statement is false. The Lotus court never ruled on whether the commands at issue were creative; their creativity was irrelevant. Because the Lotus command structure was an essential method of operating the Lotus spreadsheet program, the Lotus court did “not inquire further whether that method of operation could have been designed differently. The ‘expressive’ choices of what to name the command terms and how to arrange them do not magically change the uncopyrightable menu command hierarchy into copyrightable subject matter.”²⁹

²⁸ Oracle II, 750 F.3d at 1365.

²⁹ Lotus, 49 F.3d at 816.

Which brings us to the CAFC’s third and final basis for distinguishing Lotus: “while the court in Lotus found the commands at issue were ‘essential to operating’ the system, it is undisputed that—other than perhaps as to the three core packages—Google did not need to copy the structure, sequence, and organization of the Java API packages to write programs in the Java language.”³⁰  Judge Alsup’s factual finding, not challenged or even questioned on appeal, was that “the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function. The declaration requires precision.”³¹ Google was in fact required to copy the Java APIs in the manner it did in order to secure the level of interoperability Google sought. And as demonstrated below, the level of interoperability Google achieved was significant.

³⁰ Oracle II, 750 F.3d at 1365. The three core packages the CAFC mentions here are significant. See infra n. 37-41 and accompanying text.

³¹ Oracle I, 872 F. Supp. 2d at 998. Because “the rules of Java dictate the precise form of certain necessary lines of code called declarations,” Judge Alsup found, “Android and Java must be identical when it comes to those particular lines of code.” Id. at 979.

Any method of operation can be creative and original; anyone developing methods of operating software functions will have an infinite variety of creative choices to make. By making creativity and originality the only effective touchstone for assessing copyrightability, the CAFC has essentially extended copyright protection “to the methodology or processes adopted by the programmer,” contrary to congressional intent in enacting Section 102(b).³²

³² “If a framework of shortcuts used by programmers in their development process isn’t a procedure, system, or method of operation, what is?” Jonathan Band, Further Reflections on Oracle v. Google, Project Disco, May 12, 2014.

The only way to convey the Java rules is to express them verbatim, merging expression with ideas

Even if a method of operating software is sufficiently original or creative so as to justify extending protection to it, the longstanding case law in this area, known as the “merger” doctrine, instructs that any expressive content that exists in the Java APIs has been effectively merged with the facts and ideas those APIs communicate. In the CAFC’s own words:

Under the merger doctrine, a court will not protect a copyrighted work from infringement if the idea contained therein can be expressed in only one way. For computer programs, “this means that when specific [parts of the code], even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.”³³

³³ Oracle II, 750 F.3d at 1360 (citations and quotations omitted).

The Federal Circuit rejected the applicability of the merger doctrine (with one notable exception as described below), because, in its view, merger is relevant only for determining if expression is merged with the idea at the time of the original work’s creation, and not for determining if a later work infringed that expression. “Merger cannot bar copyright protection for any lines of declaring source code unless Sun/Oracle had only one way, or a limited number of ways, to write them”, and the factual record, the CAFC observed, demonstrated that Sun had “unlimited options as to the selection and arrangement” of the Java APIs.³⁴  For example, with respect to the “math.max” API highlighted above, the Federal Circuit stated that Sun’s developers could have called that API “any number of things, including ‘Math.maximum’ or ‘Arith.larger.’”³⁵

³⁴ Oracle II, 750 F.3d at 1361.

³⁵ Id.

That Sun had unlimited options in its creation of the Java platform is self-evident. But for anyone else seeking to develop software that is interoperable with that platform, the options are quite limited. The functionality for comparing two integers must be called “math.max” (and must be included in the package java.lang) if the Android platform is to be compatible with the Java platform. Because “the rules of Java dictate the precise form of certain necessary lines of code called declarations,” Judge Alsup found, “Android and Java must be identical when it comes to those particular lines of code.”³⁶

³⁶ Oracle I, 872 F. Supp. 2d at 979.

Curiously, the Federal Circuit incongruously recognized this in the portion of its opinion discussing three “core” Java package APIs. These three packages, Judge Alsup explained, were deemed core to the Java programming language from its inception:

When Java was first introduced in 1996, the API included eight packages of pre-written programs.  At least three of these packages were “core” packages, according to Sun, fundamental to being able to use the Java language at all. These packages were java.lang, java.io, and java.util.  As a practical matter, anyone free to use the language itself (as Oracle concedes all are), must also use the three core packages in order to make any worthwhile use of the language.³⁷

³⁷ Oracle I, 872 F. Supp. 2d at 982 (emphasis added).

With respect to these packages, the CAFC stated:

It seems possible that the merger doctrine, when properly analyzed, would exclude the three packages identified by the district court as core packages from the scope of actionable infringing conduct. This would be so if the Java authors, at the time these packages were created, had only a limited number of ways to express the methods and classes therein if they wanted to write in the Java language. In that instance, the idea may well be merged with the expression in these three packages.³⁸

³⁸ Oracle II, 750 F.3d at 1362 (emphasis added). Unhappily for Google, the CAFC nevertheless ruled against Google on its merger argument as to these three core packages because “Google did not present its merger argument in this way below and … does not try to differentiate among the packages for purposes of its copyrightability analysis ….” Id.

With this single passage, the CAFC unwittingly revealed the nature of the Java APIs as a method of operating software. Applications that are written in the Java programming language run only on platforms that contain the same Java APIs that the language mandates.³⁹ At least with respect to these three core packages, the CAFC conceded that the dictates of the Java programming language constrained Sun’s choices in developing a platform that faithfully executes applications written in the Java language. If so, these APIs are not entitled to protection; the ideas or facts posed by the Java programming language have merged with the expression of those APIs.

³⁹ Java is both an execution environment on which Java applications run, and a programming language for writing such applications. Oracle Corporation, What is Java technology and why do I need it?.  Sun’s objective was to create a universal application execution environment such that applications written in the Java language can run with no or minimal adaptation across multiple devices and operating systems (such as Windows, MacOS and Linux) and Internet browsers (such as Chrome, Explorer and Safari), so long as such devices, systems and browsers contain a ported version of the Java execution environment. In short, Sun sought application “write once, run anywhere” portability for Java applications. Oracle I, 872 F. Supp. 2d. at 977. Ironically, Java itself was enabled by the open or non-proprietary nature of the APIs of the operating systems and browsers to which the Java platform has been ported. To make Java successful, Sun required widespread adaptation of the Java platform to multiple computer and device operating systems and Internet browsers, which in turn required access to the APIs of those systems and browsers.

Yet under the CAFC’s ruling, Oracle is somehow entitled to prevent Google’s use of the other Java APIs at issue, all of which are no less constrained by the dictates of the Java programming language.⁴⁰ The CAFC evidently failed to grasp that (1) Android applications are written in the Java programming language;⁴¹ and (2) all Java APIs, including those at issue in the case, are derived from and require adherence to the rules of the Java programming language. This critical connection between the Java programming language and the Java platform was apparently lost on the Federal Circuit.

⁴⁰ See What are the 37 Java API packages possibly encumbered by the May 2014 Oracle v Google decision?, StackOverflow (Question: “How can I avoid using the encumbered APIs [found by the CAFC to be infringed by Google] in my Java code?” Answer: “Don’t write in Java. Anything written in the Java programming language will involve classes from the affected packages.” (emphasis added)).

⁴¹ See infra n. 47-51 and accompanying text. Throughout the CAFC’s opinion, the court made statements that seemingly betray an ignorance of the fact that Java (and Android) applications are written in the Java programming language so that such applications can run on a Java-compatible platform. In nearly every instance in which the court mentions the language, it does so in the context of Google’s or Sun’s design of the Android or Java platforms and APIs. See e.g., Oracle II, 750 F.3d at 1350 (referencing Google “using the Java programming language” to design the Dalvik virtual machine (i.e., Google’s version of the Java platform, which is in fact written in the C language)); id. at 1362 (“This would be so if the [Sun/Oracle] Java authors [of the Java APIs], at the time these packages were created, had only a limited number of ways to express the methods and classes therein if they [the authors of the APIs] wanted to write in the Java language.”); id. at 1363 (“Google could have written its own API packages using the Java language. Google chose not to do that.”); id. at 1365 (“Google did not need to copy the structure, sequence, and organization of the Java API packages to write programs in the Java language.” (emphasis added)). No wonder the CAFC found Google’s interoperability arguments “confusing.” Id. at 1371.

Interoperability is the foundational rationale behind Section 102(b) in the software context

The most troublesome aspect of the CAFC’s ruling is its pronouncement that interoperability has nothing to do with the copyrightability question. “Google,” the court noted with less-than-circumspect suspicion, “chose to copy Oracle’s declaring code and the [structure, sequence and organization of it] to capitalize on the preexisting community of programmers who were accustomed to using the Java API packages. That desire has nothing to do with copyrightability.”⁴²

⁴² Oracle II, 750 F.3d at 1372.

If the task at hand is to determine if something in software is an uncopyrightable method of operation, examining how and why a party other than the originator of that method implemented it is an integral part of the Section 102(b) analysis. “Seeking to capitalize on a pre-existing community of programmers” is of course seeking to promote interoperability, and interoperability “sheds further light on the character of the command structure as a system or method of operation.”⁴³  Because promoting software interoperability has become the policy foundation underlying Section 102(b), we need to know if Google was simply trying to play the same game that Sun was playing, or was taking more Sun-originated material than was necessary to play.

⁴³ Oracle I, 872 F. Supp. 2d at 1000. See also Jonathan Band, Further Reflections on Oracle v. Google, Project Disco, May 12, 2014 (“The Federal Circuit opined that the desire to capitalize on the preexisting community of Java programmers ‘has nothing to do with copyrightability.’ But this plainly is wrong. What could be better proof that something is a procedure, system, or method of operation than if a person can become ‘trained,’ ‘experienced,’ or ‘accustomed’ to using it in the course of developing new works?”).

The reason the CAFC was so willing to dismiss Google’s interoperability-based arguments is because the court failed to discern any interoperability benefit at all as a result of Google’s actions.⁴⁴ The Federal Circuit repeatedly stressed in its opinion that “Android is not generally Java compatible”,⁴⁵ and that “nothing prevented Google from writing its own declaring code, along with its own implementing code, to achieve the same result.”⁴⁶

⁴⁴ Another reason Google’s interoperability objectives, and its success, were so heavily discounted by the Federal Circuit is because the court erroneously consigned interoperability concerns to the hopelessly fact-specific and unpredictable fair use swamp. Oracle, 750 F.3d at 1372. Patently hostile to Google’s fair use contentions, the CAFC came alarmingly close to ruling in Oracle’s favor as a matter of law. Id. at 1376. A robust critique of the CAFC’s fair use explication, and its irreconcilability with the Ninth Circuit’s Sony and Sega decisions, is certainly possible and imperative, but outside the scope of this article. See infra n. 52.

⁴⁵ Oracle II, 750 F.3d at 1351.

⁴⁶ Id. at 1361.

The CAFC’s ruling on this point flatly contradicts the factual record of the case and is, more importantly, entirely divorced from the reality of Android application development. As Judge Alsup concluded:

Although the declarations must be the same to achieve the same functionality, the names of the methods and the way in which the methods are grouped do not have to be the same. Put differently, many different API organizations could supply the same overall range of functionality. They would not, however, be interoperable.⁴⁷

⁴⁷ Oracle I, 872 F. Supp. 2d at 982 (emphasis added).

Despite that the Federal Circuit found “no evidence in the record” of any Java applications “that either pre-dated or post-dated Android that could run on the Android platform”,⁴⁸ every Java application ever developed now or in the future can more easily be migrated to Android because of Google’s adoption of the Java APIs in question. The result of Google’s actions is that a large number and variety of programming tools exist to support Android application development in Java. These tools leverage the commonality in the two platforms to make it easy for Java programmers to write Android applications.⁴⁹

⁴⁸ Oracle II, 750 F.3d at 1371.

⁴⁹ Alex Marshall, Top 10 Android Apps and IDEs for Java Coders and Programmers, Java PDF Blog, Dec. 11, 2014.

And unmistakably, Google’s interoperability efforts in this respect have been a resounding success. Java is the go-to programming language for developing Android applications.⁵⁰ Much to Oracle’s chagrin, the emergence of Android has in fact led to a resurgence in the popularity of the Java programming language:

After a year-and-a-half in second place, behind the C language, Java surged back into first place in this month’s Tiobe language popularity index. Topping the Tiobe Index again is being attributed to Java’s usage in Android application development.⁵¹

⁵⁰ See e.g., Laurence Bradford, Five Things to Know before Building Your First Android App, Learn to Code with Me, Aug. 25, 2014 (“You need to learn Java, there’s no way around it.”); Shane Conder & Lauren Darcey, Learn Java for Android Development, TUTS+, Sept. 13, 2010 (“Android applications are developed using the Java language. As of now, that’s really your only option ….”).

⁵¹ Paul Krill, Java Regains Spot as Most Popular Language in Developer Index, InfoWorld, Apr. 14, 2015.

Google’s actions and Oracle’s response encapsulate the character of the Java APIs as a method of operation. Google impinged on Oracle’s attempted monopolization of the instructions for writing and supporting Java programs on mobile devices, and so Oracle sued to stop Google from capitalizing on the existing Java developer base. In essence, Oracle sought exclusivity over that developer community. It’s the same impulse that motivated Sony and Sega to incur significant legal expense in an attempt—ultimately unsuccessful—to shut down the efforts of companies that made it possible to play Sony Playstation games on a personal computer, and Accolade PC games on Sega’s proprietary game console.⁵²  In the apt words of Judge Alsup, “fragmentation, imperfect interoperability, and Oracle’s angst over it illustrate the character of the command structure as a … method of operation.”⁵³

⁵² Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000). The facts of the Sega case should be familiar to followers of the Oracle v. Google proceedings. In the early nineties, Sega manufactured video game consoles and game cartridges that could be used only with the Sega console. Sega licensed the code necessary to produce Sega-compatible game cartridges to game publishers. Accolade, an independent game publisher, attempted to negotiate a license with Sega, but could not accept Sega’s demand that Sega be the exclusive manufacturer of all games produced by Accolade. Sega, 977 F.2d at 1514-16. Accolade therefore reverse engineered the Sega console and game cartridges in order to discover the “interface specifications”—that is, the APIs or, in the terminology of the Ninth Circuit’s opinion, “header files”—that enabled Accolade’s Mac and PC games to run on—that is, interoperate with—the Sega console platform. Id. Intermediate copying as an integral part of reverse engineering, the Sega court held, is not actionable if the point of that effort is to discover the interfaces needed for compatibility. Id. at 1527. Concededly, the Sega court’s ruling was based exclusively on fair use—but its decision was undeniably premised on the unprotectable nature of interfaces as methods of operation under Section 102(b). Id. The more recent Sony decision is in accord. Sony, 203 F.3d at 602 (“Connectix’s intermediate copying and use of Sony’s copyrighted BIOS was a fair use for the purpose of gaining access to the unprotected elements of Sony’s software.”). Notably, the fact that Connectix failed to achieve perfect compatibility was not material. Id. at 599.

⁵³ Oracle I, 872 F. Supp. 2d at 1000.

Because Google failed to achieve perfect compatibility, an impossibility given the differences between a platform developed for desktop computers (Java) and a platform for mobile devices (Android), the CAFC was convinced that Google’s actions could not be explained by a desire to achieve interoperability. As a result, the CAFC discounted every argument Google raised regarding Section 102(b), interoperability, and even fair use. The unfortunate logic of the Federal Circuit’s analysis invites courts to assess degrees of compatibility in future cases.⁵⁴

⁵⁴ As Judge Alsup noted with some irony, “Oracle has made much of [the fragmentation problem], at times almost leaving the impression that if only Google had replicated all 166 Java API packages, Oracle would not have sued.” Oracle I, 872 F. Supp. 2d at 1000 (emphasis in original).

The strawman that APIs are not copyrightable because they are “functional”

One of the more frustrating aspects of the Federal Circuit’s decision is its mischaracterization of Judge Alsup’s holding:

[T]he district court recognized that the SSO [(the structure, sequence and organization of the Java APIs)] “resembles a taxonomy,” but found that “it is nevertheless a command structure, a system or method of operation—a long hierarchy of over six thousand commands to carry out pre-assigned functions.” In other words, the court concluded that, although 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.⁵⁵

⁵⁵ Oracle II, 750 F.3d at 1367 (emphasis added).

Judge Alsup’s holding was not that the Java APIs are unprotectable because they are functional. They are in fact not functional.⁵⁶ They are declarative; they dictate how functional elements should be organized and labeled. Rather, Judge Alsup’s holding was that the Java APIs are unprotectable because they are a method of operating Java software programs, a method that can only be implemented in the same manner as implemented in the replicated platform in order to achieve the entire point of the exercise—interoperability.

⁵⁶ “The court seems to not understand what an API is, confusing it with software functionality.” Mike Masnick, Tech Dirt, May 9, 2014, Appeals Court Doesn’t Understand the Difference between Software and an API; Declares APIs Copyrightable (emphasis in original). Admittedly, the Sega and Sony courts used the “functional” label as a shorthand means of referring to methods of operation barred by Section 102(b) (Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510, 1517 (9th Cir. 1992); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596, 603 (9th Cir. 2000)), but neither court’s holding, nor Judge Alsup’s, hinged on the functional or non-functional (i.e., behavioral) nature of the interfaces in question.

Having mischaracterized Judge Alsup’s holding, the appellate court then gratuitously ran with it, accusing Judge Alsup (who is a coder himself)⁵⁷ of applying a rule that would result in all computer programs losing copyrightability. In the words of the CAFC, “[i]f we were to accept the district court’s suggestion that a computer program is uncopyrightable simply because it ‘carr[ies] out pre-assigned functions,’” a holding Judge Alsup never made, “no computer program is protectable.”⁵⁸ This accusation is ironic, given that the CAFC’s reasoning inexorably leads to all methods of operation within software being protectable.

⁵⁷ Mike Masnick, Should People Learn to Code? Yes if they are Judges Ruling on Cases Involving Software, Techdirt, May 21, 2012. That Judge Alsup understood the tension between extending copyright protection to software and yet denying protection to “methods of operation” is demonstrated by footnote 7 of the court’s opinion, in which Judge Alsup notes that a prominent software copyright academic “has argued that the Section 102(b) terms ‘process,’ ‘system,’ and ‘method of operation’ should not be understood literally for computer programs.” Oracle I, 872 F. Supp. 2d at 996 n.7, citing Jane C. Ginsburg, Four Reasons and a Paradox: The Manifest Superiority of Copyright Over Sui Generis Protection of Computer Software, 94 Colum. L. Rev. 2559, 2569-70 (1994) (“[S]ome ways of achieving ‘a certain result’ (i.e., some ‘behaviors’) will be protected by copyright. What ways, and what results?”)

⁵⁸ Oracle II, 750 F.3d at 1367. The CAFC took another cringeworthy whack at this straw man, and doubled down on its factual error regarding the choices available to Google given Google’s legally-protected interoperability objectives, in a concluding paragraph notable for its succinct distillation of the myriad legal and factual flaws of this decision. “Given the court’s findings that the [structure, sequence and organization of the Java APIs] is original and creative, and that the declaring code could have been written and organized in any number of ways and still have achieved the same functions, we conclude that Section 102(b) does not bar the packages from copyright protection just because they also perform functions.” Id. at 1368.

Again, we are concerned here with nothing more than the magic words that Sun used for labeling, classifying and invoking functionality. We are focused on the declarations that take the form: java.package.class.method(). No functionality, let alone protectable expression of functionality, was copied; Google developed its own.

_____________________________

Judge Alsup’s concluding passage in his copyrightability decision captures the point perfectly:

In closing, it is important to step back and take in the breadth of Oracle’s claim. Of the 166 Java packages, 129 were not violated in any way. Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable [declarations] …. 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.⁵⁹

⁵⁹ Oracle I, 872 F. Supp. 2d at 1001-02 (emphasis added).

Unfortunately, the Federal Circuit has done just that, and now we know that the Supreme Court is not going to correct it. [NOTE: MAYBE IT WILL NOW. CERT GRANTED 15 NOV 19.] Oracle has effectively secured, for decades, a patent-like monopoly over a method of operating software.

The Java APIs may have been time-consuming and expensive to develop, and there may have been some creative choices involved. Nevertheless, they are “the rules by which computer programs interact with one another, analogous to the rules of games played by humans, like the rules of checkers or chess, which are agreed by all to be uncopyrightable ideas.”⁶⁰ Under the CAFC’s logic, no method of operation will ever be excluded so long as the author of that method exercised creativity. If the only criteria for extending copyright protection to software is originality and creativity, Section 102(b) loses all meaning.

⁶⁰ Brief for Software Freedom Law Center and Free Software Foundation as Amici Curiae Supporting Respondent at 8-9, Google Inc. v. Oracle America, Inc. No. 14-410 (U.S. Sup. Ct. Dec. 8, 2014).

“Google could have written its own API packages using the Java language”,⁶¹  the CAFC declared, but failed to explain what the point of that would be, if not to enable compatibility between Java and Android. In developing Android to be interoperable with the Java platform, Google was playing the Java game using some, but not all, of the rules that Sun established. Yet, Google made Android sufficiently familiar to application developers accustomed to writing applications in Java as to unleash thousands of applications on Android in short order. This is an outcome that copyright law should never prevent.

⁶¹ Oracle II, 750 F.3d at 1353.

Copyright protection for software, even for content that is expressive, original or creative, must be denied if that same content constitutes nothing more than a description and classification of functionality. Just as the originator of the accounting system at issue in Baker v. Selden was not able to use copyright law to prevent anyone else from adopting the accounting methods and forms he described in his book, Oracle must not be allowed to use copyright to preclude anyone else from following the same methods and systems described in the Java APIs. If the idea-expression dichotomy in the software context is to have any significant impact in limiting the scope of copyright protection, it must be that copyright extends only to code that is completely original, and that is not dictated by the requirements of compatibility with an external standard.

The software industry, and indeed every industry that relies on software, has thrived for decades without the encumbrances of proprietary claims over APIs. Because the Federal Circuit’s decision destroys the balance between copyrightable expression and uncopyrightable ideas in software, it threatens competition and innovation. It should be repudiated at the earliest opportunity.

_________________________________

Sean spent part of his career as Assistant General Counsel at Sun Microsystems, responsible for Java platform licensing and alliances in the Asia-Pacific region as an expat in Tokyo. The views expressed in this article are Sean’s alone and do not necessarily represent the positions of Sean’s former employers, law firm or clients.