- rants.org - http://www.rants.org -

How to tell that software patents are a bad idea.

I’ve written elsewhere [1] 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:

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.