FOSS Patents

When Intellectual Ventures predicted an "IP reckoning" for the automotive industry, it presumably had its enforcement action against General Motors, Toyota, and Honda (Eastern District of Texas) already prepared. Meanwhile, Sivel v. Ford and especially Acer v. Volkswagen have drawn even more interest in the automotive patent litigation arena. Automotive patent lawsuits get filed pretty much every week, and it now turns out that a patent previously assigned to Intellectual Ventures is being enforced in the Eastern District of Texas by a non-practicing entity with the patriotic name of Liberty Patents against Toyota, Subaru, and BlackBerry (this post continues below the document):

[フレーム]

21-12-17 Liberty Patents v.... by Florian Mueller

I don't know whether Liberty Patents is an Intellectual Ventures affiliate or an independent third party that struck a deal with IV resulting in the assignment of 130 former IV patents according to RPX.

The patent-in-suit, over which Liberty Patents is seeking not only damages but also a permanent injunction (it won't expire before 2024), is U.S. Patent No. 7,493,612 on an "embedded system and related method capable of automatically updating system software." BlackBerry's QNX platform, Toyota, and Subaru provide over-the-air software upgrades. In Subaru's case, the complaint mentions the Subaru Crosstek with its STARLINK system, driver asisstance software, and "other systems that utilize the Automotive Grade Linux (AGL) platform" found in such vehicles as the Subaru Ascent, Forester, Impreza, Legacy, Outback, and WRX. The infringement allegations against Toyota also involve AGL, with a wide range of models being mentioned (such as the Toyota Camry, Avalon, C-HR, Corolla, GR Supra, Mirai, Prius, RAV4, and Sienna).

This Liberty Patents case is an example of non-standard-essential patents being asserted against the automotive industry. Another example would be a complaint by an entity named Aprese Systems Texas against Nissan in the Western District of Texas over U.S. Patent No. 8.732,697 on a "system, method and apparatus for managing applications on a device."

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Last Sunday, IBM and Red Hat announced a merger agreement under which "Big Blue" (NYSE:IBM) would pay 34ドル billion, or 190ドル per NYSE:RHT share, to acquire the company that once started as a Linux distributor.

I may very well talk about the strategic ramifications of the proposed transaction some other time, but the focus of this post is exclusively on what the stock market appears to think of the deal.

On Monday (October 29), Bloomberg already reported on what was then a 12% spread, "among the highest for North American deals." The article quoted a portfolio manager who said he didn't want to bet on a deal that may be about a year away from closing, and IBM CEO Ginni Rometty as denying "any regulatory inhibitors," which she obviously had to say.

The time frame certainly affects demand, given that risk arbitrageurs could in the meantime use the money they would spend on RHT shares now to bet on a couple of other mergers, provided that those other deals would close more quickly and happen sequentially. But there's more to it. The spread does indicate that merger-focused investors are far from convinced that the deal will materialize.

On Friday (November 2), RHT closed at 172ドル.24. If the deal went through, those investing now would then rake in a profit of more than 10%. Even if it took a year, a 10%+ gain would be a great deal. The only explanation for why there isn't stronger demand, at a higher price, is skepticism. Since I can't imagine anyone doubts that IBM is a serious buyer, the reason must be concern about the merger review process in the U.S. (DoJ), EU (European Commission, DG COMP), and China (MOFCOM). While China prevented Qualcomm from acquiring NXP, IBM reportedly claims it's not critical for the Red Hat deal. I haven't formed a definitive opinion on it yet, but for now I'll take IBM's word for it.

Without going into detail (yet) on the issues presented by the transaction, we can "reverse-engineer" the stock price in order to get an idea of how likely the deal is--in the eyes of sophisticated Wall Street investors--to go through or fall through. Let's start with the roughest and simplest approach, and then fine-tune it a little bit to take the time value of money into account.

The potential upside based on Friday's closing price is 17ドル.76. Theoretically it's even greater since someone else might try to outbid IBM, but that doesn't appear to be considered too likely by anyone.

The potential downside here would not realistically be a complete loss of the investment. Red Hat is doing too well to go out of business anytime soon. The closing price over which IBM offered a premium of about 60% was 116ドル.68, pretty much at a level with RHT's 52-week low of 115ドル.31 (an intraday price as far as I can see).

If the deal falls through, it's a reasonable assumption that Red Hat's stock price will go back to that level, though it's obviously hard to predict what the market environment would be at that point in time somewhere in the second half of 2019. In order to keep things simple, let's not consider that investors might think they could mitigate their loss by getting out once there's a serious negative sign, such as a powerful Statement of Objections (SO) by the European Commission.

Assuming that the pre-merger-announcement closing price is where the price would fall, the potential per-share loss is 55ドル.56 (172ドル.24 - 116ドル.68).

If the likelihood of closing is estimated to be 76%, and the risk of things falling apart is (consequently) 24%, then there would be an equilibrium (76% x 17ドル.76 is at a level with 24% x 55ドル.56).

Let's fine-tune this by assuming a financing cost of 4ドル.00 per share (roughly the Fed rate, assuming that you have this cost for 12 months). In that case, the potential gain (by placing the right bet on the deal going through vs. doing a far safer investment that would have a 2.5% yield) is 13ドル.76, and the potential loss increases to 59ドル.56. There would then be an equilibrium if the risk of the deal being blocked (or remedies being imposed with the effect of the deal falling through) was estimated at 19% (19% x 59ドル.56 is at a level with 81% x 13ドル.76).

Even in the aftermath of Qualcomm-NXP, that is a fairly skeptical perspective, given that mergers of this kind normally go through.

I've received a couple of independent invitations to meet portfolio managers in New York to discuss the deal, plus various calls and emails. Investors used to follow my coverage of the Google-Motorola process with great interest, and many still remember my vocal opposition to Oracle's acquisition of Sun Microsystems in late 2009 and early 2010. It was funny for me how the numerous Wall Street people I talked to always called the company "JAVA" (based on the stock ticker symbol). Java--the programming language--wasn't an issue at the time; MySQL, the open-source database, was the reason for which the European Commission conducted a Phase II review and issued an SO. It's about open source again, and this time around, Java will be part of the discussion.

As a matter of transparency, Red Hat contributed to my NoSoftwarePatents campaign in late 2004 and early 2005 (two other companies, including one far smaller than Red Hat, were much bigger supporters of the campaign), but there hasn't been any business relationship with Red Hat since. I've never had any relationship with IBM, other than having the greatest respect for the work of its patent department.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

This commentary on the Microsoft-Red Hat partnership is a back-to-the-roots post for me. This blog started as a Free and Open Source Software Patents blog--hence the FOSS Patents name-- and only because of all the (ultimately not too meritorious, let alone impactful) patent attacks on Android, it effectively became a smartphone patent wars blog (but by then it was too late to rename it without losing traffic).

While I don't mean to endorse everything Dr. Roy Schestowitz has written about Microsoft on his TechRights blog (and certainly not everything he's ever written about me), I agree with him that media reports on the Microsoft-Red Hat deal could have dug deeper, especially into the patent aspects of that deal. I furthermore agree that Red Hat is apparently happy about making it easier for Microsoft to impose a patent tax on Linux and that Red Hat has simply sold out FOSS values. According to TechRights, Red Hat executives tried to dissuade Dr. Schestowitz from his vocal criticism of the deal, but failed.

I've been saying for years that Red Hat is utterly hypocritical when it comes to patents. It has a history of feeding patent trolls and fooling the open source community. There is, to put it mildly, no assurance that all of its related dealings actually comply with the GPL.

Sometimes I like the positions Red Hat takes in its amicus curiae briefs on patent issues, but more than once I got the impression that those filings were written primarily in an effort to create the appearance of defending the FOSS cause in this context. It was just window dressing.

The fact of the matter is that Red Hat seeks to be a major beneficiary of the software patents mess.

Red Hat is large enough by now that it can just make the trolls go away by paying them off, giving them funds and legitimacy to go after other companies, including other open source companies.

Red Hat has also accumulated a certain amount of patents over the years, which puts it into a better position than individual open source developers and smaller companies in this space to retaliate in the event of a strategic attack by a competitor.

Red Hat now wants to tell Linux users that the way to be protected with respect to patents is to use Red Hat Linux. "Reduce your exposure, buy from us." That is a way of seeking to benefit from software patents.

All of this is no surprise when considering that Red Hat has always just been about taking advantage of something. In terms of its product and licensing policies, Apple may be the very opposite of a "free software" company (no matter what it may do with respect to its Swift programming language). But you have to grant them one thing: they're not fooling anybody about their philosophy. They never even tried. They don't "openwash" anything. They don't pretend to be a charity. They want to make money, more than any company before them. But one could not create products more independently and single-handedly than Apple. And all by themselves they have brought about a revolution that the likes of Nokia and Microsoft would never have created.

By contrast, Red Hat's business model is parasitic (though some like to euphemistically describe it as symbiotic). While Red Hat has been a major contributor to Linux, Red Hat became what it is not because of what it did but because of what Linus Torvalds and others had done. And Red Hat is not nearly as honest as Apple. "Not nearly" may even be an understatement.

The question of whether covenants not to sue over patents (which appears to be the structure of the Microsoft-Red Hat deal and would be consistent with a Microsoft Android patent agreement that was filed publicly last year) violate the GPL v2 has not been addressed by a court of law yet. I would actually like to see someone sue Red Hat for breach of the GPL and obtain clarification, but even the Free Software Foundation and its satellite organizations are not as principled as they pretend to be. They never compromise their values per se, but they have their strategic priorities when it comes to where and how forcefully to defend them. It will be interesting to see their reaction to the Microsoft-Red Hat announcement--not in terms of what they say but in terms of what, if anything, they will do. I guess they won't do anything. Why? Red Hat is a donor, Red Hat is a code contributor, the deal offers benefits for "GNU/Linux" as they call it...

I want to give Simon Phipps (with whom I've often disagreed) credit for distinguishing between the positive and not so positive ramifications of this partnership from an open source point of view. The Open Source Initiative is an organization on whose board Simon Phipps serves with, among others, a Red Hat lawyer.

Without the Red Hat connection, Simon Phipps would presumably have criticized Red Hat clearly as opposed to just making it sound like Microsoft should do more. He says Microsoft should relinquish its patent rights because that's how he defines "love" for Linux. However, he doesn't talk about what Red Hat could have done. Red Hat could have challenged any Microsoft patents that allegedly infringe Linux: in court (declaratory judgment actions) and through reexamination requests. That course of action would have done free and open source software a greater service than a deal.

I, too, have a (past) Red Hat connection, but it's none that I would be proud of. Over the decades I've done work for a variety of companies, and Red Hat is the only one I wish I had never worked with. They supported my NoSoftwarePatents campaign in late 2004 and early 2005, probably because they just thought a sponsorship was useful for currying favor with the FOSS community. They were far larger than MySQL AB but contributed a far smaller amount. In terms of commitment relative to company size, MySQL AB was like 100 times more committed to the cause. But the worst part was that shortly before the European Parliament's decisive vote on a software patentability bill, Red Hat tried to keep the legislative proposal alive. The Red Hat lawyer who did so later responded to that, and he never denied the simple truth that he wanted the legislative process to continue.

On this blog I announced, years ago, working relationships with Microsoft and Oracle. Both are a thing of the past. But I would never say that I wasn't proud of them.

The Microsoft I worked with as a consultant was not the Microsoft under Bill Gates that made artificial scarcity of software a strategic objective and got into serious antitrust troubles. I found Microsoft to be no better or worse than the vast majority of companies in this industry. I overestimated the merit of their allegation that Android infringed on many of their patents, but I corrected that assessment more than a year ago based on the results of numerous Android-related patent lawsuits and, after a second-class settlement between Microsoft and Google/Motorola, declared Google the strategic winner. The number one priority of my work for Microsoft was about giving FRAND meaning, a cause I continue to promote (see today's post on Apple v. Ericsson). In that regard, Microsoft was the victim of abusive tactics by Motorola. Sure, that was just Motorola's retaliation for Microsoft's patent assertions against Android, but two wrongs don't make a right (as Microsoft accurately said in the FRAND context).

Oracle has been a longstanding advocate of reasonableness with respect to standard-essential patents, and of open (and ideally free-of-charge) standards. I'm happy to have helped them in that regard, too. As for their Google copyright lawsuit, everyone can see on this blog that I've always taken the same pro-interface-copyright positions. I took them before (going back to a conference in the European Parliament in 2004) and after working against Oracle's acquisition of Sun Microsystems, and before and after doing work for Oracle. I view Google's position on API copyrights as a wholesale attack on the copyright protection of all computer software. Google doesn't call for the abolition of software copyright, but there appears to be no limit to the collateral damage it's willing to inflict to software copyright only to avoid paying Oracle for using Java in Android.

I am now in the most independent position to comment on IP, antitrust and industry policy issues ever. I'll continue to be consistent, just like I'll continue to draw the necessary conclusions from new intelligence (as I did when all those anti-Android patent assertions turned out to have no merit in most cases and negligible merit in the remaining cases). That's why I can just say what I think about the Microsoft-Red Hat deal. I think it's great for Azure, and I like Azure, though my app development company is using it only to a small extent and will use a different cloud service provider for most purposes. The free and open source software community should, however, be opposed to this and shouldn't trust Red Hat with respect to patents. They weren't trustworthy with respect to the European legislative process on software patents; they weren't trustworthy with respect to various settlements with patent trolls; and they aren't trustworthy now in connection with what appears to be a covenant not to sue, which is a license by any other name, with Microsoft, when the alternative would have been to bring a declaratory judgment action that says "Linux does not infringe a single valid Microsoft patent claim and we're now going to prove it."

It's one thing to be a Linux parasite. It's another to be a Trojan horse. And the worst option is to be both at the same time.

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 and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

On Wednesday the Open Invention Network (OIN) and Google announced that Google's OIN membership was upgraded from Associate Member to Full Member. The OIN was founded eight years ago by companies including IBM and Red Hat with the stated goal of protecting Linux from patent assertions and after all these years still hasn't delivered a verifiable proof of concept. There are two ways in which it could have delivered such proof:

• It could have announced a license deal with a company that previously asserted and then, as a result of the conclusion of that agreement, abandoned patent assertions and royalty demands involving Linux.

• It could have given patents to a target of Linux-related patent assertions for the purpose of countersuing a plaintiff, who would then (if OIN's patents were strong) agreed to drop its infringement claims.

Neither of the above has happened to date, and I doubt it ever will. The closest thing to a success story that I heard from people defending the OIN approach is that the organization gave four patents to Salesforce in 2010, three of which were asserted against Microsoft. But the announcement of the Microsoft-Salesforce settlement made clear that Salesforce accepted to pay. OIN's supporters claim that Salesforce got a better deal thanks to OIN's support, but this is not a verifiable success story and I doubt it: until that point, a few other Microsoft patent disputes in which OIN was not involved at all were settled similarly quickly. (Nowadays defendants are more inclined to defend themselves for years on end, but not back then.)

Microsoft has struck many hundreds of patent license deals since the OIN was founded, and many of them relate to Linux (with or without Android on top of it) and involve large and sophisticated licensees. There's no sign of the OIN having complicated Microsoft's award-winning patent licensing efforts.

Google's decision to step up its commitment to OIN comes as no surprise. Last year the OIN added Android technologies such as the Dalvik virtual machine to its list of covered technologies. And Google likes to make patent-related announcements that actually don't change anything, typically in an open source context.

Google's real strength is to defend itself against infringement allegations and to strike down patents through invalidity challenges, though this doesn't always work (Apple has already defended a couple of key patents against attacks in which Google likely had a hand).

Any attempts by Google to bring or threaten with offensive counterclaims against others have been pathetically unsuccessful so far. It currently has zero enforceable patent injunctions in place over Motorola Mobility's patents worldwide.

Google is also playing the political card and pushing for patent reform, but at this juncture it appears that U.S. Congress won't change patent law in any way that would enable Google to get away with Android's infringement. There will be some limited and targeted changes, and those may very well happen in 2014 -- but no game-changer for disputes between large players. Google has not made any headway in terms of making U.S. lawmakers believe that the patent system is not a major innovation engine.

It's really impossible to see any tangible benefit Google is going to get out of its upgraded OIN membership with respect to the problems it currently faces. The OIN "protects" Dalvik, but Oracle left the OIN a while ago and is currently not pursuing patent but copyright claims against Android (and it's now on the winning track based on the positions taken by three Federal Circuit judges at an appellate hearing earlier this month). Microsoft already has pretty much all major Android device makers signed up as paying licensees. Apple's patent infringement claims are mostly in areas the OIN doesn't even cover -- and if the OIN had wanted to stop Apple from suing Android device makers, it would have had almost four years now (counting from Apple's first lawsuit against HTC in March 2010) to do so. And there's Nokia (in other news today, Nokia is suing HTC over Google Maps and Google Navigation). The OIN can't change anything about Nokia's patent monetization and litigation.

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 and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

After many years of fundamentalist opposition to patent licensing it appears that Free Software advocates have become more pragmatic and now, at long last, tend to appreciate the benefits of patent license agreements and recognize what they usually denied in "open standards" policy debates around the world: that FRAND licensing terms for patents that read on Free and Open Source Software (FOSS) can actually contribute to the freedom of software distributors and users.

The Software Freedom Law Center (SFLC) is run by Professor Eben Moglen, Richard Stallman's co-author of the GPLv3, the most anti-patent FOSS license. SFLC provides legal advice and defines its mission as "helping [FOSS] projects reach their long-term goals safely and efficiently so hackers can concentrate on making great software". In a response to Open Source Initiative (OSI) chief Simon Phipps's criticism that Google's proposed VP8 patent license is overly restrictive by FOSS standards, SFLC's Senior Staff Counsel Aaron Williamson writes:

"Because the patent license does not restrict those freedoms, but rather affords some new, limited protections to users and developers within the field of use, it improves on the current situation. Without this license, the patent holders would be in a position to threaten those users and developers as well as others. [...] [U]ntil software patents no longer threaten FOSS, we will look for every opportunity to preserve community development from their destructive effects. The VP8 cross-license provides such an opportunity, in an area of particularly active patenting."

This is, in fact, a ringing endorsement of Microsoft's patent license agreements with Android and Linux device makers (note that Android includes Linux, which is distributed under the Free Software Foundation's GPL license). Last month ZTE became the 20th Android device maker known to have taken a royalty-bearing Android patent license from Microsoft, and Microsoft previously announced license deals involving non-Android variants of Linux (examples: Amazon, Brother, Casio, Kyocera, LG, Samsung).

The logic of the SFLC's defense of Google's proposed VP8 patent license agreement as being "compatible with FOSS licensing" also applies perfectly to Microsoft's Android and Linux patent license deals:

• Just like the proposed VP8 patent license is a separate license from the software copyright license, Microsoft's Android and Linux patent license agreements are separate from the copyright licenses governing the open source distribution of Android/Linux.

• Just like the licensees under Google's proposed VP8 license, Microsoft's licensees are "not [...] required to pass on any restrictions limiting users' rights to copy, modify, and redistribute free programs" (if Samsung et al. imposed any such restrictions, we would know). Instead, users "have the same rights as they would if the [device makers] had never accepted the patent license".

• Just like video codecs are "an area of particularly active patenting", so are smartphones (which according to patent aggregator RPX potentially infringe a quarter million patents). In fact, smartphones are an area of far more active patenting because they include video codecs but also numerous other technologies in fields of active patenting.

• Just like the proposed VP8 license, Microsoft's Android and Linux patent license agreements "do[] not restrict [FOSS] freedoms, but rather afford[] some new, limited protections to users and developers within the field of use", which in the SFLC's opinion "improves on the current situation".

Of course, the terms of Microsoft's agreements with Android/Linux device makers aren't known -- nor are the terms of Google's agreement with 11 MPEG LA patent licensors. All that we can see from the outside is what the respective licensees do or don't do. Do they impose restrictions? No. Do end users have to pay separately? No, someone takes care of this for them. Does this mean third parties can do anything they want without possibly needing a new license from the relevant patent holders? No. Nor are they free to "do anything" under the VP8 patent license agreement.

With a vocal part of the Free Software ecosystem agreeing that patent licenses are preferable over litigation, and confirming that patent licenses wich don't result in a modification of software copyright licenses actually "afford[] some new, limited protections to users and developers within the field of use", licensing is more popular than ever. Once Google's Motorola Mobility also takes such a patent license, it will be difficult to come up with anyone else who could lend a meaningful endorsement to this commercial practice (which is also accepted in all other fields of technology).

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 and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Samsung today confirmed its plan to release during the course of 2013 multiple mobile phones running the Tizen platform, which is supported by companies including Intel, Vodafone and NTT DoCoMo, and Linux-based like Android. A Bloomberg report on this announcement says "Samsung looks to reduce its reliance on Google (GOOG) Inc.'s Android operating system after the Internet search company acquired handset maker Motorola Mobility Holdings Inc. for 12ドル.5 billion in May".

Samsung is rightly concerned about what Google will ultimately do with Motorola Mobility. Google's plan to use MMI's patents to bring about global patent peace has not worked out at all. And there comes a point at which Android will be perceived by many consumers as a Samsung platform -- because of the ubiquity of the Korean electronics giant's gadgets. Also, more and more end users become accustomed to Samsung's proprietary extensions on top of Android, named Touchwiz.

At some point Samsung may determine that Tizen meets its strategic needs better than Android does. For example, Samsung may want more freedom to partner with other providers of online services and/or to increasingly promote its own offerings. This would lead to a potentially irreconcilable conflict between the two companies.

In this scenario Google might hope that Samsung is going to remain focused on Android (and play by Google's rules) because of the huge number of existing apps. Even Samsung's strategy of hedging its bets with Tizen is not going to make the whole app developer community flock to that platform. But with both Android and Tizen being based on Linux, wouldn't it make a lot of sense to create an interface that enables most (or, at some point, all) existing Android apps to run on Tizen? Sort of an emulator? In that case, Samsung's customers could switch from Android to Tizen in a fairly smooth transition. Samsung would have to leave the Open Handset Alliance (OHA) for fragmentation of Android, but that wouldn't really matter at that point.

Over time, the Tizen engine for Android apps could even have unique functionality that would render apps optimized for Tizen incompatible with Android.

Granted, this is speculative. But this has happened before. When Google launched Android, it understood that it needed a large and diverse choice of apps, and in order to attract app developers, it provided them with a programming environment derived from Java. And it did this without a license from Sun Microsystems, which became a wholly-owned Oracle subsidiary three years ago. At the same time, it also hijacked Linux, using large amounts of Linux API material.

When Oracle decided to take legal action against this allegedly "lawless conduct", Google defended itself primarily with the argument that any material it appropriated was not protected under copyright law. Google didn't deny that it used Java API material: it merely disputed that there was anything unlawful about it.

Judge William Alsup in the Northern District of California sided with Google on this one. Oracle appealed his ruling to the United States Court of Appeals for the Federal Circuit. The appeal focuses exclusively on the copyright part of the case (which originally also involved seven patents).

As the saying goes, "live by the sword, die by the sword". Google would have to contradict its own positions on API copyrightability if Samsung decided to do to Android what Google did (and continues to be doing) to Java.

If Oracle's appeal succeeds and some or all of the appropriated API material is declared copyrightable, Google will have to work out a deal with Oracle. But in that event it will also be in a position to make it much harder for Samsung to supplant Android with Tizen.

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 and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

This is a near-simultaneous follow-up to my initial reaction to Google's EU antitrust complaint against Microsoft and Nokia over their alleged collusion with a non-practicing entity, Mosaid. Google asks the European Commission to look into something the ITC dismissed three times. Diversion is not a defense, however./p>

According to this media report, "Google alleges MOSAID is reneging on a commitment that Nokia made in a 2005 regulatory filing when the company pledged not to enforce patents against software relying on the Linux Kernel".

I would like to comment on this because I remember the May 2005 pledge and, particularly, the political context in which it was made. Nokia's Linux-related patent pledge was made ahead of a key vote in the European Parliament on a proposed European directive on the patentability of computer-implemented inventions, known as the "software patents directive". I ran a campaign against that bill. It was indeed thrown out, though the fact of the matter is that software patents continued to be granted in Europe in large numbers and are now enforced on a daily basis. I see it in the courts here all the time.

At the time, every large tech company wanted the bill to go through. Even Google didn't oppose software patents but merely wanted EU lawmakers to grant an interoperability privilege so Google wouldn't have to worry about possibly infringing Adobe's patents when indexing PDF documents (that's the example Google mentioned at the time).

The movement opposing software patents largely consisted of open source activists, at least in terms of those who actually went to Brussels, Strasbourg and other European cities to lobby politicians. Also, Linus Torvalds and Alan Cox wrote an open letter to all MEPs (Members of the European Parliament) ahead of the chamber's first-reading vote in 2003. Far-left and Green politicians had a lot of sympathy for the open source movement, while politicians from the center-left to the center-right wanted the decision on software patents to be based on economic considerations rather than open source philosophy and ideology.

In order to counter claims that software patents are a natural enemy of open source software, some companies made pledges not to assert some or all of their patents against certain open source technologies (particularly Linux). A secondary consideration was that these companies also wanted to curry favor with the open source community. I criticized them all for this. In particular, I always pointed out that those pledges had major loopholes. My criticism was quoted in many media and I authored an opinion piece for Slashdot. To me it was always clear that those pledges were political instruments of limited legal value.

The European Commission had made the proposal for the CII directive and backed it. At the time, the Commission probably also welcomed those pledges in order to weaken the open source movement's resistance against the bill.

In January 2005, IBM made the first pledge of this kind. Sun Microsystems made one, too. And so did Nokia in May 2005. Here's a Slashdot story on Nokia's pledge, and an archived version of an official Nokia webpage that contains the full text.

When reading the actual text, it's crystal clear that Nokia's promise was limited to the "Linux kernel", as opposed to something like Android. While Android uses the Linux kernel, it's not Linux, and in particular, it's not published under the same license, the GPL. Nokia's pledge, however, related to "any version of the Linux kernel which (i) is released as "stable version", (ii) is licensed under the "GNU GENERAL PUBLIC LICENSE Version 2, June 1991 for the Linux operating system" and (iii) has been published by the Kernel.org Organization, Inc on its Linux Kernel Archive website at www.kernel.org". This clearly doesn't include Android. Android itself is published under the Apache Software License, which is inherently incompatible with the GPL. Parts of Android (such as the Android Market/Google Play, Google Maps, Google Mail, Google Talk etc. clients) are made available under proprietary, closed-source software licenses, which are also incompatible with the GPL.

Google won't be able to fool the European Commission about this because it has a lot of in-house expertise concerning open source licenses. The European Commission even created an open source license of its own (the EUPL), and it has dealt with open source licensing questions in certain competition contexts such as Oracle's acquisition of MySQL (a GPL-licensed database) as part of Sun Microsystems.

I don't know which patents Mosaid acquired from Nokia. There are 2,000 patents, and apparently 1,200 of them are standard-essential. It's possible that not even one of those 2,000 patents reads on the Linux kernel (as opposed to reading on Android).

Nokia's pledge clearly didn't rule out the possibility of patent transfers, but it didn't say that the pledge would apply post-sale. Pledges that mention transfers at all are hard to find. Even the world's largest Linux company, Red Hat, made a patent pledge that doesn't address sales or transfers of Red Hat's patents. One of a very few exceptions to the rule that pledges don't survive transfers is Microsoft's February 2012 statement on standard-essential patents ("Microsoft will not transfer those standard essential patents to any other firm unless that firm agrees to adhere to the points outlined above"). That kind of language was missing from all those open source patent pledges including Nokia's.

Back in 2005, when I criticized all those pledges, there was no company that joined the chorus. If some non-governmental organizations, companies and individuals had spoken out, we could have jointly demanded that IBM, Sun and Nokia make further-reaching pledges. But Google, like most companies, decided not to take action. As I explained above, Google was still a pro-software-patent company at the time. Google can't rewrite history seven years later. If Google ever relied on Nokia's pledge (which is highly unlikely anyway, but let's assume it for the sake of the argument), it was sufficiently sophisticated to understand its limitations.

Another limitation of Nokia's 2005 patent pledge was that it covered only "patents and patent applications with a priority date of 31 December 2005 or earlier".

So far, Google hasn't named even one example of a Nokia patent with a priority date of 12/31/2005 or earlier being asserted against the Linux kernel (as opposed to Android). There may not even be such an example, and if this happened post-sale, the pledge was clearly never meant to apply. Given that I realized it from the outset, Google could easily figure it out as well. At any rate, if there are any assertions against the Linux kernel (as opposed to Android), I'm sure the kernel developers would want to know. Google should make the information public so that the kernel developers can look for ways to work around the asserted patents. Since Google is probably the largest-scale Linux exploiter in the world (on its server farm and through Android), it actually owes the Linux kernel developer community a lot more than this.

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 and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

While waiting for an apparently hung jury to reach unanimity or render a partial verdict if that's what Judge Alsup decides, I'd like to address the misinformation that some people -- mostly because they're uninformed and misguided -- are spreading these days about "industry practice" in connection with the copyrightability of APIs.

It's not impossible, but it isn't trivial, to analyze "industry practice" in connection with the concept of copyrightability. It's easier to look at industry practice in connection with what an industry actually does (such as how willing it is to indemnify customers in a given scenario) than with what an industry thinks about a question like copyrightability.

Those commentators who most vocally claim to know what "industry practice" is don't even have a commercial software industry background (by contrast, I have negotiated numerous software license deals since the late 1980s and advised one of the most successful open source startups, MySQL AB, which was later acquired by Sun). At any rate, those commentators get things wrong. There are overwhelming signs that the commercial software industry and even many key contributors to open source projects like Linux have for a long time had an "all rights reserved" approach to API copyrightability. If it's hard to find examples of enforcement, that doesn't mean that there's no basis for it. Most IP issues are resolved before anyone files suit, and no one disregarded other people's IP in APIs to the extent Google does, so previously there wasn't even a comparable need for enforcement.

I will address this issue in a structure way, but before I do, let me just show you one slide -- page 77 of Oracle's opening presentation -- showing that Android chief Andy Rubin himself knew all along that Sun claimed copyright on the Java APIs:

Let's define "copyrightability" the right way

One mistake commonly found in some of the comments on API copyrightability is that the term itself is, purposely or for lack of better knowledge, misinterpreted.

If something is "copyrightable", it means that it can be copyrighted (meaning that it's not categorically excluded from copyright protection), not that it must be copyrighted in 100% of all cases. The word "copyrightability" is the noun for "the state of being copyrightable", not for "the state of being definitively copyrighted", which would be "copyrightedness" (a word that I never heard, so I just coined it).

No one doubts that paintings are "copyrightable". But what about this one?

This is simply a blue square. I created it in a matter of seconds and can't claim copright in this because it's too trivial, chances are many other people drew a square in this shade of blue before me, and it would be insane to let anyone monopolize a square. Still paintings are copyrightable, and this includes paintings consisting of colored squares. For example, this link points to the official Guggenheim website, and you can see a picture consisting of squares, from the Josef Albers collection named "Homage to the Square". You can find another picture from that collection on Wikipedia. No one will seriously doubt that those pieces of art are unprotected only because my simple blue square isn't copyrightable.

On Tuesday I explained that the structure, sequence and organization (SS&O) of computer programs, including APIs, have been copyrightable in the Ninth Circuit (which includes California) for more than 22 years under the legal principle stated in the Johnson Control v. Phoenix Control Systems ruling. That's absolutely correct. It's 100% correct, even if not 100% of all people want to admit it or have the ability to understand that it's correct. Nothing is changed about that by the fact that the appeals court evaluated a motion for a preliminary injunction: the appeals court took a definitive position on a legal principle that applies to all cases, and the principle is that not only the literal elements of a computer program but also its SS&O are copyrightable. Nothing is changed about that by the later Supreme Court decision known as Feist v. Rural. Much to the contrary, the Feist decision upheld the concept that non-literal elements of a computer program are copyrightable and pointed out that the non-literal elements must meet the originality criterion, but a minimum level (or "spark") of creativity is sufficient for that purpose. That's a ringing endorsement of the Johnson Controls logic. So there are some incompetent and/or dishonest people out there you shouldn't trust. They can accuse me of bias, but if I had to be afraid of that accusation, why would I be as transparent as I am? Because I'm comfortable being judged by the substance of what I actually say.

Getting back to the paintings consisting of squares, the Java APIs are far more creative than most paintings -- they're huge and would fill an entire museum if printed out. Obviously that's a different field: creativity in software design is different from creativity in the fine arts. But the principle for copyrightability applies: there must be a "spark" of creativity, which is lacking from my blue square but undoubtedly found in Josef Albers' "Homage to the Square" series.

For a recap in a nutshell, copyrightability means that something can be copyrighted if it meets other criteria (especially originality): neither are APIs guaranteed to be copyrighted just by virtue of being APIs nor are they categorically excluded from copyright protection just because they're APIs. It depends on those other criteria.

Judge Alsup has in recent days asked the parties' counsel some additional questions with a view to SS&O copyrightability, and those questions show that he tries hard to understand what kind of originality and creativity went into the creation of the Java APIs (as opposed to non-creative elements dictated by technical requirements).

In the whole debate, it often happens that people raise issues that are separate from the question of API copyrightability, such as fair use considerations or other theories, and have to be addressed subsequently, not simultaneously. But let's not get into that now because this here was just meant to lay a necessary foundation for the discussion of "industry practice" in connection with API copyrightability. Using the proper definition I just discussed, the question for "industry practice" must be whether the actions and statements of industry players suggested that the SS&O of APIs are categorically excluded from copyright protection or whether the SS&O of APIs are at least potentially subject to copyright protection, depending on the specifics of each case.

All rights reserved: copyright notices on APIs

API specifications, such as source code files consisting exclusively of API definitions, typically come with copyright notices. By attaching a copyright notice to something, an author can't lower the bar for copyright protection: all requirements, such as originality, are still the same. But here we're talking about what the industry at large thinks. And in the software industry, it's hard to find code files without a copyright notice.

The screenshot I showed further above proves that even Andy Rubin was full well aware of the copyright Sun claimed in its APIs. In addition, Rubin had to admit in one of his depositions that his previous company, DANGER, which also did a mobile platform, took a license from Sun that included a license to the Java APIs. I'll talk about license agreements in the next section.

Here's another slide from an Oracle presentation to the jury (slide 63 of Oracle's closing presentation on copyright), and you can see that Bob Lee, Google's former lead developer for the Android libraries, affirmatively said that he saw the copyright notices on the Java APIs:

Last year I looked in detail at the Linux API, and quite interestingly, there are copyright notices in a number of Linux API files, even though the maintainers of the Linux project, including Linus Torvalds himself, have a rather liberal attitude toward how those files may ultimately be used by third parties.

But in all those 25+ years in the industry, I've never ever seen an API code file that contained an author's non-copyrightability notice.

The first time I ever saw a denial of copyrightability in connection with APIs was -- which is not a coincidence -- when I looked at Google's highly questionable use of Linux API material in Android. Countless API files in Android contain the following notice:

"This header was automatically generated from a Linux kernel header of the same name, to make information necessary for userspace to call into the kernel available to libc. It contains only constants, structures, and macros generated from the original header, and thus, contains no copyrightable information."

Again, nobody else did this before Google. Google departed from the established industry practice of attaching copyright notices to API files by doing the very opposite and replacing even existing copyright notices with a (legally erroneous) non-copyrightability claim.

Oracle's lawsuit against Google is perfectly consistent with the industry's (including Sun's) practice of claiming copyright in APIs. What Google and some of its supporters in the public debate claim is a total departure -- in fact, a 180-degree turnaround -- from that practice. Oddly, those who want a fundamental change claim that the court's confirmation of established practice would constitute major change.

License agreements: comprehensive licenses and API licenses

Like I said before, I've negotiated numerous software license agreements over the last 20+ years. In general, both parties to a license agreement -- the licensor and the licensee -- are interested in a comprehensive definition of the rights involved. As a result, software license agreements typically list all sorts of intellectual property rights. For example, I negotiated many software license agreements that listed "patents" even in cases in which the licensor didn't hold any since he might have filed or acquired some later on or could have been acquired by a company that previously held such patents.

In most cases, software license agreements cover all components of a complete product. In that case, there's simply no need to address the scenario of someone using only the APIs: they're part of the package, which can be used subject to the terms of the agreement, and if someone used them without a license, it would be an infringement because the license covers only the product as a whole. Most commercial software license agreements don't allow any modifications and "clean-room implementations" anyway.

Open source licenses are more liberal, but in Google's case, they don't apply (for the reasons I explained in this recent post). But even if someone puts an API under an open source license, that is a clear expression of the belief that the API is coprightable: something that isn't copyrightable can't be put under any license, no matter how restrictive or liberal the license may be, any more than one can nail together water.

The only way that any license agreement could declare something non-copyrightable is by saying so, not by putting something under a permissive, liberal license. And I've never seen any author do that.

Now let's talk about licenses that don't cover entire software products but instead relate to APIs. It's hard to find examples in which APIs can be licensed separately from a complete product, but Java is such an example. And in Java's case the situation is crystal clear: even Andy Rubin had to admit that he once took (at DANGER, not at Google) a license that included a license to the APIs, and he was always aware of the fact that Sun believed even "clean-room implementations" needed a license.

Not surprisingly, industry practice relating to copyright notices is perfectly consistent with industry practice relating to license agreements.

Actual use of APIs

Even if (contrary to what is actually the case) everyone used APIs as if they weren't protected by any intellectual property rights, that still wouldn't mean that everyone believes they aren't copyrightable: it could simply be attributable in all (or almost all) of those cases to other assumptions, such as the belief that license agreements allow a particular form of use or that it's "fair use", which is a separate question from copyrightability.

There is a way in which every programmer uses APIs without usually thinking about legal implications: if you write a program (an application) for an operating system like Windows or Linux, you will most likely compile some of the operating system's API material into your own application. Still the maker of the operating system won't go after you for a copyright violation just because of this way to use APIs. In this case, you simply do what the APIs are supposed to enable you to do.

Google's use of the Linux and Java APIs in Android is, however, fundamentally different. Google doesn't just create applications. Instead, it creates -- and distributes -- alternative platforms that aren't fully compatible. You can't take an Android app and run it on non-Android Linux. You can't take an Android app and run it on non-Android Java.

If you build a Linux or Windows application, the result is something can be used in conjunction with Linux or Windows, but you don't create an alternative system and you don't redistribute modified versions of those third-party APIs as part of what you make available. You just use what you need to use in order to make your application work.

In the Java community, it was accepted for a long time that a "clean-room implementation" of Java still required a license -- and that license agreement also related to the APIs and came with a requirement to stay 100% compatible.

Considering the enormous success of Android, no company has ever "hijacked" APIs on the scope and scale that Google has done it to Linux and Java. But I'm not even aware of any smaller-scale attempts to use API material in order to redistribute incompatible APIs.

To the extent that Google points to such initiatives as GNU Classpath, the fact that Sun didn't sue the GNU Foundation (or Apache for the non-licensed Harmony project) doesn't mean much either. By not suing, a company doesn't give up its copyrights. So far, no one has really sued open source projects. Sometimes those projects don't even correspond to legal entities you can sue but consist of individual developers. Now imagine the negative publicity a company would get for suing individual programmers (a patent troll named Lodsys did that last year, and is still doing so). Even a lawsuit against a non-profit foundation like GNU, Apache or Mozilla (though some of those foundations have greater financial resources than many companies) wouldn't look good. Commercial software companies typically let those open source foundations and projects do a lot of things that they don't accept if another commercial entity does them, especially if it does them on a large scale.

For example, here's a letter that Yahoo! sent to Facebook a couple of weeks ago. It claims that 16 Yahoo! patents may be infringed by Facebook's server infrastructure. Facebook's server software mostly consists of open source components, and if those patents read on anything runing on Facebook's server, that's most likely the open source stuff running there. Yahoo! targets Facebook, a commercial entity -- not the open source foundations or the individual open source programmers involved with the creation of those technologies.

I challenge all those who claim that treating APIs as unprotectable material is "industry practice" to provide actual examples of Google-style disregard for intellectual property in APIs. Show me the non-copyright notices that authors attach to their own code, or show me other companies than Google explicitly denying copyright through the kinds of notices Google attached to the Linux kernel headers. Show me the license agreements that state they don't relate to APIs because those aren't protected. Show me other commercial players who redistribute API material without a license. If you can come up with credible, verifiable examples, we can talk about "industry practice". But the fact that there wasn't another high-profile lawsuit over a hijacked API doesn't mean anything: there simply wasn't a need for anyone to bring such a lawsuit because no hijacked API ever reached a level of commercial significance even remotely comparable to that of Android. New types of conduct require new types of lawsuits.

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 and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

I'm starting to see a pattern. For any intellectual property issues facing Linux (or at least the most popular Linux derivative, Android), Linus Torvalds has a standard answer at hand: after admitting that he doesn't know the facts, he claims that "this [whatever it may be] seems completely bogus." Or, interchangeably, "totally bogus".

If he did this only in private conversations, there would be nothing wrong with it. Everyone may opine on anything, with or without conducting in-depth analysis. But an authority like Linus Torvalds doesn't act responsibly by repeatedly giving interviews that are as ignorant as they are assertive. He may not mean to mislead anyone, but the problem is that there's no shortage of people out there who think that he's the ultimate authority on anything Linux-related (such as Android) from whatever angle.

I truly admire his achievements. His brainchild is not only ubiquitous but also a key competitive force. Seven years ago, Linus Torvalds officially supported a statement against software patents that I had drafted. But more recently I was disappointed at two interviews in which he dismissed Android-related intellectual property issues that require a lot more thought, and may ultimatly have further-reaching ramifications, than he is willing to admit:

• In March 2011, he told ITWorld's Brian Proffitt that an analysis according to which Android's incorporation of Linux kernel header material raises copyright and, consequently, GPL copyleft issues "seems totally bogus", even though he admitted that he hadn't "looked at exactly what Google does with the kernel headers".

• Toward the end of a videotaped 40-minute interview with Muktware editor Swapnil Bhartiya at the recent LinuxCon Europe, Linus Torvalds was asked about Oracle's intellectual property infringement lawsuit against Google and said that he "[doesn't] actually know all that much about that", but nevertheless stated that "it seems to be completely bogus" (minute 39).

The problem is that both of these intellectual property issues are serious and deserve a lot more thought. If someone doesn't want to spend the time to understand them, there's no way anyone can be forced to speak out.

API copyrightability requires case-by-case analysis

Concerning the first issue, I strongly recommend this recent blog post by intellectual property litigator Edward Naughton of the Brown Rudnick firm and, even more so, his 15-page White Paper entitled "Bionic Revisited: What the Summary Judgment Ruling in
Oracle v. Google Means for Android and the GPL". That analysis makes reference to Judge William Alsup's near-complete denial of Google's motion for summary judgment against Oracle's copyright infringement claims. Google had argued that the Java APIs aren't copyrightable as a matter of law. In fact, Google wanted another bite at the apple and very recently asked for permission for another motion on summary judgment on the asserted non-copyrightability of Oracle's Java APIs, but yesterday the judge told Google (as well as Oracle) that he would leave this kind of question ot the jury.

One can argue that a denial of a summary judgment motion asking for one particular declaration doesn't necessarily mean that the opposite of that declaration is true. Fair enough. But as Edward Naughton explains in his analysis, the way Google makes use of Linux header material in Android is legally based on the assumption that all such material is, by definition, not copyrightable. If such a sweeping assertion is a cornerstone of an IP strategy, its proponent must be able to win on summary judgment -- a jury trial comes with considerable case-by-case uncertainty. The same applies to Linus Torvalds's dismissal of any related issues as "totally bogus".

As I noted, the ruling in Oracle v. Google is related to the Java APIs, not to the Linux APIs. But a general claim of certain material, regardless of its size and its arrangement, being uncopyrightable must be true for all APIs or it's simply not reliable. Also, I have looked at many Java API files and many Linux API files, and the case for copyrightability appears considerably stronger in the case of the Linux header material used in Android's Bionic library than in the Java case. If Google can't even defeat a claim of copyrightability with respect to 37 Java API files, how can it do so for more than 700 Linux header files? Also, the Linux header files contain inline functions that are particularly likely to be copyrightable, and I didn't see Oracle raise a similar argument in its Google lawsuit.

Google's own developers didn't believe that Oracle's claims are bogus

Linus Torvalds's assessment that Oracle's lawsuit is "bogus" is belied by Google's own internal analysis. In August 2010, the same month in which Oracle brought its lawsuit, Google engineer Tim Lindholm wrote a now-famous email in which he said that Google "need[s] to negotiate a license for Java".

In the Muktware interview, Linus Torvalds makes reference to a blog post by Jonathan Schwartz. In an analysis of the state of Google's 20 affirmative defenses against Oracle's complaint, I also commented on Google's equitable defenses and said that the related blog post doesn't look to me like a license grant or a waiver of any right. I'm sure that if Judge Alsup thought the related blog post was a basis for dismissal of the entire lawsuit, he'd have done so a long time ago in order to save court resources.

There's never a guarantee for the outcome of a complex litigation, and as I said more than once, Oracle will have to prove its infringement claims and fend off Google's attacks on the validity of the asserted intellectual property rights. That will require some highly technical analysis. I doubt that Google can defeat all of Oracle's claims, but it will be up to the jury. That still doesn't mean that Oracle's accusations are "bogus".

There's no doubt that most of Oracle's patents-in-suit are under reexamination pressure, and it remains to be seen how many of the asserted patent claims will ultimately be affirmed. First Office actions are, however, only preliminary, so it would be premature if anyone wanted to defend Linus Torvalds's "bogus" assessment on the basis of those ongoing reexaminations.

I have asked Scott Daniels, an experienced patent litigator and author of the WHDA Reexamination Alert Blog, whether he thinks the current state of those reexaminations indicates that Oracle's lawsuit doesn't raise serious issues. This is what Scott said:

"[...] I cannot believe that the law suit is contrived or bogus. It is easy for parties to settle and end District Court litigation. But peaceful resolution of a reexamination is not normally possible. Even where the inter partes requester decides not to participate, the PTO [Patent and Trademark Office] continues the reexamination on its own. Here, even if Oracle settled with Google, the Oracle patents would continue to be at risk in reexamination. And the risk is not confined to the specific prior art references and arguments presented by Google in its Requests. The PTO is free to reshape Google's arguments and to assert additional references. Moreover, a third party could be provoked to enter the fray by filing its own reexamination requests that would likely be merged with the Google reexaminations. The fact that the reexaminations are beyond the control of the parties suggests, to me, that the conflict is real."

The above quote may seem complicated to many people, and one could devote a whole blog post to the issues it addresses. But that's not necessary in this context to show that there are complicated and serious issues on the table -- as opposed to "bogus" claims.

Some open source leaders see SCO in everything

The simplest explanation of Linus Torvalds's attitude -- and a reasonably likely one to be true -- is that some open source luminaries appear to suffer from SCOphobia: after they experienced the Santa Cruz Operation's lawsuits over allegations of copyright infringement by Linux, they now think that there must always be some enemies of Linux at work whenever intellectual property issues facing Linux (and its derivatives, such as Android) come up.

Knee-jerk reactions are not a substitute for thorough case-by-case analysis. Whatever one may think of the merits of SCO's case, the Bionic issue (Linux headers) and Oracle's lawsuit are unrelated to it.

In closing, I would like to quote a very good point that now-assistant law professor Sapna Kumar made at a June 2007 TriLUG (Triangle Linux User Group) meeting -- you can find that statement after 12:20 in this YouTube video:

"What the GPL is isn't what Richard Stallman tells you it is. It isn't what Eben Moglen says it is or what I say it is. It's really what judges say it is."

And I would add that the GPL isn't what Linus Torvalds says it is. Even bogus isn't what Linus Torvalds says it is.

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 and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

About a year ago -- on May 18, 2010 to be precise -- Microsoft sued Salesforce.com "for infringement of nine Microsoft patents by their CRM product." Apparently Salesforce.com had refused to enter into a royalty-bearing license agreement. About five weeks later -- on June 24, 2010 -- Salesforce.com countersued Microsoft over five patents.

The assignment history of those patents shows that three of the patents asserted by Salesforce.com had been assigned to it on May 3, 2010 by the Open Invention Network (OIN), a patent pool company that claims to protect Linux.

On the same day, the OIN had also given Salesforce.com a fourth patent, but for whatever reason Salesforce.com decided not to assert that one against Microsoft.

The dispute was settled another six weeks after Salesforce.com's countersuit: on August 4, 2010 Microsoft made this announcement, according to which "Microsoft indicated that it is being compensated by Salesforce.com based on the strength of Microsoft's leading patent portfolio in the areas of operating systems, cloud services and customer relationship management software." In other words, Salesforce.com came out on the losing end regardless of OIN's patent gift.

The OIN usually likes to brag about how it thwarted Microsoft's allegedly Linux-hostile plans and helped TomTom (although that's highly doubtful, given that the outcome was like in the Salesforce.com case and Microsoft ended up receiving royalties). But very interestingly, the OIN never talked about its transfer of patents to Salesforce.com. This raises important and serious issues concerning not only the questionable effectiveness and unquestionable opacity of the OIN but also this defensive-patents-on-demand kind of service, which other patent pools such as publicly-traded RPX Corp. offer as well. With so much patent litigation going on, there will be more lawsuits down the road in which patents checked out from pools will be asserted.

The patents at issue in the Microsoft-Salesforce.com dispute

I looked at the nine patents Microsoft asserted against Salesforce.com. While Salesforce.com runs its server farm on Linux, none of those nine patents appears to me to be specifically Linux-related. There are various Microsoft patents (such as the FAT patents) that definitely read on the Linux kernel, and the aforementioned announcement of the settlement suggests that Salesforce.com is now paying Microsoft royalties for using Linux, but the nine patents Microsoft asserted against Salesforce.com in court appear to cover typical cloud and web service functionality (though only detailed claim charts could provide absolute certainty concerning the actual infringement patterns).

Therefore, the OIN's involvement with this dispute was in a gray area, which could be part of the reason why the OIN never talked about it. The OIN claims to protect Linux (according to its own arbitrary and changing "Linux System" definition). Salesforce.com's cloud software running on top of Linux was never part of that definition. Nevertheless the OIN apparently interpreted Microsoft's patent suit against Salesforce.com as a Linux issue. Since the OIN gave Salesforce.com those four patents even before Microsoft's suit, it's possible that the OIN and Salesforce merely expected Microsoft to sue over Linux-related patents.

These are the assignment records of the four patents the OIN transferred to Salesforce.com in the midst of the dispute (but prior to the first formal lawsuit):

• U.S. Patent No. 6,813,633 on a "dynamic multi-level cache manager": initially (2002) assigned to a company named Foedero Technologies in the Canadian province of Ontario; later (2004) assigned to another Ontario entity named Avokia Inc.; in 2009, acquired by the OIN, and transferred to Salesforce.com on May 3, 2010 (recorded on June 17, 2010)

• U.S. Patent No. 6,918,059 on a "method and system for handling errors in a distributed computer system": initially (2000) assigned to the world's largest record label, the Universal Music Group, whose name and address was incorrect in the original record and corrected in 2005; acquired by the OIN in 2010 and sold to Salesforce.com on May 3, 2010 (recorded on June 17, 2010)

• U.S. Patent No. 7,024,454 on "work sharing and communicating in a web site system": initially (2001) assigned to a company named Practicefirst.com, LLC, which may have been a different entity than the current owner of that Internet address; acquired by the OIN in 2008; sold to Salesforce.com on May 3, 2010 (recorded on June 17, 2010)

• U.S. Patent No. 7,251,745 on "transparent TCP connection failover": this patent was initially (2003) assigned to Eternal Systems, Inc. in San Jose, California; reassigned in 2005 to a company named Availigent, Inc. in the same city; acquired by the OIN in 2008; sold to Salesforce.com on May 3, 2010 (recorded on June 17, 2010); this is the ex-OIN patent that Salesforce.com did not assert against Microsoft

The two non-OIN patents asserted by Salesforce.com against Microsoft were U.S. Patent No. 7,209,929, an original Salesforce.com patent on a "Java object cache server for databases", and U.S. Patent No. 7,305,454 on an "apparatus and methods for provisioning services", which was filed by a company in San Francisco and changed hands a few times (mostly within the same building) before being acquired by Salesfore.com in 2007.

Checked-out patents are better than none -- but not the strongest weapon

If a company doesn't have enough patents of its own to assert, it may try its luck with patents checked out from pools. Apparently Salesforce.com had only one internal patent that it thought it could assert against Microsoft, plus one it acquired a few year before, so getting patents from OIN was necessary to put together a set of five patents, which looked reasonably solid just based on the number.

In principle, a patent can be transferred and asserted on the same day. It's not against the law, but is it effective?

I'm sure that every litigator will prefer to assert patents that can be portrayed to a judge and a jury as rights related to legitimate internal inventions. It's much better in psychological terms to ask the courts for help if someone else (allegedly) infringes on one's own intellectual property.

If the dispute between Microsoft and Salesforce.com had gone to trial, Microsoft's lawyers could (and probably would) have pointed out to the judge and the jury what the history of those patents was. In that case, Salesforce.com could have told the story of how it needed to acquire those patents for defensive purposes. But no matter how much the concept of mutually assured destruction (or mutually assured damage) is a reality, it's just not the story you want to tell a judge and a jury when it comes to why you ask for an injunction and a damage award. In that scenario you want to be as close as possible to the lone inventor whose rights someone else blatantly disregards.

Besides the psychological aspect of this, the legal position of a patent holder can't be better than if the right holder actually practices the invention (such as by selling products on which the patent reads). Of course, if one acquires a patent and practices the invention, then the fact that the patent wasn't "homegrown" makes only a psychological difference. But it's not easy to find and acquire patents covering inventions one actually practices.

The Salesforce.com patent transfer raises serious questions about the OIN

I previously pointed out that the OIN apparently transferred four of its patents to Salesforce.com even before Microsoft had formally sued, and I can't see a clear Linux context in Microsoft's lawsuit (only in the announcement of the settlement). Interestingly, Salesforce.com was not even an OIN member or licensee at the time of that transfer. It isn't on the list of OIN licensees even now that I write these lines (more than a year after the transfer). Unless the OIN did a clandestine agreement with Salesforce.com, this means that Salesforce.com got support from the OIN (even though that support apparently didn't have much impact) but would still be free to assert its own patents against any current or future OIN members. That seems very unbalanced and questionable. By contrast, TomTom became an OIN member during its dispute with Microsoft.

It's generally disconcerting that the OIN secretly sells some of its patents to third parties. The OIN portrays its patent purchases as a way to ensure certain patents don't fall in the hands of "trolls" or strategic enemies of Linux. But if the OIN sells patents to non-members and non-licensees like Salesforce.com, it's possible (unless the OIN took precautionary measures it never talked about) that those entities might sell those patents on to other parties who could use them against OIN members, at least in non-Linux contexts. In that case, the OIN would end up contributing -- indirectly -- to the rampant troll problem.

I believe the OIN owes its licensees -- some of whom have supported it for years now -- an explanation as to the criteria by which the OIN lets others check out some of its patents for the purpose of countersuits and counterclaims. It's a safe assumption that Microsoft's settlement with Salesforce.com (since the announcement suggests it's a mutual license to the companies' entire portfolios) precludes any future assertion of those patents against Microsoft. So the OIN believes certain patents are useful for countersuits and counterclaims, it would have to use them wisely. It should usually reward the loyalty of long-term supporters, but in this case it came to the aid of an entity that never supported the OIN in any official way. (Maybe Salesforce.com would have joined the OIN if those patents had been any good.)

All patent pools have the problem that a patent can only be checked out by one licensee/customer at the same time. By giving those patents to Salesforce.com, the OIN made it impossible for any of its supporters to have access to those patents if they had needed them at the same time.

And there's the question of openness. If an entity calls itself the Open Invention Network and claims to be a guardian of open source, it should be reasonably transparent. If it transfers patents, it should tell its licensees that it did so, and specifiy why and on which terms such a transfer took place. The Salesforce.com patent deal went almost completely unnoticed. The only mentioning of that deal that I was able to find on the Internet was on a Japenese CNET blog.

The OIN is preparing a major reform, and I hope "OIN 2.0" will then be more forthcoming about its dealings -- including its defeats.

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: