Monday, May 31, 2010

Open Invention Network (OIN) demystified

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

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

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

Only six companies call the shots

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

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

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

  • NEC (a large patent holder)

  • Sony (a large patent holder)

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

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

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

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

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

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

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

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

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

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

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

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

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

A look at the list of OIN licensees

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

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

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

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

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

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

So what is the OIN good for?

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

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

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

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

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

Tuesday, May 25, 2010

WebM (VP8): safe and royalty-free?

Last week, Google and a couple of strategic allies announced the WebM project, "an open web media project" including the VP8 video codec Google acquired earlier this year.

I provided comments to journalists reporting on the announcement, stressing the need for a well-documented patent clearance. eWeek, Dr.Dobb's and The Register were among the websites that picked up some of those comments, which are consistent with what I wrote on this blog two weeks ago in a broader context that also included Theora.

In favor of open-sourcing

In this particular case, since Google uses a newly created license (based on a part of the BSD license), it isn't a FOSS license in the formal sense until the Free Software Foundation declares it a free software license and the Open Source Initiative declares it an open source license, but let's optimistically assume that it will at least receive OSI approval.

Open-sourcing useful program code is great. But it also requires a very responsible approach. That's why I issued my comments. Let's face it: Google didn't take the WebM initiative purely out of generosity. Google is a business and has strategic interests involved. That's legitimate, and if such business interests benefit open source, that's wonderful. However, concerning the need to proceed responsibly, the one thing I don't want to see happen is that FOSS developers run into big and economically disastrous problems in undue reliance upon Google's vague assurances concerning patents.

Patent litigation can cost millions. Having to rewrite a piece of software later, due to patent problems, can be prohibitive and turn all of the development effort put into a project into an irrecoverable loss (in the worst case). Those are serious risks, especially in such a patent minefield as codecs.

Technical similarities suggest high risk of patent infringement

Jason Garrett-Glaser, the developer of an open-source H.264 player (meaning one can use his code per se on open-source terms but based on the type of use may need an H.264 license from MPEG LA), obtained the VP8 specs beforehand and commented on them in great detail (understandable only with in-depth technical knowledge about codecs).

Jason's analysis discusses technical limitations of VP8, the quality of the documentation (which doesn't seem to impress him), and concerning potential patent issues he concludes that " this is a patent time-bomb waiting to happen."

He "simply cannot believe that they will be able to get away with this, especially in today’s overly litigious day and age. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents." (VC-1 is a different format)

[Update] Carlo Daffara posted an analysis that disagrees with Jason's assessment in some ways. Carlo believes that the developers of VP8 made a lot of effort to steer clear of patent infringement. However, Carlo also points out that no one can guarantee that no third-party patents are infringed. I think Carlo made an important contribution to the debate, and his analysis is yet another reason (not a substitute) for asking Google for explaining in detail its position concerning patents.

No indemnification, no holding harmless

Jason also points out that Google doesn't provide any indemnification of developers adopting VP8 as part of WebM, while Sun did so in case of its OMS. I absolutely agree with Jason that the fact that Google doesn't offer any indemnification -- and I actually think they should go beyond mere indemnification and even have a hold-harmless clause in favor of adopters of WebM. To hold harmless means that a vendor also takes care of legal fees, which can be so massive in case of patent litigation that individual developers and smaller companies can't afford them, while Google could.

Google's refusal to indemnify (let alone to hold harmless) calls into question that Google is really certain that there's no potential problem with patents. Developers who believe Google's vague statements that they've looked into this are neither provided with any details of that analysis nor with legal protection. It comes down to a "trust us" kind of message.

Google wouldn't be able to solve the problem with its own patents

Some believe that if all else failed, Google might step in and use some its own patents against third parties going after WebM adopters. There's that perception out there of Google being incredibly powerful. In some ways Google is indeed massively powerful, but as far as patents are concerned, it is small compared to Apple and even Apple isn't one of the biggest patent holders. There are far bigger ones out there.

Starting patent disputes with multiple major patent holders wouldn't be an option for Google. In such a situation, those large patent holders would be able to point to all sorts of patents they own and that Google infringes, and they could so on a hugely greater scale than the other way round.

There's already empirical evidence that Google is neither willing nor able to use its patents. HTC, a maker of smartphones based on (among other operating systems) Android, is currently being sued by Apple over patent infringement. Apple's lawsuit places particular emphasis on patent infringement by Android, Google's smartphone operating system. So far Google hasn't come to the aid of HTC or other Android adopters. Also, HTC agreed to pay patent royalties to Microsoft, and there was no indication of Google doing anything to enable HTC to avoid paying those fees.

Steve Jobs pointed to the patent risk again

Jason's aforementioned analysis received a high-profile endorsement from Steve Jobs, who replied to someone asking him about VP8 (the video part of WebM) with only a link to Jason's blog.

Given that Steve Jobs previously said that a patent pool was being assembled to go after Theora and other "open source" codecs, his linking to an analysis that estimates the patent risk to be very substantial can be seen as a reaffirmation of his assumption that WebM/VP8 won't be the patent-free solution the FOSS movement would like it to be.

MPEG LA contemplating the creation of a patent pool for WebM

On Thursday, AllThingsD reported that MPEG LA, the patent pool firm behind H.264 and other patented codecs, is considering the creation of a patent pool for WebM.

MPEG LA wouldn't be saying so if the firm didn't believe that it holds patents that read on WebM and, I presume, especially on VP8 (the video part of WebM).

MPEG LA's business is all about aggregating patents: they create pools to which multiple patent holders can contribute, and they then offer everyone (contributors as well as everyone else) licenses to an entire pool, such as the H.264 pool. Those licenses aren't royalty-free the way Google would like WebM to be.

That explains AllThingsD's headline: Google’s "Royalty-Free" WebM Video May Not Be Royalty-Free for Long

The Register also contacted MPEG LA and received an answer consistent with the one given to AllThingsD.

That article quotes me as saying that I applaud Google for open-sourcing the codec but that I consider more assurances to be necessary.

More concern among responsible open-source advocates

Simon Phipps, previously Sun's chief open source officer and still a board member of the Open Source Initiative, takes a very similar position in a blog post published yesterday. He states (toward the end of his post) that he has "heard from many thoughtful people who like [Simon] want to cheer loudly yet also want these issues addressed."

So this isn't a question of being for or against open source, or for or against Google. It's a question of how to assess a risk. I use and like a lot of what Google offers. I support open source all the way. But I'd hate to see developers adopting an open-source technology exposed to patent-related risks. This could be ruinous for some.

There are some who believe that everyone should just support WebM and take his chances. That's a defiant attitude. I'm sympathetic to the cause of having a "free" codec, but it will only be free if there are no problems with third-party patents. It's not enough for Google to make its own patents available. The problem is that there may indeed be other patents that are not available on a royalty-free basis anytime soon.

It's also a question of a fair allocation of risks and opportunities:
  • Should WebM become a big success, then Google will reap more benefits than any other company on this planet. It can make use of a free codec in many ways, including Android and YouTube. Google could afford to pay royalties, but it would boost their profits to avoid it and it would give them strategic leverage to control an important codec.

  • Should anything go wrong with patents, Google could stand on the sidelines while the adopters of the technology it put out might pay dearly for their reliance upon Google's assurances and possibly their false hopes of Google being willing and able to use its own patents to bail them out.
For the time being, I believe it's best to wait until there are news, either positive ones from Google (concerning its patent clearance and/or its indemnification policy) or negative ones from other patent holders. One way or the other, this situation should be clarified before anyone takes a risk.

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.

Wednesday, May 19, 2010

German high court declares all software potentially patentable


In a nutshell:
  • After a landmark court ruling, the German perspective on the validity of software patents is now closer than ever to that of the US.
  • Basically, Germany has now had its own Bilski case -- with the worst possible outcome for the opponents of software patents.
  • Recently, the Enlarged Board of Appeal of the European Patent Office upheld that approach to software patents as well, effectively accepting that a computer program stored on a medium must be patentable in principle.
  • Defense strategies such as the Defensive Patent License are needed now more than ever.

In detail:

Last month I reported on a ruling by the Federal Court of Justice of Germany that upheld one of Microsoft's FAT patents. I thought that the publication of the detailed decision would provide answers as to whether the largest EU member state has now effectively declared software patentable without any meaningful limits. Today it turned out that this has indeed happened but in a different case (related to a Siemens patent).

In a ruling of April 22, whose details have now been published (original document in German or EndSoftPatents page with links to automated translations), the highest German appeals court in matters of civil and criminal law overruled the country's highest patent-specialized court and decided that a client-server software for the automatic generation of structured documents (such as XML or HTML) is an example of a patentable software invention. The case is remanded to the Federal Patent Court, which will now have to uphold the patent unless some other reason for its invalidity (such as prior art) is found.

This ruling has very general implications and ramifications. It's not just about that one case. This decision has the effect that in Germany, a country in which software patents were previously only considered valid under relatively strict criteria, all software ideas are now potentially patentable as long as they are innovative from a purely formal point of view, meaning they're at least marginally different from how a technical problem was solved before. There are many such patents that the European Patent Office and national patent offices have granted, and those are now more enforceable than ever.

This could result in a significant increase in litigious activity.

The criteria for patentability

Substantive patent law (the rules for what is patentable) is a very specialized field. There's a number of criteria that patent offices and courts apply to distinguish between valid and invalid patents. In Europe and particularly in Germany, software patents have so far had to solve a technical problem with technical means.

The strictest one of those principles, which was indeed applied in some past rulings by the Federal Court of Justice, required a patented invention to put "controllable forces of nature" to use to achieve a predictable effect. Software all by itself can't do that, so that principle only allowed software to be part of a traditional technical invention.

By contrast, the new ruling of that court on the document generation program now sets the bar extremely low. It now basically says that a computer is a technical device per se and software that "takes into account" the characteristics of that computer is patentable. To give some examples, if you make sure you don't allocate infinite amounts of memory (since every computer has limits in that respect), that might be enough. Or you ensure that you don't use too much bandwidth over a network.

In other words, if you do your job as a programmer right, then you create potentially patentable stuff all the time. This means an opportunity for you to obtain patents if you want to do that and can afford it, but it also means that your program could infringe dozens, hundreds or even many thousands of patents held by others.

The first part of that ruling says that a method concerning the direct interaction between the components of a data processing system (such as a client and a server that are connected to each other) is "always of a technical nature" regardless of whether the form in which the patent is filed is essentially characterized by technical instructions. This is part of the same logic, but it would take too long for purposes of this blog to explain the meaning of those terms in substantive patent law. Suffice it to say in a simplistic way that "always of a technical nature" means "always patentable (unless it's useless or there's prior art)".

The German equivalent of Bilski

Those following the Bilski case, on which the Supreme Court of the United States is expected to rule in a matter of weeks, understand the significance of such landmark cases that can set the rules for many years or even decades to come.

While the Bilski patent relates to a software-implemented business method and the German decision relates to automated document generation, either case is key in its respective jurisdiction for defining the limits of patentable subject matter in connection with software.

Some opponents of the Bilski patent believe that they can draw a line between a software-implemented business method patent and other software patents. Maybe the Supreme Court of the United States will find a way to make that distinction.

Here in Europe, the distinction exists theoretically but it doesn't work practically because it depends on how the patent applications are drafted. If I file a straightforward business method patent application in Europe, such as a patent on a method to calculate shipping costs in electronic commerce, it will usually be rejected. But once I can find any technical progress in the implementation, even if it's as insignificant as reducing the size of a data packet containing an order by a few bytes (a negligible cost in terms of bandwidth and storage capacity, especially compared to the likely value of each order), then I might get a software patent and monopolize the same concept, just by looking at the same thing from a different angle for patent purposes.

Even Amazon's famous one-click patent could be described as a "signal processing invention".

The European framework

The European Patent Convention, an international treaty that is separate from the EU (all EU member states are parties to it, but also some non-EU countries) and took effect in 1974, states that "programs for computers" are not patentable subject matter.

However, that exclusion is then restricted by the addition that it only relates to software "as such". There are different views in Europe concerning how to interpret "as such". Generally, software patent critics believe that this means software can be part of a patentable invention (such as a car brake that is computer-controlled and optimizes its efficiency) while the proponents of software patents believe that "as such" only excludes the patenting of source code but doesn't affect software patents that they describe as "technical inventions". The whole question is then: what is a technical invention?

Proponents of software patents argue that some of the functionality of a microchip can be alternatively implemented in a computer program, which is why they say it has to be patentable and if software uses the method taught by the patent, it will infringe. Most software patent critics believe that if the method can also be implemented in software (even if also in other forms), it shouldn't be patentable.

So there are really those two opposing schools of thought in Europe. Five years ago, the push for European software patents hit a snag: the European Parliament threw out a proposal that would have "codified" (turned into an EU law) the pro-software-patent position. This was a major victory for the FOSS community, whose activists were responsible for the largest part of the active resistance to that bill.

But that was in 2005. That year also brought some favorable court decisions against software patents such as in the UK.

Now 2010 looks like the year in which the proponents of software patents get their way at all levels. Recently, the Enlarged Board of Appeal of the European Patent Office decided not to intervene against its agency's practice of granting software patents, not even against the approach that anything stored on a computer-readable medium should be patentable. The EPO was jubilant. Software patent critics such as the FFII would have preferred intervention and now hope that lawmakers will take action. While I wish the FFII luck, I think the patent movement's assessment that it won't happen is quite realistic.

Defensive strategies needed now more than ever

When I first read about the upcoming Defensive Patent License, I decided that under the circumstances it was really worth taking a closer look. In my initial set of thoughts on the DPL I explained, right at the start, why I don't think the software patent problem can be solved with help from lawmakers. There is far too much support for software patents and too little resistance (in terms of economic and political power) to make it happen. That's why such initiatives as the DPL might be able to make a big difference.

Considering that now even Europe is under a US-style software patent regime, it's important to fight against the worst ways in which software patents are used by some, such as for purposes of preventing interoperability and the fundamental technique of virtualization/emulation. Let's try to make headway on those fronts.

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.

Tuesday, May 18, 2010

The DPL and the 'Fair Troll' business model: make money fighting patents with patents

Previously I published a first set of thoughts on the Defensive Patent License (DPL), which is currently being developed by two law professors at UC Berkeley. The more I think about that initiative, the more interesting it looks to me, even though its exact content isn't known yet and its future adoption remains to be seen.

Meanwhile I've had some discussions and obtained more information, and there may actually be a solution to the only fundamental concern I had, which was that the DPL might not be effective as a purely defensive mechanism.

But no matter how defensive the DPL may be at first sight, it could pave the way for a whole new business model: that of the Fair Troll (which I'll explain in this post). That approach might be able to provide what I considered to be the missing link. It could enable the DPL to attract a very broadbased following, providing many companies and persons throughout and beyond the FOSS community with economic incentives and the opportunity to contribute to a good cause at the same time.

Before I outline the Fair Troll business model and its possible implementation, I have to explain the limits of a purely defensive approach because that's what constitutes the need for one or ideally more than one company of the Fair Troll type.

No effect on mutually assured damage

Against a troll who waves with a patent you infringe, no membership in any defensive patent pool will ever help you. If the troll's patent is valid, there are no patents with which you can attack the troll because he has no products of his own, so there's no target area. If the troll's patent can be invalidated, such as by proving that the "invention" was previously published by someone else ("prior art"), then it doesn't matter to whom the prior art you find belongs: whether it's yours, belongs to someone in your pool or even to your worst enemy, you can use it in any of those cases if it's suitable for taking the patent down. So again, the DPL doesn't strengthen you.

But against producing (or some say, "practicing") entities -- companies with products or services on the market that could also be attacked with a patent -- the most effective weapon (other than a way to get the aggressor's relevant patents invalidated) is the deterrent potential, the concept of mutually assured destruction (or at least mutually assured damage).

A purely defensive pool, which is the way the upcoming DPL is described by its authors, changes nothing about the problem a troll can pose to you with a given patent (neither helps nor hurts) and, unfortunately, doesn't enhance your own retaliatory potential besides the patents you own yourself.

Of course, the DPL would still allow you to use your own patents against another company that doesn't support the DPL. If you have a patent that reads on someone else's products or services, that could put you into a position to cross-license with the aggressor -- but you don't need the DPL for that. It would still, even if you join the DPL pool, be up to you to obtain patents you can use. You have no legal basis on which you can use the patents of your fellow DPL supporters (at least based on what's been reported so far). So you're still left with all of the cost and effort of taking out patents of your own.

Would the DPL justify the hard and soft costs of taking out patents to contribute to the pool? Actually the motivation to obtain patents would be lower for a DPL member because someone outside the pool can use a patent against any infringer, while a DPL member has to leave fellow member alone. The only benefit is that a DPL member might feel better about it: after all, the patent would be committed to a purely defensive purpose. But when you talk about costs of tens of thousands of dollars/euros, feeling good is at best a secondary consideration.

Without a Fair Troll, it's just a "Coalition of the Harmless"

Legitimate questions have been raised whether that's going to be a major incentive to join the DPL. If it doesn't strengthen your position vis-à-vis a troll, if it doesn't strengthen your deterrent potential, if it doesn't make it cheaper or simpler for you to acquire your own patents -- what's the point?

The benefit would be limited to non-aggression between DPL members. By agreeing to the terms of the DPL, they effectively accede to a multilateral non-aggression pact. But if the DPL mostly attracts those who don't have any patents, or not many, and who are actually rather critical of the patent system in their field (the DPL wouldn't work only for software patents, but let's focus on those here), then that comes down to a Coalition of the Harmless.

They won't own many patents, so your risk of infringing some patent may only be reduced by a fraction of a percent. Jason Schultz, one of the two authors of the DPL, talked about examples of 1,000 to 5,000 patents in a recent speech -- that would be negligible compared to millions of patents that exist worldwide, every one of which could require you to put a product out of the market. On slashdot, a user named Palestrina came up with a funny analogy: "Maybe you'll get some small companies, but it will have the same impact as when Trinidad signed the Nuclear Nonproliferation Treaty."

It's not just that the number would be small. It's also that even if the number becomes somewhat bigger, you talk about a non-aggression pact between persons and entities with a relatively non-aggressive intention from the beginning. The DPL would primarily be joined by those who want peace. It doesn't hurt to firm up that intention on a formal basis, and once they do own patents of their own, they might indeed decide to use them occasionally against companies outside the pool to make money (or for competitive purposes). But it's certainly accurate to say that the average level of aggressiveness would be much lower among DPL members than among the entirety of patent holders. So even if the pool had 100,000 patents (20 times the top of the range Jason used in his example), the statistical risk of one of those patents being actually asserted would likely make those 100K patents as risky as 20K or 30K patents held by non-DPL entities.

"Nice guys don't win ball games"

Even though the DPL's authors can argue that someone with a defensive approach to patents could join the DPL anyway (even if there isn't a single hugely convincing benefit), I continue to believe that the DPL will take off only if the difference between being under the DPL umbrella versus standing in the rain is really significant. Otherwise, it could still be valuable as a litmus test for someone's sincerity concerning promises to use patents defensively, but someone with bad intentions could just stay outside and go about his business the same way as before.

The success formula: Be evil! At least a little bit, and within a perfectly ethical framework. And in this context, be greedy!

The objective: create dynamics (in a potentially profitable way) that will really make it very attractive to be protected by the DPL shield.

What's needed is at least one (ideally more than one) entity that will assert patents from the DPL pool very aggressively and systematically against entities who don't support the DPL. By acceding to the DPL once they are attacked, the pressured parties could limit the problem to backroyalties (paying for past infringement of the patents in question) because once they make their own patents available under the DPL, they will have access to the patents in the pool. If they decide to stay outside even longer, they will bear the full brunt of the patent attack. If they lose, they will pay dearly. Some of that money will enrich those who successfully asserted those patents. Some of it will go back into the DPL ecosystem, making the problem for non-members of the pool bigger with time. Eventually more companies will then decide that it's in their own best interest to join the DPL.

If too many companies join the DPL, then the opportunity for Fair Trolls to find targets would be diminished. But in the meantime the Fair Trolls would already have had a gigantic opportunity to make money. Some of the world's largest patent holders prefer doling out multi-million-dollar checks to dozens of trolls a year over joining an alliance like the DPL pool, so there would likely always be an opportunity to make money.

Community participation

The FOSS community -- and the wider software developer community -- would play a key role in this.

Actually, the idea I'm just describing one that comes from the community. It's not my own and it's time to credit the sources. Henrik Ingo, an executive with Finnish open source company Monty Program Ab and the author of the OpenLife blog and namesake book on the philosophy of open source, explained it in detail on my Facebook wall after I posted my first thoughts on the DPL. Even he didn't create it from scratch. He had been inspired by some contributions to a recent discussion on lwn.net.

If the idea gets implemented, the community would likely be the key contributor of patentable ideas to feed the Fair Trolls with ammunition. Software developers supporting the DPL who don't have the resources to obtain patents of their own (per jurisdiction it can easily cost tens of thousands of dollars/euros in the total of registration and legal fees) could work with a Fair Troll and sell him a patentable idea, which would have to include assistance in the form of input for the patent attorney drafting the patent application. The Fair Troll would pay for the cost and would somehow compensate the contributor, be it through a one-time payment or a percentage of royalties generated in the future or a combination.

The key thing about a Fair Troll is that he would have to make that patent irrevocably available to all members of the DPL pool on DPL terms. So a Fair Troll would only attack companies outside the DPL pool. Those could again eliminate or at least greatly reduce the problem by joining the DPL when they get attacked. A Fair Troll would have to leave peaceful people alone but would have to pursue all others relentlessly. In fact, the better the Fair Troll does his job, the more he will contribute to the DPL cause and the more attractive it will be for community members to work with him.

I said before that ideally there should be more than one Fair Troll. There should be competition. It's actually a huge benefit of the DPL that it aims to create a pool through the common use of a public license as opposed to depending on a single company or a joint venture. That makes the DPL more transparent, more reliable, more resilient than patent pool firms. But for the "trolling" part, companies are needed, and they must be profit-oriented.

There shouldn't be a single company having a monopoly. Two or more should compete with each other because those doing the best job will be most attractive for community members to work with. They will be able to pay the most money upfront, they'd have the best basis for claiming that they can generate substantial income in the future, and they'd be able to afford donations to other community causes so that community members feel even better about the idea of them cashing in on those ideas.

Would the community be up to the task?

There already is a community patent review process named peer-to-patent. The idea is that the community would be able to point out if a patent application is filed on something that's previously been patented or otherwise published. The idea is to ensure that bad patents are avoided during the granting process.

Compared to the community patent review, the idea of feeding a Fair Troll is much more attractive because there's serious money to be made. If you come up with patentable ideas that can really lead to big payments by infringers, and if you then get a cut of the deal, that's a much bigger opportunity than helping a patent office do its job (although both are good causes).

There is so much brain power in the community that its members could likely come up with some of the best patents for "trolling" purposes ever created.

The unique opportunity created by the DPL is that an "inventor" from the community gets the kind of reliability (no use of patents against other DPL supporters) and transparency that you can never get from a software company (or a joint venture of software companies) offering to obtain patents on your ideas. With them you never know what they'll be up to. But with the DPL you have certainty that there won't be any aggression within the pool, and with the Fair Trolls it's quite obvious what they will do: they will try to make as much money with your patent as they can, and that's not only good for you and for them but also for the cause.

Of course, this requires the Fair Troll to make an absolute commitment to adhere to the DPL, and competition among multiple Fair Trolls would ensure performance and would require them to think of ever more ways to position themselves as a great partner for the brightest minds in the community.

Is there a business opportunity for one or more Fair Trolls?

Initially, there would be few DPL members and a Fair Troll would have almost the same targets to attack with his patents as an unfair troll. But only a Fair Troll will get that kind of support from the community.

The perfect victims for trolls are exactly the kinds of companies who won't join the DPL ever, or at least not for a very long time. So there's plenty of money to be made.

Another important question is whether one or ideally more than one Fair Troll could be created in practical terms.

A typical group of founders of such an entity would be a team of IP lawyers who would be in a perfect position to assess the market potential of the patentable ideas offered to them and who could later also enforce those patents in court. For an example, the entity that received $612.5 million from RIM (BlackBerry) belonged to a group of lawyers, who in turn hired another group of lawyers to litigate, and they all shared the hefty proceeds in the end.

A Fair Troll would need some initial funding from investors in order to be able to amass a significant and valuable patent portfolio with the help of the community. Once it starts to generate revenues with those patents, it can reinvest some of the proceeds to acquire ever more patents. Initial capital requirements would correspond to the expectation of how many valuable patentable ideas are offered by the community. If there are many, then there's also a huge revenue opportunity. So from a return-on-investment perspective, it should be possible to pull it off. Some of the initial funding could even come from non-profits who want to support the good cause, but don't forget: for this to do a lot of good, the way in which the Fair Troll deals with the non-DPL world has to be just as bad as any other troll.

The symbiosis between the community and the Fair Trolls

A user named dmarti, who appears to have been the first to publish this idea, wrote on lwn.net: "What we need is a company that would be [DPL] patent pool by day, patent troll by night."

Another way to look at such a Fair Troll would be how Franklin D. Roosevelt, the 32nd president of the United States, purportedly labeled one of his country's allies: "Sure he's a son of a bitch, but he's our son of a bitch."

With that kind of attitude, and with professionals putting the infrastructure in place, the DPL could enable the FOSS community to beat the software patent community at its own game. Wouldn't that be great?

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

Monday, May 17, 2010

Will the Defensive Patent License be able to make patents 'less evil' for Free and Open Source Software?

About a week ago, a NetworkWorld article entitled "The Defensive Patent License makes patents less evil for open source", reporting in advance on "a software patent license in the image of the GPL" that is being developed by two law professor from UC Berkeley, drew a significant level of attention in the FOSS community.

While I agree with the FFII's very skeptical view on "collective shields against software patents", I have a lot of respect for Jason Schultz, one of the two authors of the upcoming Defensive Patent License ("DPL"). As a staff attorney with the Electronic Frontier Foundation, he was involved with a number of high-profile intellectual property cases, consistently defending the freedom to innovate.

If the disease can't be cured, let's at least deal with some of the symptoms

Software patents are becoming an ever bigger problem:Unfortunately, the push for the total abolition of software patents hasn't made any headway at all in quite a while. Five years ago, the European Parliament threw out a proposal for an EU software patent law that would have exacerbated the situation. This was a major victory for the FOSS community to which I'm proud to have made my contribution with the NoSoftwarePatents campaign.

Since then, there hasn't been any legislative process on substantive patent law (the rules for what can and cannot be patented) in any major market in the world, and the anti-software-patent movement simply hasn't been able to launch any initiative of its own. A new worldwide campaign, EndSoftPatents.org was launched, and I wish Ciaran O'Riordan best of success with it, but I can't see any tangible political progress.

As long as businesses are either in favor of software patents (basically all large IT companies and also some small and medium-sized ones) or only speak out against them without putting their money where their mouth is, politicians won't change anything. It's equally non-obvious to a non-programmer why software patents are bad as it is to a vast majority of programmers why they are undesirable. Almost all politicians are non-programmers and as long as there isn't "muscle behind the hustle" in business terms, they won't abolish software patents against the will of big industry. On the contrary, Europe is working on a broader patent reform that critics such as the FFII believe will strengthen software patents.

In light of the overall situation, I do believe that initiatives such as the Defensive Patent License (DPL) should be evaluated thoroughly and pragmatically. They won't do away with software patents and they don't claim to. Can they still be helpful in some ways? What are their strengths and weaknesses, possibilities and limitations? Let's try to be constructive.

The DPL is still work-in-progress

It's too early to comment on the details of the DPL because, as the aforementioned NetworkWorld article explains, it hasn't been finalized yet.

There's no definitive release date. I've received indications that it won't be this month. It might be sometime next month, but it could also be later.

Nevertheless, I felt it made sense at this point to write down some general thoughts that don't depend on what exactly will be in the final version of the DPL, such as my previous rationale for approaching this constructively.

The DPL is not FOSS-specific -- but it's FOSS-like and the FOSS movement could be a key beneficiary

The aforementioned NetworkWorld article on the upcoming Defensive Patent License (DPL) puts it into a FOSS context, and the similarity between the two acronyms GPL (General Public License) and DPL (Defensive Patent License) isn't coincidental: the authors of the DPL indeed think of a somewhat GPL-like approach to sharing intellectual property.

But it's important to keep in mind that the DPL isn't tied to any particular software licensing model. Participation will be open to proprietary/closed-source developers just as well, without requiring them to switch a FOSS license for their program. The DPL will only affect their patents.

Absolutely zero deterrent effect on "patent trolls" (non-producing entities)

One thing that can already be said, even before the DPL is published, is that there's just no way it could possibly have even the slightest deterrent effect on a so-called "patent troll" (a non-producing entity asserting patents against companies that, unlike a troll, have actual products on the market).

The only way that owning patents can serve as a deterrent that makes others think twice before attacking you with their patents (and ideally makes them refrain from doing so) is if you own patents you could use against them: mutually assured destruction (or if not destruction, then at least "mutually assured damage").

That concept described the role of nuclear weapons in the Cold War. It can apply to a situation involving two companies with products on the market: both would have to fear that the other can prevent them from continuing to sell their products. But a "troll" doesn't have products and therefore you can't hurt him with your own patents.

It's amazing how many commentators (professional journalists as well as commentators in online forums) who write about patents don't know that basic fact. That's why it's so important to explain it over and over: Trying to use patents against a troll is a non-starter because you don't have any target to attack, no country on which you can drop your own nuclear bomb.

The only way you can hurt a troll is by getting his patents invalidated. I'll address that in the very next paragraph.

Patent busting isn't a matter of having any patents of one's own

If you destroy all of them (or at least all those that have any commercial value), you can destroy the troll's business. But for the process of invalidation, it doesn't matter whether you own any patents yourself. The judges won't care.

If you want to get a patent invalidated, it may be helpful to show prior art (earlier inventions that show that the patentee wasn't the first to come up with something and therefore shouldn't have been granted the relevant patent.

Prior art is not the only way to invalidate patents but it's probably the most common one. That's because patent offices often fail, especially in the field of software, to really find out all of what's already been created. A large number of patents that are granted can therefore be invalidated.

A patent is one of various forms of prior art that can help to get another patent invalidated, but then it doesn't matter who owns it. All that matters is when it was filed: before or after the patent you try to take down.

If an open-source project publishes some timestamped code, that is just as useful for purposes of patent invalidation as a patent application (but without the hard and soft costs of the latter). Even if potential future use as prior art played a role in your decision to file for patents of your own, you wouldn't need the DPL for that purpose. So the DPL must deliver benefits in respects other than prior art.

Deterrent/retaliatory potential

Having identified "patent trolls" and "prior art" as two areas in which the DPL won't be able to add any value (not just very little value but literally zero value), let's now look at a field in which it will be very hard but maybe (or I should say: hopefully) not impossible for the DPL to have a noteworthy useful effect: retaliation.

At least those patent holders who have products of their own on the market certainly have to consider whether they attack a "have-not" with no patents of his own or someone who may have one or more patents he could use for retaliatory purposes in order to achieve a non-aggression pact, which in connection with patents is typically called a cross-licensing deal.

Like I said, the DPL hasn't been finalized yet. I haven't been able to obtain any information about its content beyond what NetworkWorld reported. If I took the NetworkWorld article literally, I would have to conclude that the DPL isn't going to increase a participant's retaliatory potential either. If you're a little guy and have only a few patents of your own, the DPL -- based on what NetworkWorld writes -- wouldn't give you any more leverage in dealing with a mega patent holder. You could -- based on that article -- use only your own patents to make a counterthreat, not those of other supporters of the DPL. But to file for your own patents, you don't need the DPL: to do so, you need a patentable idea and a patent attorney and have to pay the same fees with or without the DPL.

It could be that there are clear legal limits for the extent to which a a license for patent-sharing can actually accomplish the objective of enhancing every participant's deterrent potential. Maybe it just isn't possible for a license such as the DPL to enable you to use anyone else's patents for retaliation, in which case one couldn't blame the authors of the DPL for having missed an opportunity but one would nevertheless have a factual basis for calling into question the usefulness of the DPL.

However, since the DPL is still work-in-progress, I still have hopes that maybe there will be a positive surprise as far as the concept of "mutually assured damage" is concerned.

Access for those who don't own patents yet

[Update] It has meanwhile been confirmed to me (but wasn't clear to me based on the reports I had read) that the DPL will also be accessible to a company that doesn't have patents yet but commits for a certain period of time to offer any future patents of its own (if and when it will obtain any, without being required to do so) under the DPL. It's a good idea that the benefit of the DPL will be available to those who make such a commitment in order to broaden the target audience to which the DPL is appealing and to encourage participation even by those who so far haven't played the patent game at all. [While I have been able to receive direct information from the DPL's authors concerning this aspect of the DPL, they haven't yet had a chance to comment on my other observations. I might do a follow-up post should I receive further feedback.]

FOSS projects and legal entities

I'm also curious to see how FOSS projects will be able to accede to the DPL. In case of projects run by companies (JBoss and MySQL were, prior to being acquired, examples of that approach), it would be easy. It might also work for foundations such as Mozilla and Xiph.Org. But what about other FOSS projects which basically exist as virtual teams on SourceForge and similar sites, without any formalized umbrella? We will see when the DPL is published if and how its authors plan to involve such projects.

One clearly intriguing aspect: the all-or-nothing approach

Of the few things that have become known about the DPL so far, there's one that I really consider very intriguing:
Members of the DPL contribute all of their patents in their patent portfolio – they don’t pick and choose (and this is what differentiates it from other defensive patent pools).
This commit-all-or-go-home approach would at the very least make the DPL a litmus test for patent pledges. If the DPL achieved a significant degree of acceptance, then anyone who made or will make a "pledge" related to only a subset of his patent portfolio can be asked: if you're for real, why didn't you go with the DPL? Why did you decide to reserve other patents for aggressive purposes?

The first open-source patent pledge was made by IBM in January 2005, and I criticized it very harshly that same day. I said that IBM was just being hypocritical. I pointed out on that occasion and also later that year, in a slashdot op-ed entitled "Patent Pools and Pledges - Panacea or Placebo?", that it just wouldn't work if a mega patent holder like IBM makes a one-time pledge of 500 patents while obtaining that number of new patents roughly every month.

As IBM's use of patents to intimidate the founder of the Hercules open-source mainframe emulator shows, IBM still had a large number of non-pledged patents to bring into position against Free and Open Source Software and the very notion of interoperability. Of the 173 patents IBM asserted (67 of them pending), 171 (99%) were outside the pledge anyway, but to add insult to injury, IBM also used two of its 500 once-pledged patents. Not only did IBM prove that a pledge of 500 out of tens of thousands of patents is practically worthless but also did IBM demonstrate that it would try to bring up utterly absurd arguments for not letting an 11-year-old open-source project benefit from the pledge. A French magazine (LeMagIT) found the best way to describe that kind of pledge on its website: Promesse à géométrie variable (a promise whose scope can be redefined afterwards)

So the original "patent pledge" concept has been an abject failure. I've opposed it from Day One, a fact that is well-documented on the Internet. Five years later more people than ever will agree with me that it was just a PR stunt by IBM (then followed by others, such as Sun Microsystems). It was meant to kill two birds with one stone: lulling politicians and FOSS developers into a false sense of security concerning patents and misleading everyone as to the patent-related intentions of IBM, not only the biggest patent bully on the block but also one of the most ruthless ones.

By contrast, I have no doubt that the authors of the DPL are absolutely sincere and really want to protect not only FOSS but also other software developers to the extent that a license can help reduce the threat from patents. The contribute-all-or-nothing rule is part of that honest approach.

How useful the DPL is going to be remains to be seen. Being better than IBM's and similar pledges is a low hurdle and I'm quite confident the DPL will set a far higher standard in that regard. The toughest test, however, will be inhowfar such a initiative can affect not only the decisions of benevolent parties but also those of malicious aggressors. Only getting the "good guys" to contribute to a defense initiative isn't enough to make a really noteworthy difference if there isn't going to be a major impact on the "bad guys". That will be a key criterion for gauging the potential effectiveness of the DPL.

For now we have to await its publication, then its adoption. I definitely look forward to seeing and reviewing it and will then post my comments on it to this blog.

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

Monday, May 10, 2010

{Video codecs} Food for thought

This post is the third (and last one) in a three-part series on video codecs. Click here for the first post in the sequence, "The HTML 5 dimension", or here for the second post in the sequence, "Accusations flying in the aftermath of Steve Jobs' email".

The patent thicket problem

A couple of weeks ago I stated my conviction that there's no such thing as an open video codec that can be guaranteed to be unencumbered by patents. I regret to say this, but like I wrote then, the field of multimedia formats is a true patent thicket. Ed Bott, a ZDNet blogger, counted 1,135 patents from 26 companies just in the H.264 pool. That is only one of the multimedia standards MPEG LA commercializes, and there are patent holders who don't work with MPEG LA but who may also have rights that are relevant to Theora (or VP8, for that matter).

Those 1,135 patents refer to registrations in a total of 44 different countries (with different numbers in each country). So there are certainly many duplicates in terms of the scope of the patent claims. Nevertheless, even just a fraction of 1,135 is still a huge number considering that it's about a single codec.

Contrary to popular misbelief, patent law doesn't stipulate a 1-to-1 relationship between patents and products. In the pharma sector there is sometimes only one new patent on a given product, or maybe two or three. In software, every little step of the way is, at least potentially, patentable. That's why even a codec like Theora or VP8 might, although it has a different background, infringe on some MPEG LA patents.

The Xiph.Org Foundation's president, Christopher 'Monty' Montgomery, wrote that if Steve Jobs' email was real, it would "strengthen the pushback against software patents". I'm afraid there isn't enough of a pushback out there that would really be needed to bring about political change in that regard (because small and medium-sized IT companies aren't truly committed to the cause), but now that more and more people do look into the threat that patents pose to FOSS (and other software), there will be greater awareness for the patent thicket problem and for the fact that patent law creates huge numbers of little monopolies as opposed to serving to protect completely functional products or technologies.

The question of relative safety in patent terms

I agree with the FSFE's president, Karsten Gerloff, that "[j]ust because a standard calls for licensing fees does not mean that the users are safe from legal risk". It's true that there might even be patents that could be asserted against H.264 but aren't under the control of MPEG LA, for reasons such as the ones I outlined recently.

However, given the extremely widespread commercial use of H.264, including some of the prime targets of patent trolls, the fact that no such patents have been asserted against H.264 licensees so far is a fact that certainly makes a number of people reasonably comfortable. While there is also significant use of Theora (and related technologies), its adopters aren't nearly as attractive targets for patent trolls as the users of H.264. Besides patent trolls, there are those large commercial holders, and as I explained before, the MPEG LA pool is so big that problems for Theora are in my opinion not outside the realm of plausibility.

The question isn't how attractive a target Theora has been so far. If it was elevated from its current status to a part of the HTML 5 standard, we'd be talking about a commercial relevance that is easily 100 times greater.

The need for consensus in the HTML 5 standard-setting discussion

HTML 5 is an extremely important leap forward and the W3C certainly wants to achieve consensus that results in consistent support by the major browser makers. This is also in the interest of web developers and website operators. If the W3C imposed Theora as the standard video format against the concerns the leading proprietary browser makers voice, this could result in inconsistent implementations of what should become a common basis for all browsers. That, in turn, would mean a lot of potential hassle for the web community.

The market relevance of Apple and Microsoft is significant enough that even without the patent uncertainty argument the preferences and positions of those vendors must be taken into account by the W3C. Their support for H.264 doesn't mean they leverage their relevance as platform companies in order to push another product of their own. H.264 is a multi-vendor patent pool, and of the 1,135 patents in the H.264 pool, Apple contributed only one and Microsoft only 65 (less than 6% of the total), according to Ed Bott's count. Both companies are also H.264 licensees and, quite plausibly, net payers (getting charged more license fees for their own use than the share of MPEG LA income that they receive). They may very well have strategic reasons for which they favor H.264, but that would be another story.

The burden of proof in the HTML 5 standard-setting discussion

I can understand the frustration of FOSS advocates and, especially, the Xiph.Org Foundation that some companies make references to uncertainty surrounding patents Theora may infringe without telling the public which those patents are. At the same time, I don't think anyone could have expected Steve Jobs to include a list of patents in that email about open-source codecs, which was just a high-level explanation of his views.

Unfortunately for Theora's developers and other supporters, there is no such thing as a burden of proof on browser makers saying they're uncomfortable with Theora because of patent-related uncertainties.

If the proponents of Theora want to disprove the "uncertainty" argument, they can't just refer to the fact that nothing has happened yet. If Theora was elevated to a part of the HTML 5 standard, the resulting adoption would represent a fundamental change of the situation.

Unfortunately, it's easier to make the case for than against a possible infringement of patents by a given piece of software. If a patent holder wants to document an infringement, there are different formats, the most popular one being a so-called claim chart. If the Xiph.Org Foundation and its allies now wanted to show that Theora doesn't infringe on any patents, they'd have to theoretically look at every patent out there.

That wouldn't be possible, but how much of an effort would be reasonable?

Under normal circumstances I believe one couldn't expect an open-source project to undertake any patent clearance of this scale. However, if companies such as Google and Opera and a formal non-profit with very deep pockets such as the Mozilla Foundation push for a standards decision with far-reaching implications for the whole industry, then I don't think it would be unreasonable to expect that they should at least look at the patents in the MPEG LA pool and perform patent clearance for Theora with respect to those.

As long as they don't make that kind of reasonable best effort, their argument about Theora being patent-safe amounts to "trust us". I said that I agree with the FSFE that the availability of a patent pool doesn't guarantee that the pool is complete. Nor does the opposite situation (developers electing not to take out patents) guarantee anything.

I don't know what Theora's proponents and opponents laid on the table in internal discussions at the W3C level. What I just wrote is based on the public debate. Also, what I wrote about Theora would equally apply to VP8 if Google proposed its inclusion in HTML 5 (after possibly open-sourcing it).

Is H.264 licensing a practical alternative for FOSS?

I asked MPEG LA, the patent pool firm that manages H.264 and other codecs, whether it would -- hypothetically speaking -- be possible for Mozilla (the maker of Firefox) to license H.264 and then make it available to everyone on Free and Open Source Software terms including the right for users to include the code in derived works. This is the answer MPEG LA gave me:
MPEG LA’s purpose is to provide voluntary licenses of convenience to users enabling them to have coverage under the essential patents of many different patent holders as an alternative to negotiating separate licenses with each. The licenses are nonexclusive and limited to coverage in connection with the applicable standard (e.g., AVC/H.264) being licensed. Therefore, although MPEG LA does not regulate this space directly, as you point out, users are not authorized to use the licensed technology beyond these limitations without payment of applicable royalties or other licenses from patent holders permitting such use.

Under our AVC License, the Licensee is the party providing the AVC end product in hardware or software. Therefore, for products where Mozilla is the Licensee, it would be responsible for paying the royalties and notifying users of the License coverage, and where other parties are Licensees, those responsibilities will fall upon them. In normal usage such as personal use, no additional License or royalty is necessary because applicable royalties are paid by the end product supplier, but additional License rights may be required where the codec is used for other purposes such as subscription or title-by-title sale of AVC video.
That answer doesn't mention Free Software or open source, but it clearly reaffirms that "users are not authorized to use the licensed technology beyond [certain] limitations without payment of applicable royalties or other licenses [...]", and such limitations aren't compatible with FOSS licenses. They go clearly against both the Free Software Definition and the Open Source Definition with their respective prohibition of discrimination against certain types of use and the requirement to allow such use free of charge.

While it's clear that code made available under a FOSS license couldn't practically implement H.264, the alternative approach would be for a FOSS browser maker such as Mozilla to include a proprietary plugin in a distribution to end users. The proprietary plug-in would be installed automatically but the license terms would make it clear that, unlike the FOSS code that is part of the same distribution, that part can't be incorporated into derived works without obtaining a license to the H.264 patent pool from MPEG LA.

Canonical (Ubuntu) and OpenOffice are comfortable with proprietary extensions to free software

Ubuntu maker Canonical has chosen that mixed free-unfree software approach. This caused some outrage by parts of the community (since it gave the impression of a FOSS company supporting H.264 against Theora), and Canonical had to justify its approach. I interpret Canonical's "clarifications" as a recognition of the fact that H.264 is commercially extremely relevant, but they try to maintain their FOSS image as much as they can.

There's a similar debate now concerning OpenOffice, for which there are free as well as unfree plug-ins and certain FOSS advocates would like unfree ones to be excluded from the project's official list of extensions. Bradley Kuhn, a Free Software Foundation board member, expressed his personal views in a blog post, "Beware of proprietary drift". It seems the Free Software Foundation lost this argument and the OpenOffice project will continue to welcome extensions that aren't Free Software.

While patents aren't explicitly discussed in the OpenOffice context, this is clearly an example of where things may be heading, contrary to the FOSS purism some people advocate. Proprietary extensions to OpenOffice could also contain patented elements.

Will the W3C at some point have to depart from its royalty-free standards policy?

My prediction is that there won't be a solution for an HTML 5 video codec that proprietary and FOSS-oriented vendors can reach consensus on. The current diversity of codecs and plug-ins is suboptimal but acceptable: it certainly hasn't prevented web video from becoming extremely popular. So there isn't really a pressing need to converge on a single standard for now.

In the long run it remains to be seen whether the W3C can maintain is royalty-free standards policy. That approach has been key to the success that web technologies have had so far, but it could, as the situation concerning codecs demonstrates, increasingly impede progress.

In the early days of web technology development, there wasn't much attention by big industry, nor by patent trolls. Hence it was possible to create patent-free standards.

The kind of technology created at that time was also far simpler than today's advances in online media. The field has become very sophisticated, which has many implications including the consequence that patent thickets related to new web technologies will reach previously unseen heights in terms of size and density.

In this earlier blog post I wrote, under the subhead "The FOSS way of innovation exposes all FOSS to patent attacks", that patents reward the first to patent a new idea, while FOSS innovation is usually of a different kind (with a few exceptions). That's also an important kind of innovation, but it's not favored by the patent system and may therefore not be a sufficient basis for future web innovation.

HTML may become like GSM, at some point requiring licenses to large numbers of patents

As the web advances in technological terms, and given that software patents are extremely unlikely to be abolished in the largest markets anytime soon, the W3C may in a matter of only a few years feel forced to revisit its standards policy.

It takes licenses to thousands of patents in order to build a GSM phone, and at some point it may be required to license large numbers of patents to build a fully functional HTML web browser. I'm afraid it's only a question of when, not if it will happen.

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.

{Video codecs} Accusations flying in the aftermath of Steve Jobs' email

This post is the second in a three-part series on video codecs. Click here for the previous post in the sequence, "The HTML 5 dimension", or here for the next and final post in the sequence, "Food for thought".

After Steve Jobs made a thinly-veiled threat of patent enforcement against Theora and other open-source codecs, two key players from the Xiph.Org Foundation (the organization behind Theora) responded publicly. Its founder, Christopher 'Monty' Montgomery, sent his quick comments to the media (I also received them from him directly when emailing him after seeing Steve Jobs' email). His colleague Gregory Maxwell, the Theora project leader, sent his reaction to a public mailing list. A few days later, Karsten Gerloff, the president of the FSFE, stated his opinion on his blog.

The two Xiph leaders and the FSFE president took different angles but all of them doubted that Steve Jobs' threat had any substance. They used different terminology ranging from "blackmail" to (in a semi-hypothetical context) "jackbooted thugs". Those are hard words, but are they backed up by hard facts? Let's look at them one by one.

Are those patents holders dogs that bark but don't bite?

The official Xiph.Org statement starts by mentioning a long history of veiled patent threats against Ogg multimedia formats, ten years ago with respect to Ogg Vorbis (the audio format) and in recent years against Theora (the video format from the same family). Monty then concedes that this time it might "actually come to something", but he won't worry until "the lawyers" tell him to.

If the veiled threats Monty refers to appeared vain in the past (since no legal action against those open-source codecs was actually undertaken), I can understand the Xiph.Org Foundation's wait-and-see approach. However, a famous Spanish proverb says (in a literal translation) that "the pitcher goes to the well so often that it ultimately breaks."

For whatever reasons, one of which may be the fact that suing open source over patents hurts a company's popularity among software developers, certain patent holders may have refrained from legal action in the past but we may now have reached (or be nearing) a point where at least some of the relevant patent holders may indeed be prepared to strike. A reluctance to do so need not be an impediment forever. When weighing off pro's and con's (of legal action), patent holders may come down on the "no" side in one year and on the "yes" side a few years later under different circumstances in the market.

One field that is very litigious -- and for which HTML 5 and video are going to be fairly relevant -- is the mobile communications sector. Apple and Nokia are suing each other in different courts in parallel. Apple is suing HTC. Those actions are real and giving cause for concern that the concept of the mobile web may also bring mobile sector-like litigiousness with it.

The representation that patent holders -- especially some of those who have contributed to MPEG LA's H.264 pool -- only make unspecified threats and are too afraid of actually taking their patents to court (which could result in invalidation of patents for prior art or a court opinion that interprets a patent claim more narrowly than its owner) was voiced by FSFE president Karsten Gerloff in an effort to question the substance of Steve Jobs' infringement assertion. I understand his motives and they are good, but I have a different impression of how far Apple is willing to go. Just in its litigation with HTC, which is not the only one to which Apple is a party as we speak, Apple is asserting 20 patents.

Karsten makes a similar claim about Microsoft and the possible infringement of some of its patents by the Linux kernel. But it's not hard for me to imagine that there may be (easily) hundreds of Microsoft patents that have the potential to read on the Linux kernel. The ones that are most frequently heard of, the FAT patents, have survived various patent busting attempts due to the way patent law unfortunately works, a fact on which I reported recently.

I strongly doubt that companies of the nature and stature of an Amazon or HTC would pay Microsoft patent royalties without substance just on the basis Karsten speculates about. There's nothing to gain for those companies by doing a press release in which they confirm (even without specifying details, which simply isn't usually done) royalty payments to one major patent holder. That can actually result in others who believe they have patents reading on GNU/Linux trying to collect royalties from the same licensee.

All right holders will prefer to achieve their objectives without suing, which is always just a last resort, but that doesn't necessarily make it a safe assumption that they aren't prepared to sue, especially if they have already proven so or are, like Apple, proving it right now.

Is there an antitrust problem?

Monty and Gregory (both of the Xiph.Org Foundation) allude to antitrust issues in their statements while I can't see any problems in that regard.

Monty says about MPEG LA that "they assert they have a monopoly on all digital video compression technology, period, and it is illegal to even attempt to compete with them." Monty notes they don't say exactly that, but it appears to be how he interprets their past statements on these kinds of issues.

Assuming -- just for the sake of the argument -- that MPEG LA's patent pool indeed does cover so many codec-related techniques that no one can build a competitive codec at this stage without infringing on at least some of those patents, that would (in case it's true) constitute a monopoly. However, in that case the only obligation that regulatory authorities could impose on MPEG LA under competition rules would be to make its IP available on a RAND (reasonable and non-discriminatory) basis. In other words, they can charge something (there's no way that competition law could justify an expropriation without compensation), but they aren't allowed to overcharge.

When Steve Jobs wrote that a patent pool was being assembled to "go after Theora" and other open-source codecs, he didn't say that the objective would be to shut everyone else down. this could also simply mean to collect royalties from those using that technology. As long as those royalties are RAND, there wouldn't be any anticompetitive behavior, but Theora would lose its royalty-free status. It could still compete, but the playing field would look different than the way Theora's proponents describe it as of now.

Gregory's email statement quotes a US Department of Justice statement on licensing schemes premised on invalid or expired intellectual property rights not being able to withstand antitrust scrutiny. I can't see that this reduces in any way the legal risk for Theora and its proponents. I assume that there are, unfortunately, large quantities of valid and non-expired patents related to codecs.

I also can't think of any legal theory based on which patent holders forming a pool to assert rights against Theora would have to contact the Xiph.Org Foundation beforehand. Not only is there no legal obligation but also do I think that in case there are patent holders who (unfortunately) own patents that read on Theora, they are free to coordinate their efforts and present a united front to Theora's supporters.

The term "anti-competitive collusion", which appears in Gregory's email as one of the possible explanations for what's going on, is unclear to me. While my sympathy is with an open-source project, this is just about what would or would not be legal if undertaken, a question on which I reach, to my own dismay, a somewhat different conclusion.

Is there a risk of H.264 becoming too expensive?

Karsten (FSFE) is afraid of a future H.264 "lock-in" and the cost increases this could result in:
It hardly takes economic genius to determine that when enough people and works are locked into H.264, the MPEG-LA will have every incentive to start charging any fee they please. (Oh, and don’t you dare use that expensive camera for professional purposes. Your H.264 license is purely for non-commercial use.)
Lock-ins can indeed come with a hefty and ever-increasing price. The mainframe hardware market, in which IBM has a monopoly, is a good example: for a given amount of RAM, the cutthroat price is 60 times of what it is for an Intel-based PC.

However, in the specific case of H.264 and the license fees charged by MPEG LA now and in the future, there are assurances that a scenario of "charging any fee they please" (as Karsten wrote) won't happen.

Like I explained further above, if MPEG LA had a monopoly because any video codec (at least any codec that would be competitive in today's market) needs at least some their patents, then antitrust rules would require RAND pricing. Otherwise, if those patents don't cover the entire field, there could and would be competition, which would gain traction in the market especially in the event of price hikes.

One must also consider that MPEG LA's current pricing is very far from "any fee they please" (even though in a perfect, software-patent-free world the price would be zero), and they have promised to keep future price increases within certain limits. To those who are interested in those pricing questions, I can strongly recommend Ed Bott's ZDNet blog post, "H.264 patents: how much do they really cost?" His analysis contains a number of good points that are consistent with my own analysis of the information available on MPEG LA's website. While controversial (starting with its headline), his blog post "Ogg versus the world: don't fall for open-source FUD" is also quite interesting.

Having analyzed in this post some of what's been said in the debate, I will outline some of my own thoughts in the following post, including what I believe the W3C may have to consider at some point.