Friday, January 21, 2011

New evidence supports Oracle's case against Google

Google faces a steep challenge in its defense against Oracle's lawsuit over seven Java patents and some copyrighted material. More than five months after Oracle's complaint, Google appears unable to countersue Oracle over patent infringement, while evidence is mounting that different components of the Android mobile operating system may indeed violate copyrights of Sun Microsystems, a company Oracle acquired a year ago.

I have discovered additional material that Oracle might present to the court as examples of copyright-infringing material in the Android codebase:

  • Two months ago I took a close look at Exhibit J to Oracle's amended complaint, which contained a synopsis of source code shipped by Google and Sun's original Java code. I have since found six more files in an adjacent directory that show the same pattern of direct copying. All of them were apparently derived with the help of a decompiler tool. Those files form part of Froyo (Android version 2.2) as well as Gingerbread (version 2.3), unlike the file presented by Oracle.

  • In addition, I have identified 37 files marked as "PROPRIETARY/CONFIDENTIAL" by Sun and a copyright notice file that says: "DO NOT DISTRIBUTE!" Those files appear to relate to the Mobile Media API of the Sun Java Wireless Toolkit. Unless Google obtained a license to that code (which is unlikely given the content and tone of those warnings), this constitutes another breach.

Interestingly, the original version of -- a redacted version of which is shown in Exhibit J to Oracle's amended complaint -- also had a "PROPRIETARY/CONFIDENTIAL" designation at the relevant time (Java version 5.0). In version 6.0 the file has a GPL 2 header. Google said in its formal response that Oracle had omitted "copyright headers". That is correct, but now that I have seen two versions of the original file, I don't think that the missing parts are favorable to Google. Actually, the opposite is true. Whether under a proprietary license or the GPL, the related code could not be legally relicensed under the Apache license by anyone other than the right holder (Oracle/Sun).

Detailed documentation available as a set of PDF files

I have documented my findings in nine PDF files with an aggregate volume of 46 pages.

Each of the first seven files (1, 2, 3, 4, 5, 6, 7) compares the decompiled version of a file from Java 2 Standard Edition (J2SE) version 5.0 to the corresponding file in the Android source code tree.

In those synopsis files, lines with differences (in content, not just layout) are marked up in red. The amount of differences is minuscule. In most of the files, those differences are limited to comments or to a few lines having a different position without any impact on program logic. In OwnerImpl, a small code segment has a slightly enhanced logic in the Android version (for which there could be different explanations), and in PermissionImpl, a small hash code function is outcommented (and therefore inactive) in the Android version. But for most of the code, there's no difference whatsoever between the two columns.

The Android versions of those files are in a directory adjacent to the one containing the PolicyNodeImpl file presented by Oracle as Exhibit J to its amended complaint. I have also produced a synopsis for PolicyNodeImpl (file 6), and in "8 PolicyNodeImpl source copyright notices.pdf" you can find the two different copyright headers Oracle/Sun used for that file. Like I said, there is no way that file could ever have been relicensed under Apache.

In the file named "9 SJWT copyright notices.pdf" I have listed the copyright notices found in 38 other files distributed as part of Android (a dedicated copyright notice file plus notices found at the start of 37 source code files). Those warn explicitly against redistribution.

Oracle does not need to manufacture evidence

In light of the evidence I found (and which anyone can verify by downloading the original material), I believe some commentators grossly overrated Google's defense when they interpreted it as accusing Oracle of manipulating or manufacturing evidence. In paragraph 40 of its answer to Oracle's amended complaint, Google only claimed the following:

"Google further denies that the document attached to Oracle’s Amended Complaint as Exhibit J contains a true and correct copy of a class file from either Android or 'Oracle America’s Java.' Google states further that Oracle has redacted or deleted from the materials shown in Exhibit J both expressive material and copyright headers that appear in the actual materials, which are significant elements and features of the files in question."

At first sight, this may suggest that Oracle made edits to the documents that misrepresented the situation to Google's disadvantage. Much to the contrary, things will only get worse for Google when the court takes a look at the complete files. Google's Dalvik files were made available under the Apache license, but the original source code file has the following header:

* @(#) 1.10 03/12/19
* Copyright 2004 Sun Microsystems, Inc. All rights reserved.
* SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.

If you want to take a look at it, you can find it in version 1.5 of the Java Development Kit (the internal version number 1.5 corresponds to the external Java version number 5.0, which I previously stated). Within the file, is located in the /j2se/src/share/classes/sun/security/provider/certpath directory. No matter what Google says, that copyright header is anything but a permission to relicense the file under the Apache Software License. Even if one claimed that Oracle/Sun later made the file available under the GPL (for which I haven't found any conclusive evidence), that wouldn't allow such a license change either. Only an extremely permissive license would have had that effect.

It seems to me that Oracle has not even presented the tip of the iceberg in its amended complaint. The discovery process could be very fruitful for Oracle, and may become dreadful for Google.

The source code files in the "acl" directory

After Oracle amended its complaint, many people were trying to figure out whether that Exhibit J indicated an infringement. The structural/logical similarities between the two columns of that table were striking. In my analysis I pointed out that Sun's original source code was structured according to professional standards while the Android version of those files looked like an attempt to conceal an infringement.

From the beginning, some others believed that the Android developers had utilized a decompiler. I read about that theory on a couple of different websites, especially When I looked into this case again, I downloaded a Java decompiler named JAD. And when I decompiled PolicyNodeImpl.class from J2SE 5.0, the result was pretty much the same source code as Android's code (which Oracle presented in its Exhibit J). My "PolicyNodeImpl synopsis" document shows the similarities.

I then performed the same comparison for six other files in the adjacent "acl" subdirectory. The Android versions of those files are available on the Web (Android version 2.2 aka "Froyo", Android version 3.0 aka "Gingerbread"). My synopsis PDF files document the same problem: Android contains, under the Apache license, code that is essentially just decompiled code of Oracle/Sun software that was never licensed to Apache.

Interestingly, (the file used by Oracle in its Exhibit J) appears not to have been part of the most recent Android distributions, while the six other files I identified are part of the two most recent and presently most relevant distributions: Froyo (Android 2.2) and Gingerbread (Android 2.3). That makes those files even more important than the one Oracle presented.

The Apache Software Foundation disowned after Google suggested that someone other than Google might have committed the alleged copyright infringement. I am sure the ASF will also disown the additional files I presented here because they never appeared as part of the Apache Harmony project.

A copyright infringement is a copyright infringement, and if Google publishes code under a license for which it was never made available by its rightful owner, that's a serious legal problem.

Looking around

After the findings I just described, I checked on some other parts of the Android source code tree. That's where I discovered a ZIP archive anyone can (at least at the time I am writing this) download here. When I saw a Sun Microsystems copyright notice, I ran a text search on the contents of all of the contained files for that company name, and found those 37 source files with a Sun Microsoystems copyright header.

Some might argue that this proves a claim repeatedly made by proprietary software makers: open source is at a greater risk because it can be scrutinized so easily. But the open source argument is that (let me derive this from a famous quote) "to enough eyeballs, all infringements are shallow": audits can be crowdsourced.

Both views are true, and the problem is that those looking for violations of their rights typically have a much stronger motivation to embark on a search than those trying to protect their projects. People who seek to contribute to projects tend to be more interested in development than in copyright and patent clearance. That's understandable, but intellectual property issues can have wide-ranging implications if they aren't identified early enough.

If you are or become aware of copyright or patent issues that expose developers and users of open source software (Android or other key projects) to a major risk, please talk to the developers so they resolve any such issues at their earliest opportunity -- such as before a behemoth like Oracle files a suit.

In case you believe I can be of help by drawing attention to such problems on this blog, please don't hesitate to fill out the contact form. I promise confidential treatment: you won't be named unless you insist to receive credit for your findings.

[Update] I have done a follow-up post, "Android device makers distribute Oracle code online (Motorola, Samsung, LG)".

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.

Share with other professionals via LinkedIn: