Editorial by Ciarán O'Riordan, Exective Director of End Software Patents
Scope
On Monday, November 9th, the Supreme Court will hear the case of Bilski's business method patent. Being the first review of patentable subject matter since 1981, this decision could make the rules for decades to come. The court will review the 2008 ruling of the CAFC which created the "particular machine or transformation" test. This test, depending on who's reading it, could significantly narrow the scope for patenting software ideas.
The Supreme Court isn't obliged to rule on the patentability of software ideas. Bilski's patent is a business method patent, not a software patent. So why might the court make a broad ruling which would cover software? For people who are already aware of the legal arguments, I'd like to offer a review of the socio-economic arguments for abandoning software patents.
Practitioner profile
To see how different software is from most patentable fields, you just have to look at the practitioners. There is a small number of large companies with well known products, and there is a mass of small companies. The low cost of entry to software development means the number of small companies is particularly large, but we'll leave that aside to look at a bigger difference. In most patentable fields, this pyramid of big and small companies describes how products are made. If this were true for software, then the decision of patentability would be an economic decision, and some costs might have to be reduced, but there'd be no fundamental incompatibilty. But in software, this is only half the story.
In software, unlike in other patentable fields, there are two additional categories of developers. The first is the software developers that sit in the IT departments of every medium sized company. They're the folk that keep the emails flowing, who make internal software, extend software bought by the company, and who run the website. The second group is individuals, informal groups and communities who program for their own benefit or for social reasons such as providing alternatives to software seen as overly restrictive.
The existence of these two categories changes everything because it's obviously unreasonable to require them to work within the patent system, and it's unjustly restrictive. Not only are patent incentives obviously not necessary to motivate IT departments to fix problems, the timeline and budgets are orders of magnitude out of sync with the speed and costs of writing software. When a company manager reports a website problem, they don't expect the IT department to reply about first seeking legal advice for a patent search, and they don't expect to later have a bill from a patent holder because of the way in which the IT department happened to fix the problem.
For user communities programming to suit their own needs, the costs and timeline are also unreasonable, but there is also the bigger problem that the patent holder gains veto power over the distribution of the software. If the software is written for the purpose of having a freely redistributable program, then this third-party veto spoils the developer's efforts. There will be no direct profits from which to offer royalty payments, so the result is a lose-lose situation where the developer's goal is blocked, and there's isn't even anything in it for the patent holder (although the patent will still be enforced to sink the piece of software so that computer users are pushed toward a program which will pay royalties to the patent holder).
Standards
This issue is further exasperated by a problem which applies to all types of software developer: in no other domain are modern standards as crucial as they are in software. If you want to cure rubber, there are many ways to do it. When patents block a product developer from using one method, there's the possibility of useful innovation when that developer looks for an alternative method. In software, being blocked from using an email, image, or document format equates to being prohibited from writing a functional email reader, image viewer or word processor. Can you imagine the utility of an innovative word processor that can't read any existing documents? Nobody would use this, which means any innovations therein would have been wasted effort.
For video, this problem is a reality. The MPEG-LA group claims to represent more than twenty patent holders which each have one or more essential patents for implementing the commonly used mpeg video format. There's no licence available for freely redistributable software, and even royalty payers have to agree to MPEG-LA's terms. The committee developing the next standard for webpages, HTML5, spent months searching and debating which video format they could recommend in the standard, and the final answer was that, due to software patents, there is today no format they can recommend.(ref-1)
When "user communities" grow up
Now, it's important to look at the output of the mentioned user communities. If like, say, hobbiest watchmakers, they just catered for themselves and a few friends without attracting the attention of patent holders, then this wouldn't be a big problem. The system would still be unjust, but if the injustice never manifested itself, then it would be theoretical issue.
Indeed, freely redistributable software and the work that was begun by idealists and hobbyists has now lead to the world's most used webserver, the world's second most used web browser, and the GNU/Linux operating system. Indeed, the "users" are nowadays often employees, and their collaborative development models have emerged as the primary competitors in many software domains. Blocking collaboration turns out not only to be a restriction on useful individual activities, but it also stiffles competition and the mass production of useful software.
In software, rather than supporting innovators, patents protect the old against the new.
Although large firms now contribute to these projects, many of the developers are still individuals and people who don't directly profit. The terms of distribution for this software are the same now as they always have been. It's a proven formula, and a key clause is that you can't distribute if patent royalties will be required.
Example: GNU/Linux
The kernel of the GNU/Linux operating system was examined by patent attorney Dan Ravicher, who announced on August 2, 2004, that he had found no court-validated patents to be infringed but 283 *issued patents* existed which could potentially be used to support patent claims.(ref-2) Thereafter, Microsoft in the 2007 began claiming that the kernel violates 235 of its patents – although the patents have never been specified.(ref-3) Neither could be precise, but they these give us ballpark figures.
The kernel one component, and because the human-written source code is online, we can see it contains approximately 4,000,000 lines of source code. Given that a distribution of the GNU/Linux operating system, complete with applications, can contain software with more than 225 million lines of source code, when we extrapolate from the kernel numbers, we arrive at the possibility of 13,160 or 15,848 patent infringements per complete distribution.(ref-4) All of this in something that can be distributed once or a thousand times, usually at no cost, sometimes large corporations, sometimes by individuals.
This is a degree of uncertainty that can't be fixed by changes in evaluation standards.
As for innovation, lists and lists of research suggests that patents reduce software innovation.
There was a time when if you wrote something, you owned it, you could sell it, you could give it away. It could be put in the accounts and it could be used as the base for collaboration. Now, ownership of a piece of software is hopeful speculation. There is no reliable way to have a settled expectation regarding the boundaries or the extent to which you own a piece of software. This uncertainty, and this unfair regulation is what the Supreme Court has the chance to rid us of by giving the USPTO a reliable tool for excluding software ideas from patentable subject matter.
— Ciarán O'Riordan is Exective Director of End Software Patents