Post-Bilski Steps for Anti-Software-Patent Advocates

Created
Wed, 30/06/2010 - 18:45
Updated
Wed, 30/06/2010 - 18:45

Lots of people are opining about the USA Supreme Court's ruling in the Bilski case. Yesterday, I participated in a oggcast with the folks at SFLC. In that oggcast, Dan Ravicher explained most of the legal details of Bilski; I could never cover them as well as he did, and I wouldn't even try.

Anyway, as a non-lawyer worried about the policy questions, I'm pretty much only concerned about those forward-looking policy questions. However, to briefly look back at how our community responded to this Bilski situation over the last 18 months: it seems similar to what happened while the Eldred case was working its way to the Supreme Court. In the months preceding both Eldred and Bilski, there seemed to be a mass hypnosis that the Supreme Court would actually change copyright law (Eldred) or patent law (Bilski) to make it better for freedom of computer users.

In both cases, that didn't happen. There was admittedly less of that giddy optimism before Bilski as there was before Eldred, but the ultimate outcome for computer users is roughly no different in both cases: as we were with Eldred, we're left back with the same policy situation we had before Bilski ever started making its way through the various courts. As near as I can tell from what I've learned, the entire “Bilski thing” appears to be a no-op. In short, as before, the Patent Office sometimes can and will deny applications that it determines are only abstract ideas, and the Supreme Court has now confirmed that the Patent Office can reject such an application if the Patent Office knows an abstract idea when it sees it. Nothing has changed regarding most patents that are granted every day, including those that read on software. Those of us that oppose software patents continue to believe that software algorithms are indeed merely abstract ideas and pure mathematics and shouldn't be patentable subject matter. The governmental powers still seems to disagree with us, or, at least, just won't comment on that question.

Looking forward, my largest concern, from a policy perspective, is that the “patent reform” crowd, who claim to be the allies of the anti-software-patent folks, will use this decision to declare that the system works. Bilski's patent was ultimately denied, but on grounds that leave us no closer to abolishing software patents. Patent reformists will say: Well, invalid patents get denied, leaving space for the valid ones. Those valid ones, they will say, do and should include lots of patents that read on software. But only the really good ideas should be patented, they will insist.

We must not yield to the patent reformists, particularly at a time like this. (BTW, be sure to read RMS' classic and still relevant essay, Patent Reform Is Not Enough, if you haven't already.)

Since Bilski has given us no new tools for abolishing software patents, we must redouble efforts with tools we already have to mitigate the threat patents pose to software freedom. Here are a few suggestions, which I think are actually all implementable by the average developer, to will keep up the fight against software patents, or at least, mitigate their impact:

  • License your software using the AGPLv3, GPLv3, LGPLv3, or Apache-2.0. Among the copyleft licenses, AGPLv3 and GPLv3 offer the best patent protections; LGPLv3 offers the best among the weak copyleft licenses; Apache License 2.0 offers the best patent protections among the permissive licenses. These are the licenses we should gravitate toward, particularly since multiple companies with software patents are regularly attacking Free Software. At least when such companies contribute code to projects under these licenses, we know those particular codebases will be safe from that particular company's patents.
  • Demand real patent licenses from companies, not mere promises. Patent promises are not enough0. The Free Software community deserves to know it has real patent licenses from companies that hold patents. At the very least, we should demand unilateral patent licenses for all their patents perpetually for all possible copylefted code (i.e., companies should grant, ahead of time, the exact same license that the community would get if the company had contributed to a yet-to-exist GPLv3'd codebase)1. Note further that some companies, that claim to be part of the FLOSS community, haven't even given the (inadequate-but-better-than-nothing) patent promises. For example, BlackDuck holds a patent related to FLOSS, but despite saying they would consider at least a patent promise, have failed to do even that minimal effort.
  • Support organizations/efforts that work to oppose and end software patents. In particular, be sure that the efforts you support are not merely “patent reform” efforts hidden behind anti-software patent rhetoric. Here are a few initiatives that I've recently seen doing work regarding complete abolition of software patents. I suggest you support them (with your time or dollars):
  • Write your legislators. This never hurts. In the USA, it's unlikely we can convince Congress to change patent law, because there are just too many lobbying dollars from those big patent-holding companies (e.g., the same ones that wrote those nasty amicus briefs in Bilski). But, writing your Senators and Congresspeople once a year to remind them of your opposition patents that read on software simply can't hurt, and may theoretically help a tiny bit. Now would be a good time to do it, since you can mention how the Bilski decision convinced you there's a need for legislative abolition of software patents. Meanwhile, remember, it's even better if you show up at political debates during election season and ask these candidates to oppose software patents!
  • Explain to your colleagues why software patents should be abolished, particularly if you work in computing. Software patent abolition is actually a broad spectrum issue across the computing industry. Only big and powerful companies benefit from software patents. The little guy — even the little guy proprietary developer — is hurt by software patents. Even if you can't convince your colleagues who write proprietary software that they should switch to writing Free Software, you can instead convince them that software patents are bad for them personally and for their chances to succeed in software. Share the film, Patent Absurdity, with them and then discuss the issue with them after they've viewed it. Blog, tweet, dent, and the like about the issue regularly.
  • (added 2010-07-01 on tmarble's suggestion) Avoid products from pro-software-patent companies. This is tough to do, and it's why I didn't call for an all-out boycott. Most companies that make computers are pro-software-patent, so it's actually tough to buy a computer (or even components for one) without buying from a pro-software-patent company. However, avoiding the companies who are most aggressive with patent aggression is easy: starting with avoiding Apple products is a good first step (there are plenty of other reasons to avoid Apple anyway). Microsoft would be next on the list, since they specifically use software patents to attack FLOSS projects. Those are likely the big two to avoid, but always remember that all large companies with proprietary software products actively enforce patents, even if they don't file lawsuits. In other words, go with the little guy if you can; it's more likely to be a patent-free zone.
  • If you have a good idea, publish it and make sure the great idea is well described in code comments and documentation, and that everything is well archived by date. I put this one last on my list, because it's more of a help for the software patent reformists than it is for the software patent abolitionists. Nevertheless, sometimes, patents will get in the way of Free Software, and it will be good if there is strong prior art showing that the idea was already thought of, implemented, and put out into the world before the patent was filed. But, fact is, the “valid” software patents with no prior art are a bigger threat to software freedom. The stronger the patent, the worst the threat, because it's more likely to be innovative, new technology that we want to implement in Free Software.

I sat and thought of what else I could add to this list that individuals can do to help abolish software patents. I was sad that these were the only five six things that I could collect, but that's all the more reason to do these five six things in earnest. The battle for software freedom for all users is not one we'll win in our lifetimes. It's also possible abolition of software patents will take a generation as well. Those of us that seek this outcome must be prepared for patience and lifelong, diligent work so that the right outcome happens, eventually.


0 Update: I was asked for a longer write up on software patent licenses as compared to mere “promises”. Unfortunately, I don't have one, so the best I was able to offer was the interview I did on Linux Outlaws, Episode 102, about Microsoft's patent promise. I've also added a TODO to write something up more completely on this particular issue.

1 I am not leaving my permissively-license-preferring friends out of this issue without careful consideration. Specifically, I just don't think it's practical or even fair to ask companies to license their patents for all permissively-licensed code, since that would be the same as licensing to everyone, including their proprietary software competitors. An ahead-of-time perpetual license to practice the teachings of all the company's patents under AGPLv3 basically makes sure that code that's eternally Free Software will also eternally be patent-licensed from that company, even if the company never contributes to the AGPLv3'd codebase. Anyone trying to make proprietary code that infringed the patent wouldn't have benefit of the license; only Free Software users, distributors and modifiers would have the benefit. If a company supports copyleft generally, then there is no legitimate reason for the company to refuse such a broad license for copyleft distributions and deployments.