Oracle Loses to Google Again as Calif. Court Rules Java APIs Have No Copyright Protection

Access practice tools, as well as industry leading news, customizable alerts, dockets, and primary content, including a comprehensive collection of case law, dockets, and regulations. Leverage...

Case Summary: Oracle loses a significant battle in seeking copyright protection for Java software against Google and Android-based mobile phones.

Key Takeaway: The 'structure, sequence, and organization' of Java application programming interface packages does not make Java eligible for copyright protection.

By Tony Dutra  


• Case Summary: Oracle loses a significant battle in seeking copyright protection for Java software against Google and Android-based mobile phones.  

• Key Takeaway: The 'structure, sequence, and organization' of Java application programming interface packages does not make Java eligible for copyright protection.


Oracle's attempt to share in Android mobile phone revenues because of the phones' underlying software code was dealt its most severe blow yet May 31, as the U.S. District Court for the Northern District of California ruled that Java application programming interfaces are not eligible for copyright protection (Oracle America Inc. v. Google Inc., N.D. Cal., No. 3:10-cv-03561-WHA, 5/31/12).

While the focus in the case has been on the potential for huge royalty payments if Oracle were to succeed, Judge William Alsup's order could have implications for intellectual property in software products generally.

Alsup held that Oracle's Java APIs constitute “a utilitarian and functional set of symbols, each to carry out a pre-assigned function.” Their “structure, sequence, and organization”--the basis for Oracle's copyright argument as to code not literally copied by Google--thus is equivalent to “a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted,” the court said.

While the court limited its judgment to the facts of the case, most API packages offered for license follow the same basic rules as to structure, sequence, and organization.

The holding relates to companies like Google Inc. that seek to replicate the APIs. Those who want to use the functions in Java API packages are still subject to licensing requirements, the court said.

Google Offers Java Compatibility.

Sun Microsystems Inc. created the Java “write once, run anywhere” (WORA) platform in 1996. The platform includes multiple components, including both human-readable software code and computer-readable, predefined functions.

The application programming interfaces (APIs) at question in this case are intended to implement the WORA concept. Any programmer can create other software on any device using a variety of operating systems and use the functions available in the APIs. The programmer does not have to know how the API code is written, but the programmer must use specific naming conventions and “header” information to take advantage of the API functions.

Google Inc. negotiated for a license from Sun to use the entire Java platform as Google started to build its Android operating system for mobile phones, but the parties were unable to reach a deal.

Google consequently developed and implemented its own platform with its own code, but also sought to replicate support for over 6,000 functions available in 37 specific Java API “packages.” That is, Google wanted Android application programmers to take advantage of the Java WORA concept. Because Google thus had to use the Java naming conventions and headers, 3 percent of its code had to match the code in the Java APIs that Sun was licensing.

Oracle Corp. acquired Sun in 2010 and renamed the subsidiary Oracle America Inc. Oracle then sued Google in the Northern California district court.

Oracle claimed both copyright and patent infringement by the Android operating system of Java software and functionality.

Alsup split up the case so that a jury would rule on copyright issues first, then patent issues, and finally damages.

In the first part of the case, Alsup told the jury to assume the APIs were copyrighted. Google agreed that it uses the same names and declarations but contended that its line-by-line implementations are different, with the exception of nine lines of code on a “rangeCheck” function, a contention not disputed by Oracle.

The jury on May 7 returned a split verdict, finding that Google infringed by literally copying the rangeCheck code, but it did not answer the key question of whether there was a fair use (89 PTD, 5/9/12).

Then on May 23 the jury determined that Oracle America Inc. failed to prove Google's infringement of patents (RE38,104 and 6,061,520) on the Java operating system by Android-based cell phones(100 PTD, 5/24/12).

Structure, Sequence, Organization at Issue.

In his May 31 decision, Alsup now addressed the underlying question of the extent to which the Java APIs could be copyrighted so as to capture infringement even as to code that Google did not literally copy.

Oracle conceded that Google was free to use the Java programming language and implement the 6,000 individual functions.

“The copyright issue, rather,” the court said, “is whether Google was and remains free to replicate the names, organization of those names, and functionality of 37 out of 166 packages in the Java API, which has sometimes been referred to in this litigation as the 'structure, sequence and organization' of the 37 packages.”

The court therefore focused on the 3 percent of code that replicated the naming and header requirements for Java compatibility in the context of the structure, sequence, and organization (SSO) of the 37 API packages.

The court first noted that names, titles, and short phrases are not copyrightable, according to the Copyright Office's rule specified in 37 C.F.R. §202.1(a) and Ninth Circuit law, in Sega Enterprises Ltd. v. Accolade Inc., 977 F.2d 1510, 1524 n.7, 24 USPQ2d 1561 (9th Cir. 1992).

The court then addressed the idea of SSO for owners of copyrights generally:

This phrase--structure, sequence and organization--does not appear in the Act or its legislative history. It is a phrase that crept into use to describe a residual property right where literal copying was absent. A question then arises whether the copyright holder is more appropriately asserting an exclusive right to a functional system, process, or method of operation that belongs in the realm of patents, not copyrights.  


'Methods of Operation' Distinguished.

The court quoted extensively from the 1879 U.S. Supreme Court decision distinguishing “methods” from creative works and establishing the “merger doctrine” in Baker v. Seldon, 101 U.S. 99 (1879). “It is true that Baker is aged but it is not passé,” the court said.

Congress codified “a Baker-like limitation on the scope of copyright protection” in 1976, according to the court, by excluding “method of operation” from copyrightability in 35 U.S.C. §102(b). And the National Commission on New Technological Uses of Copyrighted Works (CONTU) reconciled the copyrightability of a “computer program” with the preclusion of protection for methods of operation under Section 102(b).

The court further quoted the CONTU commission's application of the merger doctrine to computer program copyrightability: “In the computer context this means that when specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to an infringement.”

Review of Case Law on Point.

Next, the court reviewed the case law on SSO copyrightablity.

It essentially discounted the holding in the case where the phrase originated, Whelan Associates Inc. v. Jaslow Dental Laboratory Inc., 797 F.2d 1222, 230 USPQ 481 (3d Cir. 1986).

Whelan has been criticized by many, the court said, including the Ninth Circuit, which has followed an approach more along the lines of the Second Circuit's “abstract-filtration-comparison” test in Computer Associates International Inc. v. Altai, 982 F.2d 693, 23 USPQ2d 1241 (2d Cir. 1992):

• Dissect the copyrighted program into its structural components.

• Filter out structures that are not copyrightable because they are “dictated by efficiency,” “dictated by external factors” such as compatibility or standard practices, or “already found in the public domain.”

• Compare the code of the programs that remain after the filtration process.


The court referenced the Supreme Court's holding in Feist Publications Inc. v. Rural Telephone Services Co., 499 U.S. 340, 18 USPQ2d 1275 (U.S. 1991), primarily to note that “copyright in a factual compilation is thin,” with competing works limited only by a prohibition against using “the same selection and arrangement” of the compiled facts.

Sweeping Conclusions Limited to Java APIs?

Using the precedents, the court arrived at a series of conclusions:

• The more than 6,000 functions addressable as subroutines in the API packages are methods of operation, and “anyone is free under the Copyright Act to write his or her own method to carry out exactly the same function or specification of any and all methods used in the Java API.”

• There is only one way to carry out the individual methods under Java rules. The header information in the 3 percent of Android's code that replicates Java headers thus is not a copyright violation because “the merger doctrine bars anyone from claiming exclusive copyright ownership of that expression.”

• The use of identical function names is not a violation because “names and short phrases cannot be copyrighted.”

• Oracle's organization of the 6,000 functions into 600 classes and then 37 packages is a copyrightable classification scheme, but in the context of Google's use of the same classes and packages, “it is also a command structure for a system or method of operation of the application programming interface.”


The court made clear that SSO copyrightability depends on the facts and circumstances of each case. It suggested that its judgment was thus limited to these specific facts:

This order does not hold that Java API packages are free for all to use without license. It does not hold that the structure, sequence and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act.  


The court consequently dismissed Oracle's claim based on the SSO argument.


The current status of the case is that Google has escaped infringement liability on all but the nine lines of code making up the rangeCheck function.

In the current opinion, Alsup referred to that infringement as “innocuous and overblown by Oracle” and “an innocent and inconsequential instance of copying in the context of a massive number of lines of code.”

Alsup chose not to proceed to the third phase of the jury trial. “The third phase would have dealt with damages but was obviated by stipulation and verdicts,” he said.

Google is, however, still liable for statutory damages, but Oracle does not contest that, once Google identified the innocent copying, it deleted the offending nine lines of code from Android.

The court did not comment on how it would resolve the statutory damages question.

Oracle is represented by David Boies of Boies, Schiller, Flexner, Armonk, N.Y. Google is represented by Donald F. Zimmer Jr. of King & Spalding, San Francisco.

By Tony Dutra  

Opinion at

Request Intellectual Property on Bloomberg Law