Three weeks ago, I started working for Open Invention Network as an intern1. 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 application2.

    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
Parody of a software patent figure

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.

  1. Since I passed the bar exam in December last year, I now have to fulfil two 6-month internships. ↩

  2. It’s patent EP0927945 The patent’s abstract begins like this: “A method and system for placing an order to purchase an item via the Internet.” This patent was filed at the European Patent Office in 1998. ↩

Le Journal du Net publiait la semaine derniĂšre Comment se repĂ©rer dans la jungle des licences open source. L’article a Ă©tĂ© pas mal partagĂ© sur Twitter. Malheureusement, il souffre de plusieurs approximations dommageables.

Voici 5 rectifications :

1. Licences libres et licences « open source », c’est pareil

L’article semble semer la confusion en essayant de diviser et de cataloguer les licences.

Les licences libres et les licences open source forment une seule et mĂȘme catĂ©gorie. Autrement dit, il n’y a pas de diffĂ©rence entre ces types de licences : une licence non-copyleft comme la licence MIT est autant une licence libre qu’une licence « open source », une licence copyleft comme la GNU GPL est autant une licence libre qu’une licence « open source ». La preuve? Il suffit de regarder la liste des licences maintenues par l’Open Source Initiative et la liste maintenue par GNU pour constater qu’en pratique, les critĂšres sont les mĂȘmes puisqu’on aboutit aux mĂȘmes rĂ©sultats

Pour mieux comprendre les raisons historiques de l’existence de ces deux termes, l’article de Björn en fait l’exposĂ©.

2. Le copyleft, ce n’est pas un virus

On qualifie de licence copyleft une licence libre qui contient des obligations supplĂ©mentaires de maniĂšre Ă  sauvegarder les libertĂ©s des utilisateurs. Autrement dit, une clause copyleft interdit d’interdire.

L’article utilise le terme « contaminant » pour qualifier ce type de clause. Ce vocabulaire nous vient directement de la propagande de Microsoft de la fin des annĂ©es 1990, qui se rĂ©fĂ©rait au logiciel libre comme un « cancer ». Il est temps de s’écarter du vocabulaire de la pathologie ! Le logiciel libre n’est pas un mal incurable, c’est un vecteur de libertĂ©s. (Si vous cherchez absolument Ă  remplacer le mot copyleft par un mot du langage courant, clause d’hĂ©rĂ©ditĂ© ou hĂ©rĂ©ditaire fonctionne plutĂŽt bien).

Ainsi, le qualificatif de « contaminant » est on ne peut plus approximatif. Si on s’intĂ©resse Ă  l’analogie, on voit qu’elle ne tient pas. Si quelqu’un me contamine de sa maladie, je suis passif : je subis, je reçois la contamination et j’en fais les frais. C’est le contact d’un autre qui est la source de ma misĂšre. Ce qui m’amĂšne Ă  une troisiĂšme approximation de l’article

3. Ce qui dĂ©clenche le copyleft, c’est la distribution, pas la publication

Les licences libres Ă©tant principalement des licences de droits d’auteur (ou copyright selon la juridiction), l’acte qui dĂ©clenche les obligations relatives Ă  la clause copyleft coĂŻncide avec l’acte auquel le droit d’auteur attache des obligations.

Ainsi, en droit d’auteur, on ne peut pas distribuer une copie d’une Ɠuvre (ici, un logiciel) sans la permission de son ou ses auteurs. La distribution, c’est la transmission d’une copie d’une personne, physique ou morale, Ă  une autre personne. C’est cet acte lĂ , tout Ă  fait volontaire, qui dĂ©clenche les obligations relatives au droit d’auteur, qui requiert l’autorisation. Cette autorisation est dĂ©jĂ  donnĂ©e par une licence libre, la clause copyleft en est cependant une condition. (On voit bien ici Ă  quel point l’analogie avec la contamination Ă©pidĂ©mique est mauvaise.)

Plus spécifiquement, cette condition :

  • concerne uniquement les dĂ©veloppements du logiciel qui sont eux mĂȘmes basĂ©s sur le logiciel publiĂ© sous licence copyleft; et non les logiciels qui fonctionnent indĂ©pendamment
  • il ne s’agit pas d’une condition de publication des modifications, en effet il est tout Ă  fait possible de respecter la licence simplement en distribuant avec les binaires distribuĂ© aux tiers, l’intĂ©gralitĂ© des sources correspondantes1
    • si ce n’est pas le cas, il y a alors pendant trois ans obligation d’offrir aux tiers Ă  qui on a distribuĂ© une copie la possibilitĂ© de demander les sources (voir les dĂ©tails de la licence pour plus de prĂ©cisions)

Par consĂ©quent, il a bien Ă©tĂ© montrĂ© que c’est la distribution du logiciel qui dĂ©clenche les obligations.2 Ainsi, on peut tout Ă  fait prendre un logiciel libre sous licence copyleft, y apporter plĂ©thores de modifications, et garder ces modifications privĂ©es voire secrĂštes si bon vous semble. Ça fait partie des libertĂ©s intĂ©grantes du logiciel libre : on peut les utiliser pour tout usage, l’utilisation n’est absolument pas restreinte ; et on peut les modifier de façon Ă  ce qu’ils fonctionnent comme on l’entend.

4. Pas de distinction entre libre d’un cĂŽtĂ© et commercial de l’autre

Contrairement Ă  ce qui est suggĂ©rĂ© dans l’article, qui oppose d’un cĂŽtĂ© des licences libres et d’un autre cĂŽtĂ© des licences commerciales ; il n’y a en rĂ©alitĂ© pas de raison de procĂ©der Ă  une distinction.

Comme il vient d’ĂȘtre soulignĂ©, un logiciel libre est forcĂ©ment utilisable sans restriction. Une clause qui limite l’utilisation du logiciel Ă  une activitĂ© non-commerciale est donc fondamentalement incompatible avec une licence de logiciel libre.

Il y a d’un cĂŽtĂ© les licences libres, qui sont gĂ©nĂ©ralement des licences publiques — c’est-Ă -dire que chacun peut les utiliser pour ses propres logiciels Ă  destination du public ; et de l’autre cĂŽtĂ©, les licences propriĂ©taires qui sont gĂ©nĂ©ralement des licences spĂ©cifiques ou spĂ©ciales, qui sont utilisĂ©es seulement par quelques entreprises et pas forcĂ©ment Ă  destination du public mais au contraire parfois pour des logiciels Ă©crits spĂ©cialement avec des modifications propres au client (ce qu’il est tout Ă  fait possible de faire avec une licence libre par ailleurs, le client jouira ainsi Ă©galement des libertĂ©s confĂ©rĂ©es par les licences).

5. La licence GNU GPL est applicable en France/en Europe

Pour s’en convaincre, il suffit de constater que la licence GPL-2.0 a bien Ă©tĂ© appliquĂ©e par des ayants droit en Allemagne Ă  plusieurs reprises (par exemple contre Skype). Bien qu’en France la licence n’ait pas vraiment fait l’objet d’un examen poussĂ© par un juge (le fait qu’il y ait peu de litiges est en soi une bonne nouvelle en fait), son invocation ici et lĂ 3 n’a pas entraĂźnĂ© la dĂ©claration de son incompatibilitĂ©4.

(Seule la loi Toubon pourrait causer quelques problÚmes, mais rien de trÚs grave en réalité ; ça se résout trÚs bien en utilisant des doubles licences et ça ne vaut pas dans tous les cas. Les administrations publiques peuvent trÚs bien faire développer et utiliser des logiciels libres et elles le font déjà !)

Quoiqu’il en soit, l’objectif de l’article est louable et le petit tableau rĂ©capitulatif partagĂ© sur Twitter est assez utile.

Pour bien s’y repĂ©rer, il y a heureusement plusieurs moyens :

  • Le livre de Benjamin Jean, Option Libre. Du bon usage des licences libres.
  • L’International Free and Open Source Software Law Book qui permet d’aborder les aspects juridiques de plusieurs juridictions, dont la France.
  • L’International Free and Open Source Software Law Review ou IFOSSLR qui permet d’aller dans le dĂ©tail avec plusieurs articles Ă  chaque Ă©dition.

Sinon, la communautĂ© du logiciel libre est Ă©galement lĂ  pour aider chacun Ă  s’y repĂ©rer. L’équipe juridique de la FSFE rĂ©pond rĂ©guliĂšrement Ă  ce genre de questions.

  1. Dans la GPL-3.0 voir le paragraphe « 6. Conveying Non-Source Forms » ↩

  2. Une prĂ©cision importante toutefois, il peut exister d’autres cas de figure oĂč les obligations du copyleft sont dĂ©clenchĂ©es. Par exemple, dans la licence AGPL, la rĂ©union de deux conditions dĂ©clenche aussi ces obligations (section 13): 1) la modification du code source, 2) l’interaction des utilisateurs avec le logiciel par l’intermĂ©diaire du rĂ©seau (par exemple dans le cas d’une application web). ↩

  3. Educaffix contre CNRS, ou encore EDU4 contre AFPA, et d’autres dĂ©cisions encore… ↩

  4. Certaines dispositions du code de la propriĂ©tĂ© intellectuelle sont parfois avancĂ©es pour expliquer que la licence GNU GPL serait nulle en droit français… c’est en rĂ©alitĂ© un argument purement acadĂ©mique, car on voit mal qui irait invoquer une telle nullité ! D’une part, c’est une stratĂ©gie dĂ©sastreuse pour celui qu’on accuserait de ne pas respecter la licence car, sans licence valide, c’est la contrefaçon automatiquement — d’autre part, cette nullitĂ© relative n’est en rĂ©alitĂ© invocable que par l’ayant droit lui-mĂȘme. Non seulement cette situation est peu envisageable car il s’agirait de se tirer une balle dans le pied, d’autre part la ratio legis de cette disposition du code pourrait nous amener Ă  considĂ©rer qu’elle n’est pas applicable aux cas d’espĂšce du logiciel libre. Une discussion donc tout Ă  fait acadĂ©mique mais sans impact sur la rĂ©alitĂ©. ↩