Oracle v. Google: District Court Holds Command Structure of Java API Not Copyrightable | Practical Law

Oracle v. Google: District Court Holds Command Structure of Java API Not Copyrightable | Practical Law

In Oracle America, Inc. v. Google Inc., the US District Court for the Northern District of California, holding that the command structure, sequence and organization (including headers and definitions) of 37 of Oracle's Java API packages were not copyrightable, dismissed Oracle's copyright infringement claim. The court's decision in this case of first impression is noteworthy for highlighting the boundaries between patent and copyright and marking the functionality-based limits of copyright protection for software.

Oracle v. Google: District Court Holds Command Structure of Java API Not Copyrightable

by PLC Intellectual Property & Technology
Published on 05 Jun 2012 • USA (National/Federal)
In Oracle America, Inc. v. Google Inc., the US District Court for the Northern District of California, holding that the command structure, sequence and organization (including headers and definitions) of 37 of Oracle's Java API packages were not copyrightable, dismissed Oracle's copyright infringement claim. The court's decision in this case of first impression is noteworthy for highlighting the boundaries between patent and copyright and marking the functionality-based limits of copyright protection for software.

Key Litigated Issue

The key litigated issue was whether the "declarations" (headers) and organization of headers of the Java API that Google replicated are protected by copyright when considering issues of:
  • Functionality.
  • Software interoperability.
  • The exclusion of names and short phrases from copyright protection.

Background

In August 2005, Google acquired Android, Inc. to develop a smartphone platform. In late 2005, Google decided to use Java language and began discussions with Sun Microsystems, Inc. (Sun) to obtain a license to Java, a popular programming language composed of keywords, symbols and a set of pre-written programs to carry out commands on multiple software platforms. Google and Sun never reached a deal.
Google decided to use Java language to write its own implementations for the Java API functions for use in its Android software for mobile devices. Google released the Android platform in 2007. In 2010, Oracle Corporation acquired Sun, including its interest in Java, and sued Google for infringement of Oracle's Java-related copyrights and patents.
Oracle's copyright claim involved 37 Java API "packages" consisting of organizational folders within the Java API class libraries. All parties agreed that Google's implementing software code, which corresponded to 97% of the lines of code in these API packages, was different from the Java implementations.
However, Google copied the remaining 3% of these 37 packages consisting of the packages' "declarations" or headers, the precise names and organization of which were necessary to replicate the code's functionality and ensure Java's interoperability with Google's Android platform. Oracle claimed that this exact replication infringed its copyrights in Java.

Outcome

In granting Google's Rule 50 motion for judgment as a matter of law dismissing Oracle's copyright claim, the district court broadly surveyed the law of software infringement, looking ultimately to US Court of Appeals for the Ninth Circuit precedent as controlling law. The Ninth Circuit has recognized that non-literal components of a program, including the structure, sequence, organization and user interface, can be protectable by copyright if, and only if, they reflect a substitutable original expression of an idea rather than the sole, or one of only a limited few, ways of communicating the idea itself (see, for example, Johnson Controls, Inc. v. Phoenix Control Systems, Inc.). Citing Johnson Controls and various other federal circuit court decisions, the district court observed that:
  • The structure, sequence and organization of software may still be copyrightable if alternative expressions and configurations can be freely substituted to reproduce the software's functionality.
  • The courts have abandoned these software features as an analytical tool for determining non-literal copyright infringement.
  • Since Johnson Controls and other early software copyright decisions, the courts have more closely followed the directive of Section 102(b) of the Copyright Act that no copyright protection extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, no matter the form of expression (17 U.S.C. § 102(b) (2011)).
  • This shift in focus, and various courts' adoption of the Second Circuit's "abstraction-filtration" test of non-literal copyright infringement (in which non-protectable elements are filtered out of the courts' infringement analysis), reflect a more cautious approach designed to avoid the danger of granting a lengthy copyright monopoly to useful subject matter that should properly be protected, if at all, only by patent.
With this reasoning as background, the district court dismissed Oracle's copyright infringement claim on the following principles of copyright law:
  • The copyright idea-expression merger doctrine directs that, when there is only one or a few ways to express an idea, including a software program instruction, the expression cannot be copyright protected.
  • Under the copyright names doctrine, names and short phrases are also noncopyrightable (see 37 C.F.R. §202.1(a)).
  • Section 102(b) of the Copyright Act precludes the extension of copyright protection to the Java API headers and command structure because they comprise a system or method of operation essential for the software's interoperability.
  • Following Feist Publications, Inc. v. Rural Telephone Services Co., courts do not confer copyright protection to reward the "sweat of the brow" or investment made by the software developer.
In applying the controlling law to the facts, the district court made two separate rulings corresponding to two levels of the Java API's functional organization.

Individual Method Level

A method is a type of command or instruction that once designated or "declared," can be invoked or "called on" elsewhere in the program. One example is a method that receives two numbers as inputs and returns the greater of the two as an output. The Java API incorporates over 6,000 of these software methods. The specifications declaring each of these methods must be identical for purposes of the functionality and interoperability of the Java software.
Oracle showed evidence that the design of its methods was a creative endeavor. However, applying the idea-expression merger doctrine, the court ruled that, under the Copyright Act:
  • The entire world is entitled to use Java's method specifications, no matter how creative or imaginative, because these specifications identify the idea of the method's function rather than solely its expression (17 U.S.C. § 102(b) (2011)).
  • In contrast, the Java API code implementing these methods is copyrightable expression.
  • Google was free to copy the Java method specifications and did not infringe Oracle's copyrights in Java so long as Google did not copy the Java API's line-by-line implementations of these methods.
  • Google's method implementations for Android were different from Java's.
  • Google did not, therefore, violate the Oracle's copyrights in Java at the method level.

Grouping of Methods

The second major copyright question was whether Google was free to group its Android methods in the same way as Java's. The organization of Oracle's Java API consisted of a hierarchy of command levels in the following ascending order:
  • Methods.
  • Classes.
  • Packages.
  • API.
Oracle argued that this overall system of organization is a copyrightable taxonomy. The court rejected this argument, reasoning that:
  • Although Java's organizational structure was creative and original and resembled a taxonomy, its purpose and function was as a command structure, in effect, a system or method of operation that Section 102(b) of the Copyright Act bars from copyright protection.
  • Of the 37 accused API packages, the 3% of line code at issue was also freely replicable under the copyright merger and names doctrine because this code, which Google did copy, consisted only of:
    • non-protectable names and short phrases; and
    • expressions that were irreplaceable for the software's interoperability.
  • Oracle had no copyrights, therefore, in the organization of the Java API packages at issue.
The court parenthetically stated it did not hold that the Java API packages were entirely without copyright protection. Nor did it hold that the structure, sequence and organization of all computer programs may be freely copied. However, the court held, given the functional composition, structure, sequence and organization of the specific Java API code copied by Google, this code was free for all to use under the Copyright Act.

Practical Implications

Although the holding in Oracle America is fact-specific, this case of first impression has some key practical and legal implications. The case signals that Section 102(b) of the Copyright Act and the copyright merger doctrine provide a strong bar to copyright protection for non-substitutable, functional software structures and elements, no matter how original and creative these may be. A software owner should, therefore, consider seeking patent protection for its API's key functional and interoperability-related features.

Court Documents