Software Copyright and Innovation After Oracle v. Google

• Jurisdiction: United States,Federal
• Citation: Vol. 40 No. 4
• Publication year: 2015
• Author: SEAN HOGLE
• topic: Patent law,Intellectual Property,Copyright law

Software Copyright and Innovation after Oracle v. Google

SEAN HOGLE
Sean Hogle PC

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.

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.

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 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.

In June of this year, 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.

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 de-ined 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.'"⁷

[Page 12]

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.

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 de-velopment."¹⁰

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.

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:

Some concern has been expressed lest copyright in computer programs should extend protection to the methodology or processes adopted by the programmer.... Section 102(b) is intended, among other things, to make clear that the expression adopted by the programmer is the copyrightable element in a computer program, and that the actual processes or methods embodied in the program are not within the scope of the copyright law.¹³

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.¹⁴

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.¹⁷

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.¹⁹

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...