Motorola's ITC complaint against Microsoft regarding "certain gaming and entertainment consoles"

Motorola just added another suit to its assortment of patent disputes with Microsoft: an ITC complaint targeting the Xbox 360.

In October, Microsoft filed patent infringement complaints against Motorola with a US district court as well as the US International Trade Commission. Those complaints related to Android-based smartphones. Observers generally expected at the time that Motorola would, like many other defendants, countersue. Motorola indicated that intention to the Associated Press before it even saw Microsoft's complaint:

"Motorola has a leading intellectual property portfolio, one of the strongest in the industry, and we will vigorously defend ourself in this matter."

Further below I'll get to the strength Motorola claims to possess. Firstly, let's continue with the evolution of the dispute. On 9 November 2010, Microsoft sued Motorola for failure to comply with licensing commitments related to RAND-based industry standards (RAND stands for "reasonable and non-discriminatory"). A day later, Motorola filed its widely anticipated countersuit: more precisely, three suits in two US district courts.

In the latest move, Motorola added an ITC complaint against Microsoft on Monday (22 November 2010), claiming that different Xbox products infringe five of its patents (which I'll list further below). The ITC 337 Law Blog has published the complaint as well as a summary of its content.

Why Motorola wants an ITC investigation

Last month I wrote about the fact that the US International Trade Commission (USITC or just ITC), a "quasi-judicial federal agency", has become an important forum for patent infringement disputes. That posting inspired a ZDNet article on the same topic.

The short version is that the ITC can order import bans on infringing products within approximately 18 months of the filing of a complaint, while proceedings in federal courts usually take years. If a low-margin product is manufactured at a lower cost outside of the United States, an import ban is similarly effective as an injunction.

On 2 November 2010, the ITC voted to investigate Microsoft's complaint against Motorola. The investigation number is 337-TA-744. Should Microsoft prevail, Motorola would face an import ban in the spring of 2012 while probably still being a year or two (or more) away from a possible injunction. Therefore, an ITC proceeding would be strategically desirable for Motorola.

ITC proceedings already go both ways between Apple and Motorola. On 3 November, the ITC voted to investigate Motorola's complaint against Apple, and on 23 November, it decided to also investigate Apple's complaint against Motorola.

But Apple and Motorola have in common that they sell smartphones that are imported into the United States, whereas Microsoft is primarily a software company. In that business, manufacturing costs aren't a strategic issue, putting Microsoft -- at least in its core business -- out of reach for ITC import bans.

The only Microsoft product line Motorola's ITC complaint relates to are gaming consoles. It mentions two different Xbox 360 S configurations. According to reports such as this recent Forbes article, "[t]he Xbox 360 outsold every competing console in the U.S. over the past four months, with sales growing 38%." It's certainly an important product group to Microsoft, but it doesn't play the essential role to it that smartphones have for Motorola. In the federal courts, Motorola also tackles Windows, Windows Phone and Office, but that effort will take time (if it ever gets anywhere).

If Motorola wanted to attack Windows Phone 7 in the ITC, it would have to try indirectly by complaining against device manufacturers. However, those hold many patents of their own and in some cases may already have cross-license deals with Motorola in place. Widening the conflict wouldn't necessarily increase Motorola's chances of winning.

Portfolio strength vs. specific impact

Further above I quoted the pride that Motorola takes in the strength of its portfolio. I can understand that. It's a company that's 82 years old, and as a former Commodore Amiga owner, I fondly remember the Motorola 68000 family of microprocessors.

At this stage, Motorola holds approximately 9,000 US patents in force, not too far away from Microsoft's roughly 15,000. The five areas in which Motorola's portfolio seems to be strongest are the following USPTO main classes:

1. Telecommunications (main class code 455)

2. Multiplex communications (370)

3. Pulse or digital communications (375)

4. Registers (235)

5. Communications: electrical (340)

I can hardly see that many patents in those categories would be relevant to Microsoft's business -- maybe to Microsoft's hardware partners, but not to the software company itself. By contrast, Microsoft has a very broad and deep portfolio of approximately 15,000 US patents, with a particular strength in operating system (including user interface) technologies. Since Google appears to have failed completely to resolve patent issues concerning Android, its partners among device makers such as Motorola now need licenses from third parties such as Microsoft for a variety of technologies.

I pointed out in another posting that numbers of patents -- such as the numbers different players assert in those disputes -- must not be confused for strength. There can be a correlation, but a company that has only a handful of patents may try to use all of them in court while another one may pick a few really strong ones out of a huge portfolio, knowing it can always add patents or start additional suits if necessary.

Portfolio strength is important in some ways. But the example of Microsoft and Motorola shows that the bottom line is not how many patents a company has. It's all about how much of a need the other party has to obtain a license. I don't see them on an equal footing in that regard. I believe that Android makes Motorola the needier one of the two parties, by far and away.

Also, Motorola's strategic options will be quite limited if Microsoft's claims are correct that Motorola failed to meet the RAND (reasonable and non-discriminatory) licensing commitments it made to certain standard-setting organizations and their members, one of which is Microsoft. In that case, the worst-case scenario for Microsoft would be that at the end of the litigation it may end up having to pay royalties (for those patents, which may be Motorola's most important ones in this context) above the level it considers reasonable, while Motorola could not ask a court to determine that Microsoft has an obligation to grant a license and to set a maximum level of royalties at all.

All in all I believe it's better not to overestimate Motorola's relative strength in its dispute with Microsoft. The name of the game is the specific impact you will ultimately have on your opponent -- not how many complaints you file, let alone in how many fora.

Patents

Finally, let's look at the five patents Motorola asserts in this ITC complaint against Microsoft.

Those include four of the six patents Motorola asserts against Microsoft in the large one of the two suits it filed in the Western District of Illinois:

• US Patent No. 5,319,712 (on a "method and apparatus for providing cryptographic protection of a data stream in a communication system") also appeared in a complaint filed against Apple in the Northern District of Illinois as well as in complaints against Research in Motion (with the ITC and in the Northern District of Texas). The dispute with Apple is ongoing; between Motorola and RIM, there was a settlement.

• US Patent No. 5,357,571 (on a "method for point-to-point communications within secure communication systems")

• US Patent No. 6,980,596 (on a "macroblock level adaptive frame/field coding for digital video content")

• US Patent No. 7,162,094 (on "frequency coefficient scanning paths for coding digital video content"; another codec patent)

The fifth patent was not previously asserted by Motorola against Microsoft (nor against Apple):

• US Patent No. 6,069,896 (on a "capability addressable network and method therefor"). It appears to describe a network in which the capabilities required by one end of the connection and the ability of different connected peers to deliver them on the other end are somehow taken into account. The peers can request, provide or relay a diversity of services, and the objective appears to be to facilitate the use of different devices with different capabilities in such a wireless setup. The description claims that the patent describes a more efficient solution than a regular computer network (in which devices offering particular services, such as a dedicated printer, are common) from a configuration and usability point of view, but I must admit that I failed to see the point in this patent even though I tried.

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.

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.

Brussels conference on "Tensions between intellectual property rights and standardization: reasons and remedies"

Last week I mentioned a European Commission and European Patent Office conference on "tensions between intellectual property rights and standards". The conference took place in Brussels on Monday (22 November 2010), and I attended it.

Different speakers pointed out that an increasing number of patents read on today's high-tech products. The European Patent Office has already received 4% more patent applications this year than during all of last year, and there is still about a month to go. While some view this trend as a key indicator of innovation and of awareness for the importance of intellectual property rights, others complain about increasing complexity and a growing risk of disputes.

Most industry standards are FRAND-based and some panelists stated that they don't see a need for a fundamental departure from the current system, which allows companies to opt for alternative models. Others, however, made proposals and demands that would in different ways weaken the rights of patent holders and discourage innovators with IP-centric business models from participating in standard-setting processes.

Major European stakeholders favor FRAND

The European Commission plans to take decisions on two standards-related initiatives before the end of the year. Other legislative initiatives on standardization will continue through 2011. Against that background, it didn't surprise me that some of the speakers made political statements and demands directed at the EU officials in the audience. But the loudest voices weren't the most convincing ones.

Before I address some of what was said, I'd like to share an observation. Speakers from US corporations (Oracle and HP) attacked FRAND from different angles and received support for this from the FSFE, a lobby group whose primary partners are IBM, Oracle, Google and Red Hat. However, there were key European stakeholders on the panels who clearly disagreed with them. Ericsson contradicted Oracle; SAP posed questions (to HP and FSFE) regarding the "openness" of open source software, the different business models that successfully leverage FOSS for financial gain, and the need to balance the rights of IPR holders and licensees.

Ericsson stressed that "the FRAND IPR regime has served the industry very well in the wireless communications area." Its vice president of patent strategies and portfolio management, Gustav Brismark, pointed to the fact that over the years there have been "numerous new entrants", which he views as an indication that the system is pro-competitive. In his experience, SMEs who make themselves knowledgeable about the patent licensing landscape can conclude the necessary license agreements with right holders and participate in the market.

SAP placed the emphasis on choices that are made by right holders on a case-by-case basis. For example, the standards developed by the World Wide Web Consortium (W3C) must be patent-unencumbered or patent rights must be available on a royalty-free basis (with possible restrictions set out in the organization's patent policy). Many of the companies participating in the W3C are, however, simultaneously involved with FRAND-based standard-setting processes.

From SAP's point of view, "market dynamics have worked very well so far", not only because there are different kinds of standard-developing organizations competing but also because certain SDOs such as OASIS create standards on the basis of FRAND as well as under other regimes.

There's nothing wrong with US corporations -- especially if they have significant European operations and partner networks -- participating in European policymaking debates. However, it's a legitimate question to ask who (and how credible and independent) the local entities on their side are. In addition to promoting continuity, which means the burden of proof is on the other side, the proponents of FRAND have the home team advantage: they can point to broad-based support for this approach among European politicians and regulators and a long list of impressive allies among European companies.

I mentioned the panelists from SAP and Ericsson. Some others of this nature and stature, such as Philips, Siemens and Alcatel Lucent, apparently weren't invited to make presentations. But the European Commission is aware of where they stand.

If US companies make demands in Europe that are different from the status quo in the US, one may ask what really dictates a different approach on this side of the pond. Oracle and HP didn't have any specifically European reason for what they proposed -- such as market characteristics. It looks to me like they are just trying to advocate here what they are unable to achieve at home.

Oracle's extrapolation and Java

I thought Oracle's Don Deutsch would comment on the Java situation. Instead of addressing it directly, he referred to Oracle's involvement with over 100 standard-setting organizations and 500 Oracle engineers participating in 600 working groups. But one thing he said raises interesting questions concerning Java.

He claimed that disagreement over FRAND (more specifically, over which terms a right holder is or is not allowed to seek after having made a FRAND commitment) resulted in "many complaints filed alleging abuses in the area." I talk about many patent-related disputes on this blog but I don't see "many complaints" of that kind. They are few and far between. Don Deutsch probably knew that many in the audience were aware of that fact, so he preemptively added that there are "probably many more complaints than we know about because they are almost always handled in a bilateral way, not discussed publicly."

That makes me wonder what all of this means for Java. There are two high-profile disputes at the moment: Oracle is suing Google and a refusal to grant a Java TCK license to the Apache Software Foundation on the terms to which the ASF believes to be entitled.

If it's true that public disputes are the exception and secret "complaints" are the norm, then the number of unreported Java disputes would have to be a lot bigger than the two conflicts that are out in the open. It would be very interesting to hear from Oracle how high that number is. Are we talking about a handful of unknown Java conflicts? A dozen? More?

If that's not the case, then Oracle shouldn't blow those controversies over FRAND out of proportion.

ICT convergence and software-specific rules

Oracle's Don Deutsch was on a panel on "ex-ante disclosures" of essential patents and most restrictive terms, an approach that doesn't rule out royalty obligations. Right holders seeking royalty payments would just have to state beforehand the maximum amount of license fees they will charge later. FRAND could still serve as a set of rules governing which terms and conditions are acceptable. Some of those demanding an ex-ante disclosure regime may, however, view it as a first step away from FRAND and toward the elimination of different restrictions (or of all of them in the long run).

In his closing statement, Don Deutsch limited his support for ex-ante to "certain market segments". He said that "it particularly fits the IT industry" and added: "We've certainly heard that the telecoms industry has a different history. The industry segments have different characteristics and therefore they have different requirements."

There appears to be little support from the broader ICT industry for proposals to depart from FRAND. That is probably the reason why Don Deutsch and some of his allies limit their demands to only a segment of the ICT field.

But Oracle did feel forced to acknowledge (without using that particular term) the convergence that is taking place. That fact, of course, is one of the reasons for which software-specific rules would not be sound policy in this particular area.

HP presented an unsuitable categorization

The panel on "open source, freely available software and standardization" was the one I was primarily interested in.

Scott K. Peterson, a Hewlett-Packard open source lawyer, started his "FOSS license analysis" with a reference to fragmentation ("it seems daunting to have to analyze open source licenses because they are so numerous, hundreds of them possibly"). But he believed that a categorization into "permissive" and "copyleft" licenses would provide clarity in connection with the impact of patent-encumbered standards on open source.

In some other contexts, the distinction between permissive and copyleft licenses is key. In this case, it misses the point.

Open source licenses are predominantly copyright licenses. A few of them have patent clauses; others don't. Copyleft can indirectly affect patent issues, but in connection with standards, the key distinction is between "patent-agnostic" licenses and those that have certain kinds of patent provisions.

To the founder of the movement, Richard Stallman, they are so different that he calls on everyone not to "lump them together" under the term of intellectual property. HP's Scott Peterson blurred that distinction completely with his unsuitable categorization.

This resulted in some errors, and one of them was particularly embarrassing in front of an EU audience: he listed the EUPL as a copyleft license and, therefore, as one that faces a particular challenge with patented standards. However, the official EUPL blog already agreed with me last month that it is possible to obtain licenses on patented standards in connection with software distributed under the EUPL. That is the case because the EUPL doesn't contain any patent provision prohibiting such inbound licensing in any way.

FSFE's reality distortion field still active

The president of the FSFE (Free Software Foundation Europe), Karsten Gerloff, spoke after HP's Scott Peterson and credited him for a "masterful introduction" to the "thorny issue of FRAND licenses, restriction-free licenses, and copyleft."

At least there's a little bit of progress related to terminology. Karsten said "restriction-free". I previously criticized the "royalty-free" movement for narrowing the issue down to only one kind of condition patent holders may impose. So it's more accurate and more honest to admit that "restriction-free" is the goal the FSFE pursues. But this means that patent holders would have to waive the entirety of their rights, and whether or not one supports the patentability of software, it's understandable that right holders will oppose such ideas.

On the question of whether free and open source software licenses can handle patent-encumbered standards, the FSFE still doesn't specify its concerns about FRAND. It still wants to make people believe that all FRAND is irreconcilable with FOSS and especially the GPL -- even though the most important GPL'd software is Linux and all of the three leading Linux distributors (Red Hat, Novell and Canonical) have licensed patents. To ignore fact, one has to operate inside a powerful reality distortion field.

HP and the FSFE were trying to advocate the same concept but gave inconsistent portrayals of the legal situation. Scott Peterson did not support the FSFE's claim that the GPL is "incompatible with FRAND licenses". Instead, he said that "even though the text of the license is not the problem", one would not get a certain "set of permissions" that is key to FOSS dynamics. He previously outlined three key "FOSS characteristics": free redistribution, ability to modify source code, redistribution of modified software on FOSS terms.

By admitting that "the text of the license is not the problem" (which he didn't say about the GPL per se, but the GPL was part of a list of licenses he discussed), Scott Peterson probably made some people in the audience wonder whether the FSFE is a reliable source of information or makes up problems only to gain a political advantage.

But even the "dynamics" HP described aren't fundamentally at odds with inbound patent licensing. Scott Peterson once again failed to distinguish between copyright and patents. The program code shared under a FOSS license can have all those benefits regardless of a need to obtain patent licenses.

The combination of HP and FSFE was interesting to watch: two speakers demonstrating two different ways to reach the same false conclusion. But they were happy that they agreed on the same anti-FRAND result. No matter why and how they arrived there.

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.

Torn between a lobby and a FRAND

Ahead of a European Commission and European Patent Office conference on intellectual property rights and standardization taking place in Brussels on Monday (22 November 2010), some of the most vocal advocates of openness have determined that FRAND is not a foe of "free" and that both concepts are legitimate in their own right.

I don't just mean the actual business practices of the companies behind the royalty-free/restriction-free lobby. Meanwhile we can even hear it straight from the horse's mouth:

Oracle provides TCK [the official testing kit for compliance with the Java standard] licenses under fair, reasonable, and non-discriminatory terms consistent with its obligations under the JSPA [the Java standard-setting agreement].

Don Deutsch, [Oracle Corp.] Vice President of Standards and Architecture

The above quote is from a statement with which Oracle -- a driving force behind ECIS and OpenForum Europe and an "open standards" lobbying partner of the FSFE -- just responded to the Apache Software Foundation (ASF), one of the two or three most important open source organizations in the world.

The context: compatibility of FRAND with FOSS; field-of-use restrictions

The statement quoted above speaks for itself, but the context makes it even more relevant: the board of the ASF had complained that Oracle "imposes additional terms and conditions [on Java licensees] that are not compatible with open source or Free software licenses." The ASF contends that "Oracle is violating their contractual obligation as set forth under the rules of the JCP [the Java standard-setting process]". It reiterated this view in a succinct reply to Oracle's FRAND statement: "The ball is in your court. Honor the agreement."

The open letter to which the word "agreement" points is more than three years old. At the time, Java belonged to Sun; Oracle acquired Sun last January. Therefore, the letter was directed to Sun, and it stated the following:

[...] The JCK license Sun is offering imposes IP rights restrictions through limits on the "field of use" available to users of our software.

These restrictions are totally unacceptable to us. As I explain below, these restrictions are contrary to the terms of the Java Specification Participation Agreement (JSPA) - the governing rules of the JCP [Java standard-setting process] - to which Sun is contractually bound to comply as a signatory. The ASF has a proud history of support for open software ecosystems in which commercial software can flourish.

However, Sun's JCK license protects portions of Sun's commercial Java business at the expense of ASF's open software. It prevents our users from using Apache software in certain fields of use.

[...] limitations on field of use for our users is contrary to the basic principles of open source licensing, and therefore these limitations would prevent distribution under any open source license, including our own. [...]

There you have the argument I addressed in this recent post ("FOSS can implemented patented standards"). The FSFE also listed the Apache license among FOSS licenses that it falsely claims to be incompatible with FRAND-based licensing. (You can read the truth about patent licensing under the Apache license here).

Oracle contradicts itself and its lobbying fronts ECIS, OpenForum Europe and FSFE

It appears to be a common pattern that open source foundations don't want to become "frandations", so they claim legal incompatibility even though their problem is a philosophical one. But what's really interesting is that Oracle uses two contradictory definitions of "open standards":

In front of policy-makers, Oracle (interestingly, Don Deutsch himself) gives talks such as this recent one in Brussels about all the good that open standards do. Oracle co-authors, finances and lends its name to statements such as this one that argue against FRAND-based licensing because it would allegedly "exclude a broad segment of the industry -- mostly open source software developers -- from implementing that specification in their products." ECIS, which issued that one, is run by Thomas Vinje, Oracle's outside counsel on EU antitrust matters. Oracle is one of its most influential members. Similarly, Oracle is a member of the OpenForum Europe (where Don Deutsch gave that talk), and it uses the FSFE for its purposes.

But when one of the most important open source organizations tells Oracle that FRAND terms "are not compatible with open source or Free software licenses", the answer is just that all Apache will get is FRAND -- take it or leave it. The Register also interprets it as saying "this is Oracle's stance on the matter and it's not changing."

As Apache's aforementioned succinct reply shows, the organization insists that this attitude constitutes a breach of the Java standard-setting agreement and, most of all, its section 5.C.III. You can find that agreement here, and this is a wording the ASF interprets in its favor:/p>

"[...] the [licensor] agrees not to impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations."

Apparently the ASF believes that this means its open source implementation of Java (the Apache Harmony project) must not be restricted. However, as I've already shown, Oracle says that FRAND licensing is "consistent with its obligations under the [standard-setting agreement]."

IBM -- the largest member of ECIS and OFE and financier of the FSF/FSFE -- supports Oracle

So Oracle believes FOSS can be reconciled with FRAND. And guess where IBM -- the other large company supporting the same European lobbying entities (ECIS, OFE and FSFE) -- stands: firmly on Oracle's side.

For a long time Big Blue supported not only the ASF in general but also its Java implementation, Harmony, in particular. Last month, however, it defected and now supports Oracle's OpenJDK, a GPL-based Java implementation.

IBM's open source VP Bob Sutor wrote on his blog that this switch of allegiance "will help unify open source Java efforts" and that "customers will benefit by having first class Java open standards developed collaboratively and constructively".

The Guardian's technology blog, however, calls this move "as much divisive as unifying."

The decisions and positions taken by those companies completely undermine the efforts of their "open standards" lobbyists in Europe such as IBM's Jochen Friedrich, who advocates extreme positions, and Oracle's Trond Undheim, who (as I mentioned in a recent post) referred to a group of EU officials as "rats" transmitting the "RAND disease" (RAND is synonymous with FRAND).

Upcoming Brussels conference on intellectual property rights and standardization

This endorsement of FRAND's compatibility with open source by Oracle and IBM has interesting implications to the debate taking place in Europe over open standards. Like I said at the beginning, the European Commission and the European Patent Office are going to host next week a conference on "Tensions between intellectual property rights and standardisation: reasons and remedies".

Some of the players I mentioned will speak there. Oracle's friend of FRAND, Don Deutsch, is on a panel on "ex-ante commitments to licensing terms". Thomas Vinje, counsel to Oracle as well as ECIS, will talk about the "certainty of availability and continuity of essential IP rights for licensing". An IBM patent attorney, Nicolas Schifano, is also on that panel. Finally, the FSFE's Karsten Gerloff will give a speech on "open source, freely available software and standardization".

I believe Don Deutsch won't be able to avoid discussing the Java situation. That one is important in and of itself, but it also plays a role in the patent infringement suit Oracle filed against Google and which draws more attention right now than any other patent suit in the industry (although there are so many going on, especially concerning mobile devices).

In its answer to Oracle's complaint, Google references the ASF's criticism and Oracle's obligations under the Java standard-setting agreement to allow independent implementations. Oracle claims seven of its Java patents are infringed by Dalvik, the virtual machine for Google's Android mobile operating system. Dalvik is derived from a part of the Apache Harmony code. So Oracle's denial of a different license has ramifications way beyond the ASF's desire.

The field-of-use restriction Apache complains about relates to mobile devices. Oracle allows independent Java implementations, but it draws a line in the sand where smartphones and tablets are concerned, for commercial reasons. This is a perfect example of a restriction that has nothing to do with royalties. Those who oppose FRAND often try to narrow the issue down to license fees while I advocate a more comprehensive approach.

Political debate and mixed-source reality

The conference "is part of an open dialogue process that the Commission is undertaking with key stakeholders [...] The EPO and the Commission hope to organise further events and meetings on issues relevant to IPR and ICT standards, with the objective of improving transparency and predictability in this crucial field."

While several of the speakers have a propensity for politicizing this topic, the conference program also lists panelists who operate on a day-to-day basis in the mixed-source reality of the IT industry. For instance, SAP is a markedly Linux-friendly vendor of proprietary software and should be able to tell us about how to cross the span. I also see major telecommunications equipment companies on the list. Nokia co-founded the MeeGo project, an open source mobile operating system based on Linux. But Nokia instigated patent litigation against Apple and is having an argument over FRAND licensing. This seems to me a perfect example of a company that cares about open source as well as its intellectual property.

In terms of an additional type of stakeholder that would have been great to have on one of the panels, I wish there were some SMEs (rather than just an association claiming to speak on their behalf) with mixed-source expertise and a complete focus on meeting customer needs by combining the best of both worlds. There are many of them out there.

That said, I really look forward to attending the conference next week and will report on it here (in compliance with applicable house rules, of course).

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.

Next Android patent suit: Vertical Computer Systems v. Samsung and LG

"The freebie operating system is proving to be quite a little suit magnet", wrote Maureen O'Gara after digital security company Gemalto announced its patent infringement suit against Google, Samsung, Motorola and HTC over Android's application platform and development tools. Meanwhile, Apple sued Motorola, and here's the next one:

Yesterday, Vertical Computer Systems, a provider of Internet technologies, filed a complaint (click to access the document) with the United States District Court for the Eastern District of Texas against Samsung Electronics, LG Electronics, and Interwoven, an Internet infrastructure software company. Samsung and LG allegedly infringe two of Vertical's patents with certain Android-based products, including but not limited to the LG Ally phone and five different Samsung Galaxy products (four smartphones and a tablet computer).

Vertical claims that all three defendants infringe the same two patents. Both patents-in-suit -- US Patent No. 6,826,744 and US Patent No. 7,716,629 -- read on a "system and method for generating websites in an arbitrary object framework." The latter is a continuation patent extending the former. It was granted this year and, according to a Vertical press release, increased "the scope of the original patent by adding 32 new claims on top of the original 53 claims".

In 2007, Vertical filed a suit against Microsoft over the '744 patent (the original one) -- with the same court in which yesterday's suit against Samsung, LG and Interwoven was filed. An SEC filing dated 28 July 2008 indicates that the case was settled with a license deal:

"Pursuant to the confidential settlement agreement, [Vertical] has granted to Microsoft a non-exclusive, fully paid-up license under the patent which was the subject of the legal proceeding."

Later, a financial report shed some light on the terms of the settlement:

"[...] the impact of the one-time Microsoft settlement that provided $1,533,000 of operating income for the year ended December 31, 2008 [...]"

Thereafter, Vertical was waiting for the continuation patent it received this year in order to enforce its rights more aggressively. This is another quote from that same SEC filing:

"We are waiting for the issuance of the Continuation Patent for U.S. Patent No. 6,826,744 (which SiteFlash™ is based upon) before we engage with new licensees because we believe the Continuation Patent provides better protection for this intellectual property asset."

Now they have that continuation patent. They will try to charge higher royalties than in the past, and they will point other companies to the fact that Microsoft deemed it commercially prudent to settle a litigation with a license deal. Maybe some others have already paid, but Samsung and LG apparently refused to and now they find themselves in court.

What should Google do? I can't think of any other company that would have exposed its partners -- the makers of Android-based devices -- to so many patent problems. Six weeks ago I wrote about the crossfire of patents in which Android is caught. That was shortly after Microsoft's complaint against Motorola, prior to which there were Apple's suit against HTC and Oracle's against Google, and in the six weeks since that "crossfire" blog posting, three more such suits have been filed (Gemalto, Apple vs. Motorola, and now Vertical vs. Samsung and LG).

I just commented yesterday that Google makes a really weak showing against Oracle by failing to launch an infringement countersuit in order to get some leverage.

The Android patent situation is completely out of control and there are no signs of improvement. On the contrary, Android's serious patent problem continues to exacerbate.

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.

Google makes weak showing against Oracle: more than three months later, still no counterthreat

On Wednesday (10 November 2010), Google filed its answer to Oracle's amended complaint dated 27 October 2010.

Five weeks earlier, on 4 October 2010, Google had already responded to Oracle's original complaint dated 12 August 2010. I commented on that answer and wrote that I was "unsurprised and underwhelmed" by Google's defense. Looking at the current state of the case, I think everything is still going according to plan for Oracle and this dispute is going to cost Google dearly.

I'm much less worried about Google than about the Android ecosystem as a whole, which could suffer severely because Google fails to protect it. (By the way, I use a Samsung Galaxy S i9000.)

Besides those who are totally in the tank for Google, only the impressionable can conclude from Google's unsubstantiated and unsurprising defense that Oracle faces a serious obstacle. It doesn't.

Oracle has many strings to its bow: seven patents, some copyrights (a subject on which I commented in my previous posting), and presumably more patents in stock should there be a need to up the ante.

The only thing that could realistically redress or even tip the balance would be a serious countersuit. More than three months after Oracle threw down the gauntlet, Google still hasn't been able to mount a counteroffensive. At this stage it's increasingly likely that Google just can't: other defendants struck back within about a month or two of being sued.

For the Android community as a whole and especially for developers whose applications run on the Dalvik virtual machine, Google's toothlessness is reason for grave concern. There's a saying that "the best defense is a good offense". That's also the name of the game in patent disputes. If Google can't play that game, it may be in for a nightmare.

Google still hasn't managed to do what Apple, Motorola and even HTC pulled off

Google's weak showing is particularly disappointing when compared with how all the other defendants in the major smartphone patent suits fight back:

• Nokia filed a complaint against Apple in Delaware on 22 October 2009 over 10 patents. Seven weeks later, on 11 December 2009, Apple claimed in the same court that Nokia infringed 13 of its patents. If Google acted like Apple, it would already have countersued Oracle in late September or early October.

• Apple lodged complaints against HTC with the ITC as well as a Delaware court on 2 March 2010. HTC responded with an ITC complaint against Apple on 12 May 2010 (later it also countersued in Delaware). So there were ten weeks between the original complaint and the first counterstrike. At HTC's pace, Google would already have countersued Oracle in mid October.

• Microsoft lodged complaints against Motorola with the ITC as well as a court in Western Washington on 1 October 2010. Less than six weeks later, Motorola filed its unsurprising countersuits. If Google were Motorola, it would already have countersued Oracle before the middle of September.

It's not just the time line that's worrying about the absence of a Google countersuit against Oracle. It's also the procedural stage. Apple's counterclaims against Nokia were made as part of its answer to the original complaint. HTC and Motorola instigated their suits even prior to their defensive replies. Google has already responded to Oracle's original complaint and the amended one, but merely defensively.

Google has presented a number of defensive theories but may not be able to support any of them

I can appreciate that Oracle vs. Google is such an important and interesting litigation that several media have already reported on Google's answer to Oracle's amended complaint. But I missed two fundamentally important pieces of information in the reports I saw: a reference to the continued and increasingly worrying absence of a countersuit by Google, and a statement of the fact that a defensive theory presented in such a filing isn't necessarily supported by any evidence.

There's nothing unusual about Google presenting defensive theories at this stage without substantiating them in any reasonably specific way. Other defendants do the same thing all the time. But until Google presents facts that really give meaning to those theories, the mere mentioning of those theories doesn't change a thing. What we see in that court document is a skeleton, but it hasn't really been fleshed out yet.

Google's defensive theories per se are just what every other deep-pocket defendant facing a major threat would do: point to each and every defense possible, including absolute long shots that may completely fail to convince the court when the facts are on the table. There's no penalty for that other than the cost of the lawsuit, which is negligible when you have as much at stake as Google does with Android.

Google obviously wants to keep all options open and clutch at every straw while it can. That's normal and legitimate, but a knowledgeable unbiased observer can't be overwhelmed by that. No one would have expected Google to throw in the towel in the early stages of the game.

Nothing unusual about Google's defense

Against Oracle's patent infringement assertions, Google puts forward all the usual defenses that you can find in any of the answers to the other smartphone patent complaints.

For example, every such document I've recently looked at contained an invalidity defense, and every claim of the patents-in-suit being invalid listed every conceivable theory including a reference to 35 U.S.C. 101, the paragraph on patent-eligible subject matter. Everyone seems to try. Google places particular emphasis on that theory but there isn't any particular reason to assume that those Java patents lend themselves to invalidation on the grounds of being too abstract. Also, the Supreme Court's Bilski ruling didn't expand the scope of what is considered too abstract for patent-eligibility: it merely reaffirmed the standards previously applied.

So my best guess is that Google stresses that part of its invalidity defense to curry favor with software patent critics in the open source community. That approach of submitting to a court of law what is actually directed at the court of public opinion was already displayed by Google's answer to Oracle's original complaint in another context (the Java Community Process).

On the copyright side of the case, it's not a major surprise that Google claims that others contributed the relevant program code. In an open source context, one might try that, but in the posting I just linked to I explained that this would only make a gradual difference. It certainly wouldn't be an excuse for continuing to distribute infringing material.

It's also obvious that Google will try to get some mileage out of the fact that Oracle/Sun published certain program code on open source terms. Google will try to leverage that fact in the patent and the copyright part of the case. However, since the code in question was published under the GPL, it's hard to see how Google's code (under the Apache license) would benefit. Those are incompatible open source licenses.

Again, I don't blame Google for not presenting more evidence at this stage. It's just that if it doesn't put forward some real substance later on, it will lose, and at this juncture I haven't seen Google do anything that would surprise (let alone scare) Oracle. When the decision-makers in Redwood Shores looked at Google's answer, they must have been extremely relaxed and thinking to themselves that so far everything was going according to plan. Whatever that plan is -- it could have major negative consequences for the Android developer community -- remains to be seen. Google hasn't thwarted it, and I increasingly doubt that Google will prevent Oracle from getting its way. Whatever that way may be.

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 copyright part of Oracle vs. Google

In my previous reporting on Oracle vs. Google, I have naturally focused on the patent infringement claims brought forward by Oracle against Dalvik, the virtual machine for Google's Android operating system. After an initial reaction, I looked at licensing issues, the Open Invention Network's failure, Google's stance on software patents, international equivalents of the patents-in-suit, the FSF's belated and misleading statement, and possible inaccuracies in Google's description of the history of the Java standard.

However, in addition to allegations that Google violates seven Java patents, Oracle also asserts copyright infringement. Patents and copyrights have a lot in common -- they are both intellectual property rights and both relevant to software -- but there are also significant differences in terms of the scope of protection.

Let's take a closer look now at the copyright part of the lawsuit from the procedural as well as the substantive angle.

Oracle provided some more clarity in response to a Google motion to dismiss the copyright infringement claim

If a company sues another over the infringement of intellectual property rights, it has to be somewhat specific in its complaint but there's a limit to the level of detail that is required at that stage. Most of this is left to the fact-finding stage of the proceeding.

I don't want to get (at least not now) into the debate whether some more specificity should be required. Gene Quinn, the author of the IPWatchdog blog, expressed a critical view of the status quo in this post. Note the final paragraph. In that one, he admits that he can't blame any particular plaintiff for playing by the rules:

"If you can initiate a lawsuit without any information to actually inform the defendants as to what they are doing that might be infringing then you might as well. If the Courts will allow you to file a complaint that says I think you are infringing but I’m not about to tell you how or why I think that; go figure it out yourself, then you might as well. [...] There is an enormous strategic advantage to keeping the defendants guessing and in the dark for as long as possible."

Basically, that's what Oracle tried as well. In its original complaint against Google, filed on 12 August 2010, Oracle listed seven counts of patent infringement (one patent per count) and added an eighth count on copyright infringement. That one, however, didn't specify the infringed rights and the infringing material too clearl. In item 38, Oracle claimed that Java is protected by copyright. In item 39, Oracle then claimed that "Google's Android infringes Oracle America's copyrights in Java and Google is not licensed to do so." In item 40, Oracle stated that "users of Android, including device manufacturers, must obtain and use copyrightable portions of the Java platform or works derived therefrom to manufacture and use functioning Android devices. Such use is not licensed. [...]"

That claim just specified that Android contains software that infringes Oracle's (originally, Sun's) copyright in Java. But Android and Java are two large pieces of software, and on 4 October 2010, Google filed (in parallel to its answer to the complaint) a motion to dismiss the count on copyright infringement "or, in the alternative, for a more definite statement". Among other things, Google wrote:

"Oracle's Complaint includes impermissibly vague and broad allegations of copyright infringement. In particular, the Complaint does not specifically identify any allegedly infringing works of Google, how Google has allegedly infringed Oracle’s rights in the two Sun works attached to the Complaint, or how Oracle believes its claim of vicarious liability for copyright infringement arises."

The short version of the above is "show me, I'm from Missouri."

Oracle didn't want to risk that its copyright infringement claim might be dismissed. On 27 October 2010 it filed an amended complaint with a significantly more specific Count VIII. To document an example of the alleged copyright infringement, Oracle attached a new Exhibit J juxtaposing code excerpts from Oracle/Sun's Java codebase to excerpts from a part of the Android codebase. Oracle made that filing one day before a deadline by which it would have had to reply to Google's motion.

The court formally asked Google (on 28 October 2010) to clarify whether (and if so, on what basis) it still believed Oracle's copyright infringement claim should be dismissed. On 1 November 2010, Google signaled that it could live with the amended complaint, which resulted -- still on the same day -- in the court's denial as moot of Google's motion to dismiss Count VIII. There was no more need to decide whether Google's motion was meritorious when filed: it had just become pointless in the meantime.

On 10 November 2010, Google submitted its answer to Oracle's amended complaint. In that one, Google denies copyright infringement and brings up every conceivable defense (without providing any detail that would support those defenses).

Oracle probably has a point about copyright infringement (at least to a certain degree)

At this stage it would be premature for me to agree with Oracle on its copyright infringement claim. While Oracle's amended complaint provides some more information, it still doesn't specify everything that one needs to know. As you saw further above in my quote from Gene Quinn, it's in a plaintiff's interest to keep their cards close to their chest for as long as possible.

But based on the information that has already been provided, I would be very surprised if Oracle's copyright infringement assertion was dismissed entirely.

Maybe Oracle will find it difficult to prove the full extent of its allegations (including that Google acted "knowingly" and "willingly"). Some of that may depend on fact-finding. But even in the event that Google is found less culpable than Oracle claims, there might still be a copyright infringement, which would entitle Oracle to all sorts of relief that would be devastating for Google and Android at any rate.

There's an important thing to bear in mind here: a copyright infringement (if there is one) is illegal and must be stopped. Simple as that.

"Others did it" doesn't matter too much -- and it particularly doesn't help app developers

Google's Sixteenth Defense (item 24 of its answer to the amended complaint) states the following:

"Any use in the Android Platform of any protected elements of the works that are the subject of the Asserted Copyrights was made by third parties without the knowledge of Google, and Google is not liable for such use."

However, claims that "if anything was wrong, others did it" (which is the short version of the above) don't mean Google isn't liable in any way. We're talking about a potential difference that would only be gradual in terms of some of the consequences for Google, such as the amounts of possible damage awards. But from the perspective of an Android developer, a defense like "others did it" doesn't make any difference at all because if there is an infringement, Oracle can stop Google (and anyone else!) from continuing to make such software available, with all it entails for the Android application ecosystem.

What I just explained is something that the other reports I saw on this didn't really point out. As an app developer, the last thing I would worry about is whether Google has to pay $50 million, $500 million or $5 billion. I would only be concerned about whether my application will still have a legally safe basis on which to run, or whether I would have to make modifications or even undertake a complete rewrite (possibly in a different programming language) when all of this is over.

In item 40 of its amended complaint, Oracle states (among other things) the following:

"Android includes infringing class libraries and documentation. Approximately one third of Android’s Application Programmer Interface (API) packages (available at http://developer.android.com/reference/packages.html) are derivative of Oracle America's copyrighted Java API packages (available at http://download-llnw.oracle.com/javase/1.5.0/-docs/api/ and http://download-llnw.oracle.com/javase/1.4.2/docs/api/) and corresponding documents."

The website on which the allegedly infringing material has been made available, android.com, is a Google website. In item 12 of its answer to the amended complaint, Google points to the "Open Handset Alliance, a group of 78 technology and mobile companies that includes Google". So what? Oracle doesn't appear to hold Google responsible for the content of the Open Handset Alliance website. If Oracle wanted, it could make the same claims against other members of the Android ecosystem, but for whatever reasons (such as existing business relationships) Oracle decided to focus on Google, at least for now. And android.com, to which Oracle's allegations relate, is a Google website, which is also made perfectly clear by the site's terms of service. Google isn't allowed to distribute infringing material.

Code similarities indicate that some infringement has indeed occurred

I have taken a detailed look at the code excerpts provided by Oracle in Exhibit J of its amended complaint. If I had written the original Java code shown in the left column of that juxtaposition and if I then saw the Android code in the right column, I, too, would claim that my copyright has been violated.

It's important to know that Oracle provided that exhibit only as an example. Item 40 of Oracle's amended complaint claims that "[i]n at least several instances, Android computer program code also was directly copied from copyrighted Oracle America code. [...] not just in name, but in the source code on a line-for-line basis."

Some commentators have overstated the importance of Google's denial of the correctness of that piece of evidence, which is found in item 40 of Google's answer to the amended complaint:

"[...] Google further denies that the document attached to Oracle's Amended Complaint as Exhibit J contains a true and correct copy of a class file from either Android or “Oracle America's Java.” Google states further that Oracle has redacted or deleted from the materials shown in Exhibit J both expressive material and copyright headers that appear in the actual materials, which are significant elements and features of the files in question."

There's nothing spectacular about that. It doesn't mean that Google believes Oracle made something up entirely. Actually, Oracle's Exhibit J makes it perfectly clear that it isn't an unmodified copy of the relevant code segments. The headline of the left column states "[comments removed and spacing adjusted for comparison]", and the headline of the right column: "[spacing adjusted for comparison]". So by denying that this is a "true and correct copy", Google simply keeps the option open to claim later that whatever Oracle redacted was so very relevant it shouldn't have been left out. However, if Google could prove that Oracle forged a document, I'm sure it would already have said so. Realistically, Oracle is a tough company but it certainly doesn't engage in any criminal activity. So let's not overstate Google's unspecified denial.

I can't imagine that the original versions of those files would render Oracle's claim invalid. The part that Oracle provides shows what really appears to be an infringement.

This is getting very technical now, but let me explain what Exhibit J shows in terms of copying of code.

The interface

The PolicyNodeImpl.java files implement (the "Impl" in the file name stands for "implementation") the PolicyNode interface, which is part of the java.security.cert library. That interface describes the structure of a tree node (an item in a tree-structured collection of data) "as defined by the PKIX certification path validation algorithm." PKIX appears to be a public-key infrastructure standard defined by the Internet Engineering Task Force (IETF).

That interface is a concise rather than talkative one. It mandates seven methods that basically appear to be read-only properties: getChildren (returns child nodes in the form of a thread-safe iterator), getDepth (returns an integer value of the depth of the given node within the tree), getExpectedPolicies (returns a set of strings describing "expected" policies), getParent (returns the parent node as an instance of the same class or null for the root node), getPolicyQualifiers (a set of instances of the PolicyQualifierInfo class), getValidPolicy (returns a string describing the valid policy represented by the given node), and isCritical (returns a Boolean value as a "criticality indicator").

It's obvious that two programmers independently implementing such a limited interface may use a number of coding patterns that are similar. However, there comes a point when similarities between two implementations are so far-reaching that it would be easier to win a lottery every week for several years in a row than to come up just by coincidence with such similar code segments through totally independent creation. In other words, at some point it becomes a safe assumption that a copycat was at work, somewhere. Maybe not at Google itself. Maybe not at the Apache Foundation (which has already disowned the code segment in question). But someone somewhere apparently acted as a copycat and somehow tried to cover up what happened but didn't really do a great job at that. The copying that has taken place is, at best, thinly veiled.

Initial declarations and constructor

The declarations at the start of the class definition are identical in both files, including the variable names. Given that those are private variables (as opposed to being part of the public interface definition), they could have been chosen freely, and then it's very unlikely that both files would contain identical variable names in that part of the code.

The constructors obviously have structurally identical parameter lists. However, the Android version of the code replaces all of the parameter names. Such replacements of variable names occur throughout the code shown by Oracle. In the vast majority of those cases, the original Java code uses more desciptive and meaningful names, whereas the variable names were apparently replaced with less informative ones for the Android version.

For example, the two sets named "qualifierSet" and "expectedPolicySet" in Oracle/Sun's code became "set" and "set1" in the parameter list of the Android version. Given that those are sets of different data types and that professional programmers generally avoid variable names with numbers in them, I have a strong suspicion that this is an approach to naming that makes sense only for the purpose of concealing a copyright infringement.

Hypothetically, someone might have just had a preference for shorter names, but a programmer always spends only a limited amount of time typing and a lot of time trying to figure out what the code does, which is why descriptive variable names are the norm and the naming approach of that Android code is, to say the least, highly unusual.

The code of the constructor then processes the parameters in the order in which they appear in the parameter list. In terms of the actual commands, both constructors do exactly the same. The only other difference (besides the slightly different variable names) is that the Android version makes more extensive use of braces in places where they aren't syntactically required. Apparently, the original version of the code uses braces in if/else constructs only if one of the blocks of code has more than one line, while the Android version of the code uses braces at any rate.

Besides the main constructor, there's also a shorter version. That one only has two parameters and then calls the main constructor. Both implementations use different variable names but they have the same logic. The Android version contains some type conversion that appear redundant to me. Again, I don't know who did that and I don't know why, but introducing unnecessary type conversions (converting data into the type in which it's already provided) could be another way of trying to make things harder for "diff" (line-by-line text file comparer) tools.

Patterns in the choice of variable names and the loop structures

Throughout the code (except for the declarations at the very start of the class definition) one can see the difference in variable naming conventions that I explained for the constructors. There are many variable names that are identical in both code excerpts, but if there are differences, they are usually of the kind I described and which doesn't smell right in the Android version.

The Oracle version of the code has a logical priority in terms of when to choose longer variable names (when it's needed to be descriptive) and when to use shorter ones (such as for loop variables). In the Android version it just doesn't make sense that short names are used where descriptiveness is needed, but a loop variable is called "iterator" when loop variables are usually just one or two characters long (Oracle's corresponding code uses "it" for an interator that serves as a loop variable). It strikes me that the Android version, presumably in an attempt to just be different from Oracle's code, runs completely counter to the naming conventions and principles of competent programmers.

Another consistent morphological pattern is that the Android version uses different loop structures (for loops that have the same body in terms of what they do). Some examples:

• The "setImmutable" method of the "isImmutable" Boolean property uses a while loop for the iteration, while the Android version uses a for loop. Again, the Oracle version does what makes logical sense in terms of source code readability. To me that loop is a clear case of a while loop. A for loop would make more sense if you have a loop variable that gets incremented and where you usually exit at a predefined point.

• The "prune" method in Oracle's code uses a while loop, while the Android version uses a do...while(true) construct that I find, frankly, quite horrible and again implausible. It's longer and less readable. It also makes use of the break command to exit the loop if the iterator has reached its end. I admit that I personally like that kind of command as well even though some purists among computer scientists are categorically opposed to it. However, this loop isn't an example of where that makes sense. Oracle's while loop checks right at the start whether the iterator still has items available that can be processed. That way, there's no need to break out of the loop. Also, a while(true) at the end of a loop is unusual. By doing so, the only way one can get out of the loop is with a break command. I could imagine such a structure in some scenarios (in which there would be at least two and usually more break commands), but this isn't one in which it would make sense (other than for the sole purpose of disguising the unauthorized use of Oracle's code).

Another oddity in the Android implementation of that interface is found in the "deleteChild" method. Unlike the Oracle version, the Android version has a return command at the end of the else block. However, there's no other code that would be executed, so the return command is just redundant.

What also strikes me as highly unusual is the use of i as a parameter name for the "getPolicyNodes" method. In Oracle's version, that integer parameter is called "depth", which makes sense and its descriptive. Usually, programmers reserve i exclusively for the use of a loop variable name.

The "getPolicyNodesExpected" method in Oracle's version performans a comparison with an ID defined at the start of the source file in the ANY_POLICY static variable. Even though the Android version also defines that static variable and assigns the same name to it, its "getPolicyNodesExpected" implementation contains a literal ("2.5.29.32.0") although it normally should and would use the static never-changing variable. The same pattern is found in the implementations of the "policyToString" member. Again, the most plausible explanation is that someone violated clean code conventions only in order to create an artificial difference between his code and Oracle's original code.

Finally, the "asString" function: both implementations use a stringbuilder, which is a more performant way of composing strings than string variables if a number of strings are concatenated. Since almost every line in that function starts with a reference to that stringbuilder instance, this is similar to a loop variable and one would, as in Oracle's code, choose a short variable name ("sb" in that case). But the Android version uses the long name "stringbuilder". This is similarly anti-conventional as "iterator" for a loop variable.

My assessment of the situation based on the information available at this point

While Oracle's Exhibit J contains only a somewhat limited amount of code, I have a really strong feeling that Oracle's copyright has been infringed and that someone made a rather pathetic attempt to veil that infringement by using the reverse approach to naming conventions as in the original code (with the net effect that variable names in the Android version are descriptive when every reasonable programmer would keep them short and are short when every reasonable programmer would want them to be descriptive), an excessive use of braces, and loop structures that are partially so bad that someone couldn't possible pass a computer science exam with such an abysmal coding style.

Even though the interface those code excerpts implement is of limited complexity, an independent creation of the Android version of the code that innocently happened to arrive at code so similar to Oracle's version isn't plausible to me at all. The differences are superficial, and where the Android version is different at all, it's different in a way that flies in the face of everything I know about coding. As a software developer and a former computer book author, I hope I know a thing or two about that...

I will take a look at the copyright aspects of Oracle vs. Google again whenever more information becomes available. For now, if I had to bet money, I would without hesitation bet it on Oracle's claim that what we see here is indeed a copyright infringement. Who wrote the apparently infringing code is another question, but like I explained further above, from the perspective of Android application developers there's absolutely no comfort in that because the potential effects on developers are independent from the answer to that secondary question.

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.

No surprise here: Motorola countersues Microsoft over alleged patent infringement

[Updated with a complete list of the patents asserted in the complaints -- three of those patents were previously asserted by Motorola Mobility against Apple]

Motorola announced that it has done what everyone watching the smartphone patent disputes knew was going to happen: it countersues Microsoft over allegations of patent infringement.

In the patent suits involving Android, everyone with the exception of Google has already countersued. Even HTC with its tiny patent portfolio countersued Apple (with a complaint to the ITC that related to 5 patents and counterclaims before the US District Court for the District of Delaware relating to 3 other patents).

It's a safe assumption that all of the parties who made the first move in a dispute carefully evaluated the other side's portfolio and decided to go ahead at any rate. Those countersuits are common and, consequently, expected.

Six weeks ago, Microsoft lodged complaints with the ITC and the US District Court for the Western District of Wisconsin, asserting the infringement of nine of its patents by Motorola's Android-based smartphones. And just a day before Motorola's expected countersuit, Microsoft filed another suit against Motorola for allegedly failing to honor its commitments to make certain patents related to standards available on the reasonable and non-discriminatory (RAND) terms required by the relevant standards-setting organizations.

Patents-in-suit and fora

Motorola Mobility, a subsidiary of Motorola, filed a total of three suits against Microsoft: one complaint (over 7 patents) with the US District Courts for the Southern District of Florida (where it previously sued Apple over 6 patents) and two complaints (one over 3 patents and another over 6 patents) with the Western District of Wisconsin (where Apple sued Motorola over 6 patents, including one that it previously asserted against HTC before the US District Court for the District of Delaware).

Motorola Mobility now claims that "Microsoft’s PC and Server software, Windows mobile software and Xbox products" infringe those 16 patents. Motorola says in the press release that the patents relate to technologies in the fields of operating systems, video codecs, email, instant messaging, object-oriented software architectures, WiFi, and graphical passwords.

That broad description suggests potential overlaps with the patents to which Microsoft's RAND complaint related. Also, I have looked at the complaints and found that 3 of the patents Motorola asserts against Microsoft have previously been asserted against Apple:

• US Patent No. 6,272,333 on a "method and apparatus in a wireless communication system for controlling a delivery of data" appears in Motorola Mobility's complaint filed against Microsoft in the Southern District of Florida as well as in one filed against Apple in the Northern District of Illinois. That patent appears to relate to a way of sending to "subscribers" (this would include mobile device users) only data that can be processed by the applications they have actually installed, also taking into account the particular versions of those applications, so as to save the costs of transferring data that wouldn't be useful on the local device for lack of software capable of processing such data. The patent application was filed in 1998. The patent was granted in 2001, and its validity will be presumably be challenged now by Apple and Microsoft.

• US Patent No. 5,311,516 (on a "paging system using message fragmentation to redistribute traffic") and US Patent No. 5,319,712 (on a "method and apparatus for providing cryptographic protection of a data stream in a communication system") appear in one of Motorola Mobility's two complaints filed against Microsoft in the Western District of Illinois (the one relating to 6 patents) as well as one filed against Apple in the Northern District of Illinois. Those two patents are old. The applications were filed in 1992 and 1993, so they are only a couple of years away from inevitable expiration. However, they may never get there since I believe Apple and Microsoft will challenge their validity now.

Motorola Mobility's Southern Florida complaint relates to six other patents than the '333 patent mentioned above:

• No. 5,502,839 (an "object-oriented software architecture supporting input/output device independence")

• No. 5,764,899 (a "method and apparatus for communicating an optimized reply")

• No. 5,784,001 (on a "method and apparatus for presenting graphic messages in a data communication receiver")

• No. 6,408,176 (on a "method and apparatus for initiating a communication in a communication system")

• No. 6,757,544 (on a "system and method for determining a location relevant to a communication device and/or its associated user")

• No. 6,983,370 (on a "system for providing continuity between messaging clients and method therefor")

The first of Motorola Mobility's two complaints filed against Microsoft in the Western District of Wisconsin relates to the following three patents:

• No. 7,310,374

• No. 7,310,375

• No. 7,310,376

All of those three patents relate to a "macroblock level adaptive frame/field coding for digital video content" and were obtained by General Instrument (GI), a Motorola subsidiary. Motorola completed its acquisition of GI in January 2000, and those three patents were applied for in 2004.

Motorola's other Western District of Wisconsin complaint relates to four patents in addition to the '516 and '712 patents mentioned above:

• No. 5,357,571 (on a "method for point-to-point communications within secure communication systems")

• No. 6,686,931 (on a "graphical password methodology for a microprocessor device accepting non-alphanumeric user input")

• No. 6,980,596 (on a "macroblock level adaptive frame/field coding for digital video content"; this is another General Instrument codec patent in addition to the three that bear the same title and are subject to the other complaint filed with the same court)

• No. 7,162,094 (on "frequency coefficient scanning paths for coding digital video content"; another GI codec patent)

Motorola's General Instrument subsidiary joins Motorola Mobility as plaintiff in both complaints filed in the Western District of Wisconsin (one of them relates to 3 GI patents and the other to 6 patents including 2 GI patents).

Strength vs. numbers

One thing that's important to consider when looking at all of the suits and countersuits is that the quantities of patents asserted are a factor of limited importance. What really matters is whether those patents are chosen from a strong portfolio (strong in terms of breadth and depth), whether they are valid, and whether they are actually infringed (and if so, whether a defendant could, should the need arise, easily work around them or just drop some functionality that customers won't miss).

The conflicts between Apple and Android phone makers HTC and Motorola have shown that such conflicts can escalate with parties adding more patents during the process. That is a possibility in all these disputes.

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.