In the previous post I talked about 43 files that Oracle might present to the court as examples of copyright-infringing material in the Android codebase, in addition to the example shown in Exhibit J to its amended complaint against Google.
Six of those files were relicensed -- apparently without permission -- under the Apache license, which allows redistribution to an unlimited number of users and its integration (with or without modifications) into other open source projects (provided they are under a compatible license) or even into closed source (proprietary) products.
Relicensing someone else's software on open source terms is not a harmless sport. Third parties may directly or indirectly obtain those files and, in good-faith reliance upon their license headers, use and distribute such software. If the right holder never consented to the terms of that new license, this can result in liability problems. The relicensed code can pop up in any number of places and spread further, and it may not be easy to put the genie back into the bottle once it's been published on the Internet.
Therefore, it's no surprise that the Oracle/Sun code I found in the repositories of Android versions 2.2 (Froyo) and 2.3 (Gingerbread) has already made its way into various open source code distributions of different Android device makers, including at least Motorola, LG, and Samsung. I'm sure those companies didn't intend to infringe Oracle's rights. They probably relied on the presumed legality of the Android codebase.
I haven't been able to check whether the relevant code is also shipped with the devices themselves. However, the online publication of those files is a risk in and of itself, for the reasons I explained. And since other vendors such as Dell and HTC decided to omit those files from their online source distributions, it could be that some of those very sophisticated companies who published the sources did so because they knew they built that code into the related products, or at least weren't absolutely certain that they didn't. It could, of course, be simply an oversight, although that would not make the distribution of those Oracle/Sun files any less copyright-infringing.
Trying to find out whether Oracle or Google is right
The key thing to understand is that a copyright infringement is a copyright infringement, and illegal relicensing can raise potentially serious issues.
There's an important dispute going on between Oracle and Google. I wanted to shed some light on the question of which of the two companies is more likely to have a point as far as Oracle's copyright infringement allegations are concerned: Is Oracle's complaint right (at least in part), or is Google's defense right?
If you had to bet money on whether or not there's an issue, I'm sure you'd be more inclined to bet it on Oracle after you saw the 43 files I showed than before (when Oracle had presented only one such file to the court).
How big the issue may be in economic terms, or how easy it may be in a technical way to avoid future infringement, are interesting but follow-on questions that I didn't address in any way. On the patent side of the dispute, I articulated my view in a recent post. Since copyright has a narrower scope of protection, it's obvious that patents can have far more of an impact. Software copyright infringements are, however, more embarrassing because they usually require an intention or a fair amount of negligence. As far as the credibility of the parties is concerned, I wouldn't underestimate the copyright part of the case.
Examples of Oracle/Sun code in source availability packages published by major Android device makers
There are many devices out there, and I guess one could find many more than the ones I list here, which are just meant to show that the availability of that code is by far not limited to the Android website.
Motorola offers some source code releases that contain both the decompiled security-related files I presented and the files marked as "PROPRIETARY/CONFIDENTIAL". I found them in the packages containing the source code of the Droid X, Droid 2 Global, and Droid Pro. If you follow those links, you can either download the entire package ("Download Release") or download specific packages. The decompiled files are in the dalvik.tar.gz package, and the "PROPRIETARY/CONFIDENTIAL" files are in the external_sonivox.tar.gz package.
LG has the decompiled "acl" files in at least a couple of source availability packages. On the LG source code page you can search for particular devices. If you search for VS740 as the model number, you get a certain LG Ally model, and for LG509TN a certain LG Optimus T model.
Samsung offers source availability packages on opensource.samsung.com. In the "mobile" section you can find all of the source releases for Samsung's Android-based phones and tablets. For some examples of source code packages containing the decompiled "acl" files, see the GT-P1000_OpenSource.zip file or GT-P1000_OpenSource_Update1.zip file (Galaxy Tab), SCH_R880_OpenSource.zip file (Samsung Acclaim), GT-I5800_OpenSource.tar file (Galaxy 3), SCH-I500_OpenSource.zip file (Samsung Fascinate), or the SPH-D700_OpenSource.zip file (Samsung Epic).
Just like their counterparts on the Android code website, the make files in those product-specific source code packages may not integrate any Oracle/Sun files into their production build by default. That still doesn't rule out the possibility of them being used in closed-source components, which are commonly added by vendors on top of the open source Android codebase. It also doesn't rule out the possibility of those files being used by device makers for internal purposes such as testing. Whether they just published the files on the Internet or use them in internal and/or external ways, they need a license from the actual right holder.
A couple of bloggers just rebutted the strawmen they set up
A couple of tech bloggers didn't agree with my disclosures. Since everything I stated in my previous post was accurate, they set up strawmen and tore them down. They tried to prove me wrong on something I never said.
I never claimed that every Android device out there contains the code I identified. You can read what I actually wrote. The way I presented my findings, I didn't even claim that a single device contained that code. I just referred to the Android software, and if the code offered on android.kernel.git.org doesn't constitute Android, what else does?
And how about those source availability packages for Android devices I just mentioned? It's problematic for those bloggers who dismissed my analysis that they didn't even talk about them. They just claimed that the related code never made it into any device. In order to prove that (which still wouldn't contradict the things I actually said), they would have to perform clearance for each and every Android device out there. Maybe they thought they had so much knowledge they didn't have to check the facts.
Since they have created some confusion, I'd like to quote some of what they said and rebut it while we're on the subject.
Ed Burnette's emotional and inaccurate post
ZDNet and Ars Technica generally have a high quality standard. However, I feel forced to contradict some of what they wrote on Friday about this Android copyright issue.
One of ZDNet's bloggers, Ed Burnette, a self-described "expert developer", wrote a post with a sensational but grossly inaccurate title: "Oops: No copied Java code or weapons of mass destruction found in Android"
Let's forget the WMD reference (which is ridiculous hyperbole). The claim that "no copied Java code [is] found in Android" makes no sense. The code on android.kernel.git.org is Android. Same with the source availability packages of the Android devices I mentioned.
He bashes Engadget for saying that Google "shipped" that code. As Engadget's Nilay Patel (a copyright lawyer by training) accurately noted, "once you've created or distributed an unauthorized copy, you're liable for infringement." Online distribution is an electronic form of shipping software. I didn't use the word "ship" on my own blog, but I think that Engadget was criticized unfairly because the term is appropriate.
By claiming that I'm not a software developer "even though [I play] one on TV" the author -- a self-described "expert developer" -- just discredits himself further.
He stresses that the decompiled Java files I found are in a test area of the source code tree, and then condescendingly explains that such code would never be shipped. If he had cared to actually look at what those files technically relate to, he'd have seen that it's general security code (permission management) that can be used for many purposes. It's not specific to unit testing. As I discussed above, simply because code is not in the make file for the default Android build does not mean it isn't being used by an OEM somewhere, especially when that code is ostensibly licensed under Apache, a very permissive open source license that allows integration into closed-source programs.
In an update, Ed Burnette then said that "Google has already taken care of these files". The six files I decompiled in addition the file presented by Oracle were, according to him, removed on 14 January 2011. However, even after that update was published, I could still find them in the Froyo (Android 2.2) and Gingerbread (Android 2.3) source trees. Ed Burnette argues that the only tree that matters is the one for future Android versions, and whatever is checked into a source code management tool will forever remain in some archives.
An estimated 50% of all users of Android devices have yet to upgrade to those two versions, which are currently the two most relevant ones. And his argument that such source code management tools will always keep old files in some kind of history doesn't have any legal relevance. If a judge decided that some code infringes someone else's rights, it would have to be removed. If Ed Burnette claimed that he can't do so, then he'd be told to take his entire relevant codebase offline. At that point you can be sure he'd suddenly find a way to delete a particular file...
Ars Technica's unique perspective on copyright
Ars Technica's article on this topic has a much more reasonable style, but it also misses the point. In the headline it claims that what was found isn't a "smoking gun". In the article it becomes clearer that Ryan Paul, like Ed Burnette, assumes that I claimed every Android device comes with the software in question. I never said that. (Even if I had said that, Ars Technica would not have disproven it by jumping to conclusions from a default make file without checking into the actual products, including their closed-source components.)
By stressing that what I identified is "not a simple case of copy and paste" and that it "doesn't represent the direct copying of Sun code into the shipping Android platform", Ars Technica again refers to something I didn't write, and what's worse, displays a fundamental misconception concerning copyright infringement. Copyright infringement is not only a matter of copying and pasting code. It certainly includes copying and pasting entire files. But it also includes copying and pasting the results of decompilation, and as I discussed above, it also includes relicensing code. There are ways to infringe copyright beyond what Ars Technica talks about.
This quote here is also remarkable: "It's worth noting that this particular new evidence supplied by Mueller isn't at issue in the litigation between Oracle and Google." Either the author has never read Oracle's complaint against Google, or he doesn't interpret it correctly. In paragraph 40, Oracle says:
"In at least several instances, Android computer program code also was directly copied from copyrighted Oracle America code. For example, as may be readily seen in Exhibit J, [...]"
So the copyright infringement allegation is by no means limited to only one file (PolicyNodeImpl, which was presented in that Exhibit J). There will now be a comprehensive discovery process involving everything, and I have no doubt that at least some (if not all) of the files I presented will come up at that stage, even if Ars Technica may still believe that this material "isn't at issue".
Update on licenses
In a discussion forum I saw a claim that some of the files I presented had in the meantime become available under such permissive terms that their presence in the Android codebase should not be a problem. I checked into that, and it doesn't change much:
So far, I haven't seen anyone dispute my statements concerning the license status of those decompiled Java classes (restrictively licensed until OpenHDK 5.0, under the GPL since OpenJDK 6.0). Those were the most critical ones from a relicensing point of view.
Also, I haven't yet seen an indication that the 16 files I listed in sections 2.7 through 2.22 of my "9 SJWT copyright notices.pdf" file are no longer proprietary. If you have any information about that, please fill out the contact form.
The six files listed in sections 2.1 through 2.6 of that document were at some point made available under the GPL. However, the Android codebase does not contain the GPL versions of those files.
The 15 files listed in sections 2.23 through 2.37 were -- several years after the versions contained in the Android codebase -- licensed on permissive terms. I saw minor differences between the permissively-licensed versions of those files and the original, "PROPRIETARY/CONFIDENTIAL", material.
However, the Android codebase does not contain the permissively-licensed files, and even if it did, the modest requirements of that license would not be met by the way the files appear where I found them.
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:
