Blog d'Hugo

Cette année, une petite nouvelle est arrivée dans le monde des licences de logiciel libre : la seconde version de la licence publique Mozilla (MPL 2.0). Elle n’est pas totalement nouvelle, car elle garde l’esprit général de la première version puisqu’il s’agit d’une licence de faible copyleft. C’est-à-dire que cette licence permet dans une certaine mesure — assez large — de combiner du code régi par la MPL avec du code sous une autre licence (y compris propriétaire). Pour autant, des modifications apportées aux fichiers du code MPL doivent être régies par les mêmes obligations : mise à disposition du code source, notifications des droits des utilisateurs (droits d’utiliser, de partager, d’étudier le fonctionnement et de publier des modifications — la définition d’un logiciel libre).

Ainsi, la MPL est un bon compromis, entre d’un côté les licences « académiques » (BSD, MIT) et de l’autre, les licences copyleft¹ fortes comme la licence publique générale GNU. Mais comme tout compromis, la MPL souffre des inconvénients incombant à chacun des deux modèles de licence.

Il y a cependant des qualités indéniables à la MPL 2.0, que j’ai voulues résumer ici :

La certitude d’une approche technique du copyleft plutôt que juridique

C’est la principale qualité du copyleft à la sauce Mozilla : la portée de celui-ci se limite aux « Modifications » telles que définies par la MPL 2.0, c’est-à-dire tout fichier originellement sous MPL qui a été modifié, et tout nouveau fichier qui contient du code originellement sous MPL. Pour faire simple : tant qu’on ne touche pas à un fichier du code sous MPL, on est en dehors du cadre d’application de son copyleft.

Cette façon de procéder contraste largement avec le fonctionnement des licences GNU dont la portée du copyleft s’apprécie juridiquement, car celui-ci s’applique aux œuvres dérivées (derivative works en copyright). Or pour déterminer s’il s’agit d’une œuvre dérivée ou non, il faut à la fois solliciter des approches juridiques et techniques. Ça ne veut pas dire pour autant que cette solution est plus compliquée, ni moins sûre (il y a consensus) mais il reste des zones à clarifier (on peut voir un essai de catégorisation de plusieurs cas de figure où le copyleft s’applique ou ne s’appliquerait pas).

Compatibilité avec les autres licences libres importantes.

• Licence Apache 2.0 : les conditions de respect des obligations de la MPL 2.0 relatives aux brevets ont été calquées sur celles de la licence Apache, de telle façon que la satisfaction des conditions de la MPL 2.0 satisfait celles de la licence Apache 2.0. En d’autres termes : incorporez du code Apache 2.0 dans du code MPL 2.0, tenez-vous aux obligations de la MPL 2.0 et vous aurez de facto respecté celles de l’Apache 2.0.
• Licences GNU GPL, AGPL, LGPL versions 2 ou ultérieures : cette compatibilité est rendue difficile par les différences d’appréciations de la portée du copyleft. Auparavant, Mozilla avait recours pour cela au double-licenciement; les logiciels étaient à la fois publiés sous les termes de la MPL 1.1 et de la GNU GPL par exemple. Cela menait à des bifurcations, puis à des incompatibilités.

  La MPL 2.0 a adopté une meilleure solution, qui déclare explicitement la compatibilité avec les licences GNU². On peut donc incorporer du code MPL 2.0 à du code GPL 3.0 par exemple, et distribuer le tout sous licence GPL 3.0 — tout en donnant la possibilité à celui qui reçoit l’ensemble de continuer à bénéficier de la portion du code MPL 2.0 sous cette licence.

  Du côté des projets et des distributeurs de logiciels en aval, cette compatibilité simplifie grandement l’analyse du jeu de licences et leur travail de documentation, etc.

Changement de la clause de défense contre les brevets.

À l’heure où la guerre nucléaire sur les brevets est déclarée, on sait l’importance de ces clauses anti-brevets dans les licences de logiciels libres qui se sont développées depuis la version 1.1 de la MPL (1998). On peut dire en quelque sorte que ces clauses sont à la guerre des brevets, ce que les traités SALT sont aux armes nucléaires : des accords mutuels de non-agression.

Le licencié d’un logiciel sous MPL bénéficie de droits accordés par ses contributeurs. Si celui-ci engage des poursuites contre quiconque pour violation de brevets par le logiciel sous MPL, alors il perd tous les droits (droits d’auteur et droits sur les brevets des contributeurs) dont il avait bénéficié jusqu’alors grâce à la MPL.

Cette clause de défense contre les attaques pour violation de brevets (attaques souvent abusives, sur des brevets parfois invalides ou fantasques) est une avancée majeure par rapport à la version 1.1 de la MPL — laquelle avait une clause à la fois bien trop large puisqu’elle se déclenchait pour toutes poursuites de violation de brevets, y compris les brevets qui n’avaient rien à voir avec le logiciel sous MPL ; et à la fois bien trop restreinte puisqu’elle ne concernait que la poursuite d’ayant-droits du logiciel sous MPL, laissant les autres sans protections.

Dans l’ensemble, il faut saluer le travail de Mozilla qui a conduit la rédaction de cette version de la MPL. Il s’agit sensiblement d’une amélioration, qui a su garder les qualités inhérentes à la MPL tout en corrigeant les problèmes pratiques et en s’adaptant aux problématiques d’aujourd’hui notamment dans cette lutte contre les brevets qui, chaque jour, menacent les développeurs de logiciel.

En anglais : Articles de Luis Villa, qui a mené ce travail de rédaction de la MPL 2.0 ; Un article de Richard Fontana (RedHat) ; Communiqué de la FSF ; et enfin, le texte de la licence.

Notes :