Android device makers distribute Oracle code online (Motorola, LG, Samsung)

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:

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 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.

[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:

Google is patently too weak to protect Android

About a week ago, IFI CLAIMS Patent Services published its new ranking of the 50 companies awarded the most US patents in 2010. Microsoft is still the number three patentee with 3,094 new patents, Apple is a rising star with 563 new patents (+94%, a greater gain over the previous year than anyone else on the list), but Google isn't even on that list.

I ran a couple of queries on the USPTO's patent database. Last year, Google was granted 282 US patents and -- at the time of posting this -- owns 576 in total.

While Google has ramped up its patenting activity in recent years, the gap in portfolio strength between the Android developer and its mobile operating system competitors actually appears to be widening.

Quite often I talk to people who vastly "misoverestimate" :-) the power of Google's portfolio. There's a popular belief that all major high tech companies own tons of patents, and many consider Google fairly innovative. But its patent portfolio is dwarved by those of its competitors. Microsoft's portfolio, for instance, is 25 to 30 times larger (and, as I'll explain further below, much more diversified).

When I point out those facts, many people are just as surprised as I was when I learned a long time ago that Australia has almost the size of the "lower 48" states of the United States but only about 5% the number of inhabitants. Counterintuitive facts are nevertheless facts.

Android is a "suit magnet"

The number one patent-related trend in 2010 was, beyond all doubt, the flood of infringement suits that swept over the smartphone industry and that I expect to further intensify this year. Prior to 2010, there were a few cases, most notably NTP vs. RIM, which had the US BlackBerry service on the verge of a shutdown and resulted in a $612.5 million settlement, and Qualcomm's fights with Nokia and Broadcom, which also raised antitrust questions. But what's going on now is far bigger, and potentially far more devastating.

The operating system that is the target of more infringement action than any other is Google's Android. When one of those many suits was filed, I already quoted Maureen O'Gara, who noted that "[t]he freebie operating system is proving to be quite a little suit magnet." That's a funny metaphor, and by now it would be an understatement.

Here's a list of Android-related disputes that started in 2010 (in chronological order):

1. Apple vs. HTC (see this overview of "Apple vs. Android")

2. Oracle vs. Google (five months later, Google still hasn't been able to countersue Oracle)

3. Interval Licensing vs. Google and others (analysis of amended complaint)

4. Microsoft vs. Motorola (overview of state of affairs at end of 2010)

5. Apple vs. Motorola (see this overview of "Apple vs. Android")

6. Gemalto vs. Google, Samsung, Motorola and HTC (analysis)

7. Vertical Computer Systems vs. Samsung and LG (analysis)

8. Helferich Patent Licensing vs. Huawei (the mid-November complaint listed 24 licensees including Apple, Microsoft and HTC, but Chinese device maker Huawei apparently refused to pay)

9. Multimedia Patent Trust (Alcatel-Lucent) vs. LG and others (analysis)

10. Hybrid Audio vs. HTC, Dell and others (analysis)

11. Hopewell Culture & Design vs. Motorola, Samsung, HTC, LG and others (analysis)

12. Sony vs. LG (complaint; this is the first such suit of one Android adopter against another)

That's a dozen already, and I have no doubt there will be more. Ten of the disputes listed above started just last quarter. Some of those suits also target Apple (which has a clash of titans going on with Nokia), but fewer than Android although it would be economically more attractive; a small number of cases involve BlackBerry or other platforms. I'm not aware of any suit accusing a Windows Phone 7 device at this stage, although Microsoft is frequently sought out by patent holders.

Google can't solve Android's problems through cross-licensing

There is indeed a connection between the rampant enforcement of patents against Android and Google's weak patent portfolio. Only a few of the litigants are non-practicing entities while most of the plaintiffs, especially the ones asserting large numbers of relatively strong patents, sell products of their own. Those who actually have products on the market would have to think (at least) twice before attacking Android if they might need access to some of Google's patents.

Cross-licenses are the way most patent disputes between large companies are resolved. If there is parity in terms of how much each party needs the other company's patents, the deal may be done without money changing hands. In most cases, however, one company will have the upper hand and make a payment to compensate for the difference in portfolio value. Still, such payments tend to be much lower than the cost incurred by a "have-not" who needs a license from a powerhouse. In a price-sensitive, highly competitive market such as smartphones, the cost of patent licensing is eminently important.

No matter how influential Google may be on the World Wide Web, its patents apparently didn't deter Oracle from suing. I'm sure Oracle took a close look at Google's portfolio and determined that there was no risk of a serious counterstrike, or of any at all. If you look at my visualizations of other smartphone patent disputes involving major players on both sides (Apple vs. Nokia, Apple vs. Android, Microsoft vs. Motorola), you can see how they escalate and involve ever larger numbers of patents. By contrast, Oracle still doesn't face any infringement allegations.

If Google could countersue, it might already have a favorable settlement with Oracle in its hands. Since it can't, it will either have to fend off all seven patents asserted by Oracle (plus any others that Oracle could assert in a second suit), in each case by taking the patent down or proving that there's no infringement, or it will have to come up with some theory that it was entitled to a license of some sort. Otherwise, Oracle will prevail and the vast majority of Android applications would presumably have to be rewritten. So chances are this will cost Google (and possibly the Android ecosystem at large) dearly.

Even the 576 patents Google owns are a significant number and set it apart from many others who have even less. But when you're competing in a highly litigious environment in which a diversity of patents is required to build a solid product, that's too little. In Google's case, it's not just weakness in numbers. There's also a lack of diversification. I've looked at a random sample of Google patents, and most of them relate either directly to search or to closely related technologies such as location-based services.

Such a narrowly focused portfolio just can't frighten players like Apple, Microsoft or Oracle, all of whom innovate in a variety of fields of technology. I'm not saying that Google isn't innovative. It's just not innovative in the way that gets rewarded by the patent system with a sizable and diversified portfolio.

Google leaves its partners in the lurch

It's quite possible that even some device makers who adopted Android overrated Google's ability to defend Android against patent threats. Now they see that many patent holders seek royalty payments from makers of Android-based devices, and roughly a dozen have already gone to court with infringement allegations directed at Android.

Google probably doesn't have any contractual obligations. It puts out Android on open source terms. If things work out well, Google reaps most of the rewards. If things go wrong, others bear the brunt of the patent litigation (only three of the twelve suits I listed name Google among the defendants).

Obviously, those device makers knew all along that Google could benefit from Android, but they felt they could still benefit from selling the hardware. Patent issues may turn Android-based devices into an unprofitable business at some point, regardless of consumer demand, and at that point it will be hard for anyone other than Google to make any money with Android.

I also think that Sony vs. LG may only be the first of a number of suits in which one maker of an Android-based device tries to get rid of a competitor. I don't want to name names but I could see some Android device makers trying the same kind of cannibalization.

The Android patent situation would definitely be different -- fundamentally different -- if Google had a stronger portfolio and could show some authority. At a rate of a couple hundred new patents per year, and without much diversification, Google won't become a major force in this game anytime soon.

The patent weakness I described is also going to be a serious problem for Google's WebM codec. That's a slightly different but related subject that I've covered separately and plan to address again.

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:

EU competition chief has no concerns over Novell patent deal

The EU is not going to intervene against the Novell patent deal about which the Open Source Initiative (OSI) and Free Software Foundation Europe (FSFE) recently complained. European Commission vice president and competition commissioner Joaquín Almunia has told a Member of the European Parliament that the sale of 882 Novell patents to CPTN Holdings LLC appears "unlikely" to require an EU-level review, and "the Commission has currently no indication that the mere acquisition of the patents in question by CPTN Holdings would lead to an infringement of EU competition rules."

The EU's competition chief said so in reply to a written question put forward by Emma McClarkin, a British conservative from the East Midlands. The question was submitted on 20 December 2010, subsequently published on the European Parliament's website, and answered yesterday (17 January 2011).

I'll quote and comment:

"Subject: Microsoft and competition rules"
"A constituent has written to me"

British MEPs are always very exact about "constituents" because unlike the MEPs in most other countries, they are elected in certain districts. So in all likelihood, someone from the East Midlands wrote to Emma McClarkin. That email may have been orchestrated by FSFE or OSI, but it may also have been someone's independent initiative based on early media reports on the deal.

"expressing concern about Microsoft recently purchasing a large number of patents from Novell. This move strengthens the hold Microsoft has over its competitors, which could potentially harm consumer choice and increase prices. Is the Commission aware of this situation? If so, does the Commission believe there have been any infractions by Microsoft of EU competition laws?"

This focus on Microsoft shows that the MEP wasn't fully informed when posing the question. The question was dated 20 December 2010. Four days earlier, I published the names of the four companies (Apple, EMC, Microsoft, Oracle) that have formed the CPTN Holdings consortium.

There still seems to be some confusion out there concerning Microsoft's role. When the acquisition of Novel by Attachmate and of those 882 patents by "a Microsoft-organized consortium" became known in November, the other companies weren't disclosed until they appeared on the website of the German competition authority. But the fact that Microsoft "organized" the consortium only means that Microsoft had a key role in bringing the partners together. It does not necessarily mean that Microsoft still leads the consortium following its foundation. All that's known so far is that Microsoft had the role of a midwife. Any assumption that Apple, EMC and Oracle decided to let Microsoft run the organization thereafter is purely speculative, and in my view, unlikely in light of the weight and pride of those partners.

Anyway, here's the vice president's answer:

"E-10547/10EN
Answer given by Mr Almunia
on behalf of the Commission
(17.1.2011)"

"The Commission is aware of the proposed acquisition by CPTN Holdings, a consortium of technology companies which includes Microsoft Corp, of a portfolio of 882 patents from Novell. On the basis of the information currently available at this stage, it appears unlikely that the proposed transaction requires a notification to the Commission under the Merger Regulation."

This means that this is so far from being an EU competition issue that it doesn't even have to be reviewed. Finally:

"Furthermore, in addition to the consideration under the Merger Regulation, the Commission has currently no indication that the mere acquisition of the patents in question by CPTN Holdings would lead to an infringement of EU competition rules."

This means that there's no problem with the sale of patents per se. The use of patents has played and is currently playing a role in some EU competition cases, but companies can sell any of their patents pretty much like they sell products, their office furniture, used company cars, or real estate.

I have seen the positions taken by OSI and FSFE. I couldn't find any real substance in them. Those complaints came down to indicating a dislike for patents and distrust for the companies behind CPTN Holdings. But they didn't raise any legal issues that would be specific to this deal.

My own position is known: I used to run a campaign against a software patent bill. However, politicians don't stop patent offices from granting them. So let's come to terms with it: this is the law of the land. As long as those patents exist, they can be sold.

Finally, if it confuses you why the deal was notified to the German competition authority while the EU (of which Germany is a member) doesn't see a need for notification, that's because the EU is a supranational body and its member states still have their own laws. Those can't be in conflict with EU rules in areas where the EU has harmonized the rules, but there can be some differences in details, such as one country requiring notification of joint ventures of a type that the EU doesn't investigate. In order to coordinate everything efficiently, the European Commission works closely with the member states' competition authorities through the European Competition Network (ECN).

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:

Procedural win: Apple obtains transfer of a Nokia suit from Wisconsin to Delaware

Last week, Apple achieved a partial streamlining of its patent dispute with Nokia: a lawsuit in which each party asserted seven patents against the other was transferred from the Western District of Wisconsin to the District of Delaware, where the parties already had two suits going.

Nokia had argued against such a transfer, claiming that it would delay resolution of the related claims by more than a year and a half.

The transferred suit may now be consolidated into one of the other suits. At any rate, the number of courts in which the two companies are suing each other has been reduced from seven to six.

Here's an overview of the curent battlefield:

Nokia vs Apple 11.01.06

It's recommended to view that diagram in full screen mode. You can also download it as a PDF file from Scribd.com. On page 21 you can see the latest changes highlighted: the Wisconsin suit and its counterclaims are gone, and the number of patents asserted in Delaware have gone up (now 25 Apple and 24 Nokia patents in that court alone).

The US District Court for the District of the Delaware is now the only federal court in which the two companies are suing each other. In addition, they are fighting each other in three ITC investigations as well as in four European courts.

Apple's motion succeeded against Nokia's opposition

Nokia had started the Western Wisconsin suit in May 2010 after previously suing Apple twice in Delaware (October and December 2009). When Apple answered to that complaint and made its counterclaims, it also filed a motion to transfer the suit to Delaware. Nokia opposed that motion unsuccessfully: on 04 January 2011 (Tuesday), the Wisconsin court agreed with Apple, and on 06 January 2011 (Thursday), it was received by the Delaware court.

Another Apple motion had previously failed: Apple wanted to consolidate four Delaware cases (two involving Nokia as well as two related to HTC). That motion was filed on 24 May 2010 and declined on 06 December 2010. The court concluded that in this particular case it wouldn't be efficient to consolidate cases involving different parties, and one of the cases involving Apple and Nokia had been stayed for the duration of certain ITC investigations. But that was a different matter than the transfer that Apple has obtained now.

Concerning the motion to transfer, the Wisconsin court found that "Apple has met its burden of establishing that the District of Delaware is clearly the more convenient forum on the specific facts and circumstances presented [in Wisconsin]".

For a transfer motion to succeed, the court must be convinced that the other forum is a proper venue. Nokia didn't disagree that Delaware is a district in which the action could have been brought. After all, Nokia itself had previously sued Apple twice in Delaware.

In its decision to grant the motion to transfer, the Wisconsin court recalled the following criteria:

"In deciding whether to transfer a case to another district, a court must consider whether the transfer (a) serves the convenience of the parties and witnesses and (b) will promote the interests of justice."

One of the efficiency considerations is "access to sources of proof". Since Nokia is a Finnish company without any particular connection with Wisconsin, the court didn't see why that particular suit would have to take place there instead of Delaware, where two similar suits had already been filed.

Another question the court looked into was whether the parties had "any meaningful connection to Wisconsin" (other than selling products to that state just like to any other part of the United States). Apple denied such a connection but pointed out that three companies -- Infineon Technologies, Foxconn Electronics, and Samsung Electronics -- would have to send witnesses to Delaware anyway (for the litigation taking place there between Apple and Nokia) and would, without a transfer, have to travel to Wisconsin as well. But since there was no indication that those witnesses would have to be compelled to testify (as opposed to being ready to do so), this wasn't a factor in the decision.

Nokia claimed a delay of more than 18 months as a result of a transfer

Nokia argued against a transfer that "it would experience a delay of over a year and a half from the expected trial date in Wisconsin." Nokia claimed that federal statistics indicate that "the median time between filing a lawsuit and trial in the Western District of Wisconsin is 15 months, while the median time between filing a lawsuit and trial in the District of Delaware is 34 months".

Nokia stressed the dynamics of the smartphone market as a need for speed. But the court wasn't convinced. It mentioned that Nokia filed its suits against Apple after licensing negotiations had filed, and concluded that if such negotiations had taken place, Nokia "could be readily compensated by a reasonable royalty, making a swift trial less critical."

What really appears to have hurt the credibility of Nokia's position is the fact that it filed the Wisconsin suit after suing Apple twice in Delaware. The court asked this rhetorical question:

"If Nokia was at risk of losing market share and thus sought a speedy resolution of its claims, then why did it not file the first two lawsuits in Wisconsin?"

The fact that Nokia brought its Wisconsin complaint about seven months after its first Delaware complaint also called into question that the allegations filed in Wisconsin needed to be resolved particularly quickly.

Possibility of post-transfer consolidation of Delaware cases

The court finally also had to analyze the feasibility of consolidation. While Nokia claimed that the issues it raised in its Wisconsin complaint weren't sufficiently related to the suits it filed in Delaware, the court disagreed:

"The feasibility and practicality of consolidation supports an expectation that this case would be consolidated with the related litigations between these parties in Delaware. The parties are the same and there will be common questions of law and fact because each action involves the same potentially infringing products: the Apple iPhone, iPhone 3G, and iPhone 3GS. In addition, the patents feature technological overlap, such as the manner in which mobile devices interface with users, transmit and receive user information over the air, and how these devices encode, modulate, and encrypt information transmitted over the air."

This reduced Nokia's argument against the possibility of consolidation to the fact that the suits relate to different patents. But "[t]he fact that there is no direct overlap in patents, however, is not, by itself, a sufficient justification to deny transfer" according to the court's citation of a ruling in a similar matter. It then stressed the following:

"In litigation of this size involving this number of patents, a party will surely be capable of drawing distinctions in the technology and its components."

In other words: when two such companies sue each other over dozens of patents, it's not too hard to argue that there are some differences between the various assertions, but that doesn't mean the cases can't be consolidated, especially in view of the following:

"At a minimum, these cases involve the same parties, same products, similar components, and at least some degree of overlapping technology. Chief Judge Sleet in Delaware will thus already be familiar with the general technology underlying Apple‟s wireless communication devices. When such is the case, it is to the parties' benefit to litigate before a judge that is familiar with the products and general technology. [...] To require two different courts to educate themselves about the same underlying technology does not promote judicial efficiency."

Another efficiency argument is that cases involving "many of the same product components" and "many of the same non-party witnesses" should be handled by the same court because "coordinating discovery in one district would promote efficiency by avoiding duplicative discovery" and, even more importantly, make "conflicting judicial decisions" less likely.

Conclusion

While this is just a procedural matter, Apple is probably glad that its motion succeeded against Nokia's opposition. There's now a possibility of some consolidation in Delaware.

Did Apple file that motion in order to stall? I don't know. There's no doubt to me that Nokia is a much tougher adversary for Apple to deal with than Motorola and HTC are. Nokia has a large patent portfolio and owns some intellectual property that may be fairly relevant to Apple. At the same time, Apple has patented inventions that are important for new generations of smartphones. This is a clash of two titans, and it will continue to be very interesting to watch. I wouldn't be surprised to see a settlement later this year, but they might still be suing each other in 2012.

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: