Patent Absurdity

A case when ignorance is the best policy

Dear KV,

I had been reading through a bunch of patents related to some code I'm writing so I could avoid coding up something that was known to be patented. This seemed to be a good idea, but when I told my boss about it, we had to have a meeting with one of the company lawyers where I got to explain which patents I'd read. I was then taken off the project and assigned some other work. I think that this was a stupid thing for my manager to do because now the person working on this feature has no clue if the patent is being violated or not. Was I wrong to try to do the requisite research before I started coding up this function?

Made Ignorant of the Law

Dear Made,

If there is one legal issue that ought to be taught to all software engineers, it is, "Don't read patents!" I am sure that the company lawyer pointed out that had you not read the patent and violated it, the penalty would be much lower than if you had read the patent, and accidentally violated it. It is trivially easy to accidentally violate a software patent because, of course, lawyers write such patents to be overly broad, and thereby set traps for the unwary coder.

It is, alas, long past the moment when we could have avoided these problems by not allowing software patents at all, for, just like inviting a vampire into your home, once you invite in the lawyers, they will suck you dry. As we've seen over the past 30 years, the only people who profit from software patents are those who weaponize them for profit, and those who abet them (i.e., lawyers). The real value of software patents comes not from protecting the intellectual property of "the little guy"—a fictitious character devised by patent lawyers to justify their billable hours—but from being weaponized into portfolios that various large companies can use to manipulate both the market and their competitors.

The main reason a lawyer will give for not reading a software patent is that, if you run afoul of the patent and it can be shown that you had knowledge of it, your company will incur triple the damages that they would have, had you not had knowledge of the patent. That seems like reason enough to avoid reading them, but there is an even better reason, and that is, as design or technical documents, software patents suck.

KV has, on several occasions, had reason to read software patents, because one of the things KV enjoys doing is to help take down patent trolls. Of course, in these cases, KV was not involved in coding up anything relating to the patent but, instead, was looking for prior art or other things that would invalidate the troll's hold on a particular idea or concept.

In all cases where I've had cause to read such documents, my first reaction has been revulsion, but then revulsion is my first reaction to waking up in the morning as well. The revulsion to patents stems from the fact that all the software patents to which I've been exposed have had several things in common: They lay claim to obvious ideas that any software practitioners might come across in their working careers, and they are overly broad, rarely novel, and seem to be written by an infinite number of monkeys attempting to bang out a version of Hamlet on ancient typewriters.

All of which is to say they are bullshit, but you can't get up in a court of law and say that. Instead, you must spend hours meticulously deconstructing every claim. The claims are not written in either code or plain English, but in a legal code meant to protect the lawyers and their clients' intellectual property. While you might glean an understanding of what the patent intended from reading it, it's more likely you'll just wonder why anyone bothered to write the patent at all.

KV often feels that the reason software developers and engineers give these documents any consideration is that they are official documents, blessed by the legal priesthood, and, as such, must have value. They do have value, but that value is not technical in nature, so, as a technologist of any sort, it's best to put down those fancy, wordy documents and let the company lawyer worry about software patents. After all, they're paid three or four times your salary to do so.

Kode Vicious, known to mere mortals as George V. Neville-Neil, works on networking and operating-system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking, operating systems, and rewriting your bad code (OK, maybe not that last one). He earned his bachelor's degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. Neville-Neil is the co-author with Marshall Kirk McKusick and Robert N. M. Watson of The Design and Implementation of the FreeBSD Operating System (second edition). He is an avid bicyclist and traveler who currently lives in New York City.

Originally published in Queue vol. 19, no. 4—
Comment on this article in the ACM Digital Library

More related articles:

Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx: What Actually Drives Productivity
Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. In addition to improving productivity, DevEx drives business performance through increased efficiency, product quality, and employee retention. This paper provides a practical framework for understanding DevEx, and presents a measurement framework that combines feedback from developers with data about the engineering systems they interact with. These two frameworks provide leaders with clear, actionable insights into what to measure and where to focus in order to improve developer productivity.

Jenna Butler, Catherine Yeh - Walk a Mile in Their Shoes
Covid has changed how people work in many ways, but many of the outcomes have been paradoxical in nature. What works for one person may not work for the next (or even the same person the next day), and we have yet to figure out how to predict exactly what will work for everyone. As you saw in the composite personas described here, some people struggle with isolation and loneliness, have a hard time connecting socially with their teams, or find the time pressures of hybrid work with remote teams to be overwhelming. Others relish this newfound way of working, enjoying more time with family, greater flexibility to exercise during the day, a better work/life balance, and a stronger desire to contribute to the world.

Bridget Kromhout - Containers Will Not Fix Your Broken Culture (and Other Hard Truths)
We focus so often on technical anti-patterns, neglecting similar problems inside our social structures. Spoiler alert: the solutions to many difficulties that seem technical can be found by examining our interactions with others. Let’s talk about five things you’ll want to know when working with those pesky creatures known as humans.