Software Patents Explained to my Grandfather
This article is a write up of the talk I gave at OggCamp10, and some of the discussions thereafter. It’s not a reiteration of the talk, however. There’s a video that I’ll link to once it’s uploaded.
My idea started when someone suggested to my that I should apply for a patent if I wanted to market a piece of my software. I thought this was a terrible idea – software patents are destructive to software innovation. But not having a succinct way to explain why to someone who’s not an open source programmer, I just shrugged off the issue.
Then, at the first OggCamp, I saw an excellent talk by Bruno Bord on explaining programming and open source to non-techies. He used an analogy of Jam making to show how he explained programming to his grandmother. This seemed like a good method of explaining software patents, if I could think of the right analogy.
There are 2 reasons I wished to give this talk at OggCamp. Firstly, to see if my analogy worked, and secondly to see if my arguments held water. Let’s face it, if I couldn’t convince a bunch of Open Source Geeks that I was along the right lines with a criticism of software patents, I certainly couldn’t convince anyone else!
The analogy I settled on was chess. In a chess set, you have a board and pieces, which are analogous to a the computer hardware. You also have a book if defined rules which are analogous to a computer’s instruction set, the basic operations that can be performed by a processor. By combining these rules with the board and pieces you can create games of chess, just like you use the computer’s instruction set to write programs. Whatever language you write, whatever you do with the data, they all boil down to a sequence of the same instructions executing on the processor in the same way.
There are 3 conditions any invention must satisfy to be granted a patent: It must be new, it must have an industrial application, and it must represent an inventive step. Now, there’s no denying that software has an industrial application, and some of it is certainly new, but does it represent an inventive step? I’d say not.
As a programmer, when I get asked to solve a problem with software, I certainly never have to invent anything to do so. I may need to write a lot of code, I may have to rewrite it to work a bit differently to how I have before. But would other programmers in my field, given the same problem, have ended up with a solution that fundamentally does the same thing in the same way? Almost certainly. If it’s as obvious to them as it is to me, it’s not an inventive step.
One of the counter-arguments presented to my viewpoint was that if all inventions are merely the sum of their parts, then surely nothing represents an inventive step?
This put me in my place for a moment or two. Had I known when I was writing the talk that I’d be delivering it on the main stage, I’d certainly have prepared better for this sort of question. However, while it’s true that physical patented inventions do use the same processes that have come before, those processes aren’t the end product like they are with software. A Dyson vacuum cleaner may be made with conventional plastic molding techniques, but the end result is a fundamentally different way of moving air within the device to extract dirt without the need for a bag. When a piece of software is written, the end result is always that of moving data around the hardware. You can’t change how the processor manipulates electrons with code.
Other arguments were raised about how best to protect your inventions. The example of SQL’s invention, a completely new way of querying databases at the time, was cited. Had it been protected, IBM could have prevented companies like Oracle from even have existing, yet they didn’t. It was suggested that the best way to protect your interests is to “be first to market and shut up,” the very behaviour that real-world patents were created to discourage. However, in the open source world, we’ve seen that sharing ideas and technologies isn’t incompatible with commercial interest. Red Hat releases all it’s code as open source, yet it still makes money. There’s even CentOS who give away exactly the same product for free that Red Hat sell, and yet their stocks are on a recession-defying rise.
The final point that was raised was that of copyright. Do I think that copyright needs to be strengthened, or that the terms of open source licences be more restrictive to provide us with the protection we lose out on by rejecting patents? No, I don’t. Copyright is already effective immediately, and it’s effective for longer than any technology created today will still be useful for. As far as licencing goes, we even have licences that enforce sharing if we want to, which is what patents were for in the first place.
In conclusion, I think that my analogy works quite well. My argument as a whole needed work, but now I’ve seen the counter arguments, I think that the modern, open software industry has moved beyond patents to a place where we don’t need to sue the competition into submission in order to protect our interests.