Background of Google v. Oracle
Before Sun Microsystems (now Oracle) created the Java language and platform, there was not an effective means for an application to run across multiple different operating systems—for example, Windows and Mac. Instead, application developers had to rewrite their application for each operating system. Sun Microsystems created the Java computer language and a collection of ready-to-use programs, i.e., modules that developers could incorporate into their own applications. Once written, these applications could be used on different operating systems, each running a specific implementation of the Java platform for that operating system. Each individual program or task, called a “method,” performs a unique function, like drawing a shape, solving a type of math problem, creating a user interface element, etc. Sun organized the methods into an intricate collection of “classes” that group related methods and define unique data types on which methods operate, and “packages” that group related classes. Together, these form the Java application programming interface (API) and the method-class-package organizational structure form part of the Java API’s “structure, sequence and organization,” or SSO. Sun created over 30,000 methods organized in 3,000 classes and 166 packages.
There are two main kinds of code in the Java API. One kind, called “declaring code,” contains the detailed technical specifications for the Java API functions. An example of declaring code is:
public static int max(int x, int y)
This code performs a function “max” that returns the greater of two integers specified in the brackets.
To use this function, a Java programmer writes a portion of their own application that matches this declaring code. For example:
int a = java.lang.Math.max (2, 3)
When a program does so, the actual computation requested by the programmer (here, finding the greater of two integers) is carried out by the other kind of code in the Java API, the “implementing code,” which is called via the declaring code.
Google wanted to develop an operating system for smart phones. The reason was likely to greatly expand its core search and ad businesses well beyond its PC platform at that time. So, to get a jump start, it acquired Android Inc. in 2005. Android Inc. was developing the forerunner to today’s Android phone operating system. To encourage third parties to use Android and develop those apps, the Android operating system was free but also needed to offer familiar ways to develop applications. At that time, the Java language and API was well-known among developers. Shortly after acquiring Android Inc., Google began talks with Sun about the possibility of licensing the Java platform for the new smartphone operating system Google was building. The negotiations between Google and Sun failed, and Google subsequently copied verbatim the declaring code of 37 Java API packages ≈11,500 lines from the then version of the Java platform, the Java Platform, Standard Edition (Java SE). Google also copied the structure and arrangement of those packages. These packages were the ones “Google believed Java application programmers would want to find” in Android. The copied lines effectively provide a large part of the Java API as an API in the Android platform.
Android is incompatible with the Java platform. That is, an Android application would not work on a Java implementation on another operating system. Google pitched the Java API as a selling point to hardware manufacturers and cellular carriers (Qualcomm, LG, AT&T)—including Oracle’s own customers—touting Android’s “Core Java Libraries,” “Java API,” and “Powerful, Simple Java Application Framework.”
Amazon leveraged the free availability of Android to force Oracle to reduce its Java licensing fee by 97.5%. The Android software is now the largest platform for mobile devices (installed on more than 2.5 billion devices).
Following its 2010 acquisition of Sun, Oracle filed suit against Google alleging copyright and patent infringement and sought $8.8 billion in damages. After the Federal Circuit held that Google’s use was not fair use, Google appealed to the Supreme Court. The main question on appeal was whether Google’s copying constituted a permissible fair use of that material.
The Supreme Court assumed that the copied lines of Java SE could be copyrighted and only ruled on whether Google’s use of those lines was fair use. The Court found that each of the four fair use factors weighed in favor of Google.
The first factor looks at the purpose and character of the use. Google’s implementation of the Java API and use of the Java SE code was to create new products, to expand the use and usefulness of Android-based smartphones. Google copied the API (which was created for use in desktop and laptop computers) only insofar as needed to include tasks that would be useful for smartphones and used only as much as necessary to allow programmers to call upon those tasks with a familiar programming language. Google’s use was what some amici call “reimplementation,” which is defined as the “building of a system … that repurposes the same words and syntaxes” of an existing system. Google “reimplemented” the Java API so programmers who had learned an existing system could put their basic skills to use in a new one. If the API labels changed, a developer would have to learn a whole new language. The portions of the Java API that Google reimplemented helped preserve consistency within the larger developer community. Allowing for reasonable fair use of functional code for this purpose enables innovation that creates new opportunities for the market to grow. To the extent that Google used parts of the Java API to create a new platform that could be readily used by programmers, its use was consistent with that creative progress that is the constitutional objective of copyright itself.
The second factor focuses on the nature of the copyrighted work. The Court distinguished between declaring code and implementing code stating that declaring code embodies a different type of creativity than implementing code. Writing implementing code requires balancing considerations such as “how quickly a computer can execute a task or the likely size of the computer’s memory.” “One witness described that creativity as ‘magic’ practiced by an API developer when he or she worries ‘about things like power management’ for devices that ‘run on a battery.’” Declaring code does not involve this type of creativity. This goes back to Java SE’s creator’s main strategy, which was to use the ideas embodied in the API to attract programmers. They wanted to attract programmers who would learn the system, develop it further, and be reluctant to use another. Unlike many other programs, the declaring code’s value in significant part derives from those who do not hold copyrights—namely, computer programmers, who invest their own time and effort to learn the API’s system. The system was designed to be intuitive and understandable to developers while also being easy to remember. Its value lies in its efforts to encourage programmers to learn and to use that system so that they will use (and continue to use) Java-related implementing programs that Google did not copy. The Court also noted that declaring code’s use is inherently bound together with uncopyrightable ideas (general task division and organization) and copyrightable new creative expression (Android’s implementing code). “[S]ome works are closer to the core of [copyright] than others.” The declaring code, if copyrightable at all, is further from the core of copyright than most computer programs (such as implementing code). Therefore, this factor weighed in favor of Google and for fair use.
The third factor looked at the amount and substantiality of the portion used. Google copied 11,500 lines of code, or about 0.4%, from the Java API computer code, which had a total of 2.86 million lines of code. But a small amount of copying may fall outside of the scope of fair use where the copied portion consists of the “heart” of the original work’s creative expression. The Java API declaring code is inseparably bound to the task implementing lines. Its purpose is to call them up. In essence, it is linked to the heart, but it is not the heart. Google did not copy the Java SE code for its creativity, beauty or “even (in a sense) because of their purpose.” Google copied those lines because programmers had already learned to work with the Java API, and Google wanted to allow them to make use of their existing knowledge and experience using the Java API when they wrote new programs for the Android platform. Google’s basic purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform that would help achieve and popularize that objective. “In a sense, the declaring code was the key that it needed to unlock the programmers’ creative energies.” “The ‘substantiality’ factor will generally weigh in favor of fair use where, as here, the amount of copying was tethered to a valid, and transformative, purpose.” Therefore, this factor weighed in favor of Google and for fair use.
The fourth factor turned on the effect of the use upon the potential market. The Court found that the Android platform did not harm the actual or potential markets for Java SE. Google’s Android platform was part of a distinct and more advanced market than Java’s software: smart phone (Android) versus personal desktop computers (Java SE). Oracle would not have been able to enter the advanced smart phone market successfully whether Google did, or did not, copy a part of its Java SE code. Java SE’s primary market was laptops and desktops. Sun’s many prior efforts to move into the mobile phone market had proved unsuccessful. As far back as 2006, prior to Android’s release, Sun’s executives projected declining revenue for mobile phones because of emerging smartphone technology. When Sun’s former CEO was asked directly whether Sun’s failure to build a smartphone was attributable to Google’s development of Android, he answered that it was not. The source of Android’s profitability has much to do with third parties’ (i.e., programmers) investment in creating applications using the Java API. It has less to do with Sun’s investment in creating the Java SE code that was copied. The Court found no reason to believe that the Copyright Act seeks to protect third parties’ investment in learning how to operate a created work. Therefore, this factor weighed in favor of Google and for fair use.
Some takeaways:
- Not all software is created equal—some will get greater protection than others.
- Declaring code is given less copyright infringement protection as compared to implementing code.
- The value of code can change with time. When new code (e.g., API, declaring code, etc.) comes onto the market, it may be valuable or attract users, based on its intrinsic features. But, over time, externalities (e.g., network effects, installed user base, programmer skills and experience) can make it more likely that a fair use defense will be successful.
Reimplementation of an API is given a wide berth. The Court’s opinion allows for wide fair use of APIs and declaring code in other applications. Why? To enable the transfer of long learned skills to a new environment and reuse of old code. Questions remain whether the Court would have allowed fair use: if the declaring code was used in a directly competing product to Java SE, or if the declaring code was from a closed API (Java is an open API; it is published and freely usable under license), or if the declaring code was of a different nature (e.g., perhaps have “creative” choices therein).
RELATED ARTICLES
A Short History of the Fair Use Defense in the Software Industry
Can a Software Developer Copyright the Output of Its Software?