Building the patent commons

by Greg DeKoenigsberg

Introduction

One day, the whole software world may wake up and recognize that software patents are, in reality, stumbling blocks to true innovation. Until that magical day arrives, software patents will continue to be an unfortunate fact of life. For any software company that competes against any other software company, the patent portfolio is still an essential shield for self-defense. Red Hat will continue to build its patent portfolio, reluctantly, for this purpose.

For companies like Red Hat that are also completely committed to the open source development model, this need for patent protection poses a unique and difficult problem: patents can scare open source developers away. And with good reason--open source developers have been burned over technologies they've wrongly assumed to be in the public domain, only to discover belatedly that these technologies were patented.

The protections provided by open source licenses are meaningless if code written under those licenses violates somebody's patent.

Perhaps the best-known example of this is the story of the Unisys LZW compression algorithm patent. Here's the short version. The algorithm was published in a journal while there was a patent pending on it. Lots of engineers assumed that if algorithm appeared in a journal, it was fair game. Compuserve incorporated LZW into the GIF image format. When GIFs became the most popular image format on the planet, used by open source and proprietary applications alike, Unisys connected the dots and said, "Hey, you're using our patented compression algorithm, give us our money." (A fair assertion in this case.) Open source developers scrambled to replace all of their GIF-writing code with PNG-writing code, a world full of lazy webmasters ignored the switch, lawsuits were threatened, fear and loathing ensued.

The last of the Unisys LZW patents expired last year, but the harsh lesson remains. The protections provided by open source licenses are meaningless if code written under those licenses violates somebody's patent.

The patent commons and the software commons

The idea of the "patent commons" has been around for a while. There have been various proposals of entities that might act as patent trusts for the public good--but ownership itself is the real issue. The vast majority of patents are held not by individual developers, who might be more willing to donate patents to some benevolent entity, but by businesses that must treat them as valuable property. No matter how companies may feel about software patents, no responsible company is going to give away a potentially valuable piece of property out of sheer altruism.

The goal of the "patent commons" is not, in the end, to give away patents; it is a tool to protect developers, so that they may safely contribute to the software commons. Bearing that goal in mind, it shouldn't necessarily matter who owns a particular patent. What matters is the freedom of developers to innovate, the freedom to contribute those innovations to the software commons, and the freedom to do all of this without worrying about the threat of litigation.

Red Hat was the first company to address this problem directory with the Red Hat Patent Promise, first published in 2001. As we discussed in December's edition of Red Hat Magazine, by promising in writing not to litigate against developers who might "infringe" Red Hat patents, so long as their work is published under an approved open source license, Red Hat has successfully extended the right of development to the broader open source community.

In January, IBM opened 500 patents to the community of open source developers, closely following the example of the Red Hat patent promise. With these legally binding pledges, first by Red Hat and now by IBM, the model for a practical "patent commons" is starting to take shape in a meaningful way.

Traits of the useful patent promise

The open source patent promises by Red Hat and IBM share a number of traits. These traits could form a strong basis for other companies looking to make similar patent "donations" to the open source community:

• The promise should say, unambiguously, that the party making the promise will not sue, presuming that the developer follows the guidelines set forth in the promise. The clearer the promise is, the more difficult it is for the company to break it.
• The promise should apply only to developers who contribute code to open source projects. This way, the company retains the ability to defend its patent should that patent be violated by, say, a proprietary competitor. Without such protection, few companies, if any, would even consider making their patents available.
• The promise should define the scope of its coverage. The Red Hat promise specifically applies to all patents now held by Red Hat; the IBM promise applies only to 500 of its patents, a small subset.
• The promise provides an explicit definition of what is considered to be an acceptable open source project. IBM specifies that code licensed under any OSI license is covered by the promise; Red Hat defines a more specific set of open source licenses that ensure that the code will remain free.
• The promise contains language that revokes the promise in case of counter-litigation. This is an extremely important provision to make, because it helps to ensure a detente between companies who donate code to the software commons.

Some companies are making their own promises about patents, and these are steps in the right direction. Ulimately, though, no developer should ever rely upon any promise that lacks the proper language to make it legally binding.

Benefits to companies

These patent promises obviously benefit the software commons by making it safer to enlarge that commons. There are also benefits to the companies that make such promises, which may be less obvious.

• Developers could actually read their patents. One of the ugly side effects of patent law, as currently written, is that it actively discourages developers from gaining too much familiarity with patents. If a developer knowingly infringes upon a patent, the penalty is substantially worse than if that developer infringes unknowingly. The result: developers avoid patents like the plague, and consequently know little about them.
• Companies might get help from the open source community to get their products to market faster. It's a common misconception that a company can't build products around open source software. In reality, companies like Red Hat are becoming very successful doing exactly that. By strategically opening up their patent portfolios, software companies can encourage open source developers to help make their ideas into reality, while at the same time preventing competitors from taking a lead. These companies could then spend their resources on marketing, selling and supporting these products based upon their value.

As open source projects continue to prove their legitimacy and value, more and more companies will explore the benefits of making their own code available to these projects. The emergence of a clear model for a patent commons that protects the interests of both businesses and potential contributors can only help in the effort to bring the benefits of open source to the marketplace.

About the author

Greg DeKoenigsberg is the Community Relations Manager for Red Hat. He is not a lawyer, but he does have a dubious design patent to his credit (US Patent D432,536), about which he feels a deep ambivalence.