How to tell that software patents are a bad idea.

I’ve written elsewhere about how software patents harm software development. This article is about how there’s very little corresponding benefit to justify that harm.

Ostensibly, our patent system is supposed to stimulate innovation and progress, by granting those who come up with a genuinely new and useful invention a temporary monopoly on that invention, as long as the inventor describes it by publishing a description in the government’s public registry of patents. (Already we’re on shaky ground, because this isn’t actually how the modern patent system came to be, but let’s leave aside the history for a moment — interesting and unexpected as it may be — and concentrate just on the present-day realities of software patents.)

The first sign that there’s something wrong with software patents is that (as any patent attorney working in software can tell you) they are overwhelmingly collected as a defense against incoming patent infringment suits. Most companies don’t intend to collect royalties on their software patents, they just keep the patents around in case some other company decides to bring a patent infringement suit, at which point the target of the suit goes digging in their patent portfolio and comes out with some patents that the plaintiff is probably violating — at which point the two sides sit down, work out a cross-licensing deal whereby each gets the rights to the others’ patents, and neither has to worry about it again. It’s a classic arms race situation: in a world where everyone is armed to the teeth, everyone must be armed to the teeth. Except, of course, that small players can’t afford the overhead of filing patents and keeping patent attorneys on staff, and are therefore vulnerable to infringement suits that they cannot defend against, regardless of the suits’ merits.

Another sign the system is broken is that filing software patents is almost always a byproduct of normal software development work, rather than the intended goal of research projects. In other words, programmers are solving problems in new and useful ways just in the normal course of their work. Typically, their employers instruct them to say if they’ve done anything that might be patentable, so the company can file for the patent. (I’ve received such instructions myself, as have most programmers I know.) So the innovation precedes the intent to patent, and would have happened anyway without the patent, since it was needed to do whatever the programmer was trying to do in the first place.

“Ah”, some would say, “but that’s missing the point. The patent still does society some good, because it forces the programmers to publicly describe their solution, so we can all benefit from it. Without the requirement to publish, the secret trick would remain hidden in their private source code, where others cannot learn from it.”

That argument would make sense if programmers ever used the patent office as a research aid, but in fact, they don’t. I’ve never heard of a programmer turning to filed patents to get help solving a technical problem. (I once made this assertion in the company of another programmer, who said he had heard of someone doing this, but when pressed, he thought about it more and realized the person was actually just examining patents for competitive analysis: he was trying to get news on what his competition was up to, not looking for information on solving technical problems.)

Even if filed patents did contain interesting technical information, which for the most part they don’t, they’d still be a pretty cumbersome way to find out that information, because patents are written in a special language designed for making claims that are defendable in court, not for communicating technical details clearly. Companies naturally want their claims to be as broad as possible, while still being defensible. But these goals are orthogonal to, and often opposed to, the simplification and reduction that are the heart of technical clarity. Learning a programming technique by reading a patent would be like learning to cook by reading municipal health inspection regulations: boring, painful, and in all likelihood unsuccessful.

But as I said, programmers rarely read software patents to learn from them anyway. The vast majority of the time, when they’re reading software patents, they’re doing it to determine whether they or someone else might be infringing. Don’t take my word for it — go ask a programmer about their actual experiences with software patents. You’ll find they’re either filing patents on work they were doing anyway, or spending time analyzing patents (solely to determine infringement, not to learn something new in their art), time they would almost certainly rather spend doing just about anything else.

Are you ready for the final irony?

Most programmers are instructed to consciously avoid looking at patents at all. This is because when you knowingly infringe on a patent, you are liable for triple damages as compared to accidental infringement. I don’t know what legislators came up with that doctrine, but what on earth were they thinking? We now have the paradox of a system whose supposed purpose is to spread knowledge, yet which those capable of using take pains to avoid, for fear of increased legal liability.

To summarize:

  • Software patents are mainly used as a defense against other software patents — a zero-sum arms race.
  • Filing software patents is generally a byproduct of work the programmers would do anyway, that is, the acquisition of the patent is not a motivating factor in the development of the new technique, it is merely a result.
  • Programmers do not use the patent office as a research tool, even though that was supposed to be part of the point.
  • Patents are written in a special style which is antagonistic to communicating software techniques clearly anyway.
  • Due to the triple-damages rule, programmers must consciously avoid looking at other software patents whenever possible.

I’m mostly leaving aside the issue of patent duration here. While it’s true that the length of time a software patent lasts is ridiculous (20 years from the earliest claimed filing date, in the U.S., for all patents, not just software), the term length is not in itself a philosophical objection. Although the harm of software patents would be greatly reduced if the term length were only, say, 3 years instead of 20, that would still do nothing to address the other concerns. No matter what the term length, we just don’t need software patents. If the purpose of patents is to stimulate innovation (a debatable goal in the first place), they are having the opposite effect in software: programmers are forced to avoid using the best tool for the job, for fear of infringing on a patent, and are forced to avoid building on each others’ work, for fear of triple damages. And even granting that innovation were a goal worth sacrificing freedom for, there would be no need to artificially stimulate innovation in software, because tremendous innovation already happens in the natural course of things.

3 Responses to “How to tell that software patents are a bad idea.”

  1. Eric Says:

    I disagree with many of the arguments you have made in this article as they are largely based on opinion. However, I appreciate the intellectual stimulation this article provides and look forward to reading other articles.

    Remember when you criticize protection of any type of IP that without the incentive, less innovation will be made. In regards to the patent length, inventors need to be given a fair amount of time to recoup a return on their investment of both time and money.

  2. Karl Fogel Says:

    Thanks for the comment. I’m trying to make the argument based on facts, actually, which is why I cite others’ experiences. Note that most of the arguments for patents are based on opinion or abstract reasoning too. I haven’t seen a presentation of facts that supports the current patent system. Of course, this is partly because facts are so hard to come by. These things are very hard to measure.

    I’m suspicious of the “innovation is the goal” argument. Innovation is less useful when not everyone is free to take advantage of that innovation. Also, innovation is also never de novo: it is based on existing work. The patent system thus impedes innovation, too; can you be sure which effect is stronger?

    It is not a given that inventors need to be given any kind of monopoly at all. There was no shortage of inventiveness in the world before patents. (There were sometimes inventors who tried to keep their inventions secret; but that is once again true in effect, in the sense that now so many patents are filed, and are written in such impenetrable language, that the patent database is the last place other engineers would look for technical help.)

  3. Jose_X Says:

    >> Remember when you criticize protection of any type of IP that without the incentive, less innovation will be made.

    If you are referring to copyright or to anything else besides patents, then you were not reading the article or are making assumptions beyond what was argued in it. This article is against software patents not against software copyrights (and we need not ask the author, but only read it).

    I will assume you did read the article and also are referring specifically to patents.

    Then, not only does this disagree with some research and possibly is not supported to any significant degree by any, but it makes almost no sense within the context of a widely populated competitive field that assigning a monopoly to one person over many others’ original works would promote advancement (I’ll leave up for debate whether copyright ever promotes the progress.. though at least for software, “copyleft” licenses appear to promote revelation of trade secrets). It’s rather likely instead that such monopolies will stifle and perhaps significantly depending on their broadness and simpleness.

    I can clearly say that I have been disincentived to create as much software as I otherwise would specifically because of our patent system. It’s ridiculously easy for a wealthy entity to surf the net and open source channels for ideas (even specific ones) with little risk that those providing the ideas will seek a patent. The risk would be in reputation, but even that is only a modest risk.

    Note that a monopoly removes incentives to keep creating at an aggressive pace, and, because patents give much power without even requiring a competitive or marketable product to exist, you might not even lose any incentive to create one period when you can instead sue others who are creating.

    And as mentioned in the article, the incentives to leverage existing patents are very low except perhaps for professional patent applicants who never really had an intention to try and build a business or even a competitive product that would avoid others’ patents.

    Oh, and did you catch that the inventiveness bar to patenting is extremely low? Honestly, in a field loaded with people, how many people do you think (by glancing at any “bell curve”) would find to be obvious (or at least non-obvious or even difficult but achievable within one year) an invention that merely is “non-obvious to a person having ordinary skill in the art”?

    Bingo! Patents stop the smartest people.

    They also tend to reward (in a winner-take-all fashion) those potentially far down the competency rung. There is simply too large of a pool of those able to come up with the broad ideas quickly and stop the geniuses real work.

    Thank goodness Einstein and many others were able to leverage their social context without fear of infringement. And notable is that this guy was a patent examiner so knew very well of the “benefits” of patent infestation. I’d say he was motivated to contribute to mankind already.. and to avoid patents.

    Among the many that object strenuously to software patents are these

Leave a Reply