And there’s even economic research showing that this is so—showing how in a field with a lot of incremental innovation, a patent system can actually reduce investment in R & D. And of course, it also obstructs development in other ways. So even if we ignore the injustice of software patents, even if we were to look at it in the narrow economic terms that are usually proposed, it’s still harmful.
People sometimes respond by saying that “People in other fields have been living with patents for decades, and they’ve gotten used to it, so why should you be an exception?”
Now, that question has an absurd assumption. It’s like saying, “Other people get cancer, why shouldn’t you?” I think every time someone doesn’t get cancer, that’s good, regardless of what happened to the others. That question is absurd because of its presupposition that somehow we all have a duty to suffer the harm done by patents.
But there is a sensible question buried inside it, and that sensible question is “What differences are there between various fields that might affect what is good or bad patent policy in those fields?”
There is an important basic difference between fields in regard to how many patents are likely to prohibit or cover parts of any one product.
Now we have a naive idea in our minds which I’m trying to get rid of, because it’s not true. And it’s that on any one product there is one patent, and that patent covers the overall design of that product. So if you design a new product, it can’t be patented already, and you will have an opportunity to get “the patent” on that product.
That’s not how things work. In the 1800s, maybe they did, but not now. In fact, fields fall on a spectrum of how many patents [there are] per product. The beginning of the spectrum is one, but no field is like that today; fields are at various places on this spectrum.
The field that’s closest to that is pharmaceuticals. A few decades ago, there really was one patent per pharmaceutical, at least at any time, because the patent covered the entire chemical formula of that one particular substance. Back then, if you developed a new drug, you could be sure it wasn’t already patented by somebody else and you could get the one patent on that drug.
But that’s not how it works now. Now there are broader patents, so now you could develop a new drug, and you’re not allowed to make it because somebody has a broader patent which covers it already.
And there might even be a few such patents covering your new drug simultaneously, but there won’t be hundreds. The reason is, our ability to do biochemical engineering is so limited that nobody knows how to combine so many ideas to make something that’s useful in medicine. If you can combine a couple of them you’re doing pretty well at our level of knowledge. But other fields involve combining more ideas to make one thing.
At the other end of the spectrum is software, where we can combine more ideas into one usable design than anybody else, because our field is basically easier than all other fields. I’m presuming that the intelligence of people in our field is the same as that of people in physical engineering. It’s not that we’re fundamentally better than they are; it’s that our field is fundamentally easier, because we’re working with mathematics.
A program is made out of mathematical components, which have a definition, whereas physical objects don’t have a definition. The matter does what it does, so through the perversity of matter, your design may not work the way it “should” have worked. And that’s just tough. You can’t say that the matter has a bug in it, and the physical universe should get fixed. [Whereas] we [programmers] can make a castle that rests on a mathematically thin line, and it stays up because nothing weighs anything.
There’re so many complications you have to cope with in physical engineering that we don’t have to worry about.
For instance, when I put an if
-statement inside of a while
-loop,
• I don’t have to worry that if this while
-loop repeats at the wrong rate, the if
-statement might start to vibrate and it might resonate and crack;
• I don’t have to worry that if it resonates much faster—you know, millions of times per second—that it might generate radio frequency signals that might induce wrong values in other parts of the program;
• I don’t have to worry that corrosive fluids from the environment might seep in between the if
-statement and the while
-statement and start eating away at them until the signals don’t pass anymore;
• I don’t have to worry about how the heat generated by my if
-statement is going to get out through the while
-statement so that it doesn’t make the if
-statement burn out; and
• I don’t have to worry about how I would take out the broken if
-statement if it does crack, burn, or corrode, and replace it with another if
-statement to make the program run again.