The Kollected Kode Vicious

Kode Vicious - @kode_vicious

  Download PDF version of this article PDF

Kode Vicious

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.

KV

 

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.

Copyright © 2021 held by owner/author. Publication rights licensed to ACM.

acmqueue

Originally published in Queue vol. 19, no. 4
see this item in the ACM Digital Library


Tweet


Related:

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.





© 2021 ACM, Inc. All Rights Reserved.