Showing posts with label OIN. Show all posts
Showing posts with label OIN. Show all posts

Friday, December 20, 2013

Latest move in Google's erratic patent strategy: upgraded Open Invention Network membership

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

Share with other professionals via LinkedIn:


Tuesday, May 31, 2011

The OIN gave Salesforce.com four patents to assert against Microsoft

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:

Wednesday, April 20, 2011

US Department of Justice announces modified Novell patent deal

The United States Department of Justice (DoJ) just announced that a deal that originally envisioned the sale of 882 Novell patents has been modified in order to address its concerns. The DoJ also announced close cooperation in this regard with Germany's Federal Cartel Office (FCO; German name: "Bundeskartellamt").

[Update] The German FCO made an announcement of its clearance decision that is materially consistent with the DoJ's announcement. [/Update]

In formal terms, the DoJ's work is not yet finished: its Deputy Assistant Attorney General Sharis Pozen said that "the department will continue to investigate the distribution of patents to ensure continued competition." But in practical terms, this looks like a done deal, and Novell's stock price is now only a hair's breadth below the $6.10 per-share price to be paid by Attachmate, the acquirer of Novell as a company.

[Update 2 on Apr 21] Novell's latest SEC filing just announced that the formal consummation of the patent deal as well as Novell's acquisition is now scheduled for April 27, 2011. Apparently that will be the date barring any unforeseeable events. [/Update 2]

The announcement by the DoJ essentially reaffirms what I blogged about two weeks ago with only smaller changes:

  • The DoJ refers to "approximately 882 patents". A Novell SEC filing revealed a few months ago that there was some disagreement resulting from the fact that Novell originally listed some patent applications that were withdrawn or rejected. There were talks between the parties about whether to replace those assets with others, or whether to adjust the price. The word "approximately" suggests that the number may have changed, or may still change, but only slightly in all likelihood.

  • There are 33 (not 31 as originally announced by the OSI) virtualization-related patents that EMC won't get to acquire.

  • The fact that Microsoft will effectively sell back its allotment of patents is not new. The DoJ's announcement just makes it clearer than the OSI's recent statement that Microsoft is granted a license to all of the patents changing hands (including the roughly 200 patents that Microsoft will own temporarily) as well as "any patents retained by Novell." Considering that Microsoft for hundreds of new patents every month, it seems obvious that they don't have to acquire a couple hundred Novell patents in order to beef up their own patent portfolio. By contrast, Google with its relatively small portfolio would have benefited from such an acquisition in a more significant way, relatively speaking.

  • The DoJ mentions some provisions according to which CPTN Holdings LLC and its owners (Apple, EMC, Microsoft, Oracle) won't be allowed to interfere with Novell's relationship with and commitments to the Open Invention Network. In other words, after the acquisition it will be the prerogative of Attachmate (Novell's acquirer) to make a determination concerning Novell's post-acquisition relationship with the OIN. Maybe the original agreements stipulated that Novell would leave the OIN, or maybe there wasn't any such provision but the DoJ was afraid of the patent deal affecting Novell's partnership with the OIN. In my opinion, the flood of patent lawsuits especially in the smartphone space shows that the OIN doesn't deter anyone from asserting patents against Linux and Linux derivatives like Android. Therefore, whether or not Novell continues to be an OIN member doesn't matter too much.

  • There's one item in the DoJ's announcement that isn't clear without knowing the details:

    "All of the Novell patents will be acquired subject to the GNU General Public License, Version 2, a widely adopted open-source license, and the Open Invention Network (OIN) License, a significant license for the Linux System"

    Novell made some commitments "subject to" the GPL and the OIN license in the past. It's not clear to me inhowfar the DoJ imposed anything new on Novell or any of the acquirers beyond already existing obligations.

    In its criticism of the deal, the OSI, FSF and others claimed (not for the first time) that they believe the GPL is incompatible with obligations to pay patent royalties. However, the DoJ's announcement doesn't necessarily say that the acquirers of those patents are now required to make those patents available on royalty-free terms to publishers, distributors or users of GPL'd software.

    My guess is that the DoJ didn't support those claims by OSI and FSF that royalty-free is the only GPL-compatible option, just like the European Commission also found that royalty-bearing patent license deals can be structured in open source-compatible ways. In other words, some royalty-bearing deals may not work for open source, but others do. Per-unit royalties could be difficult given the way open source software is shared, but fixed royalty amounts or royalties relative to a company's revenues are possibilities.

    There's a perfect example of patent royalties that were paid on software distributed under the GPL: Red Hat's $4.2M FireStar settlement, which is mostly a patent license deal (just with additional provisions to withdraw a lawsuit). In Eben Moglen's opinion, the related deal would have been compatible even with the GPLv3. I assume that such GPL-compatible patent license deals would still be a perfectly valid option for the companies acquiring those Novell patents if they find GPL'd software to infringe any of those patents. But I don't know what exactly the revised patent purchase agreement stipulates (except for what the DoJ just announced, which is vague).

If any additional details become known, then there may be more clarity concerning the "subject to" language. For now this is all a bit speculative. It also remains to be seen inhowfar the regulatory intervention in this case could backfire on some of the complainants should similar issues ever come up in connection with the aforementioned OIN. Regulators didn't seem to care much about the secondary market of patents in the past. They apparently raised concerns (whether or not those would have been defensible in court is another question) in this case, and who knows what questions may come up in connection with the sale of Nortel's patent portfolio.

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:

Thursday, November 25, 2010

Attachmate, Novell and the sale of 882 patents to CPTN Holdings, a consortium organized by Microsoft

On Monday I attended a European Commission and European Patent Office conference on intellectual property rights and standardization (I blogged about it) when the long-awaited acquisition of Novell was announced. I received questions about it but for lack of information wasn't able to say anything of substance at that point.

Relatively speaking, it's easier to comment on new patent suits because once one obtains a copy of the complaint, there are usually various aspects worth looking into.

Just so you're not disappointed if you read further: there still isn't anything spectacular or dramatic about this Novell transaction and I guess there never will be. But it is an important deal for open source, so I'll sum up what I've read and what I think so far. Let's talk about the projects first, then the patents.

Mono

Miguel de Icaza, a Novell vice president who started the Mono project (a FOSS implementation of the .NET API) and previously founded the GNOME project, reassured the Mono community with this tweet:

"After the Novell acquisition, Mono continues as-is, but our paychecks will come from Attachmate instead of Novell."

A few months ago I disagreed strongly with Richard Stallman after I read an interview with Glyn Moody in which RMS said that developers "shouldn't write software to use .NET. No exceptions."

I don't know if any of those Mono critics will restate their baseless concerns, but at any rate, I believe that the acquisition of Novell is positive for Mono. It ends a period of uncertainty for the brilliant team Miguel leads. Miguel's blog indicates that they are being very productive these days.

SUSE and openSUSE

I remember the time when SUSE was capitalized differently ("SuSE") and often spelled with dots ("S.u.S.E."). That German Linux distribution used to be much more popular in Europe than Red Hat Linux. At an online gaming startup I co-founded and managed in the late 1990s, we used SuSE on our servers. I also ran SuSE on a computer at home (for MySQL).

Later, SuSE was acquired by Novell and renamed "SUSE" because people struggled with the lowercase "u" in the middle of an otherwise all-caps name although the SuSE team liked that kind of silhouette: they named one of their key differentiators YaST ("Yet another Setup Tool"). SoME SeEM To LiKE ThAt.

A few months ago I blogged about IBM's discriminatory pricing strategy in the mainframe business and mentioned z/Linux, the mainframe version of Linux. SUSE has been the market-leading mainframe Linux distribution all the time and still has a market share of 80% (worldwide).

I'm sure that SUSE is a pretty substantial part of the value that Attachmate saw in the acquisition. There's a lot of potential to narrow the gap between SUSE and Red Hat. For a company that doesn't own much intellectual property, Red Hat's margins are unbelievably high, suggesting to me that SUSE has a world of opportunity if it executes well. An open source model doesn't guarantee low prices all by itself: market dynamics still depend on effective competition.

Attachmate has already emphasized that SUSE will be run as a stand-alone business unit, and that the openSUSE community project "is an important part of the SUSE business" and "no change to the relationship between the SUSE business and the openSUSE project" is expected as a result of this deal. Pascal Bleser, a leader of the openSUSE project, writes on the official openSUSE blog that "the openSUSE Project has had, since its beginning, a very vibrant cooperation with Novell, especially with Novell’s SUSE business". Now he and his team "are looking forward to continuing this once Novell and SUSE become part of Attachmate!"

882 patents to be acquired for $450 million

My focus on this blog is on how patents get used -- from an open source angle -- and not on the secondary market for patents. But I do know that numerous patents are on the auction block all the time: some are sold individually or in smaller packages, others are sold in large blocks. Deals come in all sizes. For example, a Morgan Stanley analyst estimated six months ago that a portfolio of 4,500 Nortel Networks patents and 1,000 patent applications was worth in excess of $1 billion.

The structure of the Novell deal appears to be such that Attachmate pays $6.10 in cash per share of Novell (NASDAQ:NOVL) shareholders, a total of approximately $2.2 billion. Since Novell has, according to certain reports, cash of approximately $1 billion in the bank, this means an "enterprise value" of approximately $1.2 billion. The price to be paid already takes into consideration that a Delaware company named CPTN Holdings LLC will acquire "all of Novell's right, title and interest in 882 patents [...] for $450 million in cash" (I quoted from the SEC filing related to the acquisition, to which the merger agreement is attached).

A list of those patents is not available. Some have pointed out that 882 is a greater number than that of all patents registered in Novell's name with the USPTO. This led some to believe that the number includes some patent applications, and it may. It's also possible that Novell acquired the ownership of some patents that have not yet been re-registered in its name.

But the one piece of information that could make a major difference is whether that count relates to 882 patented inventions or 882 per-jurisdiction patents. Software patents are granted in almost all of the industrialized world. In an analysis of international equivalents of patents over which Apple, Paul Allen's Interval Licensing and Oracle are suing other companies, I gave examples. I found that a certain Apple touch-screen software patent was filed for in the United States, Canada, China, South Korea, Japan, Australia, and 34 European countries. Depending on the approach, this could count as 1 patent, 7 patents (if Europe counts as one patent because of a centralized examination process at the EPO) or as 40 patents (since an EPO patent is a bundle of national patents, each of which results in additional costs, gets a separate patent number and would have to be enforced separately in its jurisdiction with potentially different outcomes; the number of countries in which an EPO patent actually gets registered varies greatly, with the 34 countries in that example being close to the maximum).

Financial structure: $2.2 billion for Novell minus patents plus $1.4-$1.5 billion

Attachmate offers to lay down $2.2 billion in exchange for a company that will, following the patent sale, have $1.4-$1.5 billion in the bank. That makes the transaction more affordable, and NOVL shareholders benefit because they will get to sell their stock at a price that is 28% higher than before a hedge fund named Elliott Associates (which already held a chunk of Novell shares at the time) made a buyout proposal. Attachmate's offer is 9% higher than the closing price on the last trading day before the Attachmate-Novell announcement.

Wall Street clearly believes in this deal. Yesterday NOVL closed at $5.93. This means that investors buying the stock now will -- all going well -- realize a 3% gain, which is a good deal for the "arbs" (risk arbitrageurs) if the deal closes quickly. They need a certain margin since every once in a while a deal may fall through for whatever reason and then they may have to sell their holdings with losses. A 3% margin so shortly after the announcement suggests that those professional speculators expect the deal to close on those terms relatively quickly. It's a nice margin for a virtually certain quick flip but wouldn't make sense otherwise.

It's also a good sign that Elliott -- whose buyout offer got the ball rolling earlier in the year -- "will become a shareholder of Attachmate under the latest offer" (as Zacks.com reports). Some thought Elliott's offer in the spring wasn't serious and was just meant to force a sale. However, by putting its money where its mouth is, that hedge fund shows it really believes in the longer-term value of the combined company and wasn't merely looking for an exit strategy concerning Novell.

In this financial context, let me restate a disclosure I previously made in connection with possible investments in mainframe software companies: at the time of publication of this posting, I do not own stock (or related derivatives) in any of the companies mentioned.

Patent holding consortium organized by Microsoft

The fact that Microsoft organized CPTN Holdings LLC, the consortium that agreed to buy those 882 patents, has made waves in the media. I have seen worries expressed over this fact in articles by Steven J. Vaughan-Nichols ("Dark horse Attachmate buys Novell, Microsoft helps"), Dana Blankenhorn ("Novell sale shows its control by Microsoft"), Katherine Noyes ("Microsoft's Hand in Novell Deal Bodes Ill for Linux"), Rob Enderle (who sees Red Hat and Google as "first targets" of a "creative" IP strategy), and Timothy Prickett Morgan, who asked:

"Novell shareholders have to wait to see exactly what Attachmate is selling off to Microsoft and then ponder the deal. Wouldn't it be funny if Microsoft ended up owning whatever rights to Unix that Novell thinks it has?"

The wait-and-see approach is right. Actually, the other journalists -- all of whom I really respect -- also made it clear where the facts end and their gut feelings begin.

CPTN Holdings LLC is a consortium organized by Microsoft but involving other "technology companies". Names, numbers and the allocation of shares are unknown at this stage, but it's certain that the decisions of the consortium will not be taken by Microsoft singlehandedly. That fact should actually give a lot of comfort even to those who don't want to trust Redmond.

No big difference

I previously commented on Microsoft's cooperative approach to patents and still can't see any reason to be particularly concerned about. (I could, however, put together a whole list of other patent holders I would be uneasy about.) Microsoft's dispute with Motorola is just one of many in the smartphone context. So even if Microsoft bought those patents directly as opposed to being just one of several shareholders of CPTN Holding LLC, I wouldn't be concerned.

Mary Jo Foley, famous for her intimate knowledge of Microsoft, looked into "Microsoft's role in the Novell-Attachmate deal" and quoted Horacio Gutierrez, Microsoft’s Corporate Vice President and Deputy General Counsel of Intellectual Property and Licensing, with a business-as-usual statement.

I just want to be rational. The prospect of a company that already owns about 15,000 US patents -- and uses them pretty reasonably -- acquiring indirect, partial ownership of hundreds more doesn't set off an alarm on my end. At their current rate (roughly 3,000 new US patent applications a year) they file for that number of new patents every quarter, and I'm sure many of those -- as well as many patents obtained and held by countless others -- read on some open source software.

Software patents are a fact of life. Even if all of those 882 patents were invalidated overnight, the patent threat to open source wouldn't be diminished in any noteworthy way.

I also don't subscribe to theories that the Open Invention Network plays any role in this transaction. The OIN doesn't appear to impact anything too much. I have yet to see a single verifiable success story involving the OIN. My guess is that Attachmate will look at all of the partnerships Novell has in place, continuing with those that deliver tangible value and revisiting those that don't. The patents that are sold to CPTN Holdings LLC will be outside the scope of the OIN, but that could happen to the patents of any other OIN member or licensee. Other OIN companies, especially IBM, are far bigger patent holders than Novell.

A year ago I warned against the acquisition of MySQL by Oracle. The FOSS community was divided, but today hardly anyone describes Oracle as a good steward of the open source assets it acquired. Some argued that the acquisition was a way to prevent Microsoft from acquiring Sun's patents and using them against open source, but Oracle's suit against Google proved that preference completely wrong.

I will continue to watch this process, of course, and I will discuss relevant new information if and when it becomes available.

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.

Sunday, October 3, 2010

The US International Trade Commission as a patent enforcement agency

Microsoft lodged its patent infringement complaints against Motorola with a "traditional" court (namely, the US District Court for the Western District of [the State of] Washington) as well as the US International Trade Commission (USITC, or often also referred to as ITC). The USITC has in recent years also become an important forum for patent infringement disputes but many of you may not have been aware of it until recently.

You may remember that Apple's infringement action against smartphone vendor HTC, which also takes aim at Google's Android smartphone operating system, was also filed (in March) with a court plus with the USITC. In May, HTC brought its own complaint against Apple before the USITC (not in court at that point).

So why do some companies take their patent complaints to the USITC, additionally or alternatively to a court of law? What implications does this have for the patent infringement suits surrounding Android? I'll explain.

A "quasi-judicial federal agency" that can exclude infringing products from entry into the US

On its website, the USITC describes itself as an "independent, nonpartisan, quasi-judicial federal agency". The term "quasi-judicial" means that it's very similar (but not identical) to a court of law.

Its court-like functions are only a subset of the USITC's activities. The USITC also conducts studies and statistical analysis and provides advice to the President of the United States regarding trade issues. Those functions complement the work that is done by the Department of Commerce and the Department of Agriculture. The USITC itself is, unlike those government departments, not a policy-making body, nor does it negotiate trade agreements with other countries.

The USITC describes its quasi-judicial role as follows:

The USITC makes determinations in investigations involving unfair practices in import trade, mainly involving allegations of infringement of U.S. patents and trademarks by imported goods. If it finds a violation of the law, the USITC may order the exclusion of the imported product from the United States.

The last sentence shows that the USITC really has teeth: it can order an import ban on products infringing patents (or trademarks, but let's focus on patents here).

The effect of such a ban is that any further attempt to import the relevant products can be stopped. Banned products can be seized at customs or after already having entered the market.

A fast track for US patent holders -- subject to certain requirements

If you're a US patent holder and meet certain requirements, the USITC can save you a lot of time when you seek an injunction against an infringer. In a court of law it will take you several years from filing to (all going well for you) an injunction. How many years depends on many factors, but it's most often a much longer time than the roughly 18 months within which you can prevail in front of the USITC.

If you meet the USITC's requirements, you can lodge a complaint with it in addition to a court proceeding. This makes sense, especially since the USITC isn't a full-fledged court. If it orders an import ban, such decision has an effect similar to an injunction ordered by a court. But a court of law can do more, such as ordering the payment of damages.

Similarly to a first-instance court, an USITC decision can also be appealed. Patent infringement matters can be brought before the Court of Appeals for the Federal Circuit (CAFC).

I said before that an import ban is similar to an injunction. The key difference is that it only relates to imports of goods from other countries. Unlike an injunction, it doesn't affect vendors who manufacture their products (or have them manufactured) within the US. In a market such as smartphone, in which almost everyone (even a household US name like Motorola) manufactures outside the US for cost reasons, an import ban is almost as powerful as a court injunction. By contrast, in a market like enterprise software, production either takes place in the US or could be relocated there easily in order to circumvent an import ban.

Not only can a USITC proceeding relate only to imported goods but a complainant also has to prove competitive harm. This means in particular that you must show that you actually practice, in the US market, the inventions protected by the patent claims you assert (such as by selling products that make use of them), and you must show that you compete with the infringer.

The USITC's role in the three patent infringement cases involving Android

I mentioned before that Apple was the first one to bring an Android case before the USITC. The patents Apple is asserting in a Delaware court are an entirely different group from the ones used in its complaint with the USITC. Microsoft, however, is asserting identical sets of patents in either forum, which is the most forceful method to begin with.

In between Apple's and Microsoft's filings, Oracle initiated its patent infringement suit against Google in a California court. That one relates to Dalvik, the virtual machine on which all (or almost all) Android apps run.

Unlike Apple and Microsoft, Oracle did not lodge a complaint with the USITC. It's not that Oracle lacks determination. While Apple and Microsoft assert their rights against vendors of Android-based smartphones, Oracle decided to pursue Google itself. Under patent law, Google can indeed be held responsible for all infringements resulting from its publication of Android. Oracle goes straight to the source (from a free and open source software point of view, that's actually scary). But it's also possible to pursue vendors. Theoretically, even commercial users of infringing goods could be sued.

For the USITC, however, Google wouldn't be an acceptable target because it isn't (anymore) a vendor of imported Android-based phones. If Oracle wanted to, it could additionally lodge complaints against vendors importing Android-based phones. I wouldn't be too surprised if that happened. Assuming that Google doesn't work things out with Oracle in the near term, that would be a way for Oracle to increase the pressure.

The Open Invention Network wouldn't have access to the USITC

Finally, let's also look at the Open Invention Network (OIN) in connection with the USITC. Since both Oracle and Google are OIN licensees, many people have begun to realize that the OIN doesn't serve its stated purpose of protecting Linux against patent infringement assertions.

The OIN previously made completely unconvincing claims about having deterred Microsoft from enforcing patents in a Linux context. The fact that such companies as Amazon.com, Salesforce.com and TomTom announced that they pay royalties to Microsoft is yet another indication that the OIN just doesn't work.

Now in connection with Microsoft vs. Motorola, the question of the OIN's effectiveness will be brought up again. It's worth noting that the OIN, a patent-holding company that doesn't practice its inventions, wouldn't be able to satisfy the USITC's domestic industry requirement. The OIN grants licenses but without generating revenues, likely without significant expenses in general, and it doesn't litigate. According to recent ITC jurisprudence, a licensing company needs to prove expenses in connection with licensing, and litigation expenses are considered an essential type of expenses for that purpose.

Given that the USITC is the fastest track to an injunction, this further limits the OIN's effectiveness.

In a court of law, the OIN wouldn't be able to obtain an injunction either. Under the Supreme Court's eBay vs. MercExchange ruling (which I discussed in this posting on Paul Allen's patent infringement action), the OIN would not be able to pass a critical four-factor test. It could seek indemnities, but it couldn't disrupt an opponent's business.

So there are also procedural reasons, in addition to other explanations, for which the OIN is unable to change the calculus of major right holders like Apple, Oracle and Microsoft. The USITC and its recent popularity is part of that consideration.

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.

Saturday, August 21, 2010

The Open Invention Network (OIN): Oracle vs. Google is its biggest debacle so far

Right after I learned about Oracle's patent infringement suit against Google, I pointed out that this was "another big failure for the so-called Open Invention Network" (OIN), an organization that claims (without any credible evidence) to protect the Linux ecosystem against patent threats.

The OIN has three stated goals, and a few commentators failed to look at all of them:
  1. The OIN buys up patents at auctions and licenses them for free to companies who accept its license agreement. This part isn't relevant to Oracle vs. Google. Oracle asserts seven patents that previously belonged to Sun but never belonged to the OIN.

  2. The OIN wants to serve as a deterrent because it might enforce those patents against other companies. Mutually assured damage. This isn't stated explicitly on its website but it's made pretty clear by some of its press releases, such as this one ("'We view an OIN license as one of the key methods through which open source leaders and innovators can deter software patent aggression,' said Lasse Andresen, CEO of ForgeRock.").

    Oracle sued Google without any fear of the OIN possibly enforcing against Oracle, as an act of retaliation, some of the patents it acquired. So the OIN has certainly failed on this count (until it proves the opposite, but I'm sure we won't see it happen).

  3. In the Oracle vs. Google context the most important fact is that the OIN, in addition to the two previous items which relate to patents the OIN itself owns (as a company), also tries to establish a plurilateral (multi-company) cross-license agreement with respect to those companies' patents. The OIN recently announced that by the end of last quarter 140 companies had acceded to its license agreement.

    What has failed here is primarily this multi-company cross-license agreement. If it worked, it would serve as a Linux-related cross license deal -- a patent peace treaty -- between (among others) Oracle and Google. But everyone can see now that it doesn't.

TheRegister quoted me on Oracle vs. Google, and I highlighted the OIN's failure.

Well-known FOSS advocates share the concern

I was the only vocal critic of the OIN's shortcomings for some time, but the fact that Oracle (one OIN licensee) decided to sue Google (another OIN licensee) over an essential component of Android has led others to also express doubts concerning the OIN's suitability-to-task.

Simon Phipps was formerly Sun's chief open source liaison and is now a ForgeRock executive. ForgeRock is one of OIN's 140 licensees. Simon is also a board member of the Open Source Initiative. On Twitter he wrote:
"Oracle's move is a huge test for OIN. They need a coherent response when one licensee attacks another over a Linux distro."
Bradley Kuhn, a former FSF executive and now the Technical Director of the Software Freedom Law Center (SFLC), pointed out on identi.ca:
"OIN claims to be defenders against patent trolls that hurt [FOSS]. What'll it do when its members are the trolls?"
While Brad is right to call the OIN into question, his organization's silence about the Oracle/Google situation is conspicuous. They've now had more than a week to take a position. On the SFLC blog, something related to BlackBerry (!) was discussed a week ago. But not a word on Oracle vs. Google. I explained the primary reason here.

There's also a conflict of interests. Last year Eben Moglen, the SFLC's leader, declared in a submission to the European Commission that "the funding from Oracle [...] has [not] exceeded 5% of our total funding since SFLC's inception." Then you might add funding from Sun (now owned by Oracle) on top. Presumably it was a lot. Sun was known to be very generous vis-à-vis such entities...

Questions concerning the OIN's true agenda

The OIN is funded by IBM, Philips, Sony, NEC, Red Hat and Novell, and to a lesser degree, Canonical.

When a "cartel" like that suffers a failure of enormous proportions, you can be sure that there will be apologists trying to spin-doctor the event. It's critical for the OIN and its allies to do so. After all, the OIN's inability to do what it claims to be able to do raises questions as to whether there's a hidden agenda concerning those patents.

I feel strongly that there is an ulterior motive: the OIN's owners want to disadvantage non-member FOSS companies. They want to equip those whose FOSS programs are covered with a "protected by OIN" selling point, although the Oracle vs. Google situation makes that selling point pretty weak from today's perspective. By not protecting the FOSS projects that are relevant to their competitors, they can try to distort competition. In a worst-case scenario, the six owners could even decide to use the OIN as a patent troll that enforces its patents against the competitors of its owners, especially against FOSS-related ones.

Look at the current situation: if Oracle is right, then the seven patents it asserts will read on Dalvik, Google's virtual machine for Android. Dalvik is an important component: Android applications run on it. You can be sure that if Dalvik were a similarly essential part of Red Hat's or Novell's Linux distributions, or if it played an Apache-like strategic role to IBM, it would definitely fall within the OIN's scope of protection.

My suggestions would solve the problem for Dalvik

The OIN has a completely arbitrary definition of "the Linux System", which is a list of programs to which its whole patent license agreement relates. Apache is on that list, although it's not needed to run Linux (well, it's simply key to IBM). But Dalvik isn't.

If Dalvik were on the list, Oracle couldn't sue Google now. But Google is only a licensee, not an OIN member, and therefore has no control over the OIN's definition of "the Linux System".

Back in June I made four alternative suggestions for how the OIN could address the problem of the arbitrarily defined "Linux System" and provide a reliable definition or at least a proper process. If you look at those suggestions, you can see that any one of the four could solve the problem for Dalvik.

Another way to look at those suggestions is to read them one by one and ask oneself: why doesn't the OIN do any of that if it's sincere? If it really wants to protect the Linux ecosystem, why wouldn't it either use a reliable definition of its scope or otherwise at least put a process in place that it could be proud of?

The only plausible answer I can come up with: they aren't sincere. But I'd be happy to see real improvement. I just doubt it. The OIN prides itself on being one of the biggest buyers of patents. It's spent many hundreds of millions of dollars already. The companies funding that operation certainly want to gain a strategic advantage. An unfair one in my opinion because they capitalize on the lack of patent-related expertise on the part of most of those licensee companies.

Those licensees are largely companies who don't even have a patent department, nor know much about IP strategies, and they fall for the OIN's line. They are misguided by false hopes. Through their support they make the OIN bigger and more dangerous, not better and trustworthier.

The smokescreen they're preparing: Sun wasn't an OIN licensee

In a discussion on ZDNet, Ed Burnette said he talked to "sources close to the organizations [one of which is the OIN]" and that "there's a debate about whether the OIN patent license grants apply to Android or not, given that both Oracle and Google are licensees of OIN (but Sun wasn't)."

Ed is right from a journalistic point of view to look into all of the possible aspects and ramifications of this matter, but the fact that Sun wasn't an OIN licensee is irrelevant and just a smokescreen that the OIN and its apologists are trying to create. I will pre-empt them and explain this right here and now.

I have analyzed the OIN License Agreement:
  1. With only one minor exception, all provisions of the OIN License Agreement are limited to the "Linux System" as defined by the OIN (in the form of a list of program files). Dalvik never was on that list. So all those clauses of the agreement give Oracle total freedom to sue Google over (alleged) patent infringement by Dalvik's code.

    Note that the term "Linux System" is capitalized throughout the agreement. That means it can be understood only as defined by the agreement, not by common sense.

  2. The one minor exception is Section 3.3. It refers to "products that perform substantially the same function as the Linux System". I can't see how this would help Google in any way. The term "substantially" is a fairly high hurdle. There's nothing like Dalvik on the OIN's list, so I can't see how this would apply.

    Even if (contrary to my belief) the clause did apply, it wouldn't stop Oracle from suing. That clause would only make it easier for Google to countersue Oracle if Google had patents that read on "the Linux System" and hurt Oracle. I doubt strongly that they have any patents that meet those criteria. (Also, Oracle presumably checked on the risk of retaliation before going to court.)

  3. In the combination of the two previous items, you can see that even if Sun's patents fell under the OIN agreement, Oracle could still sue its fellow OIN licensee Google because Dalvik isn't part of the OIN's Linux System definition.

  4. Therefore, any talk about the fact that Sun (unlike Oracle, and unlike Google) never signed the OIN license agreement is irrelevant. Should the OIN and its allies tell this to journalists and to community leaders, then it's just a diversion from the real problem: the OIN's arbitrary scope.

    The more they try to divert away from it, the clearer it is that the arbitrary scope is a cornerstone of a scheme that can hurt FOSS companies and FOSS projects in the future.
OIN agreement is poorly crafted with respect to acquisitions of companies

Even though -- as I just noted -- the question of Sun's status is irrelevant due to the OIN's fundamentally flawed scope, I nevertheless did look into the hypothetical question of how this relates to Sun's patents (considering that Sun, unlike Oracle, never signed the agreement) out of curiosity and discovered that the OIN license agreement is poorly crafted with respect to acquisitions of companies by licensees.

This is now just about the cross-license aspect of the OIN agreement. For the sake of simplicity, let's forget for now about the patents the OIN acquires because those aren't relevant to the question at hand.

The cross-license between all OIN licensees is established by Sections 1.2 and 1.4.

In 1.2, a newly-joining licensee grants a patent license (limited to the OIN's scope) from there on out to all fellow licensees, certifies that it isn't legally restricted from doing so and declares that there aren't any pending legal claims in the relevant context ("Linux System", as always).

In 1.4, the newly-joining licensee then basically has to grant a retroactive license with respect to the past and always in connection with "the Linux System". It's called a release, not a license, but that's just a matter of terminology.

Let's focus on Oracle vs. Google. Oracle did what Sections 1.2 and 1.4 require. Sun never did. Let's forget for the sake of the argument that the OIN's scope doesn't cover Dalvik anyway. So what would Google do if the OIN covered Dalvik?

Google would firstly have to invoke Section 5.5 of the OIN agreement. Under that clause, Google is a "third party beneficiary" with respect to the agreement between Oracle and the OIN, and has "the right to enforce [the OIN agreement] against [Oracle] and [Oracle's] Affiliates."

The term "Affiliates" (capitalized because defined by the agreement) is key. It's not Oracle Corporation suing Google. It's "Oracle America", which is a wholly owned subsidiary of Oracle and which used to be Sun. But as you can see, Section 5.5 would give Google the right to enforce the agreement also against "Oracle America".

But to enforce the agreement against "Oracle America" is only of use if Google finds something in the agreement that it can benefit from. I repeat myself, but since the OIN's scope doesn't include Dalvik, this here is hypothetical and not a real option anyway.

In this hypothetical scenario, we have to look separately at the commitments Oracle made under Section 1.2 and under Section 1.4.

License grant from a given date into the future (Section 1.2)

Section 1.2 (the grant of a license from there on out) relates to "Your [Oracle's] Patents". The OIN agreement defines "Your Patents" pretty broadly, and states specifically that those are patents belonging to "You or any of Your Affiliates" at any time during the relevant period (which started for Oracle in March 2007 and there's no reason to assume it has ended). The term "Affiliate" is defined in a forward-looking way ("now or in the future").

So even though Oracle signed in March 2007, its acquisition of Sun (concluded in January 2010) would be included. It's not stated explicitly as of when it would be.

One could argue that a company signing the OIN license agreement makes a commitment with respect to future acquisitions (I explained how "Affiliate" is defined in a forward-looking way and Section 1.2 is a commitment "on behalf of yourself and your Affiliates"), but it makes the commitment per se on the day it signs. In that case, Oracle made the commitment as of March 2007 and acquiring Sun in January 2010 -- virtually speaking -- automatically and retroactively extended the license (in Google's favor) back to Oracle's signing date. However, there's no such word there as "retroactive", and a license is typically granted on a given day and then extends into the future. So an alternative and more convincing interpretation would be that Sun's patents fall under Oracle's promise as of January 2010 (because Oracle wasn't able to make a commitment on Sun's behalf before consummating the acquisition).

Android was unveiled in November 2007. So the difference between a license in Google's favor starting in August 2007 (when Google joined) versus one starting in January 2010 is relevant in terms of indemnification that Oracle can demand.

If (hypothetically) Google received a license in January 2010, it would also be relevant. In that scenario, Oracle couldn't now ask for an injunction (meaning a court order to prohibit Google from further distributing Android). In that case, Oracle could -- if this Section 1.2 were the only relevant clause -- only ask for indemnification related to the period from November 2007 (initial Android release) until January 2010 (when the license grant occurred). But Oracle did ask for an injunction, just to remind you.

Still, Section 1.2 is only one of two clauses Google could try to use. There's also 1.4.

Release (retroactive license) for the past

Section 1.4 relates to a release (simply put, a retroactive license) related to the time before a license grant occurs under the OIN agreement. In Android's case, if one assumed (hypothetically) a license grant as of January 2010, the key period would then start in November 2007 (Android's first release, which was after the dates on which Google and Oracle, respectively, became OIN licensees) and end in January 2010.

By committing to Section 1.4 in March 2007, Oracle granted that retroactive license to "each Licensee on the Eligibility Date". One may wonder whether this means that the grant occurs on the Eligibility Date or whether it means that the licensee already has to be a licensee on that date (or else will never benefit). I analyzed the definitions in the OIN agreement. The term "Licensee" has a definition that contains "at any time, now or in the future". That's (hypothetically) good for Google, which joined after Oracle. Also, the OIN agreement talks about "Agreement Date" when it means what in our example is Oracle and "Eligibility Date" would in our example be when Google joined. Otherwise the distinction between "Agreement Date" and "Eligibility Date" wouldn't make much sense, nor would I be able to make sense of the definition of "Eligibility Date" as "the later of the [Oracle] Agreement Date and the date such Licensee [Google] becomes a Licensee."

What I consider a shortcoming of the OIN agreement is that it doesn't clearly state in the definition of "Eligibility Date" (and/or the definition of "Licensee") that this relates to OIN licensees other than the party signing the agreement at the relevant time (which also makes it a licensee, immediately). That clarification would eliminate the need to argue that it's the only way to explain the distinction between "Agreement Date" and "Eligibility Date".

But for the reasons I just explained, my interpretation is that Oracle did grant to Google a license to Sun's patents -- and even a release (retroactive license) for the past -- within the OIN's scope. And that scope is, as I explained on multiple occasions, the biggest OIN-related problem.

Since I concluded that Oracle did grant that retroactive license, the end result is the same whether one says it did so with respect to Sun's patents only when it acquired Sun in January 2010 or whether the grant has to be construed to have been made virtually back in August 2007 (when Google joined OIN, after Oracle).

If it was August 2007, it's easy because Android was unveiled only three months later.

If it was January 2010, which is the way I would interpret the agreement, then Google also benefits from it with a view to all of the time before.

So the problem is not that Sun itself never joined the OIN. Oracle acquired it; Oracle became an OIN licensee long before; and one way or the other, the only reasonable interpretation of the OIN agreement is that this way Google got (under Section 1.2) a license to whichever Sun patents read on "the Linux System" and (under Section 1.4) a release (like a retroactive license) for all of the time before, which goes beyond the time since Android's first release.

Again, and now for one last time at the end of such a long posting: the definition of "the Linux System" is the real problem. Concerning the OIN as a whole, it's not the only problem, but it's key and the Oracle-Google case shows it.

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.

Saturday, June 26, 2010

The OIN's Linux System: the only constant is arbitrary change

The Open Invention Network (OIN), on which I already commented last month, reared its head again on Tuesday with the announcement of its Associate Member program.

The secretive style of the announcement added to my uneasiness over that organization, which claims to protect Linux from patent attacks but still, five years after its inception, hasn't produced any evidence for its suitability to the stated task. Actually, I see strong indications to the contrary (the situation surrounding HTC is an example).

In this posting I would like to elaborate on one major issue I have with the OIN's patent license agreement: its arbitrary scope of protection. I already explained that in my first posting on the OIN but I can see that the OIN still attempts to confuse and mislead journalists researching the issue, and their readers. ZDNet blogger Dana Blankenhorn interviewed the OIN's chief executive Keith Bergelt and wrote:
[...] Bergelt said the group’s definition of the Linux System is clearly listed on the group’s Web site [...]
This is a textbook example of trying to mislead people by saying something nobody called into question instead of addressing the actual issue, which is a very serious one for anyone dealing or planning to deal with the OIN on the basis of its patent license.

Let me explain the issue in this posting in greater detail, starting with why the OIN's definition of "the Linux System" is so very important, then explaining the things that could go wrong with this, and finally outlining ways for the OIN to address the problem at least in part.

The OIN Patent License Agreement isn't a general-purpose peace treaty for patents

I will use an analogy. Let's assume we both have patents. I have some patents on an air conditioning system and you have some patents on an underfloor heating. We could cross-license our patent portfolios on a general-purpose basis, the effect of which would be that I can't sue you if you use my patented air conditioning methods in any room of any house you own or rent, and in exchange for that you can't sue me for using your patented underfloor heating methods in any room of any house I own or rent.

In that scenario we'd have a total non-aggression pact in place as far as patents are concerned. It would be a peace treaty signed by you and me.

If we wanted to do the same kind of deal not just amongst ourselves but with as many likeminded people as possible, we could both join the Defensive Patent License (DPL) in the future (its authors are still working on it but it should be available soon). The DPL is a cross-license between all who join the club by declaring themselves in acceptance of the DPL's terms. But there will be no restriction on how to use one's patents against non-members, creating an opportunity for making money and simultaneously fighting patents with what I call the "Fair Troll" concept.

Unfortunately, the OIN Patent License Agreement isn't such an all-purpose peace treaty. The OIN Patent License Agreement is a purpose-specific license, which is stated clearly on its About page is:
"Patents owned by Open Invention Network are available royalty-free to any company, institution or individual that agrees not to assert its patents against the Linux System."
In other words, if you become an OIN licensee, you make your own patents available on those terms and get everyone else's on the same terms, but you can still use your patents against fellow OIN licensees (or they can use theirs against you) if the patents are used for a purpose outside the scope of "the Linux System."

In the analogy I used, this means for the deal between you and me that we let each other use the relevant patents only in particular rooms of particular types of buildings. For an example, we could agree that those rooms must have a size of no more than 25 square meters, and they must be in a ten-story or higher building. If you use my patented air conditioning system anywhere in a five-story building, I can sue you because you'd be operating ouside the boundaries of our purpose-specific deal. If you use it in a qualifying building but in a room that's 26 square meters big, I can sue you because that's one more square meter than we agreed. And vice versa for my use of your patented underfloor heating system.

The problem: they can pull the rug out from under you -- whenever they want

It gets worse. Far worse. The example I just gave with the patent license that's tied to particular types of rooms in particular types of buildings would be limited, but at least it would be fair and reliable within its specified scope.

What makes the OIN so unfair und unreliable is that the scope of protection (meaning where you may infringe the patents you license) isn't based on any objective criteria. It's just called "the Linux System". That doesn't mean "GNU/Linux and every other open source software that runs on top of it", even if many of us would like to understand it that way. It doesn't work that way under the law. In the Definitions section of the OIN Patent License Agreement, the "Linux System" is described in the following way:
“Linux System” shall, at any time, have the meaning set forth, at that time, on www.openinventionnetwork.com.
That definition is absolutely outrageous. Let me explain it with the analogy I provided:

This would be like if you and I did a purpose-specific deal (the deal where the patents can only be used in certain rooms in certain types of buildings), but only one of us would have the right to define what the license relates to and could change that anytime. If I'm the privileged one, then I can change any moment, as often as I want and in whichever way I want, the scope. If we agreed initially on use in ten-story or higher buildings, I could simply change it to twenty-story buildings. If you originally trusted me and moved into a twelve-story building, you were safe under the agreement at the time we concluded it, but now I changed it against your will and can sue you all I want. And by pure coincidence I would live in a twenty-story building so you can't...

Unfair to a despicable extent

To someone who understands what reasonable license agreements look like, this shows that the people who conceptualized the OIN had nothing good in mind. They designed a mechanism that is unfair to a despicable extent. They built in a backdoor so they would be able to use the OIN for future purposes that could even harm developers, distributors and users of Linux and other open source software.

The ones who have the prerogative to redefine the "Linux System" are the six companies who effectively own the OIN (IBM, Philips, Sony, NEC, Red Hat, Novell). I don't know whether they have to reach a unanimous agreement among the six to make changes to that definition. Maybe a majority is sufficient. Maybe IBM contributed most of the money and can change it singlehandedly. Who knows. They don't tell.

The current version of the list of program files that constitute the "Linux System" is available on this webpage. For each file, they also specify a program version. For an example, by the time I'm writing this, the version of PostgreSQL that's part of the list is version 8.1.0 (by the time you read this, this may already have changed). If you infringe any OIN patent with any other version of PostgreSQL than the one on the list, you're at risk.

They don't even have an obligation to notify you. It's your responsibility to reload that list all the time and see if anything has changed, or else you're at risk.

This means that PostgreSQL's developers, when adding new features, don't even know if they will face patent problems with the OIN when finished. Again, PostgreSQL is just an example. There are many other projects that face the same problem.

Example of a refusal to add a new version of a Linux-based program to the list

Now let's assume a scenario in which this could be a really serious issue. Let's assume PostgreSQL adds some functionality to its version 9.0.0 that IBM doesn't like because its own DB2 database could then face strong competition from PostgreSQL, much stronger than today. And let's also assume that IBM has patents that it can use against software providing that functionality.

IBM could then use its influence over the OIN to ensure that the definition of the "Linux System" won't be updated with respect to PostgreSQL. They could ask for PostgreSQL to be removed completely from the list, or they could make sure that it only stays on the list in an older version that doesn't have the features in question. In that scenario, even an OIN licensee could be sued by IBM over the use or distribution of PostgreSQL.

I'm sure you understand that this gives enormous strategic leverage to the six companies that own the OIN: they will try to boost their products (and those of their strategic allies) by always adding the latest version to the OIN's definition of the "Linux System". But they can shut out software that's key to their competitors, even if a common sense understanding of "Linux System" would include it.

It's easy to see why IBM wouldn't want the list to include the Hercules open source mainframe emulator. Its patent pledge shows that it likes to redefine its commitments. But if Red Hat and Novell determined that some OIN patents might hurt a competitor of theirs like Mandriva, they could also use the OIN for that purpose.

The OIN's definition of the "Linux System" changes all the time. Since it's version-specific, that's inevitable until they adopt a fair, reasonable, non-discriminatory, reliable and transparent approach instead of the current scheme.

What the OIN could/should do in order to address the problem I described

I'm constructive and I want to outline different ways in which the OIN could address the problem. Those different ideas have varying degrees of effectiveness, but any one of them would be way preferable over the current status quo, which is not just unacceptable but also an insult to human intelligence.

1. The ideal solution: OIN on DPL basis

The OIN should take a serious look at the Defensive Patent License (DPL) whenever it becomes available (likely to happen soon). Provided that the DPL meets expectations (and I'm optimistic but of course we all need to see), the OIN should drop its own unfair license in favor of the DPL, meaning that the OIN, which holds a number of patents it acquired, and its six backers should join the DPL.

This way the license would be an all-purpose patent peace treaty for all who want to be peaceful. It would solve the problem for the "Linux System" and way beyond, even beyond the realm of free and open source software.

2. The second-best solution: define the scope once and for all as "all existing and future FOSS"

If the OIN's backers don't want to adopt the DPL because they have hostile intentions, they should at least give peace of mind to the whole FOSS world. They should define the scope of the agreement as "all software available now or in the future under an OSI-approved or FSF-approved license" (the approval could be tied to a date that would be updated from time to time, such as licenses approved as of June 1, 2010).

Dual licensing (same software also available on a non-FOSS licenses) is acceptable to Richard Stallman and should also be supported. For the commercialization of proprietary (non-FOSS) licenses to programs that are available as FOSS, I would propose fair, reasonable and non-discriminatory licensing of OIN patents (royalty-free would be better, but I understand if a distinction is made between closed and open source, favoring the latter).

3. The third-best solution: define the scope once and for all in a GNU/Linux-specific way

Similar to proposal 2, but this way they could exclude any other operating system than GNU/Linux if they wanted to. The definition would include "existing and future versions of GNU/Linux and existing and future versions of (existing and future) GNU/Linux-based free and open source software." This would mean they could still use patents against closed-source software and also against free and open source software that runs on a system competing with GNU/Linux.

Like the two options outlined before, this approach wouldn't require any list of program files.

4. Better-than-nothing approach: a changing list but based on a transparent decision-making process and objective criteria

If the OIN's backers want to keep things complicated and aren't prepared to make a true commitment to peace on the patent front, they should at the very least abandon the concept of arbitrary changes to the list.

They should modify the definition in the OIN Patent License Agreement in several ways at the same time. Obviously it would depend on the exact wording whether any of this is actually helpful, but let me just outline examples of what they could do if they wanted to show good faith:
  • Software commonly shipped with major Linux distributions should be included on a mandatory basis.

  • Whenever a program gets added, not only all past and current versions but also all versions released into the public domain until three years (a reasonable cycle for a major upgrade) after the decision to remove the program from the definition should be included.

  • Changes to the list should become available to licensees as well as anyone interested in the general public in the form of a well-structured monthly summary (on the Web with optional email subscription).

  • The decision-making process on which programs to include or remove should be more transparent. The OIN should announce each such decision on its website. If a decision is not unanimous, those OIN backers who disagreed shall have the right to be named at their request.

  • Licensees (not only financiers) should have the right to propose GNU/Linux-based programs that should be included in the definition. If the OIN turned down the request, it should be required to state its reasons. In the event a licensee considers the decision inconsistent with the standard the OIN applied to previous decisions, there would have to be an appeals process (in a public court or by means of AAA arbitration) to resolve the dispute. In case of doubt, inclusion of programs should be the norm and exclusion an exception requiring appropriate justification.
The problem is clear, and it's serious. There's no shortage of possible solutions if there's good faith. The sole remaining question is: will the OIN's backers prove with their deeds -- not with empty words -- that their alliance is a good-faith initiative? In other words: is the OIN a patent troll in disguise or truly meant to protect the Linux ecosystem? It's time for the OIN to get real.

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.

The Open Invention Network's Associate Member Program: what's that?

I recently commented on the Open Invention Network (OIN), an alliance of six companies that claims to protect Linux from patent threats but hasn't ever proven any success in that regard. I outlined some of my concerns in the aforementioned posting and concluded that a company-independent solution is needed. The Defensive Patent License (DPL) may soon be a much better choice.

An enigmatic press release

On Tuesday (June 22), the OIN announced that Canonical (the Ubuntu company) became the first "Associate Member" of the OIN. The announcement is one of the most unspecific press releases I've ever seen. It looks like a parody of the proverbial politician who talks a lot but says nothing. They announce a new Associate Member program and don't even say what sets an Associate Member apart from a full member (they say "Founding Member") and from a mere Licensee (which is what Canonical was prior to its promotion to Associate Member).

Here's how they "define" the term:
Associate Members are recruited from Linux-related companies, including those that are leaders in advancing Linux's migration into emerging growth markets. Associate Members make a commitment to the Linux Community by virtue of their commitments to and membership in OIN and help to ensure that patent issues do not impair Linux's growth.
What in the world is that supposed to mean? Nothing. The first sentence says you have to be a Linux-related company. Since the OIN's patent licensing terms are specific to what they call "the Linux System", there's no reason why anyone who isn't in one way or another "Linux-related" (very broad terminology!) would join the OIN as whatever type of member. The second sentence equally applies to the other two member categories: even a Licensee must make a commitment not to assert his patents against "the Linux System". So how's this different for an Associate Member? There must be a difference, but they won't really tell what it is.

That nebulous language isn't just due to a lazy PR person. It simply reflects the OIN philosophy (which, of course, is in no small part a reflection of the attitude of the OIN's financiers).

Systematic secrecy

I'd never expect them to be too open for their own good: if they become involved with a patent dispute, I understand they won't disclose their case-specific strategy in public.

But there are many things that they certainly could talk about without any adverse effect on their activities. If they wan't to be secretive, why do they issue such a press release in the first pace? If you want to announce something, you usually want people to get at least the basic message. All they said was that Canonical is now called an Associate Member, whatever that may be.

Journalists are also puzzled

TheRegister also mentioned the lack of clarity concerning the meaning of the term "Associate Member", accurately stating that "it's far from clear what Canonical will do as an associate member."

DaniWeb informed its readers of the announcement and published my comments. AlcanceLibre did so in Spanish and Pro-Linux quoted a part of my statement in German.

ZDNet blogger Dana Blankenhorn tried to obtain more information the OIN's chief executive Keith Bergelt. However, what the OIN told him still doesn't really add much information. "Associate Members pay an unspecified fee and will exist somewhere in the middle [between Founding Members and Licensees]", Dana concluded from what he was told.

Linux Pro Magazine has also asked the OIN and Canonical for more information and will publish it when available. We'll see if the self-proclaimed protector of Linux is going to be more forthcoming now.

The OIN should be at least as transparent as MPEG LA

I understand the reservations of many opponents of software patents concerning MPEG LA, which like the OIN is a non-practicing entity administrating patents on behalf of practicing entities that effectively own it. Our community doesn't like the idea of having to pay for multimedia codecs (Canonical recently became the first Linux company to pay patent royalties to MPEG LA for H.264, by the way).

But MPEG LA says a whole lot more about the way it conducts its business than the OIN does. That's a fact. Not only does MPEG LA provide a lot more information on its website than the OIN but it also provides reasonably informative answers to individual questions. I recently had doubts about MPEG LA's annual royalty cap as well as the protection of licensees against infringing competitors, and I got clear answers that I published in this recent blog posting.

They gave that information even though they knew that I'd like to see software patents abolished, which would spell the end for their business model.

It goes without saying that I don't mean to promote MPEG LA. It just beats me that the OIN can't be at least as open as MPEG LA, and this adds to my impression that the OIN has something to hide.

Next steps

In my next blog posting I'll discuss one of the biggest problems I have with the OIN, which is its arbitrary, ever-changing scope of "protection".

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.

Monday, May 31, 2010

Open Invention Network (OIN) demystified

An organization that was founded in 2005 and pompously claims in a press release to be "the company formed to enable and protect Linux" is the Open Invention Network (OIN). But at a closer look it's not nearly as useful as its backers would like to make us all believe. There's absolutely no evidence it has ever helped any FOSS company.

What's beyond doubt is that the OIN's structure is fundamentally flawed and unbalanced.

Above all, the OIN is under the exclusive control of half a dozen companies who have funded it with (presumably) hundreds of millions of dollars and who just use it for their own purposes rather than advancing the cause of software freedom. Therefore, I believe company-independent defense initiatives such as the Defensive Patent License are a fairer, more transparent and more reliable approach than the OIN.

Only six companies call the shots

The OIN's name starts with an utterly misleading term: "open".

In reality, the organization is owned and run by a closed circle of six companies, some of whom have a terrible background concerning software patents:
  • IBM (the world's largest patent holder and one of the most ruthless ones, recently in the news for betraying its own "patent pledge" by infringement assertions made against open-source startup TurboHercules)

  • Philips (a company that once benefited from the temporary abolition of patents in its country but later lobbied extremely aggressively for software patents, left the World Wide Web Consortium because of the latter's royalty-free patent policy, and threatened politicians with killing software development jobs in Europe if they weren't going to allow software patents, even though patents are always related to a target market in which they're valid and 100% independent from where in the world the patented invention is made)

  • NEC (a large patent holder)

  • Sony (a large patent holder)

  • Novell (which never supported any serious push against software patents and instead told EU officials in 2004 that it liked software patents a lot except that a proposed EU law on them appeared to limit "customer choice" a bit too much)

  • Red Hat (which lobbied to keep the aforementioned EU bill alive when we had already formed a majority for its rejection, and which partners with IBM on a number of initiatives that appear to protect FOSS but are either ineffectual or even potentially harmful)
When it comes to patents, would you buy a used car from those fellows?

Everyone else may join as a second-class citizen who won't have a say

The six-pack that controls the OIN invites everyone else to become a mere "licensee". There's only one benefit for a licensee: OIN licensees can't use some patents against each other in some context. If "some patents [...] in some context" sounds strange to you, then that's because the whole OIN is based on an arbitrary definition of the "Linux System". If an OIN member has patents that are infringed by that arbitrary definition of the "Linux System", then it can't use those particular patents against other members as far as those use or distribute the "Linux System" (in whole or in part). If those other members use or distribute software that's not part of the "Linux System", then even those patents could be used against them in that context.

The wording used by the OIN on its About page is:
"Patents owned by Open Invention Network are available royalty-free to any company, institution or individual that agrees not to assert its patents against the Linux System."
Unfortunately, the OIN's six owners decide in a completely intransparent process what is and what isn't part of that "Linux System". The OIN publishes that list, which can and does change from time to time, on its website. The OIN's License Agreement doesn't provide any definition or criteria other than pointing to that list. That list contains not only Linux but also some applications (not all Linux applications), and once again, there's no transparent basis on which the OIN makes or modifies that list at its whim. That's what they mislabel as "open".

[Update] In the meantime I've published this detailed explanation of the arbitrarily-changing definition of "the Linux System" and its implications, and in that posting I have also outlined four alternative ways to address the problem identified. [/Update]

This combination of intransparency and arbitrariness puts licensees into a weak take-it-or-leave-it position. If the OIN changes the list based on the strategic goals of its six owners, all others can stay or leave but they have no basis on which to require the OIN to include certain components in that list or to exclude some from it.

That's not the only important way in which licensees are disadvantaged as compared to owners.

Owners can use the OIN as a patent troll -- but the retaliatory strength of licensees remains unchanged

There are two fundamentally different approaches to patent defense: non-aggression pacts related to a certain range of patents, which is what the OIN's licensees get (with the serious flaws and limitations previously described), and the concept of mutually assured damage (deterrent/retaliatory potential). The latter is much more powerful. While nothing really helps against a "troll" (non-producing entity), a retaliatory arsenal can indeed deter a strategic patent holder from attacking, provided that the attacked entity disposes of patents that the would-be aggressor also needs for his own products/services.

Unfortunately, the OIN doesn't add anything to the retaliatory strength of its licensees. They don't get access to any additional patents that they could assert against an aggressor. But the OIN's six owners could use the OIN as a "troll" that would attack third parties because the OIN itself acquires patents (currently owns a few hundred) for that purposes. OIN licensees can use those patents in connection with Linux; OIN members can use their influence to make the OIN assert those patents against others.

There are no obligations on the OIN or its owners concerning how they would have to strike back against an aggressor. Just like the definition of the "Linux System", it's a backroom process without any transparency or published and binding criteria. They could use those patents for purposes that have nothing at all to do with Linux or other FOSS, and no third party, such as a mere OIN licensee, would have any basis to either get them to help or to make them refrain from a harmful way to use those patents.

They make vague statements on the OIN website as to what they plan to do and that they don't plan to build licensing revenue. None of that is legally binding. If you then look at the patent-related positions and history of that group of companies, you better be careful. The most frightening example is IBM, which never apologized for its assertion of patents against TurboHercules.

A look at the list of OIN licensees

The OIN lists its licensees (starting with the six owners, but that changes nothing about the privileges those have). There are two large players among those licensees: Google and Oracle.

Google provided an official reasoning for becoming a licensee that's fundamentally wrong:
"OIN members can focus their energy on writing and releasing software rather than vetting their code for intellectual property issues."
This is incorrect in two ways at the same time:
  1. The use of those patents is tied to that "Linux System" definition, so the OIN's members still have to be equally careful for all software they develop that isn't part of that definition (which only the OIN's six owners determine and modify, and that definition is always related to particular program versions, so even a contributor to Linux wouldn't have any guarantees if upgrading an existing component).

  2. No one who might want to assert his patents against OIN members will join, and since the OIN controls only a small portion of all patents worldwide, the reasoning of not having to perform patent clearance anymore makes no sense whatsoever, at least for the foreseeable future and probably for all eternity.
It's more likely that Google, the world's largest-scale Linux user, thought that any measure to reduce -- even if just marginally -- the risk of being sued for infringement of patents on hundreds of thousands or even millions of computers was worth trying. But that's their specific situation and doesn't validate the OIN as a whole.

One of OIN's medium-sized licensees is TomTom. That maker of navigation systems became an OIN licensee at a time when it had a dispute with Microsoft. That one was actually settled very quickly at any rate, and part of the agreement was that TomTom would have to stop the infringement of certain Microsoft patents within two years. Apparently, TomTom also agreed to pay royalties. So TomTom recognized it had a problem that the OIN couldn't solve.

What happened later is that some propagandists close to IBM and other OIN owners tried to fool the FOSS community into believing that the OIN played any role in that settlement. That's downright absurd because TomTom only became an OIN licensee, not an owner. By becoming a licensee, TomTom changed its patent licensing situation vis-à-vis other OIN members but nothing changed for the siuation between Microsoft and TomTom.

If the OIN were the kind of magic wand that would do the trick, then why would Amazon and HTC and many others have agreed to pay Microsoft royalties on patents that are considered to read on Linux? They could have joined the OIN, but quite apparently they found out the truth, which is that it doesn't strengthen them at all in their dealings with companies outside the OIN.

So what is the OIN good for?

The fact of the matter is that today, almost five years after its foundation, the OIN still hasn't proven its ability to help any Linux (or other FOSS) company in any meaningful way. Totally unsubstantiated and illogical claims by propagandists aren't a substitute for a single convincing success story. That success story would have to consist in some company potentially hostile to open source (and with a dangerous patent arsenal) accepting the OIN's licensing terms. That hasn't happened and I have serious doubt that it ever will.

The OIN continues to buy patents at auctions that might otherwise be acquired by regular trolls. At first sight, that may sound good. But given the intransparent and arbitrary structure of the OIN, it's not clear whether that's actually the lesser or the greater evil than a conventional troll. In the end, the OIN is under the control of those six companies who could decide to use some of those patents against competitors, including FOSS competitors. By controlling the definition of what the OIN calls the "Linux System", they can always ensure that their competitors don't benefit from it, even if they were or became OIN licensees.

Buying those patents at auctions is really expensive. So far the OIN has spent hundreds of millions of dollars. Given the way businesses operate, that's not the amount of money that one would spend unselfishly. Instead, that level of investment, intransparency and unbalanced rights suggests ulterior motives, if not a long-term hidden agenda.

In closing I can only repeat what I said further above: company-independent defense initiatives such as the Defensive Patent License are a fairer, more transparent and more reliable approach than the OIN. And with the Fair Troll business model, that reliability can be fully preserved while sharpening the DPL's teeth. By contrast, a small group of companies can turn the OIN into an unfair troll anytime, and the rest of the world -- including the FOSS community -- wouldn't find out until it's too late.

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.