Discuss technical issues, software, and hardware.
Don't attack people!
Don't respond to the Anti-Apple Thread Trolls!
PLEASE IGNORE THEM!!!
Apple Ping!
If you want on or off the Mac Ping List, Freepmail me.
Posted on 01/22/2011 12:44:17 PM PST by Swordmaker
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 PolicyNodeImpl.java -- 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 PolicyNodeImpl.java source code file has the following header:
/*
* @(#)PolicyNodeImpl.java 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 jdk-1_5_0-src-jrl.zip file, PolicyNodeImpl.java 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 reddit.com. 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 PolicyNodeImpl.java 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, PolicyNodeImpl.java (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 PolicyNodeImpl.java 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.
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.
If you want on or off the Mac Ping List, Freepmail me.
How hard is it to do a “search and replace” before you compile somebody else’s code?
However, there is also evidence that the code was uploaded into the repository by mistake, and none of this code is actually used in Android:
The dog ate my source code tree.
The Oracle CEO doesn't differ much politically ...
The article you listed does a lot of hedging. It says they were clearly uploaded accidentally. As a non-techie, I have trouble understanding how it’s possible to determine it was an accidental upload.
Further in the article, they state the files aren’t used by Android and PROBABLY didn’t ship with Android devices. Again, I’m a non-techie, but I don’t know how someone can determine that compiled code did not use certain codes that were in the repository. In both instances, there may be a viable explanation.
Finally, it says from a legal perspective, it may not matter. The code was not licensed by Google, was in the source code repository, and modified without Oracle’s permission. Whether the code was actually used may be a moot point.
If Oracle can win in court and see a big payday, they’ll definitely reject the “no harm, no foul” defense.
Am I reading this article correctly? There are portions of code that actually, when copied, the “team” didn’t even removed copyright warnings and other obvious tags?
Unbelievable....
There are many contributors to Android, and one is SONiVOX.
When they put their code into the Android code repository, they included a file called MMAPI.zip. This zip file contained stuff meant to be used to test SONiVOX’s contribution. Among this was some Sun (now Oracle) code.
Being what it is, when Android is compiled, of course stuff like that doesn’t actually end up in the code. It’s code used to test Android, not part of Android itself.
It’s also not super double secret proprietary code since it was also publicly published by Sun, but under restricted distribution. The most I can see is an order to remove the offending code from the code repository if it hasn’t already been (no, not from Android itself because it’s not there). It’s hard to claim monetary damage for that code.
All I see here is a mistake. The developers likely used the code legally for their own purposes of testing their Java stuff, then uploaded their testing code into the Android code repository, which they forgot included the Sun code.
Where or not the code was used in Android is a huge point. If it was, they could get an injunction and stop Android from shipping, until Google pays them billions in damages.
If it was just sitting in the code repository, Google could argue that Oracle did not experience significant harm.
Instead of letting Oracle by Sun, Google should have bought Sun Microsystems. Huge miscalculation by Schmidt...me thinks this is why Schmidt is getting the boot upstairs.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.