Skip to content

On Software Patents

There’s been a lot of linking to Stephen O’Grady’s piece on software patents lately, and I thought I’d do the same but provide my own twist on these arguments.

The area of “software that should be patentable” exists between a floor defined by “algorithms and math” and a ceiling of things that are overbroad and are already used by everybody. The rub is that I’m not actually sure there is any room between those two.

It should be noted that “algorithms and math” technically can’t be patented right now, but if you claim to be patenting a “system which” performs that algorithm, you can effectively patent that algorithm. This is a perversion of the process, and that’s bad, both because it allows things to become patent-encumbered that need to be free and because it becomes an argument for there being a larger space of patentable things in the software world.

Further complicating matters, software patents do not require the code to be made public, whereas physical device patents require blueprints. So when your butter churner patent expires, the public is enriched by open access to your invention, and until then other people can see what you did and make their butter churner work differently to avoid your patent. With software patents it’s a minefield where you can never be sure you’re safe and no one gets to see what you’ve done.

Finally, software patents have historically been overseen by people who have no idea how software works, leading to horrible patents on things that are obviously covered by previous use, other things that are just obvious, and things that aren’t possible when patented but will be later (so you can lock your competitors out of a market before the market even exists).

This leads to the entire industry living in fear of a massive patent war, with everybody arming themselves with defensive patents and being overly cautious, with the result that we as a public lose out on innovative products