Slashdot Mirror
An Argument Against Software Patents
clndnng writes "Roughly 90% of web content consists of discussions of software patents,
so it's a little surprising that Ben Klemens has written what may be
the first dead-trees book analyzing their validity. It has a lot of
ground to cover: you could approach the topic from the perspective of
the geeks, the lawyers, the economists, or the businessmen. Klemens is
equal-opportunity, addressing every perspective." Read the rest of the review.
Math You Can't Use: Patents, Copyright and Software
author
Ben Klemens
pages
publisher
Brookings Instituion Press
rating
9/10
reviewer
ISBN
0-8157-4942-2
summary
Explains why patents don't make sense for software
The first question you are probably asking yourself is whether this book says anything that you haven't already read on Slashdot's pages. Barring any omniscient readers, the answer is probably yes, because the book covers so many different angles. You might already know what he will say about the Church-Turing Thesis, but you probably don't know the law of scènes à faire or contributory infringement. Slashdot chestnuts like Amazon.com's one-click patent and the SCO v IBM case make only passing appearances, leaving room for more interesting examples about Garbage Pail Kids and Banana Protective Devices.
Chapter two of the book gives a quick-and-dirty overview of the economic motivations for patent law. I should tell you that Ben Klemens and I were both students at Caltech's PhD program for Social Sciences, so I was half expecting him to whip out the infinite sequences of integrals over a Riemann manifold here. But he either didn't think the Greek relevant or chose to spare us mere mortals, because he keeps the theory pretty simple: patents are supposed to maximize the size of the market. If nobody is providing a good, patents should induce somebody to provide, but if many people are providing the good, then a good patent regime shouldn't diminish that number of providers to one.
You can see where this is going: patents on software are often not necessary to induce code-writing, and when they do exist they seriously diminish what could have been a crowded market. He ties this to finding the optimal breadth of a patent, because a too-broad patent gives the owner a cheap monopoly over a range that could have held a large number of competitors.
The next chapter is the computer science chapter. He goes into detail about how we go from transistors to instruction sets, which turns out to be important in the next chapter when patent examiners try to draw a line between the two. He also talks about how one could write up a symbol table to translate any given program into lambda calculus expressions, which are pure math by any definition of the term. If pure math isn't patentable, and a program can be translated into a pure mathematical expression, then where does the program get off being patentable?
Chapter four shows how U.S. law went from disallowing software patents to letting through patents on anything sort of techy-sounding. The first alibi by the courts is that code may be pure math, but a machine on which is programmed pure math is a physical device, just like a toaster. Klemens tries to address this via the discussion above about how the transistors are soldered on at the factory, but the programs coded onto them are just states on a state machine. He brings up the breadth problem above: a patent for an algorithm on any general-purpose computer is a patent of huge breadth.
The second alibi by the courts is that the application of an equation to a useful purpose is distinct from the equation itself. As tenuous as such a distinction is, it hasn't held, so there are now patents on the books for math applied to useful purposes like a "Method for performing complex fast Fourier transforms," a "Method of efficient gradient computation," and a "Cosine algorithm for relatively small angles."
That's the thrust of the theory that Klemens covers. Most of the rest of the book shows how software patents in the real world create problems. He cites interviews with venture capitalists by a University of Texas researcher in which they say that they just expect to be violating patents left and right in the normal course of business. He cites another set of researchers who surveyed technologists in a variety of fields, and found that companies in most fields mostly patent in order to protect their inventions, while computing companies are most likely to patent so they can game the system.
Klemens seems to be downplaying the role of open source in all of this. In Chapter 6, he points out that the U.S. software market is evenly split between software companies (32.6%), consultants (36.4%), and in-house software (31.0%). That is, most software isn't written by software companies, and some of that not-software-company software is OSS. It's the decentralization, not the openness, that matters. Patents have never been applied to a decentralized industry before, and they don't work there because independent invention is not a valid defense against claims of patent infringement, and independent invention is inevitable in such a decentralized industry.
Finally, the book covers copyright, which makes sense because if patents really are going to be thrown out, then coders will be relying on copyright more. For example, the GPL is based on copyright protection. The recommendation here is that copyright be aimed at detecting plagiarism anywhere along the line, so if you cut and paste my FORTRAN code and run it through f2c, your C code is still infringing my copyrights. He points out that software is uniquely well-suited to enforcing copyright all along the development process, because coders have backups and RCS repositories that poets don't keep.
Klemens's anti-software patent position happens to be the position I believed when I started reading, so I can't say that he changed my mind. But he did point out many arguments, stories, and facts that I hadn't known (or had misheard) beforehand.
Klemens covers a lot of ground in an ADD-friendly manner, and if you don't like one of his arguments against software patents, he has ten more for you to try out. For me, he made the injustice in software patents salient, and by the end of the book I wanted to find a machine to rage against—or to at least send my copy of the book to my Congressman. In fact, on the Brookings Institution website, Klemens suggests political action, because Congress has patent reforms in process that won't fix software patents without a push from the rest of us. Hopefully, this book will be a step in the right direction.
You can purchase Math You Can't Use: Patents, Copyright and Software from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The first question you are probably asking yourself is whether this book says anything that you haven't already read on Slashdot's pages. Barring any omniscient readers, the answer is probably yes, because the book covers so many different angles. You might already know what he will say about the Church-Turing Thesis, but you probably don't know the law of scènes à faire or contributory infringement. Slashdot chestnuts like Amazon.com's one-click patent and the SCO v IBM case make only passing appearances, leaving room for more interesting examples about Garbage Pail Kids and Banana Protective Devices.
Chapter two of the book gives a quick-and-dirty overview of the economic motivations for patent law. I should tell you that Ben Klemens and I were both students at Caltech's PhD program for Social Sciences, so I was half expecting him to whip out the infinite sequences of integrals over a Riemann manifold here. But he either didn't think the Greek relevant or chose to spare us mere mortals, because he keeps the theory pretty simple: patents are supposed to maximize the size of the market. If nobody is providing a good, patents should induce somebody to provide, but if many people are providing the good, then a good patent regime shouldn't diminish that number of providers to one.
You can see where this is going: patents on software are often not necessary to induce code-writing, and when they do exist they seriously diminish what could have been a crowded market. He ties this to finding the optimal breadth of a patent, because a too-broad patent gives the owner a cheap monopoly over a range that could have held a large number of competitors.
The next chapter is the computer science chapter. He goes into detail about how we go from transistors to instruction sets, which turns out to be important in the next chapter when patent examiners try to draw a line between the two. He also talks about how one could write up a symbol table to translate any given program into lambda calculus expressions, which are pure math by any definition of the term. If pure math isn't patentable, and a program can be translated into a pure mathematical expression, then where does the program get off being patentable?
Chapter four shows how U.S. law went from disallowing software patents to letting through patents on anything sort of techy-sounding. The first alibi by the courts is that code may be pure math, but a machine on which is programmed pure math is a physical device, just like a toaster. Klemens tries to address this via the discussion above about how the transistors are soldered on at the factory, but the programs coded onto them are just states on a state machine. He brings up the breadth problem above: a patent for an algorithm on any general-purpose computer is a patent of huge breadth.
The second alibi by the courts is that the application of an equation to a useful purpose is distinct from the equation itself. As tenuous as such a distinction is, it hasn't held, so there are now patents on the books for math applied to useful purposes like a "Method for performing complex fast Fourier transforms," a "Method of efficient gradient computation," and a "Cosine algorithm for relatively small angles."
That's the thrust of the theory that Klemens covers. Most of the rest of the book shows how software patents in the real world create problems. He cites interviews with venture capitalists by a University of Texas researcher in which they say that they just expect to be violating patents left and right in the normal course of business. He cites another set of researchers who surveyed technologists in a variety of fields, and found that companies in most fields mostly patent in order to protect their inventions, while computing companies are most likely to patent so they can game the system.
Klemens seems to be downplaying the role of open source in all of this. In Chapter 6, he points out that the U.S. software market is evenly split between software companies (32.6%), consultants (36.4%), and in-house software (31.0%). That is, most software isn't written by software companies, and some of that not-software-company software is OSS. It's the decentralization, not the openness, that matters. Patents have never been applied to a decentralized industry before, and they don't work there because independent invention is not a valid defense against claims of patent infringement, and independent invention is inevitable in such a decentralized industry.
Finally, the book covers copyright, which makes sense because if patents really are going to be thrown out, then coders will be relying on copyright more. For example, the GPL is based on copyright protection. The recommendation here is that copyright be aimed at detecting plagiarism anywhere along the line, so if you cut and paste my FORTRAN code and run it through f2c, your C code is still infringing my copyrights. He points out that software is uniquely well-suited to enforcing copyright all along the development process, because coders have backups and RCS repositories that poets don't keep.
Klemens's anti-software patent position happens to be the position I believed when I started reading, so I can't say that he changed my mind. But he did point out many arguments, stories, and facts that I hadn't known (or had misheard) beforehand.
Klemens covers a lot of ground in an ADD-friendly manner, and if you don't like one of his arguments against software patents, he has ten more for you to try out. For me, he made the injustice in software patents salient, and by the end of the book I wanted to find a machine to rage against—or to at least send my copy of the book to my Congressman. In fact, on the Brookings Institution website, Klemens suggests political action, because Congress has patent reforms in process that won't fix software patents without a push from the rest of us. Hopefully, this book will be a step in the right direction.
You can purchase Math You Can't Use: Patents, Copyright and Software from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Did you know 83% of all reported statistics are made up?
e to the i pi equals negative one
Firefox... pr0n. Nope, no misspeelings.
Dammit. *Turns spell checker on* Firefox... pr0n. Nope, still no misspellings.