Why Paul Allen doesn't want to be a troll

ZDNet blogger Ed Bott has already made the case that Microsoft co-founder Paul Allen and his Interval Licensing company don't meet the definition of a "troll".

They sue a number of large players over some patents, but there's some history there that sets them apart from other licensing (or "non-practicing") entities. Among 11 defendants, the lawsuit targets Google (as well as its YouTube subsidiary), and Google once gave credit to Interval Research (the company whose patents are now being enforced) on its About page (shown toward the bottom of this screenshot).

This indicates that Interval did indeed contribute to Internet innovation.

A matter of business models

I for my part prefer the business model of companies putting out actual products and don't like the notion of software innovation being largely a matter of patent filings.

However, Google's founders applied for the PageRank patent very early on through Stanford University, where they developed their technology prior to founding their company, and owe their success in no small part to that kind of exclusivity (which Google still maintains by not licensing its most important patents to any competitor). So if Google favors this kind of business model and knowingly and willingly cooperated with Paul Allen's company on that basis, it may now have to eat its own dogfood.

Of course, there are some other companies who may never have had a working relationship with Interval but get sued anyway, such as Facebook. But I haven't seen any company on the list of defendants (Apple, Google + YouTube, eBay, Facebook, Yahoo, Netflix, AOL, Office Depot, OfficeMax, and Staples) who would ever have spoken out against software patents.

Contrary to opposing software patents, Google essentially supported the patentability of software in its Bilski brief, Apple goes after HTC very aggressively, Yahoo is known to be pro-patent and eBay co-financed lobbyists who advocated software patents in the EU and against whom I fought with the NoSoftwarePatents campaign at the time.

So they now have to respect the rules they themselves favor.

Recognition

Based on what a spokesman for Paul Allen has said (quoted by Ed Bott), I believe that this is a matter of recognition for contributions to innovation.

In the world of business, being paid for a contribution -- in this case, for patents -- is the sincerest form of recognition. Unfortunately, it seems that a lawsuit was necessary to (maybe) get there.

Given Paul Allen's biography, a categorization as a "troll" just wouldn't make sense. If other world-class entrepreneurs such as Larry Ellison, Steve Jobs, Larry Page or Sergey Brin founded a research company and later tried to commercialize their patents, they couldn't be called "trolls" either.

To me a troll is someone who never contributes in any serious way to innovation and simply leverages the patent system (which has serious problems, let there be no doubt about it) for his purposes. Entrepreneurs who have actually proven -- in Paul Allen's case multiple times -- that they can build real businesses aren't trolls.

Similarly, if a company like Yahoo registers some web domains for future use, that can hardly be considered an act of "domain grabbing" except under the most egregious of circumstances.

By contrast, NTP, the company that received $612 million from the BlackBerry company in 2006, was set up by lawyers. No programmers, no entrepreneurs. Just legal experts who identified and seized a business opportunity by obtaining a monopoly on some key functionality and litigating. They're still doing it, now suing Apple, Google, HTC, LG, Microsoft and Motorola.

Legal implications: entitlement to injunctive relief

In addition to image and psychological considerations, the question of "troll or not" has a very important legal aspect: in the US, "trolls" usually don't get injunctions anymore.

The possibility of obtaining an injunction -- a court order that forces an "infringer" to stop offering infringing services or products -- is powerful leverage in the hands of a patent holder. I explained in this earlier posting that injunctions are the most dreadful use of software patents and without that threat the BlackBerry company would probably not have felt forced to cough up $612 million back in 2006.

Only a few months after the BlackBerry blackout was averted at the 11th hour, the US Supreme Court decided on a different patent matter: eBay vs. MercExchange.

In that context, the key question put before the SCOTUS was under which circumstances a patent holder can obtain an injunction against an infringer and under which those patent holders have to content themselves with monetary indemnification (but can't disrupt the infringer's business).

That is a very US-specific kind of legal question. In Germany, for instance, no one even asks that question because §9 of the German "Patentgesetz" (patent act) makes an injunction an absolute right that any patent holder can demand. But the relevant part of the US Patent Act (35 U. S. C. §283.2) allows injunctions only "in accordance with the principles of equity" (the latter meaning "justice" or "fairness" in this context). So there can be an argument over whether an injunction is appropriate or overreaching in a particular scenario, all things considered.

The eBay vs. MercExchange ruling and what it means for Paul Allen's Interval Licensing company

Before the Supreme Court looked at the case, there had been two conflicting decisions by prior instances. Despite finding that eBay infringed MercExchange's patents (which were considered valid), MercExchange was denied an injunction by the first instance, a district court which argued that MercExchange was willing to license those patents (in other words, only after some license fees) and, very importantly, was not "practicing the patents" commercially. The latter was certainly an allusion to the term "non-practicing entities" (or some say "non-producing", but here we're talking about Internet services, not products per se), a euphemism in many cases for "trolls".

That was one extreme. The second instance, the Court of Appeals for the Federal Circuit (CAFC), took a diametrically opposed position. The CAFC believed that injunctions are the norm and refusal to grant them is a rare exception. In particular, the CAFC said that injunctions would be denied only under "exceptional circumstances [and] in rare instances [...] to protect the public interest." MercExchange would not have been exceptional only for being a non-practicing entity.

The Supreme Court then took a unanimous decision disagreeing with both lower instances. The first instance had established a broad rule that the SCOTUS considered to be too hard on patent holders, while the second instance favored the rights of patentees too much (that case wasn't the first, only or last time where it did so).

Some misunderstood the SCOTUS decision as supporting pretty much the first instance (trolls can't get injunctions). But in reality, the SCOTUS outlined a more complex legal test than either of the lower instances and favors a significant degree of flexibility:

After reaffirming a sophisticated four-factor test that a patent holder must pass to obtain an injunction (irreparable harm, money not being enough, patent holder unjustly suffering more from not getting an injunction than the infringer would under an injunction, no disservice to public interest), the SCOTUS also explained that "some patent holders, such as university researchers or self-made inventors, might reasonably prefer to license their patents, rather than undertake efforts to secure the financing necessary to bring their works to market themselves. Such patent holders may be able to satisfy the traditional four-factor test [...]"

So it would be incorrect to claim that the SCOTUS wanted to deny all non-practicing entities the right to obtain injunctions against infringers. The ruling certainly raised the bar for non-practicing entities very considerably. Until that decision, a lot of judges in the US really thought that an injunction was pretty much a foregone conclusion (provided that there was an infringement of presumably valid patents).

But make no mistake: the SCOTUS also wanted to support the patent-centric business model I described further above.

In its lawsuit, Interval Licensing asked for an injunction but for the event that it can't get one just requested financial compensation. That's different from Apple and Oracle, who in their suits against (respectively) HTC and Google shoot for injunctions all the way. Apple and Oracle will have no problem with the "four-factor test". With Interval Licensing, it's not certain but just looking at the screenshot where Google gives Interval Research credit, this might be a case in which even a non-practicing entity could be entitled to an injunction, depending on a lot of things I don't know yet (such as the nature of its past contract with Google, and many other circumstances).

Whether it gets to the point where an injunction might be granted will depend on how quickly Paul Allen's company can settle with the 11 defendants. Since there are so many of them, it's possible that one or more of them will decide to see this case through, and then we may get clarification in a few years as to whether this plaintiff is treated by the courts more like a "troll" or more like a legitimate inventor.

Ed Bott was the first one to say this isn't a troll. A court -- possibly even the SCOTUS -- may have the last word on this.

If you are interested in international equivalents to the patents at the heart of this lawsuit, please read the previous posting.

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.

International equivalents of Apple's, Oracle's and Paul Allen's patents-in-suit

The three IT patent cases drawing the most interest these days are

1. Apple vs. HTC (over Android; suit filed in March)

2. Oracle vs. Google (over Java patents allegedly infringed by the Dalvik virtual machine; suit filed in August)

3. the latest: Paul Allen's Interval Licensing vs. 11 defendants (Apple, Google as well as its YouTube subsidiary, eBay, Facebook, Yahoo, Netflix, AOL, Office Depot, OfficeMax, and Staples; over fundamental web/e-commerce patents; suit filed in August)

All of those lawsuits were filed in the US. Apple, in addition to suing in a court, also lodged a complaint with the US International Trade Commission, which could ban imports of infringing merchandise into the US.

While suing only in the US, the three plaintiffs also filed for international equivalents of some of the patents-in-suit (the patents they are now trying to enforce in court). There's a misconception among some people that software patents are a purely American phenomenon. They do exist in Europe, Asia and Australia as well.

There are various reasons for which Apple, Oracle and Paul Allen's Interval Licensing sue only in the US. After all, it's the jurisdiction where they have more patents than anywhere else, it's the largest single market at this point (since the EU doesn't have a single patent that can be enforced Europe-wide in only one litigation), and it's the legal system with which they and their lawyers are most comfortable. If they prevail in the US, they can most probably resolve the matter with respect to the rest of the world through negotiation, typically by agreeing on a worldwide license fee or -- if they want (like Apple) an injunction instead of money, through local cease-and-desist orders or a related clause of an overall settlement.

Nevertheless it's interesting to take a look at the international (European, Asian and Australian) aspects of those spectacular patent cases. It tells something about how internationally oriented those companies were during different parts of their history, and in some cases it shows that some other jurisdictions don't grant patents as easily as the US.

Please note that the information provided below on international equivalents of some of those US patents-in-suit isn't guaranteed to be complete. It is possible that additional international versions of some of the patents-in-suit exist but weren't identified by me.

Apple: very strong international patent portfolio

Of the three plaintiffs discussed in here, Apple clearly has the strongest position in terms of international patents. They always seemed to have been quite internationally oriented, and over the last decade or so even more than before.

Its patent on "time-based, non-constant translation of user interface objects between states" was filed internationally and is currently under examination at the European Patent Office (EPO).

The patent on a "touch screen device, method, and graphical user interface for determining commands by applying heuristics" was also applied for worldwide, in particular in Europe, South Korea, Japan, Canada and Australia. In addition to filing for a regular patent at the European level, Apple also obtained a utility model (a fast-track patent-like right) in Germany. Looking at that list, it's clear that Apple regards this patent as highly strategic.

Another highly strategic patent relates to "unlocking a device by performing gestures on an unlock image." Apple filed in South Korea, Japan, Europe (at the EPO as well as for a German patent, German utility model, Spanish patent and Austrian patent), Hong Kong, China, and Australia.

Also a pretty international patent application relates to "list scrolling and document translation, scaling, and rotation on a touch-screen display." Apple filed for this in China, South Korea, Australia, Canada, Japan, and massively in Europe where it designated 34 countries (even including tiny states like Liechtenstein and Monaco) and took out a fast-track German utility model in addition to applying for a full-blown patent.

Apple's patent application for an "automated response to and sensing of user activity in portable devices" was filed in Canada, China, Japan, South Korea, with the EPO, plus a fast-track German utility model.

Compared to those examples, Apple's patent application going back to 1995 and relating to a "method and apparatus for distributing events in an operating system" was modest. The European patent application only relates to the UK and Germany. They also filed for it in Australia and Japan.

Two other international patent applications from the mid-1990's were limited to Australia and Europe: "a network component system" and a "real-time processing system for serially transmitted data". The international scope of an application published three years ago, relating to an "extensible, replaceable network component system", is similarly limited.

Oracle/Sun: some international patents (but not on an Apple scale)

Sun filed for a patent on "protection domains to provide security in a computer system" in Australia and at the EPO, where it withdrew it (probably by failure to pay fees) in 2000. Companies withdraw such applications only if the examiners have serious objections that make it a waste of time and money to continue the process.

The patent application for a "method and device for preprocessing and packaging of class file" was filed in Japan and with the EPO, where Sun designated six countries (Germany, France, UK, Italy, Netherlands and Sweden).

The James Gosling patent application for a "method and apparatus for resolving data references in generated code" is, surprisingly, still being processed by the EPO in some newer form but an older one appears to have been granted a long time ago. It was also filed for in Japan.

For its "method and system for performing static initialization", Sun filed in China, Japan and with the EPO, where the three largest contracting states (Germany, UK and France) were designated.

Paul Allen's Interval Licensing: could also litigate overseas

Interval filed for its patent on a "browser for use in navigating a body of information, with particular application to browsing information represented by audiovisual data" in Australia and with the EPO, where it, however, withdrew its application in 2000.

Finally, an Interval patent-in-suit with significant international presence relates to an "attention manager for occupying the peripheral attention of a person in the vicinity of a display device." It was filed for in Australia, Japan, and with the EPO, with Germany, the UK and France being the designated countries there.

This overview demonstrates that the patent game is a global one, even though there are reasons (mentioned further above) for which litigation usually takes place in the US when patents are enforced against major IT companies.

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's Bilski brief didn't advocate the abolition of software patents

After Oracle filed its patent infringement suit against Google, most of the initial reactions in the community expressed disappointment over Oracle's action. However, the more time passes, the more people have second thoughts. It's noticeable in the blogosphere and in discussion forums.

I try hard to be fair and as objective as humanly possible. With this posting I want to shed some light on Google's amicus brief in the Bilski vs. Kappos patent case. The Supreme Court of the United Status (SCOTUS) took its decision in late June, and it was a major disappointment and a setback for the free software/open source movement.

Some large IT companies filed so-called amicus curiae briefs (submissions to tell their views to the judges), and since Google is now being sued over patent infringement, it's worth taking a look at what the "Don't Be Evil" company did in connection with Bilski.

Google partnered with financial services organizations

Google filed its amicus brief jointly with Bank of America, Barclays Capital, The Clearing House, The Financial Services Roundtable, Metlife and Morgan Stanley.

All of those organizations Google partnered with are part of, or represent parts of, the financial services sector. While financial services companies are large-scale software users, it would have been a major surprise to find them take a position on software patents. After all, the Bilski patent application wasn't technically a software patent filing. It claimed a method for managing certain risks related to price changes in the energy market.

Also, those banks have business relationships with large software companies that want patent protection. So it's easy to see that they had a narrow focus (just the Bilski type of business method) as opposed to a broader agenda concerning patents including technical software patents.

However, those who oppose software patents looked at the Bilski case as an opportunity for the SCOTUS to establish criteria for patentable subject matter ("patent-eligibility") that, ideally, would have caused collateral damage (or collateral benefit from the anti-software-patent point of view) to the patentability of software.

Google's choice of partners in this is an indication that I wanted to mention because it's easy to understand. If they had partnered with (for instance) Knowledge Ecology International, the likelihood of a truly anti-software-patent brief would have been hugely greater. But let me now explain the content of Google's brief and why it isn't an anti-software-patent position.

Against straightforward business method patents

Google's brief speaks out against "patents on methods of doing business" and "abstract methods and mental processes like [the Bilski application]". It describes the essence of the Bilski patent application as "the abstract idea of managing the weather-related risks associated with energy pricing".

Such an idea could be implemented -- and nowadays would typically be implemented -- in the form of (a part of) a computer program. That's why Google's brief also argues against "patents on [...] software that merely implements such methods".

But this doesn't mean opposition to software patents that relate to other subject matter than the automation of such business methods.

Amazon's patent on the one-click order is probably the most famous business method patent, at least in connection with the Internet. In a totally unconcealed fashion, it could be categorized as a patent on a business method or on "software that merely implements" one. So it's the kind of patent Google proposed to do away with.

Google gave some examples of such patents that the US Patent & Trademark Office has granted: "method and apparatus for tax efficient investment management," a "process for creating a financial plan for ... funding of college education," a "system for funding, analyzing and managing life insurance policies funded with annuities," and a "system, method, and apparatus for providing an executive compensation system."

However, I said before: "in a totally unconcealed fashion". That's what the one-click patent and the examples listed in the previous paragraph are. But if Amazon had to file the patent in an environment where business methods are formally unpatentable, its patent attorneys could try to draft around that restriction. For an example, they could describe it as a signal processing patent, and instead of the convenience for the buyer they could argue with a reduced number of signals (or if it's a "communications" patent, with reduced network traffic). In the end they might monopolize the underlying concept anyway. Maybe they would even obtain a broader monopoly.

That's what I'd call a disguised business method patent. I didn't find anything in Google's brief that stressed the need to do away with such patents as well.

Only against abstract software patents (not concrete ones)

Wherever Google's brief relates to software patents, it does one of three things:

1. complain that there are generally too many of them (which would be an argument for higher quality standards, not necessarily for abolition)

2. refer to the implementation of business methods in software (as discussed in the previous section)

3. limit the scope of statements on software patents with the word "abstract"

The third item means: if a software patent application is too abstract, it should be rejected, but if it's somewhat concrete, it may be fine.

Google's brief doesn't suggest exactly where to draw the line between an abstract software patent and a concrete one. There's no doubt that a patent on a computer program implementing the Bilski idea would be "abstract". But the brief doesn't argue that software is abstract by definition and should, therefore, not be patent-eligible (as many opponents of software patents claim). I don't believe in the strength of the "all software is abstract" argument anyway. So I don't blame Google for not subscribing to it either. I'm just trying to figure out where Google stands, based on its Bilski brief.

The question of whether a patent is too "abstract" has to do with the breadth of the claims (it's the claims where the scope of the time-limited monopoly is defined) and it may also have to do with disclosure (the extent to which an invention is truly explained). Generally, the more "abstract" a patent is, the broader, and the broader, the more valuable. So it's obvious that applicants and their attorneys will try to push something as abstract as possible through the system. It's up to the patent examiners (or to the judges, post-grant) to insist on a narrower and more concrete application, and on the disclosure of an actual solution.

This is isn't software-specific at all. Half a century ago the SCOTUS already stressed that "a patent is not a hunting license", meaning that it's not a monopoly on the right to solve a problem, but a reward for an actual solution.

Conventional vs. non-conventional programming of a computer

Google's brief describes quite clearly on page 10 of the PDF file where Google would draw the line between patentable and unpatentable subject matter. I'll quote and explain:

Rather, "the clue" to patent-eligibility

The term "patent-eligibility" means whether something falls under patentable subject matter. If software is excluded from patentable subject matter somewhere, then it's "not patent-eligible", or more elegantly, "patent-ineligible". The term is meant to distinguish subject matter from other patentability criteria (novelty, nonobviousness etc.). However, when we talked about patent-eligibility in the EU debate over software patents, we always just said "patentability [of software]".

is whether a process results in physical transformation or reduction of an article to a different state
or thing.

That's the "transformation" part of the machine-or-transformation test. Software all by itself can't do that, so it's an non-issue for us. Google cites the Gottschalk vs. Benson case, which we don't have to worry about here.

Where such transformation does not occur, the Court has recognized processes to be patent-eligible only when the claim, considered as a whole, is necessarily tied to the non-conventional use of a machine.

Google talks about conventional vs. non-conventional use of a machine (such as a computer) at several points. One might think that programming a computer is by definition a conventional use because being programmed is what computers are for. Unfortunately, that's wrong.

I know this in detail because in the EU software "as such" isn't patentable subject matter, but a lot of software patents get granted, and the reasoning will always have to do with theories that are the equivalent of "non-conventional use of a machine". For an example, optimizing the use of the limited number of pixels of a screen (such as by a tab control), accelerating a database operation (such as by a better sorting algorithm), compressing data, encrypting data... all those kinds of achievements go beyond a conventional use of a machine under the logic of patent law.

Why would Google be fine with patents on a non-conventional use of a machine? Because pretty much everything on which Google seeks patents meets -- or is at least intended to meet -- that requirement, not from a programmer's common sense point of view but under patent law. For an example, Google's patented PageRank algorithm would not be considered a "conventional" use of a computer by a patent examiner or court because it's so useful for the purpose of estimating the relevance of web pages.

To resolve this case — and to provide needed clarity regarding the scope of patentable subject matter — this Court need only reaffirm these long-established precepts.

There you have it: Google called on the SCOTUS to uphold a set of criteria under which the kinds of patents Google obtains are available. Let's face it: the kinds of patents over which Oracle sues Google now also fall in that "non-conventional use of a computer" category. Google is getting a taste of its own medicine.

Adaptability of patent law to future innovation

At the top of page 11 of the PDF file, a long sentence relates to "technological advancements" and supports the idea that new technologies should be patentable in principle. Google's brief just argues that the Bilski patent application, which isn't as technological as Google's PageRank patent, is a kind of subject matter that has "existed since the time of the first Patent Act." That law was passed in 1790. Of course, businesses and markets existed before, so the Bilski idea could, in theory, have come up in one shape or another more than 200 years earlier.

In terms of where Google stands, it's just important to realize that this kind of reasoning isn't an anti-software-patent position at all. Instead, it is consistent with the idea of an "expansive" patent system that covers ever more fields of technology with time.

An anti-software-patent theory in this context would argue that even though US patent law is meant to adapt to new technologies, patent law is only a means to an end, and for reasons A, B, C and D, software patents run counter to the lawmakers' original intent (including that one might even argue they're unconstitutional).

It would undoubtedly be a huge challenge to win that kind of an argument, but it would be theoretically possible because very few legal principles are absolute: in most cases, different principles and values have to be weighed off against each other. In this case, the idea of the patent system expanding is one principle and value, and one could bring others into play to argue against the compatibility of software patents with existing patent law and, possibly, the Constitution. I just want to highlight that Google doesn't do that.

References to patent-critical literature

In all fairness I have to say that Google does cite some very patent-critical authors, such as James Bessen and Michael Meurer. I know the former (we were sitting next to each other on a conference panel years ago and agreed on a lot of things). Google also recalls that in the early 1990s virtually all software companies opposed the patentability of software (ironically, that would also include Oracle). Quite accurately, Google points out that innovation in software occurred anyway and, at the time, didn't require patent protection.

Google deserves credit for having drawn the attention of the SCOTUS justices to such theories and eye-opening writings. While this wasn't the only amicus brief to do so, the combination of Google with several of the giants of the financial services industry certainly did lend a kind of credibility to those critical voices that, by contrast, a notorious communist without any track record in business, authoring a submission on behalf of non-commercial entities, never brings to the table.

Still, Google stopped far short of advocating the abolition of software patents. One may prefer to crack one nut at a time and do away with business method patents first, then deal with other software patents.

However, if you look at Google's unequivocal support of non-abstract patents on a "non-conventional" use of a computer and its failure to argue against an expansive patent system, there's just no way a person knowledgeable in the field of substantive patent law could say that Google's brief was an anti-software-patent submission. It was at best neutral with respect to the kinds of patents Google itself files for, and I think it's fair to say that on the bottom line -- especially in the most crucial context, the legal tests for patent-eligibility -- was pretty much pro-software-patent.

Also, it must be considered that Google has never spoken out against the patentability of software as a whole on any other occasion either. I'll comment on that some other time.

I don't support patent aggression, but perhaps Google has to learn about patents the Ellison way.

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

The two faces of the mainframe: different economics for legacy and new workloads

Until I learned about the mainframe business, I always thought that if I have a computer program (whether purchased or homemade), the cost of running it on a given machine depends exclusively on how resource-hungry the software is: how much memory it allocates, how much CPU power it consumes, how much it writes on storage media, and so forth. But I never thought that age could make a huge difference if all other factors are equal.

Then I found out that IBM's mainframe business is kind of schizophrenic. There isn't just one mainframe price matrix based on performance. There are two sets of rules: one for old ("legacy") workloads and another for the new workloads. The price points for identical levels of performance are worlds apart.

What's even more paradoxical is that contrary to conventional IT wisdom, "old" costs far more than "new". I can see why that would be the case for vintage cars, art or wine. But it flies in the face of all I thought I knew about IT economics. The explanation: negative forces are in play and override healthy market dynamics.

For several decades, the mainframe was the only platform for heavy duty computing

When most of the world economy became computerized, starting in the 1950s, the only platform capable of crunching large amounts of business data was the mainframe.

For a few decades there were smaller players competing with IBM (which was only made possible by antitrust intervention), offering plug-compatible mainframes. So it wasn't always just a single-vendor platform like today's mainframe business, or the iPhone. But for the important first several decades of the age of computing, the mainframe category as a whole was the only game in town if you meant big business (or government).

As a result, most of the world's governments, banks, insurance companies and reservation systems developed (internally or with the help of subcontractors) custom software on the mainframe for the most critical parts of their IT operations.

Computerization progressed, so they added ever more functionality to existing programs and created ever more new ones. Circumstances (such as legal parameters or business models) changed, so they kept those custom programs up to date. They had to.

Much later, the PC revolution set in and in accordance with Moore's Law, Intel CPUs became ever more powerful and narrowed the gap. IBM just presented its new zEnterprise mainframe, breaking through the 5 gigahertz barrier for the first time in mainframe history. Today's Intel CPUs reach about 3.5 GHz. Still a difference, but not a huge one.

With programming techniques that enable a whole "farm" of servers to work together and share the load, distributed computing became an intriguing, cost-efficient alternative to the mainframe. New businesses such as Google and Facebook started and scaled out impressively on that technological foundation.

But all the existing operations, most of whom existed long before Google's and Facebook's founders were even born, didn't have the luxury to start from scratch. They had to keep going and going, updating and updating, from one incremental, evolutionary cycle to the next. They were -- and still are -- chained to their mainframes.

The collective value of all mainframe legacy code: $5,000,000,000,000

Theoretically, migration is an option. Any existing piece of software can be ported to another platform. But in practical terms this is difficult for an organization's most mission-critical IT infrastructure, and it's economically a tough choice if the existing program code represents an extremely expensive business asset.

IBM itself estimates that the total value of applications residing on today's IBM mainframe systems amounts to approximately $5 trillion. $5,000,000,000,000. That's about the annual GDP of Japan. In most parts of the world, $500,000 will buy you a home, and for $5 trillion you could buy 10 million such homes.

The number is mind-boggling but realistic. I mentioned in my previous posting on mainframe economics that there are about 200-300 billion lines of mainframe program code still in use. So if you multiply that number of lines with a development cost per line in the $20 range, you arrive at $5 trillion. Those mission-critical business applications are expensive development projects requiring a lot of planning and testing, limiting the output of programmers. The average cost per line of dynamic web page code in PHP or Visual Basic is presumably much lower.

Another consideration that makes the number realistic: the collective revenues of all mainframe customers are unbelievably massive. Each of the top 585 corporations that use mainframes generates, on average, annual revenues of $36 billion. Multiplying the two numbers results in collective revenues of $21 trillion. That is substantially more than the GDP of the European Union ($16.4 trillion) or the United States ($14.3 trillion). And that's just, roughly, the top 10% of mainframe customers and only one year's revenues. So it's not too hard to imagine that over the years all of them created mainframe code worth $5 trillion.

IBM's monopoly: the only platform capable of executing legacy mainframe code

The staggering numbers I just mentioned show what an enormous leverage IBM has as the only player in the market to offer platforms (in terms of hardware and operating systems) on which that legacy code can be executed.

In mainframe lingo, the distinction is made between "legacy workloads" and "new workloads". The term "workload" stems from the multi-tenancy concept of mainframes: multiple processes running in parallel on the same system. With today's multi-core CPUs and virtualization software, an analogy exists even for Intel-based PCs.

It's laughable that IBM claims the mainframe is just a "niche" of the overall server market and denies antitrust implications by claiming fierce competition from other server platforms, especially from distributed solutions. Alternative platforms can't run those mainframe legacy programs. For companies starting from scratch -- I mentioned Google and Facebook -- there are certainly some more cost-effective choices. But not for all those banks, insurance companies or governmental agencies who depend on their mainframe every day.

Migrations that enable such customers to dump their overpriced mainframes are few and far between. Not only are they rarely found but also do they usually relate to smaller solutions, therefore not representing a significant chunk of the overall mainframe business in financial terms.

I have seen the slides of an internal IBM presentation that was given last year and whose presenter claimed that for banks, (other) financial services, reservations, transaction accounts and batch workloads there's simply "no effective alternative on distributed [platforms]". So much for a competitive market.

The sheer cost of migration isn't the only obstacle. There are also other factors that make it very difficult in technical and organizational terms, and I'll elaborate on those some other time.

z/Linux isn't the answer to the lock-in problem

So where does z/Linux -- the mainframe version of the GNU operating system and the Linux kernel -- fit into all of this?

IBM recently celebrated the tenth birthday of z/Linux. Novell's SUSE Linux is still the most popular z/Linux distribution, and there are other choices. Virtualization makes it an option to run z/OS (the proprietary mainframe operating system on which the legacy code runs) and z/Linux in parallel.

Programs that are written for z/Linux can be easily recompiled (often without source code changes) for GNU/Linux on other platforms. But z/Linux isn't the answer to the existing lock-in problem: porting legacy code from z/OS to z/Linux is just as hard as porting it to any other platform.

New workloads are the raison d'être of z/Linux. If companies want to write new program code for an operating system that is available for different hardware platforms, z/Linux is eligible. In some cases, those new workloads may very well benefit from data exchange with legacy workloads. If a bank processes most of its transactions on a mainframe (which is what virtually all major banks do), it may choose z/Linux for the generation of dynamic web pages that use data from the transaction system. So z/Linux plays a complementary role -- but it isn't a substitutive force.

There may be a few exceptions, but it's a pretty accurate portrayal of the situation that mainframe legacy workloads run on z/OS and z/Linux becomes a choice only at the start of entire new projects.

IBM wouldn't have enabled the creation of z/Linux if its availability hurt its core business in any way. There was nothing stopping companies from developing software for new workloads on GNU/Linux for other servers, exchanging data with the mainframe via the network. There are important technical advantages to running everything on the same machine (which will be the subject of another posting), but the cost of mainframe equipment is so outrageous that z/OS would have lost the business of most of the new workloads to other operating systems (with GNU/Linux obviously capturing a large share on the server side) one way or the other.

The massive lock-in tax: ten times the price for identical performance

Recognizing that many new workloads have a real platform choice while legacy workloads are hopelessly locked in, IBM came up with a way to have it both ways: "coprocessors".

I put the word in quotes because IFL (Integrated Facility for Linux), zIIP (z Integrated Information Processor) and zAAP (z Application Assist Processor) aren't coprocessors in the traditional sense, such as an arithmetics coprocessor that can only perform some auxiliary computations. Instead, IFL, zIIP and zAAP are processors that execute actual program code. They are real CPUs.

The only way in which they're limited is that IBM erected artificial barriers (through microcode changes). Those have the effect that legacy workloads can't be executed on those processors. IFL can only be used for z/Linux, zIIP only for database purposes and zAAP only for Java programs and certain XML-related computations under z/OS, while legacy workloads are generally a matter of z/OS-based COBOL programs. But again, those limitations were built in on purpose.

Customers get two economic benefits from using those limited-purpose processors. One is that mainframe software license fees are calculated based on CPU power, and those limited-purpose processors are usually not factored in. The other is that IBM sells those limited-purpose processors at prices that are hugely lower than for the general purpose chips on which everything including the legacy code can be executed.

For an example, if you buy a mainframe and you "insert" a certain amount of processing power for all purposes (including legacy workloads), you pay about ten times as much as for the same hardware component that is limited to z/Linux. So for economic reasons, a mainframe customer will want to use the expensive general-purpose component only for legacy code and make as much use of lower-cost limited-purpose processors as possible for new workloads.

Unbelievable but true

You might wonder whether the price difference -- a factor of 10 in general -- is justified by any other reason than the artificial limitation I mentioned. There isn't any other reason. You get the same processing speed and in terms of hardware (at the level of the circuitry) it's also the identical product. The limited-purpose components aren't even optimized to be particularly efficient for Linux, Java or XML or whatever. It's just that IBM determines unilaterally what you are allowed to run on them -- and what you are not.

This is a unique two-tiered business model. Customers see that IBM can, if it wants, sell them everything at a tenth of the price and still make money (otherwise IBM wouldn't do it). However, to the extent customers are required to use general-purpose processors because of the $5 trillion lock-in, they have to pay ten times as much.

Even one tenth of regular mainframe costs is still high compared to, for an example, Intel-based servers. But it's a pricing that shows there's at least a minimum of competitive dynamics in play.

Actually, there is a technical solution on the market to make legacy workloads eligible for execution on those less expensive "specialty" processors: zPrime. IBM doesn't want that one to be used. Its vendor, NEON Enterprise Software, filed an antitrust lawsuit against IBM in the US last year and recently lodged a complaint with the European Commission.

The lock-in tax reduces to absurdity any claims that z/Linux competes with z/OS or that Intel-based servers compete with mainframes. IBM couldn't charge -- for identical performance -- ten times the price if it didn't have a monopoly for platforms that execute legacy mainframe workloads. It shows that competitive server platforms and the legacy mainframe business aren't in the same market.

Think of two gas stations, located next to each other in the same street. At one of them, it costs you 60 euros to fill up your car. At the other, it costs 600 euros -- quantity and quality being equal. So no customer in his right mind would go to the place that charges 600 euros -- unless there's some reason for which certain customers don't have a choice.

This must change.

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

Oracle vs. Google licensing issues

A few days ago Oracle announced its patent infringement suit against Google, claiming that Android violates seven Java patents (plus unspecified copyrights).

Both parties haven't said much in public. I would really have liked to see indications of constructive, good-faith efforts (by both of them) to resolve the issue with a mutually acceptable license deal. It may take some more time -- possibly a long time -- to get there. As long as so little is known about what preceded the lawsuit, both deserve the benefit of the doubt about their intentions. That's separate from the question of software patents in general and their use against FOSS.

In recent days I have seen two talking points that looked to me like attempts to justify Oracle's action. I'd like to comment on those. They relate to licensing issues, and I believe I can shed some light on them.

Google's suspected non-compliance with the Java specification

Bruce Perens, whom I know as a staunch opponent of software patents, pointed out that Google might not have adhered to every detail of the intellectual property license granted by the Java Language Specification.

That IP grant is royalty-free but it's tied to a variety of conditions. In particular, it doesn't allow "subsetting or supersetting", that is to say, adding anything on top of the specification ("embrace, extend, extinguish") or implementing only parts of it.

Google's virtual machine for Android, a FOSS program named Dalvik, may very well deviate from the specifications. While technically different, Dalvik practically serves the purpose of a Java virtual machine (JVM). Instead of executing Java bytecode, it executes files in its own .dex (Dalvik executable) format. Those .dex files are generated from Java source code.

Assuming Google has departed from the Java specification, it can't expect to benefit from the royalty-free IP grant. That's one thing. But in that case I would still like to see a license deal as the ultimate solution. If Google elected not to meet the requirements for royalty-free access, then it should pay.

Like I said on previous occasions, also in the WebM context, Google should then also take care of the entire ecosystem concerned, not only solve the problem for itself. I'm much more concerned about all those Android application developers and their investment of time, energy and money. Google will survive. But the little guys must have legal certainty. I hope they won't have to rewrite existing programs.

I don't want to speculate too much, but it's not entirely inconceivable that Oracle wants to prevent Google from hijacking Java via Android. Should there be any legitimate concerns of that kind, I hope they will also be resolved by way of a license agreement. The sooner, the better.

The flawed Java Community Process

Some opponents of Oracle's acquisition of Sun had serious concerns over Oracle getting to control the Java Community Process (JCP), "the mechanism for developing standard technical specifications for Java technology."

The JCP is just window dressing. It suggests some kind of community involvement and democratic decision-making, but the owner of Java (originally Sun, now Oracle) is firmly in control. The owner controls so many voting rights that even if all of the truly independent representatives agreed on something, they wouldn't be able to take decisions against Oracle and its stooges.

So we're talking about a single vendor standard with fake democracy. It's a fact -- not a crime -- that there are pervasive technologies out there that one vendor controls. It's also a fact that Oracle just inherited that mess from Sun. But it's hypocritical to lobby politicians about "open standards" while acting so heavy-handedly.

Don Deutsch, Oracle's VP Standards Strategy and Architecture, gave this presentation at the OpenForum Europe Summit two months ago in front of EU officials. The deck has 20 slides, and slide number 13 is unbelievable. It states that there are two choices, a "proprietary base" and an "open standards foundation". That slide gives three reasons why "proprietary" is bad and "open" is good.

Give me a break. What is Java if not a proprietary, patent-encumbered standard?

The third point Mr. Deutsch made for open standards is the opportunity for "you" (he meant all stakeholders) to influence the evolution of a technology base. At that lobbying event, he was sitting on the same panel (Session 1 on this page) as David Drummond, Google's chief lawyer.

IBM, Oracle and Google are the three largest members of OpenForum Europe. I recently pointed out that all three of them are non-open in some important respects, so their lobbying isn't credible.

Would Google have been safer with the GPL?

Some say now that Google could have avoided the problem by building its Java virtual machine on the basis of the existing OpenJDK (Java Development Kit), then adding mobile-specific code. The OpenJDK source code is available under the GPLv2, and according to the copyleft principle, Google would then have been bound to the GPLv2 as well. Alternatively, JavaME is part of the phoneME package. The majority of phoneME components appear to be GPL'd.

The GPLv2 stipulates an implicit patent grant (in this case, by Oracle as the right holder) vis-à-vis "forkers" (developers of derivative works, which is what Google would have become by taking that code and modifying it).

Note: under GPLv2 the patent license is only implicit, not explicit. The problem with an implicit patent license is that you have a considerable degree of legal uncertainty once the program is modified.

The European Commission recognized that factor of uncertainty in paragraph 733 of its decision on the Oracle/Sun merger and accurately noted in footnote 456 that Oracle's legal team (which effectively included Eben Moglen) didn't cite even one court decision to buttress the claim that the GPLv2 would take care of patent problems between a "forker" and the original right holder.

If the GPLv2 solved the problem, the FSF wouldn't have changed its approach to patents so fundamentally with GPLv3.

Apart from whether the GPLv2 would have solved the patent problem, it seems that Google generally tries to navigate around the GPL in connection with Android because the Apache Software License is more favorable to the proprietary, closed-source strategies of certain vendors of Android-based phones. That's a serious issue to bear in mind when discussing Android and the Oracle-Google dispute.

Clarification of my attitude toward the GPL

I know that the GPL is a politically sensitive issue in the community, so let me make this very clear: my own experience with the GPLv2 is extremely positive. It enabled MySQL AB to derive commercial value from its open source project and to retain a maximum degree of control. MySQL AB was founded in 2001 (a few years after the project itself) and in 2008 was sold for $1 billion to Sun. What a success story.

Even in connection with Oracle's acquisition of MySQL (as part of Sun), I continued to believe that the GPLv2 was the best license for MySQL.

I didn't want Oracle to acquire that much control over a technology that had become much more of a competitive threat to Oracle's core business than most industry analysts realized. But the solution I consistently advocated was simply that Oracle shouldn't be allowed to acquire MySQL. If they had wanted to buy the rest of Sun, then they should have sold MySQL to a suitable third party of their choosing ("suitable" means "no company about which the European Commission would have had concerns") and that third party should then have continued the MySQL business under the GPLv2.

The possibility of reducing Oracle's level of control by a license change would have been better than nothing but still insufficient to truly resolve the competition concerns I outlined. On numerous occasions, I argued fervently against any claim that a license change away from the GPL would have been a substitute for a divestiture and a continuation under the GPL. I stressed the severe downside of a license change until I was blue in the face.

In some online discussion forums, the opposite of what I just wrote may be claimed. Forgive me for the strong language, but those are damn lies, originating from sources who don't deserve to be trusted when the interests of certain corporations are at stake, and propagated by people who may in most cases mean well for FOSS but regrettably relied on those dubious sources.

I want to back up with quotes and documents my pro-GPL logic:

• An early version of a position paper only said that "some major concerns [...] could be somewhat alleviated" by a license change (from GPL to ASL). Those who quote that and hold it against me are untruthful in two ways:
  
  
  • They fail to point out that "some" means "not all", and "somewhat alleviated" means "this isn't a complete solution" (not even to parts of the issue). The European Commission's guidelines for horizontal merger cases clearly require any solution of a merger problem to be complete, reliable and seamless. Under the rules, the standard solution is a spin-off of the problematic part of a business; if it's not a spin-off, it's an exception and must be equally effective. Our position paper made it clear that a license change would have been only a partial solution to only parts of the problem -- clearly much weaker than a divestiture of MySQL to a suitable third party would have been, therefore insufficient under EU rules. We just wanted the regulators to know about the pro's and con's of that suboptimal alternative, especially since we never knew what Oracle was going to propose to secure approval of the deal (such as even weaker license changes).
  
  
  • Very importantly, the liars take those words out of context by omitting this statement from the very same section of the position paper: "such a commitment [license change] could not be reasonably expected to result in a continuation of disruptive innovation at the level of recent years" (and the whole paper argued about how important MySQL was as a major force of disruptive innovation).
  
  
• Monty Program press release of 19 October 2009, just look at the headline: "MySQL founder outlines solution: instead of letting Sun suffer, Oracle should sell MySQL"; in that press release, Monty called on Oracle "to be constructive and commit to sell MySQL to a suitable third party"


• Presentation slides for my Silicon Valley press conference on 26 October 2009 and my Wall Street analyst briefing on 27 October 2009: headline on page 12: "Only divestiture [spin-off] sustains virtuous circle"; last bullet point on page 13: "Only separate commercial entity will use MySQL to compete with Oracle ever more"


• FAQ documents provided to numerous journalists and analysts of 12 November 2009 and of 23 November 2009: bottommost paragraph on page 1 (of both documents):
  "Could Oracle resolve antitrust concerns by other means than a divestiture, such as licensing-based remedies?
  As a general rule there is a preference for clean structural remedies rather than behavioural remedies such as licensing which are difficult to devise and require constant monitoring. In this specific case, most licensing-related commitments on Oracle's part would be entirely, or almost entirely, ineffectual. Only very far-reaching commitments could have any effect, and even those would not achieve the objective of sustaining MySQL as a major force in the market."

Could it have been stated any more clearly? I never advocated an "un-GPL'ing" of MySQL as a solution. I wanted MySQL to continue under the GPL, but not under Oracle's stewardship.

Apart from that, the European Commission could never have imposed a license change unilaterally on Oracle. EU law doesn't allow them to do that in a merger case. The way it works is that a deal is proposed, and if the regulators have no concerns, they clear it. If they have concerns, they may ultimately block it (in which case Oracle would have had to walk out on the deal with Sun).

In most cases where there are concerns, the acquirer will propose possible solutions to the Commission, which will always only say "we have a deal" or "we still have concerns". So it would have been completely up to Oracle to propose a license change. The Commission would not even have been allowed to tell Oracle "if you switch from GPL to ASL, you got a deal." Therefore, a forcible license change wouldn't even have been possible. Moreover, we would never have been invited to any meeting in which Oracle would have proposed remedies to the Commission. We weren't in a position to negotiate with anyone.

I'd like to point out that I have no intention at all to restart the debate over Oracle and MySQL. Ultimately, all regulatory agencies (EU and elsewhere) approved the acquisition. I respect those decisions. I'm not involved with Monty's appeal against the European Commission's clearance decision. I just wanted to set the record straight on where I stand concerning the GPL.

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.

Oracle sues Google, says Android infringes seven Java patents (plus unspecified copyrights)

Last night Oracle announced that it filed a lawsuit in Northern California against Google, claiming that Android infringes seven Java patents (which Oracle acquired along with Sun in January) as well as some unspecified Java-related copyrights.

The document filed by Oracle with the United States District Court for the Northern District of California has been published by VentureBeat.

ZDNet thinks that this "may be the most gigantic patent battle ever seen in this industry."

Some aspects of this are unclear, so I believe this is mostly the time to ask the right questions, and time will provide the answers, probably sooner rather than later.

1. Apparently an assertion of patents against Free and Open Source Software

While there is serious doubt about the full compliance of many Android-based products with open-source rules, it appears to me that Oracle asserts the patents in question against components of Android that are open source. Even if some Android-based or Android-related products may include components that don't meet open-source criteria, I find it impossible to imagine that the patents Oracle tries to enforce here would be infringed only by closed-source components and not by Android's many open-source components.

Therefore, I consider this a patent attack on free software and open source.

2. How cooperative and constructive was Oracle prior to filing the lawsuit?

In my recent posting on Microsoft's cooperative use of patents I explained at length why I'm much less concerned about patent holders who are willing to do license deals on fair, reasonable and non-discriminatory (FRAND) terms than about those who use patents for exclusionary strategic purposes (meaning they require companies to remove features from products or even entire products from the market). If companies only go to court because someone doesn't accept a reasonable license deal, then even I as an opponent of software patents can see the commercial logic and can't condemn such action in moral terms because it allows companies to stay in business.

I've read the document Oracle filed with the court, and Oracle's succinct press release. There isn't any indication that Oracle offered Google a license deal on FRAND terms.

That doesn't mean that Oracle didn't do it. However, in the four cases in which Microsoft started patent litigation, it always made it clear in its official statement that it previously tried to reach a license agreement. Since Oracle doesn't claim to have made a good-faith attempt to resolve the issue amicably, it's certainly possible (unless information to the contrary surfaces later) that this is a hostile, aggressive and destructive move on Oracle's part.

3. Will Google only protect itself or also the makers of Android-based phones?

In the WebM context I have previously pointed out that Google must demonstrate its willingness and ability to protect those who adopt its open source technologies, such as Android and WebM.

It would be very disappointing to see Google settle its dispute with Oracle on a basis that would take care only of Google but not of the wider Android ecosystem, including but not limited to the makers of Android-based phones.

4. Another big failure for the so-called Open Invention Network

I have repeatedly criticized the "Open" Invention Network (OIN), an entity that claims to protect "Linux" against patent threats. I've always said that there's no evidence it has ever helped any company (the latest example is Salesforce, which apparently pays royalties to Microsoft for a variety of patents including some that read on Linux). And I've explained in detail that the OIN doesn't truly protect all of FOSS but only an arbitrarily defined list of program files.

Oracle's lawsuit against Google is the strongest evidence that my concerns about the Open Invention Network are well-founded. Both Oracle and Google are OIN licensees, so in theory there is a non-aggression pact in place between them, but everyone can see that Oracle sues Google anyway because the OIN's scope of protection is too narrow.

I'm not alone with those concerns. This ArsTechnica article also mentions the OIN's limitations.

5. Oracle's open double standards and the "Open"Forum Europe

In the European Union, both Google and Oracle are members of the "Open"Forum Europe (OFE), a lobby organization that claims to advocate open standards. It's not about open standards. It's all about open double standards. I explained that before.

I still consider IBM the biggest open hypocrite. Big Blue uses patents aggressively to shut out competition from its hugely lucrative and strategically important mainframe business. The mainframe is a pervasive technology, a de facto standard, and IBM is anything but open in that regard.

However, Oracle's patent infringement suit against Google is also an aggression against the notion of open standards. Java should be an open standard, and according to Oracle-backed organizations such as the OFE and ECIS, such standards would have to be made available on a royalty-free basis.

In his initial thoughts on the Oracle-Google dispute, "Mr. Mono" Miguel de Icaza has made a number of good points. One of them is that Google would actually have been better off, from a patent point of view, with the Microsoft Community Promise for C#, the core .NET class libraries and the related virtual machine.

I recently explained why Richard Stallman, whom I really respect but with whom I sometimes disagree, was IMO wrong with his concerns about patents on C# and Mono. See, I told you so: there's no point in being too much focused on Microsoft in this context when other companies pose the real threats and problems. The Microsoft bogeyman can be a huge distraction from the actual issues.

Miguel de Icaza even suggests Google might now want to switch from Java to .NET and C#. There may be reasons for which it's not the most likely thing for Google to do, but anything is possible now in the wake of Oracle's patent infringement suit against Google. Indeed, Microsoft's C# is an open standard by any reasonable definition while Oracle proves once again that Java is not.

6. Where are the free software activists, lawyers and paralegals who supported Oracle's acquisition of Sun?

Concerning open double standards and open hypocrisy, it's very regrettable that the Free Software Foundation Europe and the FFII collaborate with the "Open"Forum Europe. The two most influential members of the OFE, IBM and Oracle, have both shown in recent months that they use patents against free software in order to prevent interoperability.

I know a thing or two about EU politics and I'm profoundly concerned that the FSFE and the FFII stand to lose some of their credibility by partnering with organizations that clearly defend corporate interests, not values. It ultimately raises questions about the nature of the motivation that drives the FSFE and the FFII, or its leaders. What they do in this context isn't genuinely NGO-like to say the least.

Some of you reading this may know that I opposed the MySQL part of Oracle's acquisition of Sun. I was also against them acquiring Java, but I kept quiet about that. What I did speak out on was the MySQL part of the deal because I couldn't see (and still can't see) how MySQL could ever be a competitive force that puts Oracle under pressure if Oracle owns and controls it to the greatest extent any company can ever control an open source product.

I worked with Michael 'Monty' Widenius, MySQL's creator and founder, in opposing MySQL's acquisition by Oracle. Among other things, I authored this position paper, which Monty's company filed with the European Commission and regulators in other jurisdictions. (However, I am not involved with Monty's appeal against the European Commission's decision to ultimately clear the merger.)

Most members of the FOSS community understood and supported our concerns. More than 40,000 signed up (in only about a month) on helpmysql.org to voice their opposition to the deal. But some well-known voices who claim to advocate FOSS interests supported Oracle (and even accused us of absurd things). And very importantly, Richard Stallman co-signed a letter asking the European Commission to block the merger.

It was part of Oracle's and Sun's communication strategy to tell community leaders that the deal was good in the community's interest because Sun owned so many patents that others (in some cases suggesting Microsoft although they never made a bid for Sun) might be able to use against free and open source software. They said that Oracle was a reasonable patent holder and wouldn't harm open source.

Yes, they said that. You can still read these claims. Carlo Piana, a lawyer affiliated with the FSF Europe, wrote about that when he explained why he joined Oracle's legal team. A website that always supports IBM's actions unconditionally (and IBM publicly supported the Oracle-Sun deal) parroted Carlo Piana's argument. And there was a lot of talk about it at community events and on various blogs.

It is worth noting that Eben Moglen of the Software Freedom Law Center (SFLC) also supported Oracle, including that he traveled to Europe to support their case at a European Commission hearing. He, too, claimed it was good for free software.

So where are those pro-Oracle FOSS advocates now? Will they come out unequivocally in support of Google and condemn Oracle's action? Will they admit that it was a bad idea to let Oracle acquire Sun in the first place? Will they concede that they were wrong when they said Oracle would be a good owner of those patents? Will the SFLC and the Public Patent Foundation now lend pro-bono legal support to Google in order to get those Java patents invalidated before they do more damage?

Or will they keep quiet due to a conflict of interests and only talk about a bogeyman and propose fake solutions such as the OIN in order to distract the community from the real problems?

Oracle's patent suit against Google raises many important questions, including the ones I just asked.

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.