Did Oracle Overlook the Smoking Gun in its Case against Google?

The decisions in the recent intellectual property lawsuit of Oracle v. Google [i] have drawn the attention of software developers and intellectual property lawyers alike. As we read about the verdict’s potential to shape future copyright case law, our team here at Zeidman Consulting also wondered whether all the facts in the copyright portion of the case had been uncovered. We decided to pursue these questions using the advanced tools for detecting copyright infringement created by our sister company, Software Analysis and Forensic Engineering (SAFE Corporation) and the thorough processes that we have developed. What started off as simple curiosity turned into an interesting research and analysis project to determine if we could uncover evidence of copyright infringement that Oracle’s experts had missed. Our two-week effort turned up some very surprising results–significant amounts of apparently copied code that was not brought up at the trial.

The Oracle v. Google Lawsuit

The lawsuit began with Oracle accusing Google’s mobile operating system, Android, of violating both patents and copyrights that Oracle holds based on its Java programming language. Specifically Oracle initially accused Google of infringing seven of Oracle’s patents [ii] though five were later thrown out [iii], and also accused Google of copying 37 Java language application program interfaces (APIs) [iv] and other Java source code into Android source code. This article focuses on the copyright portion of the case, leaving the patent infringement claims to a future article (if we have the time).

Oracle claimed that by violating Java copyrights Android reaped the benefits of the large Java programming community as well as a faster time to market. Google’s own chief Android architect Joshua Bloch, who had worked at Sun for eight years before moving to Google, admitted that Google probably copied Java source code. When a company copies software functionality from source code and wants to avoid copyright infringement, it must implement a formal development process called a clean room that separates the developers who have access to the original source code from those who are attempting to duplicate its functionality independently. Google claimed that a clean room was implemented, and Google CEO Larry Page claimed that company would take any copying or pasting of code “very seriously,” but Bloch said that Google had him work on Android code development despite having also worked on Java while at Sun [v].

Google countered that APIs are not creative and any similarity in the APIs is necessitated for the sake of conciseness and interoperability within the industry. Google also argued that the direct source code copying that was found was so small and easy to reproduce that it added “no or little value to Android.” The jury and judge essentially agreed with Google. The verdict absolved Google of any wrongdoing regarding the patent infringement allegations but was more nuanced when addressing the copyright violations. Judge William Alsup initially instructed the jury to consider any API copying to be a violation of copyright [vi] and the jury, under these directions, returned a guilty verdict regarding Google’s violation of Oracle’s Java copyrights. Judge Alsup then took the bite out of the verdict when he ruled that the structure, sequence, and organization of the Java APIs were not copyrightable. In the final ruling the only element Google was found guilty of copying was a nine line method named RangeCheck(). Our task was to analyze the code and determine if this method really comprised the only implementation of non-API source code that matched between Android and Java.

Our Challenge

The Java and Android projects are very large code bases. The version of Java at issue during the trial, and the version we analyzed, was J2SE 5.0 [vii]. It contains 127 megabytes of source code in 12,262 files [viii]. The version of Android at issue in the case and in our analysis was Android 2.2, also known as Frozen Yogurt or Froyo, and it contains 127 megabytes of source code in 17,062 files [ix].

The sheer number of files is an enormous amount of information for a human to analyze, and the dataset becomes truly enormous when considering that a thorough analysis involves comparing each file from the Java code base to each file in the Android code base. This amounts to 209,214,244 comparisons and becomes impossible to completely analyze manually for anything short of an army of software developers. Thorough analysis in situations like this is exactly what the CodeSuite tool, designed by our sister company SAFE Corporation, is intended for. One of the tools within CodeSuite is CodeMatch, and it is designed to compare thousands of source code files in multiple directories and determine which files are the most highly correlated, or most similar [x]. This automates the comparison process and allows the source code examiner to very quickly narrow down the files of interest. The CodeMatch algorithm recognizes statements, comments, identifiers, and instruction sequences in all major programming languages, including Java, and compares these programming constructs in an asynchronous fashion to identify similarity between source code files. The output of CodeMatch is a database which contains the correlation score of file pairs that fall within certain user defined parameters. Following our process for finding copyright infringement, the database is iteratively filtered using the CodeSuite tool, and false positives are ruled out, exposing any source code files with matching source code [xi].

History

To gain some perspective on these two code bases a brief overview of their histories may be useful. Java was first developed at Sun Microsystems in the early 1990s and released to the public in 1995. It is a hardware-independent, object-oriented programming language that runs via a virtual machine supporting its “write once, run anywhere” promise. The majority of Java is licensed under various open source licenses, such as the GPL (general public license) and the LGPL (lesser general public license) [xii]. Sun was purchased by Oracle in January 2010, which transferred all Java rights to Oracle. The Java source code download was trivial and hosted by Oracle on a webpage titled Java SE 5.0 Downloads [xiii]. We chose the Linux version of Java 2SE 5.0 as Android is based on Linux.

Android source code was initially developed by Android Inc., a company purchased by Google in 2005. The first version of Android was released in 2007. It is a Linux-based operating system for mobile computing devices. It incorporates open source licensing under the Apache License and the GPL [xiv]. The Android interface and applications created for Android are written in a customized version of Java, which is what caused Oracle to take exception. We downloaded the Android source code from an Android forum hosted by Google [xv].

Our Findings

Because of the large number of files, we ran the MP version of CodeMatch that runs on multiple processes on a multicore computer. We chose to run 10 processes on an 8-core machine, and it took just under 34 hours to complete. We took the results and performed our standard filtering to eliminate correlation due to reasons other than copying: common algorithms, automatically generated code, common identifier names, common author, and third party code.

Our results revealed at least nine file pairs exhibiting code showing significant literal copying of this code. Eight of these nine file pairs have the same name in each code base, while one file pair has nearly the same name. These files and their paths are listed below.

Java files:

jdk1.5.0\src\com\sun\jmx\snmp\IPAcl\ParseException.java
jdk1.5.0\src\com\sun\jmx\snmp\IPAcl\TokenMgrError.java
jdk1.5.0\src\com\sun\jmx\snmp\IPAcl\SimpleNode.java
jdk1.5.0\src\com\sun\jmx\snmp\IPAcl\JJTParserState.java
jdk1.5.0\src\java\util\concurrent\ArrayBlockingQueue.java
jdk1.5.0\src\java\util\concurrent\AbstractExecutorService.java
jdk1.5.0\src\java\util\concurrent\ConcurrentHashMap.java
jdk1.5.0\src\java\util\concurrent\LinkedBlockingQueue.java
jdk1.5.0\src\java\util\concurrent\PriorityBlockingQueue.java

Android files:

android-2.2-froyo\org\apache\james\mime4j\field\address\parser\ParseException.java
android-2.2-froyo\org\apache\james\mime4j\field\address\parser\TokenMgrError.java
android-2.2-froyo\org\apache\james\mime4j\field\address\parser\SimpleNode.java
android-2.2-froyo\org\apache\james\mime4j\field\address\parser\JJTAddressListParserState
android-2.2-froyo\java\util\concurrent\ArrayBlockingQueue.java
android-2.2-froyo\java\util\concurrent\AbstractExecutorService.java
android-2.2-froyo\java\util\concurrent\ConcurrentHashMap.java
android-2.2-froyo\java\util\concurrent\LinkedBlockingQueue.java
android-2.2-froyo\java\util\concurrent\PriorityBlockingQueue.java.

Matching functional code

In the Java version of the file ParseException.java, the method public String getMessage()is almost identical to the method of the same name in the Android version of the file ParseException.java. The following snippet from the method shows an example of this identical code.

String retval = “Encountered \””;

Token tok = currentToken.next;

for (int i = 0; i < maxSize; i++) {

if (i != 0) retval += ” “;

if (tok.kind == 0) {

retval += tokenImage[0];

break;

}

retval += add_escapes(tok.image);

tok = tok.next;

}

This kind of identical functional code between Java and Android is also seen in the file TokenMgrError.java. The following is a code snippet from an identical switch() statement within the method protected static final String addEscapes(String str).

default:

if ((ch = str.charAt(i)) < 0x20 || ch > 0x7e) {

String s = “0000” + Integer.toString(ch, 16);

retval.append(“\\u” + s.substring(s.length() – 4, s.length()));

} else {

retval.append(ch);

}

continue;

Matching Comments

The similarities between the files grew even more stark as we continued analyzing the files. Another similarity between the code bases were identical comments and misspellings within those comments, which in our experience is a sure sign of copying. For example, a snippet of a comment in ParseException.java shows an identical comment with the word ‘following’ misspelled in both files:

* this object has been created due to a parse error, the token
* followng this token will (therefore) be the first error token.

A comment snippet taken from TokenMgrError.java shows an identical comment and the words ‘lexical’ and ‘occurred’ misspelled in both Java and Android versions.

*    EOFSeen     : indicates if EOF caused the lexicl error
*    curLexState : lexical state in which this error occurred

Matching Whitespace

Another sign pointing to copying is that both ParseException.java and TokenMgrError.java have identical whitespace sequences including spaces, tabs, and new lines.

Other Clues

In addition to matching code, whitespace, comments, and misspellings, several of the Android files contain the following comment inserted among code that is otherwise identical to the Java file of the same name. An example follows as found in the Android version of the file ArrayBlockingQueue.java:

// BEGIN android-note
// removed link to collections framework docs
// END android-note

Another piece of evidence that points to copying between Java and Android is that several of these nine file pairs seem to have been written by the same person because an identical comment stating the author is found in several of the file pairs. The following comment appears in both Java and Android versions of the file ConcurrentHashMap.java:

* @since 1.5
* @author Doug Lea
* @param <K> the type of keys maintained by this map
* @param <V> the type of mapped values

Another comment appears in several of the Java files but not in the Android versions of the same file. The following comment is shown as it appears in the Java version of the file LinkedBlockingQueue.java:

* <p>This class is a member of the
* <a href=”{@docRoot}/../guide/collections/index.html”>
* Java Collections Framework</a>.

Changed Copyright Notices

Perhaps most interesting of all is that the two sets of files have comments showing different copyright notices and claim that the code is subject to different licenses. All nine of the files found in the Java source code have the same copyright notice, a short comment at the beginning of each file that reads:

* Copyright 2004 Sun Microsystems, Inc. All rights reserved.
* SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.

The Android files have a few different comment headers, only some of which are copyright notices. They include:

*  Copyright 2004 the mime4j project
*
*  Licensed under the Apache License, Version 2.0 (the “License”);

and

/* Generated By:JJTree: Do not edit this line. SimpleNode.java */

and

/* Generated By:JJTree: Do not edit this line. /Users/jason/Projects/apache-mime4j-0.3/target/generated-sources/jjtree/org/apache/james/mime4j/field/address/parser/JJTAddressListParserState.java */

and

* Written by Doug Lea with assistance from members of JCP JSR-166
* Expert Group and released to the public domain, as explained at
* http://creativecommons.org/licenses/publicdomain

The Java versions of the files ParseException.java and TokenMgrError.java contain the Sun copyright as shown above, but the Android versions carry the following copyright and license notice:

*  Copyright 2004 the mime4j project
*
*  Licensed under the Apache License, Version 2.0 (the “License”);

The Apache James Mime4j project is an open source project developed by the Apache James team that “delivers a rich set of open source modules and libraries, written in Java, related to Internet mail communication which build into an advanced enterprise mail server [xvi].” Based on this copyright notice appearing in Android’s source code and software developer comments on the internet [xvii], it appears that Google is using the Mime4j project in Android’s email client. In addition, the licenses conflict as the Java file uses the GNU General Public License and the Android files use the Apache License. Both copyrights are dated 2004, but the earliest release of software for the open source Mime4j project is actually May 3, 2005 [xviii]. While we can’t be sure that there was no development before this date, and we can’t determine the date that Sun began development, obviously only one of these copyright notices can be correct and the code can be covered by only one license.

Moving on to the code with Doug Lea listed as the author, the files AbstractExecutorService.java, ArrayBlockingQueue.java, ConcurrentHashMap.java, LinkedBlockingQueue.java, and PriorityBlockingQueue.java, we found that Doug Lea used to serve on the Executive Committee of the JCP (Java Community Process). He also chaired JSR 166, which was a Java Specification Request group under the JCP, andthis position is referenced along with his name in the above authorship comment. In addition Doug Lea announced his intention not to run for that position again on October 22, 2010 [xix], only a couple months after Oracle served Google with its infringement lawsuit [xx].

Finally, in reference to the Android files without any copyright comments, the files SimpleNode.java and JJTParserState.java, if a file has a copyright notice it is not acceptable to merely remove that notice and use the material. This may state the obvious, but a copyright remains in effect whether the notice is shown on the material or not.

These files that are all almost identical cannot be legally distributed with different copyright notices or licenses unless the copyright was transferred from one party to another, and we find no evidence that this was the case. One release must be a violation of the other’s valid copyright—one must have been copied and the other the original. Similarly, we are unaware of a way that software can be released under one license and later released under a different license.

Conclusion

In the copyright portion of the case Oracle claimed that Google had copied 37of Oracle’s Java APIs, eight decompiled files, and nine lines of source code [xxi]. In his ruling the judge dismissed the APIs and decompiled files as evidence of copying when he wrote, “So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API [xxii]. The judge found the nine lines of identical code in the RangeCheck()function to be, “so innocuous and overblown by Oracle that the actual facts, as found herein by the judge, will be set forth below for the benefit of the court of appeals22.” In the judge’s opinion Oracle did not posses compelling enough evidence that Google had copied Java when creating Android and the little copying that was discovered was found to be insignificant. In our opinion that evidence would have become much more compelling had Oracle discovered the source code similarities we have uncovered.

We extensively compared 12,262 Java files to 17,062 Android files using CodeMatch and found 9 files in each of the code bases that matched 9 files in the other code base almost entirely. In fact, 3,110 lines in these files were identical. These files had different copyright notices and claimed to be available through different licenses. We can determine that only one entity owned the copyright and once released through one license they could not be subsequently released through a different license. Therefore one set of files has the correct copyright license and the other does not. One set of files are the original ones and the other set of files are copies.

Did Oracle lose its case because it missed these examples of copying? Quite possibly. Not knowing all of the details of the case, there could be issues that we’re not aware of. However, from the facts we have found, it appears that Oracle did in fact blow it and missed 3,110 smoking guns.

To download the correlated Java files and Android files that were found and to see the reports that were generated by CodeMatch, go to http://www.safe-corp.biz/Oracle-Google.

Acknowledgements

We would like to acknowledge Steve Wu of Cooke Kobrick & Wu LLP for his help locating trial documents for this case.

---

Endnotes

[i] Oracle v. Google

[ii] http://news.cnet.com/8301-30684_3-20013546-265.html

[iii] http://news.cnet.com/8301-1001_3-57417144-92/android-java-and-the-tech-behind-oracle-v-google-faq

[iv] http://news.cnet.com/8301-1035_3-57418976-94/oracle-and-google-continue-sparring-over-apis

[v] http://www.theverge.com/2012/4/19/2961128/google-chief-java-architect-likely-i-copied-sun-code-in-android

[vi] http://www.economist.com/blogs/babbage/2012/06/oracle-v-google

[vii] http://opensource.com/law/12/6/oracle-v-google-and-api-copyrightability

[viii] http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase5-419410.html#jdk-1.5.0-oth-JPR

[ix] http://code.google.com/p/android/issues/detail?id=979

[x] http://www.safe-corp.biz/CodeMatch_algorithms.htm

[xi] http://www.safe-corp.biz/company_process.htm

[xii] http://en.wikipedia.org/wiki/Java_(programming_language)

[xiii] http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase5-419410.html#jdk-1.5.0-oth-JPR

[xiv] http://en.wikipedia.org/wiki/Android_(operating_system)

[xv] http://code.google.com/p/android/issues/detail?id=979

[xvi] http://james.apache.org/

[xvii] http://therning.org/niklas/2009/03/mime4j-used-by-androids-e-mail-client/

[xviii] https://github.com/apache/james-mime4j/commits/trunk?page=21

[xix] http://en.wikipedia.org/wiki/Doug_Lea

[xx] http://news.cnet.com/8301-30684_3-20013546-265.html

[xxi] http://www.wired.com/wiredenterprise/2012/05/oracle-v-google-no-steak-only-parsley/

[xxii] http://www.courthousenews.com/2012/06/01/Gcopyright.pdf