Saturday, June 26, 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Unfair to a despicable extent

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

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

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

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

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

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

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

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

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

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

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

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

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

1. The ideal solution: OIN on DPL basis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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