Linux and Patent Risksby chromatic
Conventional wisdom among free software and open source developers has long warned that software patents could corrupt and disrupt good software projects. The GPL mentions such a risk, for example. While only a few patents have actually stopped the development of some software (Unisys' GIF patent, the patented LZW algorithm, and Fraunhofer's MP3 patent), the risks involved in developing software in a patent-haunted world remained unclear.
Though many developers prefer to ignore patents, the current laws (at least in the U.S.) provide minimal legal defense for unwitting infringements. Worse yet, though a project may have pedigreed and documented prior art that could easily convince a court to overturn a patent, the cost of such an action is out of reach for most developers -- and many companies.
A recent report commissioned by Open Source Risk Management (OSRM) examined the Linux kernel for patent violations that patent holders could cite in lawsuits against distributors. Unsurprisingly, the report found 283 patents that might come into play.
Reactions to the report varied greatly. This was apparently the first broad study of its type, the first such study to clarify the risks that software patents pose to open development. Many longtime developers always suspected that this was the case. Other people took offense, as if the report suggested a flaw in the development of the kernel; suggested reasons not to use Linux or free software in general; or provided fear, uncertainty, and doubt in an attempt to sell OSRM's legal insurance.
Dan Ravicher is the patent attorney who conducted the study. By day, Ravicher is the executive director of the non-profit Public Patent Foundation, working to reform the patent system. He also represents the Free Software Foundation on a pro-bono basis.
I recently spoke to Ravicher in an attempt to clarify the aims of the study and the conclusions he reached from it.
The best way to analyze the study and its conclusions is to consider the idea of risk as a business would. Ravicher suggested that the purpose of the study was to answer several questions:
- Are there pieces of code in the Linux kernel that may potentially violate patents?
- Of the potentially violated patents, have the courts upheld any of them?
- Who holds these patents?
- Are the risks associated with these patents greater, less, or the same as with similar proprietary software projects?
- How can users, developers, distributors, and companies ameliorate these risks?
OSRM's position is that it's better to have specific answers to these questions. It's easier to have plans in place when you know the problems you might face and the likelihood of those problems. Before announcing the results of the study, Ravicher shared them with several entities in the free software development community, including Bruce Perens, Linus Torvalds' legal counsel, OSDL, Red Hat, IBM, and Hewlett Packard. They had mostly similar, favorable reactions.
The most important finding is that Linux infringes on zero patents that have survived reviews in court. The 283 patents that the kernel could infringe have all gone unchallenged so far. There is a chance that a court could find the patents invalid -- so the conclusion that there are 283 ways in which patent holders could bring suit against kernel developers, users, and distributors is flawed.
Further, Ravicher discovered that open-source-friendly companies (including IBM and HP) hold about 100 of those patents. Again, the likelihood that such a company would bring suit against someone using or distributing Linux is small, especially since those companies often distribute Linux themselves. (Legally, a company probably could, but it goes against the spirit of open source.)
Less-friendly companies, such as Microsoft, do hold several of the 283 patents. Though courts may find these patents invalid, even reaching the point of judgment is expensive and time-consuming. It could cause a lot of trouble.
How much trouble this could cause depends on several factors. Pragmatically, individual users, developers, and small businesses have relatively little risk -- it's expensive to initiate patent infringement proceedings. Suing someone with few assets (compared to a large company with a large portfolio of offensive patents) is likely a bad investment.
A court judgment in this case could be as simple as an injunction against a particular developer, leaving other developers reasonably free to continue developing and distributing the software. The damages would be minimal, as an open source developer often distributes comparatively few copies of the software (preferring mirrors and other download sites) for little or no charge.
Large companies, such as the aforementioned IBM, also present un-tempting targets, with armies of lawyers and filing cabinets full of patents to use defensively. It's likely that two behemoths would settle with a cross-licensing agreement.
Medium-sized companies without several patent attorneys on staff or a portfolio of similarly-broad patents have the most risk. This is the space where OSRM seeks to make its business -- building a valuable service around free and open source software, not by selling licenses or keeping code secret.
As Ravicher explained, the cost of proprietary software includes some amount of patent insurance. The vendor of the software takes on the risk of defending its users against patent claims made by other parties. Open source and free software demand no such licensing fees, giving users the option of ignoring the problem or, now, purchasing patent insurance from OSRM or a similar group.
Ravicher also carefully pointed out that this study helped OSRM consider their business model. Contrary to the perception that they want such suits to come about, that would actually be bad for business. OSRM is betting on two things. First, that there will be few suits claiming patent infringement. Second, that providing insurance against these suits will be valuable to enough businesses to cover OSRM's costs.
Toward a Better Patent Policy
There are other objections to the study, namely that OSRM has not released details of the patents and that someone should challenge these patents and reform the system overall.
To the first objection, Ravicher notes that the current system of awarding damages in a patent infringement case is unusual. Notably, it relies on the amount of knowledge the infringing party had about the patent. If the court finds you guilty of willful infringement, where you knew about the existence of the patent at the time of your infringement, you may be liable for triple damages and the attorney fees of the other party.
Unwillful infringement leaves you liable for only damages with no multiplier. This is the real trap, since if you search for potential infringements and find one, you open yourself to charges of willful infringement. In this case, ignorance is still bad, but it's much better than the alternative.
If OSRM were to release the exact patents, this would turn the kernel developers (and distributors) into willful infringers, increasing their risks. This is not a goal. Many attorneys recommend against looking for patents you infringe for this reason.
Of course, it's better that the software not infringe at all. To this end, Ravicher said that OSRM plans to help developers work around troublesome sections to help to redesign out infringements or to prove that the kernel doesn't actually infringe upon specific patents. This may prove tricky, with both sides walking a thin wire of deniable willfulness, but it's doable.
As for the notion that someone should challenge the patents altogether, remember that the cost and trouble of challenging a patent is excessive. Chasing down a couple of hundred patents right now, when none of the patent holders have used them offensively against the kernel, is asking for trouble and, again, increasing risk.
OSRM could publish the details of patents that the patent holders agreed, in a legally binding form, never to assert against Linux. In effect, IBM could write a formal legal license for open source software to use patented methods in perpetuity, mitigating the risk that IBM (or anyone who asserted a right to that specific patent) would bring suit against users, developers, and distributors.
This seems to be the best outcome, but only time will tell if open-source-friendly companies will lay down legal weapons in this way.
The biggest question is how the Linux kernel compares to other pieces of software, especially proprietary ones. Ravicher concluded that it is no worse off than proprietary software, repeating that the difference between the two (in this sense) is that the price of a proprietary license nominally provides some indemnification against unwillful infringement on the part of the user.
For developers, the best approach seems to be to continue developing. The current legal framework over software patents really discourages even trying to find possible infringements. Until and unless the system stops rewarding ignorance, there may be little developers can do except support other groups who can help work around patents without opening themselves up to increased legal liability.
For businesses, the risks are nearly the same, unless you present a tempting, tasty target to a malicious patent holder. Unfortunately, those sharks have started to swim lately.
Ideally, non-profit groups such as the EFF and Ravicher's own Public Patent Foundation will succeed in their quest to reform software patents. Until that happens, though, knowing the risks involved can only help people make better choices.
Return to LinuxDevCenter.com.