Intro to Open Invention Network’s defensive publications

Three weeks ago, I started working for Open Invention Network as an intern¹. Open Invention Network, or OIN in short, aims at creating a safe environment for Linux and Linux-based systems to thrive in spite of all the threats that patents constitute to software developers.

As one of my activities with OIN in the Linux Defenders program, I am helping Free Software (aka Open Source) projects submit “defensive publications.”

Defensive publications are sort of anti-patents:

• while patents are claimed to exclude others from being able to implement something,
• defensive publications prevent anyone to exclude others from being able to implement something.

They’re called defensive because they can be used against further patent applications or they can be used a posteriori to defend oneself against patent infringement claims. Indeed, if the software is already accessible by the public before a patent on it is submitted, there’s no way you or anyone would be infringing on a patent on that software. Actually in that situation the patent should be invalidated. Then you might ask: why do I need to write defensive publications if I have already published my source code? – Unfortunately, that’s because just releasing source code is not effective to protect yourself against patents.

In theory, it is true that you are immune from infringement of subsequent patents as soon as you’ve made your software source code publicly accessible online, for instance using a public version control system like Github.

In practice, it’s not really effective. Here’s why:

1. the life of patents begin at the patent office where patent applications are submitted, then reviewed by patent office staff:

   Patent examiners have a strong sense of the technology that is patented, but they’re missing an understanding of what has been and is currently being developed in the open source world. As shocking as it may seem, the result is the examiner formulating an inaccurate sense of what is innovative. As the final arbiter of a very significant monopoly grant, they are often grossly uninformed in terms of what lies beyond their narrowly scoped search. This is not wholly their fault as they have limited resources and time. However, it is a strong indication of a faulty system that is so entrenched in the archaic methods under which patent offices have been operating.

   As Andrea pointed out, patent office staff will usually not go to software repositories and read source code in order to find prior art. That’s why making it easy for them to read about what you’ve done in software is necessary. That’s what defensive publications are supposed to do.

2. The life of patents end in several ways, whichever comes first:

   1. The patent was filed more than 20 years ago or the patent holders have not paid their yearly patent-taxes, it’s now in the public domain
   2. an authoritative court decision has striked out the patent as invalid (and there’s no appeal pending)
   3. the patent office reverts their decision to grant the patent

   The problem is that in each of these cases, the process can be quite long. Litigations can go on for several years, especially since a patent holder will probably try to appeal a decision that invalidate its patent.

   As for the patent office procedures, they can take a decade. For instance, it took more than 15 years to strike down a single very broad Amazon patent application².

   Meanwhile, the patent will constitute a potential threat that will effectively encumber the use and distribution of your software.

Basically, defensive publications consist in documenting one aspect of software projects that’s focused on solving a challenge and does it in a new, innovative way. The document would give some context about the state of the art and then describe in more details how the system works, usually by using meaningful diagrams, flowcharts and other figures.

Not like this one:

Created by Libby Levi for opensource.com

And who’s going to read defensive publications? At OIN, we maintain a website to list defensive publications. Then, we submit them to databases used for prior-art examination by patent office examiners. So the target audience for these defensive publications is the patent office that reviews patent applications. A good defensive publication should use generic terms that are understood even by someone who’s not programming in the same language as the one used for the program.

Defensive publications may be no more than a re-arrangement of what’s already written on the project’s blog, or in the documentation. They can be useful to explain how your program works to other programmers. In some aspect, they look like a (short!) scientific publication.

For software that works in areas heavily encumbered with patents like media codecs, actively submitting defensive publications can safeguard the project’s rights against patent holders. For instance, consider that patent trolls now account for 67% of all new patent lawsuits and as shown in a 2012 study, startups are not immune to patent threats.

So part of my job is to work with Free Software projects to help them submit defensive publications. I have been working with Pablo Joubert on a defensive publication around search engines making use of distributed hash tables (DHT). Pablo was involved in the Seeks project and has now started a new project building upon seeks. It was very interesting for me to learn more about how DHT are used in peer-to-peer networks and how we can make use of them for new awesome applications like social search. Now, Pablo also has a document that explains concisely what the project is and how it works. This could be the preamble to the documentation 😉

I’ve also worked on a guide to defensive publications and I am starting to think on how a tutorial might look like. I hope you will find that useful. I’ll write more about that next time!

If you are interested, don’t hesitate to join #linuxdefenders on the IRC freenode server.