Skip to content, sitemap or skip to search.

Personal tools
Join now
You are here: Home Bulletins Bulletins from 2009 Fall 2009 End Software Patents

End Software Patents

by root Contributions Published on Dec 18, 2009 03:36 PM
by Ciaran O'Riordan, End Software Patents

The Bilski case is the first review of patentable subject matter since 1981. This decision could make the rules for decades to come and the justices' comments at the November 9th hearing indicate that they do see problems with the patenting of software. This hands us our biggest opportunity, and a heavy responsibility.

Some legal experts have speculated that the ruling will be handed down in early Spring 2010. Others have suggested that whatever the result, legislative change will be proposed. The ongoing Supreme Court case makes it easier for us to raise media interest in this topic, and if it comes to legislation, we're going to need broad public support for abolition of software patents. In the next three months, we have a unique chance and a need to build a groundswell for abolition of software patents in the USA. That's where we need you.

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?

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, the array of big and small companies describes how products are made. If this were true for software, then the decision of patentability would only have economic implications, and patents would only raise economic problems. 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 folks that keep the emails flowing, who write internal software, extend software bought by the company, and who run the Web site. 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 impractical to require them to work within the slow patent system and bear the legal and financial risks involved. Obviously, patent incentives are not necessary to motivate IT departments to fix problems. Further, when a company manager reports a Web site 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 or a cease-and-desist letter from a patent holder because of the way in which the IT department happened to fix the problem.

A second issue is that applying industrial regulations to activities people do for fun or for the benefit of their community is unjust. For user communities programming to suit their own needs, the veto power that the patent holder gains over distribution of the software is far too powerful. If the software is written for the purpose of having a freely redistributable program, then this third-party veto can spoil the developer's efforts at any moment. There will be no direct profits from which to offer royalty payments, so the result is a lose-lose situation where the developer's work is destroyed, and there was never even anything to gain 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).

In software, rather than supporting innovators, patents protect the old against the new.

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 the developer of physical products 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. An innovative word processor that can't read any existing documents is simply useless, and any innovations therein are thus wasted effort.

For video, the standards problem is very real. 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 license available for freely redistributable software, and even royalty payers have to agree to MPEG-LA's terms. The committee developing the next standard for Web pages, 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.

Now, it's important to look at the output of the mentioned user communities. If like, say, hobbyist watchmakers, they just catered for themselves and a few friends, or a small enough clientele that didn't attract 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.

However (as supporters of the FSF know), freely redistributable software and the work that was begun by idealists and hobbyists has now lead to the world's most used Web server, 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 stifles competition and the mass production of useful software. Lists and lists of research suggests that patents reduce software innovation.

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.

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. Thereafter, Microsoft in 2007 began claiming that the kernel violates 235 of its patents -- although the patents have never been specified. Neither could be precise, but they give us ballpark figures.

The kernel is one component, and because the human-written source code is online, we can see it is approximately 4,000,000 lines long. 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. All of this in something that can be distributed once or a thousand times, usually at no cost, sometimes by large corporations, sometimes by individuals.

This is a degree of uncertainty that can't be fixed by changes in evaluation standards.

There was a time when if you wrote something, you owned it. You could distribute it, you could use it as a starting point for collaboration. Whether the ownership is a good or bad thing for society depends on what freedoms you grant the recipients, but at least those who did the right thing had legal certainty. 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. The Supreme Court now has the chance to rid us of this uncertainty and this unfair regulation, by giving the United States Patent and Trademark Office a reliable tool for excluding software ideas from patentable subject matter. You can support our efforts and follow ongoing news as the Bilski case unfolds at

Document Actions

The FSF is a charity with a worldwide mission to advance software freedom — learn about our history and work. is powered by:


Send your feedback on our translations and new translations of pages to