Richard Stallman
Speech given at Model Engineering College, Government of Kerala, India, 2001 (audio recording)
Prof. Jyothi John, Head of Computer Engineering Department introduces Stallman:
It's my privilege and duty to welcome the most distinguished guest ever we had in this college.
Mr. Richard Mathew Stallman launched the development of the GNU operating system in 1984, the goal being to create a completely free Unix-like operating system. The organization that was founded in 1985 to further this purpose is the Free Software Foundation.
Stallman is a visionary of computing in our times, and is the genius behind programs such as Emacs, GCC, the GNU debugger and more. Most importantly, he's the author of the GNU General Public License, the license under which more than half of all free software is distributed and developed. The combination of GNU with Linux, the kernel, called the GNU/Linux operating system, now has an estimated twenty million users worldwide.
Stallman's concept of free software talks about freedom, rather than about price. His ideas go a long way into ensuring development of software for the welfare of society, collectively developed by programmers who do not “lock up” their work, but rather release it for others to study, modify and redistribute.
Stallman received the Grace Hopper award from the Association for Computing Machinery for 1991, in 1990 he was awarded MacArthur Foundation Fellowship — other recipients of this prestigious award include Noam Chomsky and Tim Berners-Lee. In 1996, an honorary doctorate of Technology from the Royal Institute, Sweden was awarded to him. In 1998, he received the Electronic Frontier Foundation's Pioneer award, along with Linus Torvalds. In 1999 he received the Yuri Rubinski Memorial award.
Today, Stallman will be talking about the danger of software patents. In fact this is one of the most important aspect of the freedom of programming because the aspect of software patents may make all programmers potential lawbreakers because unknowingly they may be violating some of the patents registered by some other company.
After that introduction, I am sure many of you want to know about free software. But unfortunately that's not what I am supposed to speak about. In fact, this topic, software patents, is not very closely related to the issue of free software. Software patents are a danger that affect all programmers and all computer users. I found out about them, of course, in working on free software because they are a danger to my project as well as to every other software project in the world.
There is a very unfortunate phrase that you may have heard. It is the phrase “intellectual property.” Now, there are two things wrong with this phrase.
One — it prejudges the most important policy question about how to treat some kind of ideas or practices or works, or whatever. It assumes that they are going to be treated as some kind of property. Now, this is a public policy decision and you should be able to consider various alternatives to choose the best one. Which means you shouldn't name the whole field, name the question with a term that prejudges what kind of answer you use.
But second and even more fundamental, that term is actually a catchall for totally different areas of law, including copyrights, patents, trademarks, trade secrets and various other things as well. Now these areas of the law in fact have almost nothing in common. What the laws say is totally different from one to the next. Their origins are completely independent and the public policy issues they raise are completely different. So, the only intelligent way to think about them is to pick one of them and think about it; think about them separately.
So the intelligent way to talk about them is never to generalize about them but to talk about a specific one, you know, talk about copyrights, or talk about patents, or talk about trademarks, but never lump them all together as intellectual property because that's a recipe for simplistic conclusions. It's almost impossible to think intelligently about “intellectual property” and so I refuse to do that. I just tell people why the term is a mistake, and then if you ask me for my opinion on copyrights or my opinion on patents, it will take me an hour to tell you it. But they are two different opinions, and my opinion about trademarks is something completely different as well.
So the most important thing for you to start with is never mix copyrights and patents as topics. They have nothing to do with each other. Let me tell you some of the basic differences between copyrights and patents:
There are many other differences as well. In fact every detail is different. So the worst thing you should ever do is learn something about copyrights and suppose that the same is true of patents. No, more likely it's not true of patents. If it's true of copyrights, it's not true for patents. That would be a better guideline if you have to guess.
Now most of the time when people describe how the patent system works, they are people with a vested interest in the system. And so they describe the patent system from the point of view of somebody who wants to get a patent and then point it at programmers and say “hand me your money.” This is natural, you know; when they sell lottery tickets, they talk about people who win, not people who lose. Of course most of the people lose, but they don't want you to think about that, so they talk about the ones who win. It's the same with patents. The patent system is a very expensive lottery for its participants. But of course, the people who run the system want you to think about the small chance you might win.
So to redress this imbalance, I am going to explain what the patent system looks like from the point of view of somebody who might be the victim of a patent; that is, somebody who wants to develop software. Suppose that you want to develop a program and you are in a country that has software patents. How do you have to deal with the patent system?
Well, the first thing is you have to find out about the patents that might potentially affect your area. This is impossible, because patents that are in the pipeline, being considered by the patent office, are secret. Well, in some countries they are published after 18 months but that still gives plenty of time for them to be secret. So you might develop a program this year, which is perfectly legal and safe this year. And then next year, a patent could be issued and all of a sudden you could be sued. It happens. Or your users could get sued.
For instance, in 1984 the Compress program was developed and, since it was free software, it was distributed by many companies along with Unix systems. Well, in 1985, a US patent was issued on the LZW compression algorithm used by Compress, and after a few years Unisys began squeezing money out of various companies.
Well, since we in the GNU project needed a data compression program and since we could not use Compress, we began looking for some other compression program. We found out about… Somebody came forward and said: “I have been working on this algorithm for a year and now I have decided I am going to contribute it to you, and here is the code.” We were a week away from releasing this program when I just happened to see a copy of the New York Times, which doesn't happen very often, and it just happened to have the weekly patents column and I noted it and so I read it. It said that somebody had got a patent for inventing a new method, a better method of data compression. Well, that was not in fact true. When I saw this, I thought we'd better get a copy of this patent and see if it's a problem, and it turned out to cover exactly the algorithm that we were about to release. So this program was killed one week before it was released. And in fact that person, that patent holder, had not invented a better method, because in fact it wasn't new. But that doesn't matter, he had a monopoly.
Eventually we found another compression algorithm which is used in the program that's known as GZIP. But this illustrates the danger that you face: even if you had unlimited resources, you couldn't find out about all the patents that might endanger your project. But you can find out about the issued patents because they are published by the patent office. So in principle, you could read them all, and see what they restrict, what they prohibit you from doing. Practically speaking though, once there are software patents there are so many of them that you can't keep up with them. In the US there are over a hundred thousand of them; maybe two hundred thousand by now. This is just an estimate. I know that 10 years ago they were issuing 10,000 a year and I believe that it has accelerated since then. So it's too much for you to keep track of them unless that's your full-time job. Now you can try to search for the ones that are relevant to what you are doing, and this works some of the time. If you search for certain keywords or follow links, you'll find some patents that are relevant to what you're doing. You won't find them all.
A few years ago somebody had a US patent — maybe it's expired by now — on natural order recalculation in spreadsheets. Now, what does this mean? It means the original spreadsheets did the recalculation always from top to bottom. Which meant that if a cell ever depended on a lower cell, then it wouldn't get recalculated the first time; you'd have to do another recalculation to get that one. Clearly it's better to do the recalculation in the order, you know. If A depends on B, then do B first and then do A. This way a single recalculation will make everything consistent. Well, that's what the patent covered.
Now, if you searched for the term spreadsheet, you would not have found that patent because that term did not appear in it. The phrase “natural order recalculation” didn't appear either. This algorithm — and it was indeed the algorithm that they covered, basically every imaginable way of coding this algorithm — the algorithm is called topological sorting, and that term did not appear in the patent either. It presented itself as a patent on a technique for compilation. So, reasonable searching would not have found this patent but it would still have been a basis to sue you.
In fact you can't tell what a software patent covers even roughly, except by studying it carefully. This is different from patents in other areas, because in other areas there is some physical thing happening, and the details of that physical thing usually give you a sort of anchor so that you can tell whether it relates or not. But in software there is no such thing, and so it's easy for two totally different ways of saying something to cover, in fact, the same computation, and it takes careful study to see that they cover the same one. Because of this, even the patent office can't keep track. So, there is not one, but two patents covering LZW data compression. The first one was issued in 1985 and I think the second one in 1989. But that one I think had been applied for even earlier. One of these patents belongs to Unisys and the other belongs to IBM.
Now, this kind of mistake is not in fact that rare. It's not the only one. You see, patent examiners don't have a lot of time to spend on one patent. In the US they have an average of 17 hours per patent. Now that's not enough to carefully study all the other patents in the area to see if they are really the same thing. So they are going to make this kind of mistake over and over.
So you won't find all the patents that might threaten you but you'll find some of them. Then what do you do? You have to try to figure out precisely what these patents prohibit. That is very hard, because patents are written in tortuous legal language which is very hard for an engineer to understand. You are going to have to work with a lawyer to do it.
In the 1980's the Australian government commissioned a study of the patent system — the patent system in general, not software patents. This study concluded that Australia would be better off abolishing the patent system because it did very little good for society and caused a lot of trouble. The only reason they didn't recommend that was international pressure. So one of the things they cited was that patents, which were supposed to disclose information so that it would no longer be secret, were in fact useless for that purpose. Engineers never looked at patents to try to learn anything, because it's too hard to read them. In fact they quoted an engineer saying “I can't recognize my own inventions in patent deeds.” Now this is not just theoretical.
A few years ago, an engineer in the US named Paul Heckel was suing Apple. He got a couple of software patents in the late 80's for a software package, and then when he saw Hypercard he looked at it and said “ this is nothing like my program,” and didn't think anymore of it. But then later on, his lawyer explained to him that if you read his patents carefully, Hypercard fell into the prohibited area. So he sued Apple, figuring this was an opportunity to get some money. Well, once when I gave a speech like this, he was in the audience, and he said “oh no that's not true, I just wasn't aware of the scope of my protection.” And I said “yeah, that's what I said.”
So you are going to have to spend a lot of time working with a lawyer and explaining to the lawyer what project you are working on, so the lawyer can explain to you what the patents imply. This is going to be expensive, and when you're done the lawyer will tell you something like this: “If you do something in this area, you are almost sure to lose a lawsuit. If you do something in this area, you are in a substantial danger, and if you really want to be safe you'd better stay out of this area, and, of course there is a substantial element of chance in the outcome of any lawsuit.” So now that you have a predictable terrain for doing business, what are you going to do?
Well, you have three options to consider:
Any one of these three is sometimes a viable alternative, and sometimes not.
First, let's consider avoiding the patent. Well, in some cases that's easy. You know, Unisys was threatening people using the patent on LZW compression; we just had to find another data compression algorithm and we could avoid that patent. Well, that was somewhat difficult because there were many other patents covering lots of other data compression algorithms. But eventually we found one that was not in the area that those others' patents cover; eventually we did. So that program was implemented. It actually gave better compression results and so we now have GZIP, and a lot of people use GZIP. So, in that one case it was considerable work but we were able to do it, to avoid that patent.
But in the 80's, CompuServe defined an image format called GIF and used LZW compression in defining it. Well, of course once the uproar about these patents became known, people defined another image format using a different compression algorithm. They used the GZIP algorithm, and that format is called PNG format, which I suppose means “PNG is Not GIF.”
But there was a problem: lots of people had already started using GIF format, and there were many programs that could display GIF format and produce GIF format and they couldn't display PNG format. So the result was people felt it was too hard to switch. You see, when you are dealing with a data compression program used by somebody who says “I want to compress some data,” well, you can give him a different data compression program; if he can get sued for using this one and you give him another one, he'll switch; but if what he wants to do is make images that can be displayed by Netscape, then he can't switch, unless Netscape handles the other format… and it didn't. It took years, I think, before Netscape started to handle PNG format. So people essentially said “I can't switch, I just have… ” And so the result was, society had invested so much in this one format, that the inertia was too great for a switch, even though there was another superior format available.
Even when a patent is rather narrow, avoiding it can be very hard. The PostScript specification includes LZW compression, which we in our implementation of postScript cannot implement. We support another kind of compression in some sense that is not correct, even though it does the useful job. So, even a narrow patent is not always feasible to avoid.
Now, sometimes a feature gets patented. In that case, you can avoid the patent by taking out that feature. In the late 80's the users of the word processor XyWrite got a downgrade in the mail. That word processor had a feature where you could define a short word or sequence as an abbreviation. Whenever you typed in that short sequence and then a space, it would turn into a longer expansion. You could define these any way you liked. Then somebody patented this, and XyWrite decided to deal with the patent by removing the feature. They contacted me because in fact I had put a feature like that into the original Emacs editor back in the 70's, many years before this patent. So there was a chance that I could provide evidence that would enable them to fight the patent.
Well, this showed me that I had at least one patentable idea in my life. I know because someone else patented it. Now, of course, you can respond to these patented features by taking the features out. But once your program starts being missing several features that users want, it might be useless as a program.
Now you may have heard of Adobe Photoshop. We have a program called the GIMP which is more powerful and general than Photoshop. But there is one important feature that it doesn't have which is Pantone color matching, which is very important for people who want to actually print the images on paper and get reliable results. This feature is omitted because it's patented. And as a result, the program for one substantial class of users is crippled.
If you look at programs today, you'll see that they often provide many features, and the users demand these features. If any important feature is missing, well, it's easy to leave it out, but the results may be very bad.
Of course, sometimes a patent is so broad that it's impossible to avoid it. Public key encryption is essential for computer users to have privacy. The whole field was patented. That patent expired just four years ago; there could be no free software in the US for public key encryption, until then: many programs, both free and nonfree, were wiped out by the patent holders. And in fact that whole area of computing was held back for more than a decade despite strong interest.
So, that is the possibility of avoiding the patent. Another possibility that is sometimes available is to license the patent. Now, the patent holder is not required to offer you a license that's his whim. The patent holder can say “I'm not licensing this, you're just out of business, period!”
In the League for Programming Freedom, we heard in the early 90's from somebody whose family business was making casino games — computerized of course — and he had been threatened by somebody who had a patent on a very broad category of computerized casino games. The patent covered a network where there is more than one machine, and each machine supports more than one kind of game and can display more than one game in progress at a time.
Now, one thing you should realize is the patent office thinks that it's really brilliant. If you see that other people implemented doing one thing and you decide to support doing two or more — you know, if they made a system that plays one game and if you make it able to play more than one game — that's an invention. If it can display one game and you decide to set it up so that it can display two games at once, that's an invention. If he did it with one computer and you do it with a network having multiple computers, that's an invention for them. They think that these steps are really brilliant.
Of course, we in computer science know that this is just a rule, you can generalize anything from one to more than one. It's the most obvious principle there is. Every time you write a subroutine, that's what you're doing. So this is one of the systematic reasons why the patent system produces, and then upholds patents that we would all say are ridiculously obvious. You can't assume, just because it's ridiculously obvious, that they wouldn't be upheld by a court. They may be legally valid despite the fact that are utterly stupid.
So he was faced with this patent and the patent holder was not even offering him the chance to get a license. “Shutdown!” is what the patent holder said, and that's what he eventually did. He couldn't afford to fight it.
However, many patent holders will offer you a chance of a license. But it will cost you dearly. The owners of the natural order recalculation patent were demanding five percent of the gross sales of every spreadsheet. And that, I was told, was the cheap pre-lawsuit price. If you insisted on fighting over the matter, they were going to charge more. Now you could, I suppose, sign a license like that for one patent, you could do it for two, you could do it for three. But what if there are twenty different patents in your program, and each patent holder wants five percent of the gross sales? What if there are twenty one of them? Then you are pretty badly screwed. But actually business people tell me that two or three such patents would be such a big burden that they would make the company fail in practice, even if in theory it might have a chance.
So, a license for a patent is not necessarily a feasible thing to do, and for us, free software developers, we're in an even worse position because we can't even count the copies, and most licenses demand a fee per copy, so it's absolutely impossible for us to use one of those licenses. You know, if a license charged one millionth part of a rupee for each copy, we would be unable to comply because we can't count the copies. The total amount of money, I might have in my pocket, but I can't count it so I can't pay it. So we suffer some special burdens occasionally.
But there is one kind of organization for which licensing patents works very well, and that is the large multinational corporations; the reason is that they own many patents themselves and they use them to force cross-licensing. What does this mean? Well, essentially the only defense against patents is deterrence: you have to have patents of your own, then you hope that if somebody points a patent at you, you will be able point a patent back and say “don't sue me, because I'll sue you.”
However, deterrence doesn't work as well for patents as it does with nuclear weapons, and the reason is that each patent is pointed in a fixed direction. It prohibits certain specified activities. So the result is that most of the companies that are trying to get some patents to defend themselves with, they have no chance of making this a success. They might get a few patents, you know. So they might get a patent that points there, and they might get a patent that points there. OK, and then, if somebody over here threatens this company, what are they going to do? They don't have a patent pointing over there, so they have no defense.
Meanwhile, sooner or later, somebody else will wander over there and the executive of the company will think “gee, we're not as profitable as I would like, why don't I go just squeeze some money out of them.” So they say first “we're getting this patent for defensive purposes,” but they often change their minds later when a tempting victim walks by.
And this, by the way, is the fallacy in the myth that the patent system “protects” the “small inventor.” Let me tell you this myth, it's the myth of the starving genius. It's somebody who has been working in isolation for years, and starving, and has a brilliant new idea for how to do something or other. And so, now, he's starting a company and he is afraid some big company like IBM will compete with him, and so he gets a patent and this patent is going to “protect him.”
Well, of course, this is not the way things work in our field. People don't make this kind of progress in isolation this way. They are working with other people and talking with the other people and they are developing software usually. And so the whole scenario doesn't make sense, and besides, if he was such a good computer scientist, there was no need for him to starve. He could have got a job at any time if he wanted.
But let's suppose that this happened, and suppose that he has his patent, and he says “IBM, you can't compete with me 'cause I've got this patent.” But here is what IBM says: “Well, gee, let's look at your product, hmm, I have this patent, and this patent and this patent and this patent and this patent that your product is violating. So how about if we cross-license?” And the starving genius says “hmm, I haven't got enough food in my belly to fight these things, so I'd better give in.” And so they sign a cross-license, and now guess what — IBM can compete with him. He wasn't protected at all!
Now, IBM can do this because they have a lot of patents. They have patents pointing here, here, here, everywhere. So, anybody from almost anywhere that attacks IBM is facing a stand-off. A small company can't do it but a big company can.
So IBM wrote an article. It was in Think magazine, I believe, issue number five, 1990 — that's IBM's own magazine — an article about IBM's patent portfolio. IBM said that it got two kinds of benefit from its 9000 active US patents. One benefit was collecting royalties from licenses. But the other benefit, the bigger benefit, was access to things patented by others. Permission to not be attacked by others with their patents, through cross-licensing. And the article said that the second benefit was an order of magnitude greater than the first. In other words, the benefit to IBM of being able to make things freely, not being sued, was ten times the benefit of collecting money for all their patents.
Now the patent system is a lot like a lottery, in that what happens with any given patent is largely random and most of them don't bring any benefits to their owners. But IBM is so big that these things average out over the scale of IBM. So you could take IBM as measuring what the average is like. What we see is — and this is a little bit subtle — the benefit to IBM of being able to make use of ideas that were patented by others is equal to the harm that the patent system would have done to IBM if there were no cross-licensing — if IBM really were prohibited from using all those ideas that were patented by others.
So what it says is: the harm that the patent system would do is ten times the benefit, on the average. Now, for IBM though, this harm doesn't happen, because IBM does have 9000 patents and does force most of them to cross-license, and avoids the problem. But if you are small, then you can't avoid the problem that way, and you will really be facing ten times as much trouble as benefit. Anyway, this is why the big multinational corporations are in favor of software patents, and they are lobbying governments around the world to adopt software patents and saying naive things like “this is a new kind of monopoly for software developers, it has to be good for them, right?”
Well, today, after you have heard my speech I hope you understand why that isn't true. You have to look carefully at how patents affect software developers to see whether they are good or bad, and explaining that is my overall purpose.
So, that is the possibility of licensing a patent. The third possible option is to go to court and challenge the validity of the patent.
Now the outcome of this case will depend largely on technicalities, which means essentially on randomness, you know. The dice were rolled a few years ago, and you can investigate and find out what the dice came up saying, and then you'll find out whether you've got a chance. So it's mainly historical accident that determines whether the patent is valid — the historical accident of whether, or precisely which things, people happen to publish, and when.
So, sometimes, there is a possibility of invalidating. So even if a patent is ridiculously trivial, sometimes there is a good chance of invalidating it and sometimes there is none.
You can't expect the courts to recognize that it is trivial, because their standards are generally much lower than we would think are sensible. In fact, in the United States, this has been a persistent tendency. I saw a Supreme Court decision from something like 1954, which had a long list of patents that were invalidated by the Supreme Court starting in the 1800's. And they were utterly ridiculous, like making a certain shape of doorknob out of rubber, when previously they'd been made out of wood. And this decision rebuked the patent system for going far, far away from the proper standards. And they just keep on doing it.
So you can't expect sensible results from that, but there are situations where, when you look at the past record, you see that there is a chance to invalidate a certain patent. It's worth the try, at least to investigate. But the actual court cases happen to be extremely expensive.
A few years ago, one defendant lost and had to pay 13 million dollars, of which most went to the lawyers on the two sides. I think only 5 million dollars was actually taken away by the patent holder, and so there were 8 million to the lawyers.
Now, these are your possible options. At this point, of course, you have to write the program. And there, the problem is that you face this situation not just once but over and over and over, because programs today are complicated. Look at a word processor; you'll see a lot of features, many different things, each of which could be patented by somebody, or a combination of two of them could be patented by somebody. British Telecom has a patent in the US on the combination of following hypertext links and letting the user dial up through a phone line. Now these are two basically separate things, but the combination of the two is patented.
So, that means if there are 100 things in your program, there are potentially some five thousand pairs of two that might be patented by somebody already, and there is no law against patenting a combination of three of them either. That's just the features, you know. There's going to be many techniques that you use in writing a program, many algorithms, they could be patented too. So there are lots and lots of things that could be patented. The result is that developing a program becomes like crossing a field of land mines. Sure, each step probably will not step on a patent, each design decision. Chances are it will be safe. But crossing the whole field becomes dangerous.
The best way for a nonprogrammer to understand what this is like is to compare the writing of these large programs with another area in which people write something very large: symphonies. Imagine if the governments of Europe in the 1700's had wanted to promote progress in symphonic music by adopting a system of music patents, so that any idea that could be described in words could be patented if it seemed to be new and original. So you'd be able to patent, say, a three-note melodic motif which is be too short to be copyrightable, but it would have been patentable. And maybe they could have patented a certain chord progression, and maybe patented using a certain combination of instruments playing at the same time, or any other idea that somebody could describe.
Well, by 1800 there would have been thousands of these music idea patents. And then imagine that you are Beethoven and you want to write a symphony. To write a whole symphony, you are going to have to do lots of different things, and at any point you could be using an idea that somebody else has patented. Of course, if you do that he'll say: “Oh! You are just a thief, why can't you write something original?” Well, Beethoven had more than his share of new musical ideas, but he used a lot of existing musical ideas. He had to, because that's the only way to make it recognizable. If you don't do that, people won't listen at all. Pierre Boulez thought he was going to totally reinvent the language of music, and he tried, and nobody listens to it, because it doesn't use all the ideas that they're familiar with.
So you have to use the old ideas that other people have thought of. Nobody is such a genius that he can reinvent the entire field of software and do useful things without learning anything from anybody else. So in effect, those people, the patent holders and their lawyers, they are accusing us of being cheaters because we don't totally reinvent the field from scratch. We have to build on previous work to make progress, and that is exactly what the patent system prohibits us from doing. And we have to provide features that the users are accustomed to and can recognize, or they'll find our software just too difficult to use no matter how good it is.
Now, people sometimes ask me: why is software different from other fields? Sometimes, of course they ask this in a rather nasty fashion, they say: “the other fields can deal with patents, why should software be an exception?” Now that's a nasty way of putting it because it's making the assumption that it's wrong to want to escape from a problem. I could imagine I am saying: “well, other people could get cancer, why shouldn't you?” Clearly, if it's a problem, enabling any field to escape is good. But it is a good and serious question: are these fields the same issue? Do patents affect all these fields the same way? Is the right policy for software the same as the right policy for automobile engines or pharmaceuticals or chemical processes, you know, this is a serious question which is worth looking at.
When you look at it, what you see is that the relationship between patents and products varies between the fields. At one extreme you have pharmaceuticals where typically a whole chemical formula is patented. So if you come up with a new drug, then it's not patented by somebody else. At the other extreme is software where, when you write a new program, you are combining dozens or hundreds of ideas, and we can't expect them all to be new. Even an innovative program, which has a few new ideas, has to use lots and lots of old ideas too. And in between you find the other fields. Even in other fields, you can get patent deadlock.
When the United States entered World War I, nobody in the US could make a modern airplane. And the reason was that modern airplanes use several different techniques that were patented by different companies, and the owners hated each other. So nobody could get a license to use all these patents. Well, the US government decided that this was an unacceptable state of affairs, and essentially paid those patent holders a lump sum and said “we have nationalized these patents; now, everybody, go make airplanes for us!”
But the amount to which this happens, the frequency and the seriousness of it varies according to how many different ideas go in one product. It varies according to how many points of patent vulnerability there are in one product. And in that question, software is at the extreme.
It's not unusual for a few people working for a couple of years to write a program that could have a million parts in it, different parts, which is maybe, say, 300,000 lines of code. To design a physical system that has a million different parts, that's a mega-project, that's very rare. Now you'll find many times people make a physical object with a million parts, but typically it's many copies of the same subunit and that's much easier to design — that's not a million different parts in the design.
So, why is this? The reason is that, in other fields, people have to deal with the perversity of matter. You are designing circuits or cars or chemicals, you have to face the fact that these physical substances will do what they do, not what they are supposed to do. We in software don't have that problem, and that makes it tremendously easier. We are designing a collection of idealized mathematical parts which have definitions. They do exactly what they are defined to do.
And so there are many problems we don't have. For instance, if we put an if statement inside of a while statement, we don't have to worry about whether the if statement can get enough power to run at the speed it's going to run. We don't have to worry about whether it will run at a speed that generates radio frequency interference and induces wrong values in some other parts of the data. We don't have to worry about whether it will loop at a speed that causes a resonance and eventually the if statement will vibrate against the while statement and one of them will crack. We don't have to worry that chemicals in the environment will get into the boundary between the if statement and the while statement and corrode them, and cause a bad connection. We don't have to worry that other chemicals will get on them and cause a short-circuit. We don't have to worry about whether the heat can be dissipated from this if statement through the surrounding while statement. We don't have to worry about whether the while statement would cause so much voltage drop that the if statement won't function correctly. When you look at the value of a variable you don't have to worry about whether you've referenced that variable so many times that you exceed the fan-out limit. You don't have to worry about how much capacitance there is in a certain variable and how much time it will take to store the value in it.
All these things are defined a way, the system is defined to function in a certain way, and it always does. The physical computer might malfunction, but that's not the program's fault. So, because of all these problems we don't have to deal with, our field is tremendously easier.
If we assume that the intelligence of programmers is the same as the intelligence of mechanical engineers, and electrical engineers and chemical engineers and so on, what's going to happen? Those of us with the easiest field, fundamentally, are going to push it further. We make bigger and bigger things and eventually it becomes hard again. That's why we can develop much bigger systems than the people in the other fields. They just have these hard problems to deal with all the time. In the other fields, it may be necessary to develop an idea. You may have the idea, but then you may have to try out lots of different ways to get it to work at all. In software it's not like that, you have the idea and what you go and do is you write a program which uses this idea, and then the users may like it or not. And if they don't like it, probably you can just fix some details and get it to work.
There is another problem that we don't have to worry about: manufacturing of copies. When we put this if statement inside the while statement, we don't have to worry about how the if statement is going to be inserted into the while statement as a copy is being built. We don't have to worry either about making sure we have access to remove and replace this if statement if it should burn out. So all we have to do is type “copy” and it's an all-purpose copy-anything facility. People making physical equipment and physical products, they can't do that, these things have to be built piece by piece each time.
The result is that for them, the cost of designing a system of a certain complexity may be (gesturing) this much and the factory may take this much to set up. So they have to deal with this much from the patent system. It's a level of overhead they can live with. For us, designing it may cost (gesturing) this much and manufacturing it may cost this much, so this much overhead from the patent system is crushing.
Another way to look at it is that because we can — a few of us can — make a much bigger system, there are many more points of vulnerability where somebody might have patented something already. We have to walk a long distance through the mine field, whereas they they only have to walk a few feet through the minefield. So it's much more of a dangerous system for us.
Now, you have to realize that the ostensible purpose of the patent system is to promote progress. This is something that is often forgotten because the companies that benefit from patents like to distract you from it. They like to give you the idea that patents exist because they deserve special treatment. But this is not what the patent system says. The patent system says: the goal is to promote progress for society, by encouraging certain behavior like publishing new ideas; and after a certain — originally that was fairly short — time, everyone could use them.
Of course there is a certain price that society pays as well, and so we have to ask the question: which is bigger, the benefit or the price? Well, in other fields, I am not sure. I am not an expert on other fields of engineering, I've never done them and I don't know whether having patents is good for progress in those fields.
I have been in software since before software patents existed, and I know that software patents do a lot of harm and essentially no good. In the old days, ideas came along. Either people in a university had an idea, or somebody had an idea while he was working on developing software. And either way, these ideas got published, and then everyone could use them. Now why did the software publishers publish these ideas? Because they knew that the big job was writing the program.
They knew that publishing the ideas would get them credit from the community, and meanwhile anybody else who wanted to compete with them would still have to write a program, which is the big job. So they typically kept the details of the program secret — of course some of us think that's wrong, but that's a different issue. They kept the details of the program secret and they published the ideas, and meanwhile the software development — because software development was going on — That provided the field with a steady stream of ideas, so ideas were not the limiting factor. The limiting factor was the job of writing programs that would work and that people would like using.
So, in effect, applying the patent system to software focuses on facilitating a thing which is not the limiting factor, while causing trouble for the thing which is the limiting factor. You see the software patents encourage somebody to have an idea, but at the same time they encourage people to restrict its use, so in fact we are actually worse off now in terms of having ideas we could use, because in the past people had the ideas and published them and we could use them, and now they have the ideas and patent them and we can't use them for twenty years. In the mean time, the real limiting factor — which is developing the programs — this is hampered by software patents because of other dangers that I explained to you in the first half of this talk.
So the result is that, while the system is supposed to be promoting progress in software, actually it is so screwed up it's just obstructing progress.
Today we have some economic research showing mathematically how this can happen. You can find it in www.researchoninnovation.org. I am not completely sure of the name of the paper, but it's one that shows that in a field where incremental innovation is typical, having a patent system can result in slower progress. In other words the system produces counter-intuitive results that are the opposite of what it was intended to do. This backs up the intuitive conclusion of every programmer who sees that software patents are absurd.
So, what can a country do to avoid this problem? Well, there are two approaches: one is to address the problem at the issue of granting patents, and the other is to approach it at the point where patents are being enforced.
Doing this at the stage of granting patents is not quite as easy as you might think. Now, I have been talking about software patents but strictly speaking you can't classify patents into hardware patents and software patents, because one patent might cover both hardware and software. So in fact my definition of a software patent is: a patent that can restrict software development.
And if you look at many software patents you often find that the system they describe has a large part of the computer itself as part of the description of what's going on. That's a great way of making the whole thing seem complicated when it is really trivial. So it's a way they can get the patent office to decide it's unobvious.
But there is a different criterion that can be used, a slightly different place to draw the line that still does a reasonable job, and that is between processes that transform matter in a specific way, and processes where the result is just calculation and display of information, or a combination of data processing and display steps — or others have put it as: mental steps being carried out by equipment. There are various ways of formulating this, which are more or less equivalent.
Now this is not exactly the same as prohibiting software patents, because in some cases computers are used as part of specific physical equipment to make it do a specific thing. And software patents might be allowed if they are part of a specific physical activity. But that's not really a disaster. After all, once people are involved in a specific physical activity or a specific physical product, they are bringing into their whole business all those complexities of dealing with matter. So it's more like those other fields of engineering. Maybe it's okay to have patents on that narrow kind of software. As long as we can keep the core areas of software, the purely software activities safe from patents, we have solved the bulk of the problem.
So that is a feasible approach and that's what people are working towards in Europe. However, that is not going to be any use in the United States because the United States already has tens of thousands, probably hundreds of thousands of software patents. Any change in the criteria for issuing patents does not help at all with the patents that already exist.
So what I propose to the United States is to change the criteria for applying patents, to say that purely software systems running on general purpose computing hardware are immune from patents. They by definition cannot infringe a patent. And this way the patents can still be granted exactly the way they are now, and they can still, in a formal sense, cover both hardware implementations and software implementations as they do now. But software will be safe.
That's the solution I propose to the US, but it could be used in other countries as well.
Now, one of the tremendous dangers facing most countries today is the World Trade Organization, which sets up a system of corporate regulated trade — not free trade as its proponents like to call it, but corporate regulated trade. It replaces the regulation of trade by governments, that are somewhat democratic and might listen to the interest of their citizens, with regulation of trade by businesses, which don't pretend to listen to the citizens. So it's fundamentally antidemocratic and ought to be abolished.
But it's crucial to note that the part of the GATT agreement which deals with patents does not require software patents. Many experts who have studied this, for instance in Europe, make this claim. And the reason is that they interpret technical effect as: there is a specific physical consequence or physical system going on. And so the software that doesn't do that doesn't have to be in the domain that patents can cover.
So, at least you don't have to worry about the Word Trade Organization causing problems here, despite the tremendous problems they cause in other areas of life.
Preventing India from having software patents will be up to you — to the citizens of India. I am a foreigner, I have no influence except when I can convince other people through the logic of what I say. There is a chance that you can do this. When the US started to have software patents, the public policy question was not considered at all. Nobody even asked whether it was a good idea to have software patents. The Supreme Court made a decision which was then twisted around by an appeals court, and ever since then, there were software patents.
But when Europe started to consider officially authorizing software patents a few years ago, public opposition started to rise and became so strong that the politicians and the parties began paying attention to it, and started saying they were against it. In fact two attempts to authorize software patents have been blocked already in Europe. The French Minister of Industry says that software patents would be a disaster and under no circumstances should they be allowed in France. All of the German political parties have taken a stand against software patents.
The battle is not yet over, you know. We have not conclusively blocked software patents in Europe, because the multinational companies and their servant, the United States government, is lobbying very hard, and they have ignorance on their side. It's so easy for somebody with a naive neo-liberal view to be persuaded that a new kind of monopoly has to be good!
You have to look at the details of how software patents affect software development to see that they cause a problem. You have to study that economic research in its mathematics in order to see why you shouldn't assume that patents always promote progress. So, it's easy for IBM to send a lobbyist to someone and say: “You should really adopt software patents, they are great for programming. And look, the US is ahead and the US has software patents. If you have software patents too, you might catch up.” Well, you can't get more dominant than that, and the US was ahead in computers before it had software patents, it can't be because of software patents.
It's important to understand that each country has its own patent system and its own patent laws and what you do in a certain country is under the jurisdiction of that country's patent law. So the result is, that if the US has software patents, the US becomes a sort of battleground where anybody using computers might get sued. If India avoids software patents, then India is not a battleground, and computer users in India do not face this danger of getting sued.
It turns out that each country will issue patents to foreigners, just as to its own citizens. So in fact, in a place which has this scourge of software patents, foreigners can own those patents. There are lots of non-US companies that own US software patents, so they are all welcome to get involved in the fighting in the US. Of course it's we Americans who become the victims of this. Meanwhile, in India, if there are no software patents, that means both Indian companies and foreign companies are prevented from coming into India and attacking people with software patents.
So, yes it is important that each country has its own patent law. That makes a big difference, but you've got to understand what difference it makes. Having software patents in a certain country is not an advantage for the developers in that country. It's a problem for anybody distributing and using software in that country.
Now, if you in India are developing a program for use in the US, you may face the problem — or at least your client will face the problem — of US software patents. At least probably you can't get sued here. The client who commissioned the program and tries to use it might get sued in the US, and indeed you will have to deal with the problem — the US's problems — when you try doing business in the US. But at least you'll be safe here. You know, at least it is a big difference between your client got sued because your client told you to make a product and that product is patented, versus you get sued for making that product.
If there are software patents in India, then you will get sued. Whereas in the current situation, at least you can say to the client: “You told us to make this and we made it. So, I'm sorry this happened to you but it's not our fault.” Whereas if there are software patents in India, you'll get sued yourself and there is nothing you can say about that.
So the ultimate conclusion is that software patents tie all software developers, all computer users and essentially all businesses in a new kind of bureaucracy, which serves no beneficial social purpose. So it's a bad policy and it should be avoided.
Businesses don't like bureaucracy. If businesses knew that they were threatened with a new kind of bureaucracy, they would oppose software patents very strongly. But most of them aren't aware of this.
In the US, software patents have led directly to business method patents. What does this mean? A business method is basically how you make decisions about what to do in the business. And in the past, these decisions were made by humans but now sometimes they are made by computers, and that means they are carried out by software, and that means the decision policies can be patented. Software patents imply business method patents and business procedure patents. The result is that any business could find itself, you know, once they decide “we're going to automate the way we carry out our procedures,” now they get sued with a software patent.
So if businesses only knew, they would be organizing through things like the chamber of commerce to demand opposition to software patents. But mostly they don't know, and therefore it's going to be your job to inform them. Make sure they understand the danger that they are facing.
And then India may be able, with the help of other countries like France and Germany, to reject software patents. It is important for people in the Indian government to make contact with officials in European countries, so that this battle against software patents doesn't have to be fought one country at a time, so that countries can work together to adopt an intelligent policy. Maybe there should be a no software patents treaty that various countries can sign and promise each other aid, when they are threatened by economic pressure from the United States, as part of its economic imperialism.
Because the United States likes to do that, you know. One of the provisions in the GATT agreement is that countries have the right to make compulsory licenses for making medicine, to address a public health crisis. And the South-African government proposed to do this for medicine against AIDS. Now, South-Africa has a very bad problem with AIDS; the figures I've heard was that a quarter of the adult population is infected. And of course, most of them can't afford to buy these medicines at the prices charged by the US companies.
So the South-African government was going to issue compulsory licenses which, even under GATT, it's allowed to do. But the US government threatened economic sanctions. Vice-President Gore was directly involved with this. And then, about a year before the presidential election, he realized that this was going to look bad, so he dropped out of the effort.
But this kind of thing is what the US government does all the time in regard to patents and copyrights. They don't even mind if people get patented to death.
So it's important for countries to work together against this.
For more information about the problem of software patents, see www.progfree.org [archived] and www.ffii.org. And there is also a petition to sign, www.noepatents.org [1]
Please talk with all executives of businesses — any kind of businesses — about this issue. Make sure they understand the extent of the problems they face, and that they think of going to business organizations to have them lobby against software patents.
Now I'll answer questions.
Oh, by the way to any journalists who are here, I recommend writing articles about software patents separately from articles about free software. If you cover them in one article together, people may get the idea that software patents are only bad for free software developers and they are okay for other software developers. This is not true. If you think back of what I have said, hardly any of it relates to the question of whether the programs are free or not; the dangers are the same for all software developers. So please don't take the risk, the people will get confused. Write separate articles.
To develop nontrivial programs you're going to have to infringe patents of IBM's. Now if you are big and often lucky enough, you might have some patents of your own and make IBM cross-license with you. Otherwise you are completely at their mercy and you have to hope that they just let you pay the money.
Is someone else asking?
Most programmers don't agree with you.
That's the way it was before software patents. If you wrote the program yourself there was nothing to sue you about. Today you can write the program yourself, it may even be a useful and innovative program, but because you didn't reinvent the whole field, you use some ideas that were already known, other people sue you. Now, of course, those people who wanna go around suing you, they are going to pretend that this extortion is protection for them. Protection from what? Protection from having competitors, I guess. They don't believe in competition, they want monopolies.
Well, to hell with them. It's not good for the public that they should get what they want. This is a question of public policy. We have to decide what is good for the citizens generally.
Audience: [applause]
Not have somebody saying “I wanna have a monopoly because I think I am so important I should have one, so protect me from anybody else being allowed to develop software.”
So you shouldn't try to have an opinion about intellectual property. If you are thinking about intellectual property, you are thinking at a simplistic level. And any conclusions you reach will be simplistic. So, do as I do, you know, pick one topic at a time and focus on it, and find out the details about that one area, then you can think intelligently about that area, and later on you can think intelligently about the other areas too.
First, make it clear that ordinary patents do not apply, and second, if you wish, you could create a different system of five-year software idea monopolies. Well, it's not clear that there is any particular benefit in these five-year software monopolies but it would be much better than the current situation. So if you found the government prepared to make this deal, well, I would say, we should take it. But, but we have to realize, though, that the first step is to abolish software patents strictly speaking, and that has to be part of this deal.
Okay, if you gonna pass a note, you'd better read it out loud. Any other questions?
Now in India you have probably taken for granted that you are safe from that. But that will only last as long as there are no software patents in India.
The point is, therefore, let we try not to hand them that opportunity. For instance, we don't have a government agency handing out guns to people on the street, and we should not have a government agency handing out software patents to people on the street either.
Now we collected examples of this, and we are looking for people to write them up — you know, to look at each example and investigate it fully and write down a clear description of what happened and what the harm was and so on. We have had trouble finding people to do this. We're looking for more. So someone who is really good at writing clear English might want to volunteer for this.
So it looks like we have now moved to free software questions. I'd like to remind people that, until this last answer, I was not speaking for the Free Software movement. I was speaking about something of vital interest to every programmer which is: to be free to write programs and not get sued for having written them, as long as you wrote it yourself. And that is a freedom that you've taken for granted until now, and it's a freedom you will lose if you have software patents.
Now however we're moving to the topic of free software, which is what I spent most of my time working on, and the individual, the actual software development project that I've lead, which is developing the GNU operating system, which is a free software, Unix-like operating system used by some twenty million people estimated today. So I am now going to start answering questions about free software and GNU.
I can't tell you what's going to happen. What I can tell you is that when IBM claims to have put a billion dollars into the GNU plus Linux operating system, that is not entirely true. You have to look carefully at what they're spending this money on, and you'll find they are spending this money on various different things, some contribute and some don't.
For instance, they are funding some work on developing the GNU/Linux system. That's good, that contributes. They do develop some other free software packages that they've contributed to the community. That's a real contribution.
They are also developing many nonfree programs to make them run with the GNU/Linux system and that is not a contribution. And they are publicizing the system, well, it's not a primary contribution but it does help, you know. Having more users is not our primary goal. But it's nice, if more people would try our software, so that does help, but then they're mistakenly calling this Linux which is not quite right, and they're lobbying for software patents in Europe, which is bad. So, you know, IBM is doing many different things. Some are good and some are bad, and if you want to have a thoughtful view, it's important to look at the individual actions. Do not try to add it up because that just means you're missing the important aspects of the situation.
Are there any more questions?
Now, one thing I am unhappy about is when the companies that do this add some nonfree software to it.
So that's a major problem that our community faces now, the tendency to put free software together with nonfree software and make these nonfree overall systems. And then, you know, it might seem that our software is a success because there are many people using it. But if you look at our real goal, our real goal is not popularity. Our real goal is to spread a community of freedom, and we're not succeeding in doing that if the people are using nonfree software still.
Unfortunately, I couldn't give both speeches. I can give a speech about software patents, or I can give a speech about free software. They're very different and each one of them is a long speech. So unfortunately what that means is that I can't fully explain about free software and the GNU project here. Am I giving another speech in Kochi? Am I giving the free software speech in Kochi?
So I'll answer five more questions and then I'll have to call it quits because it gets to be quite draining to answer so many.
So, I would say, a person who's using Windows, well, either he is actively supporting this power structure, or at least maybe he's trapped in it and doesn't have the courage to get out. In that case you can forgive him, I guess, and encourage him. You know, there are different situations of people; in any place there are people… different. Some people are making more or less effort to try to improve things. I believe in judging people as individuals, not as lumping them together by their groups.
But this is, in this one case it is, somewhat of a political choice with political consequences for society, and that's exactly where it makes sense to criticize people.
Note: At this point, there was a short blackout, and both the recording and the transcript is incomplete here.
So this will be the last question.
So that was the last question, I can't stay all day answering questions, I'm sorry. So at this point I am going to have to call a halt and get going, and go have lunch. So thank you for listening.
[Applause].
[1] In 2014, this petition against software patents is archived.
For more information about the problem of software patents, see also our End Software Patents campaign.