Stallman: Why software patents are a special case

Part III: Writing software is like writing a symphony, says Richard Stallman, founder of the Free Software Foundation. Just imagine if music could be patented...
Written by Matt Loney, Contributor
In the third part of his speech at the Cambridge Computer Lab, Richard Stallman explains why building software is not like building physical projects, and offers two solutions to the problem of software patents: one for Europe where software patents are not widely granted and one for the US where the situation already seems to be out of control. Software patents: Should there be a special case?
Stallman: Now, people used to say to me, "Well, there are patents in other fields, why should software be exempt?" Note the bizarre assumption in there, that somehow we are all supposed to suffer through the patent system. It is like saying "Some people get cancer. Why should you be exempt?" As I see it, each person who doesn't get cancer is good.

But there is, behind that, a less biased question, a good question, which is: Is software different from other fields? Should patent policy be different in different fields? If so, why?

Let me address that question: patents relate to different fields differently because in different fields patents relate to products differently.

On one extreme we have pharmaceuticals where a given chemical formula would be patented, so that patent covers one and only one product. Some other product wouldn't be covered by the existing patent. If there is to be a patent for this new product, the patent holder would be whoever developed the new product.

This fits in with the naive idea of the patent system that we have, that if you are designing a new product, you are going to get "the patent". The idea that there is one patent per product and that it covers the idea of the product. In some fields it is closer to being true. In other fields it is further from being true.

[The software field is at that extreme.] This is because software packages are usually very big. They use many different ideas in a new combination. If the program is new and not just copied, then it is probably using a different combination of ideas -- combined, of course, with newly written code, because you can't just magically say the names of these ideas and have them work. You have to implement them all. You have to implement them all in that combination.

The result is that even when you write a program, you are using lots of different ideas, any one of them might be patented by somebody. A pair of them may be patented as a combination by somebody. There might be several different ways of describing one idea which might be patented by various different people. So there are possibly thousands of things, thousands of points of vulnerability in your program, which might be patented by somebody else already.

This is why software patents tend to obstruct the progress of software -- the work of software development. If it were one patent-one product, then these patents wouldn't obstruct the development of products because if you develop a new product, it wouldn't be patented by somebody else already. But when one product corresponds to many different ideas combined, it gets very likely your new product is going to be patented by somebody else already.

In fact, there is economic research now showing just how imposing a patent system on a field where there is incremental innovation can retard progress. You see, the advocates of software patents say "Well, yes, there may be problems, but more important than any problems, the patents must promote innovation, and that is so important it doesn't matter what problems you cause". Of course, they don't say that out loud because it is ridiculous, but implicitly they want you to believe that as long as it promotes progress, that outweighs any possible cost. But actually, there is no reason to believe it does promote progress. We now have a model showing precisely how patents can retard progress. The case where that model can fit describes the software field pretty well; incremental innovation.

Why is software on that extreme of the spectrum? The reason is that in software we are developing idealised mathematical objects. You can build a complicated castle and have it rest on a thin line and it will stay up because it doesn't weigh anything. In other fields, people have to cope with the perversity of matter -- of physical objects. Matter does what it is going to do. You can try to model it, (but) if the actual behaviour doesn't fit the model then tough on you, because the challenge is to make physical objects that really work.

If I wanted to put an 'If' statement in a 'While' statement, I don't have to worry about whether the 'If' statement will oscillate at a certain frequency and rub against the 'While' statement and eventually they will fracture. I don't have to worry whether it will oscillate at a certain higher frequency and induce a signal in the value of some other variable. I don't have to worry about how much current that 'If' statement will draw, and whether it can dissipate the heat there inside that 'While' statement. Whether there will be a voltage drop across the 'While' statement that will make the 'If' statement not function. I don't have to worry that if I run this program in a salt water environment, the salt water may get in between the 'If' statement and the 'While' statement and cause corrosion.

I don't have to worry when I refer to the value of a variable whether I am exceeding the fan-out limit by referring to it 20 times. I don't have to worry how much capacitance it has and whether there has been sufficient time to charge up the value. I don't have to worry when I write the program, about how I am going to physically assemble each copy and whether I can manage to get access to put that 'If' statement inside the 'While' statement. I don't have to worry about how I am going to gain access in case that 'If' statement breaks, to remove it and replace it with a new one. [There are] so many problems that we don't have to worry about in software. That makes it fundamentally easier. It is fundamentally easier to write a program than to design a physical object that's going to work.

This may seem strange because you have probably heard people talking about how hard software is to design and how this is a big problem and how we are going to solve it. They are not really talking about the same question as I am. I am comparing physical and software systems of the same complexity, the same number of parts. I am saying the software system is much easier to design than the physical system. But the intelligence of people in these various fields is the same, so what do we do when we are confronted with an easy field? We push it further! We push our abilities to the limit. If systems of the same size are easy, let's make systems which are ten times as big, then it will be hard! That's what we do: we make software systems which are far bigger in terms of number of parts than physical systems.

A physical system whose design has a million different pieces in it is a mega project. A computer program whose design has a million pieces in it is maybe 300,000 lines; a few people will write that in a couple of years. That is not a particularly giant program. GNU Emacs now has several million pieces in its design, I think. It has a million lines of code. This is a project done with essentially no funding whatsoever, mostly done by people in their spare time.

There is another big saving. If you have designed a physical product, the next thing you have to do is design the factory to make it. To build this factory may cost millions or tens of millions, whereas to make copies of the program you just have to type 'copy'. The same copy command will copy any program. You want copies on CD, then fine, You burn a master CD and send it off to a CD plant. They will use the same equipment which will copy any contents on a CD. You don't have to build a factory to make this product.

There is tremendous simplification and tremendous reduction in costs of designing things. The result is, say for an automobile company, who will spend 50 million dollars to build a factory, to build a new model of auto, they can hire some lawyers to cope with patent licence negotiations. They can even cope with a law suit if they wanted to.

To design a program of the same complexity may cost 50 thousand or 100 thousand dollars. By comparison, the cost of dealing with the patent system is crushing. Or actually designing a program with the same complexity as the mechanical design of an auto is probably a month's work. How many parts does an auto have...that is, if it is an auto which doesn't have computers in it. That is not to say designing a good one is easy, but just that there are not that many different things in it.

The result is software really is different from other fields because we are working with mathematical stuff designing something is far, far easier and the result is that we regularly make systems which are much, much larger and do so with just a few people. The result is that instead of being close to one product-one patent, we are in a system where one product involves many, many ideas which could be patented already.

The best way to explain it by analogy is with symphonies. A symphony is also long and has many notes in it, and probably uses many musical ideas. Imagine if the governments of Europe in the 1700's had decided they wanted to promote the progress of symphonic music by establishing a European musical patent office that would give patents for any kind of musical ideas which you could state in words. Then imagine it is around 1800 and you are Beethoven and you want to write a symphony. You will find that getting your symphony so that it doesn't infringe any patents is going to be harder than writing a good symphony.

When you complain about this, the patent holders would say "Aw Beethoven, you are just bitching because you have no ideas of your own. All you want to do is rip off our inventions". Beethoven, as it happens, had a lot of new musical ideas -- but he had to use a lot of existing musical ideas in order to make recognisable music, in order to make music that listeners could possibly like, that they could recognise as music. Nobody is so brilliant that he can re-invent music [completely different] and make something that people would want to listen to. Pierre Boulez said he would try to do that, but who listens to Pierre Boulez?

Nobody is so brilliant he can re-invent all of computer science, completely new. If he did, he would make something that the users would find so strange that they wouldn't want to use it. If you look at a word processor today, you would find, I think, hundreds of different features. If you develop a nice new innovative word processor, that means there are some new ideas in it, but there must be hundreds of old ideas in it. If you are not allowed to use them, you cannot make an innovative word processor. Because the work of software development is so big, the result is that we don't need any artificial scheme to incentivise new ideas. You just have people writing software and they will have some new ideas. If you want to write a program and you want to make it good, some ideas will come to you and some you will see a way to use.

What used to happen -- because I was in the software field before there were software patents -- was most of the developers would publish any new ideas that they thought were noteworthy, that they thought that they might get any credit or respect for. The ideas that were too small or not impressive enough, they would not publish because that would be silly. Now the patent system is supposed to encourage disclosure of ideas. In fact, in the old days, nobody kept the ideas secret. They kept the code secret, it's true. The code, after all, represented the bulk of the work. They would keep the code secret and publish the ideas so that way the employees would get some credit and feel good. After software [patents], they still kept the code secret and they patented the ideas, so in fact, disclosure has not been encouraged in any meaningful sense. The same things are kept secret now as what were kept secret before, but the ideas which used to be published so that we could use them are now likely to be patented and off-limits for 20 years.

What can a country do to change this? How should we change the policy to solve this problem?

There are two places you can attack it. One is the place where patents are being issued, in the patent office. The other is where patents are being applied. That is a question of what does a patent cover.

One way is to keep a good criterion for issuing patents. This can work in a country which has not authorised software patents before, for instance, for the most part, in Europe. Simply to clearly re-enforce the European Patent Office's rules which say that software is not patentable. This is a good solution for Europe. Europe is now considering a directive on software patents. (The directive I suppose may be broader than that, but one of its important implications is for software patents.) Simply by modifying this to say software ideas cannot be patented will keep the problem out of Europe for the most part, except for some countries that may have admitted the problem on their own. Unfortunately one of them being the UK (Unfortunately for you.)

That approach won't work in the US The reason is that the U.S already has large numbers of software patents, and any change in the criteria for issuing patents won't get rid of the existing ones. In fact, these patents are not officially labeled as software patents. I say software patents but what do I really mean? Patents which might potentially apply to software, patents which might potentially get you sued for writing software. The patent office doesn't divide patents into software patents and other patents. So, in fact, any patent might conceivably get you sued for writing software if it could apply to some software. So, in the US, the solution would have to be done through changing the applicability, the scope, of patents, saying that a pure software implementation running on general purpose computer hardware which does not in itself infringe the patent is not covered by any patent, and you cannot get sued for it. That is the other kind of solution.

The first kind of solution, the solution that operates on what types of patents can be valid, is a good solution for Europe to use.

When the US started having software patents, there was no political debate. In fact, nobody noticed. The software field, for the most part, didn't even notice. There was a Supreme Court decision in 1981 which considered a patent on a process for curing rubber. The ruling was that the fact that the apparatus included a computer and a program as part of the process to cure the rubber didn't make it unpatentable.

The next year, the appeals court which considers all patent cases reversed the quantifiers: they said the fact that there is a computer and a program in this makes it patentable. The fact that there is a computer and program in anything makes it patentable. This is why the U.S started having business procedure patents: because the business procedures were carried out on a computer and that made them patentable.

So this ruling was made, and I think the natural order recalculating patent was one of the first or might have been even the first.

Throughout the 80's, we didn't know about this. It was around 1990 that programmers in the US started to become aware that they were faced with a danger from software patents. So I saw how the field worked before and how the field worked after. I saw no particular speed up in progress after 1990.

There was no political debate in the US, but in Europe there has been a big political debate. Several years ago there was a push to amend the Munich treaty that established the European Patent Office. It has a clause saying that software is not patentable. The push was to amend that to start allowing software patents. But the community took notice of this. It was actually free software developers and free software users who took the lead. [But] we are not the only ones threatened by software patents. All software developers are threatened by software patents, and even software users are threatened by software patents.

For instance, Paul Heckel, when Apple wasn't very scared of his threats, he threatened to start suing Apple's customers. Apple found that very scary. They figured they couldn't afford to have their customers being sued like that, even if they would ultimately win. So the users can get sued too, either as a way of attacking a developer or just as a way to squeeze money out of them on their own or to cause mayhem. All software developers and users are vulnerable.

But it was the free software community in Europe that took the lead in organising opposition. In fact, twice now the countries that govern the European Patent Office voted not to amend that treaty. Then the E.U. took a hand and the Directorates of the E.U were divided on the issue. The one whose job is to promote software is against software patents it seems. They were not in charge with this issue. It is the Open Market Directorate who is in charge, and is run by somebody who is in favour of software patents. They basically disregarded public opinion which has been expressed to them. They have proposed a directive to allow software patents. The French government has already said they are against it.

People who are working [on] various other governments in Europe to oppose software patents, and it is vital to start doing so here. According to Hartmut Pilch, who is one of the leaders in the European struggle against software patents, the main impetus comes from the UK Patent office. The UK patent office is simply biased in favour of software patents. It had a public consultation, and most of the responses were opposed to software patents. They then wrote a report saying people seem to be content with them, completely disregarding the answers. You see, the free software community said, "Please send the answers to them and to us too." So they published these answers which were generally opposed. You'd have never guessed that from the report that the UK patent office published.

They use a term that they call "technical effect". This is a term which can stretch tremendously. You are supposed to think it means a program idea would only be patentable if it only relates to specific physical acts. If that is the interpretation, it would mostly solve the problem. If the only software ideas which can be patented were those that really did relate to a particular technical, specific physical result that you might have patented if you didn't use a program, that would be OK. The problem is that you can stretch that term. You can describe the result you get by running any program as a physical result. How does this physical result different from any other? Well it is as a result of this computation. The result is that the UK patent office is proposing something that looks like it leads to mostly solving the problem and really gives carte blanche for patenting almost anything.

The people in the same ministry are also involved in the copyright issue, which really has nothing to do with software patents except that it is being handled by the same people. It is a question of interpreting the recent E.U copyright directive, a horrible law like the DMCA in the US, but there is some latitude for countries to decide how to implement it. The UK is proposing the most draconian possible way of implementing this directive. You could greatly reduce the harm it does by implementing it properly. The UK wants to maximise the tyrannical effect of this directive. It seems there is a certain group -- The Department of Trade and Industry? -- Who need to be reined in. It is necessary to put a check on their activities, stop their creating new forms of power.

Software patents tie up every software developer and every computer user in a new in a new form of bureaucracy. If the businesses that use computers realised how much trouble this can cause for them, they would be up in arms, and I am sure they can stop it. Business doesn't like being tied up in bureaucracy. Sometimes, of course, it serves an important purpose. There are some areas where we wish the UK government did a more careful job in tying certain businesses up in bureaucracy, like when it involves moving animals around. But in cases when it doesn't serve any purpose except to create artificial monopolies so that somebody can interfere with software development, squeeze money out of developers and users, then we should reject it. We need to make management aware of what software patents will do to them, get their support in fighting against software patents in Europe.

The battle is not over. It still can be won.

Previous page: Three ways to deal with software patent threats First page: Why software patents are a bad idea

Copyright 2002 Richard Stallman
Verbatim copying and distribution are permitted without royalty in any medium provided this notice and the copyright notice are preserved.

Editorial standards