(cet article nécessite un minimum de connaissances sur les licences libres)

Il y a quelques mois, j’ai écrit un article sur les licences libres sur un autre de mes sites. J’y citais, au même titre que d’autres licences, la EUPL (European Union Public License).

Petite parenthèse sur la licence EUPL : Il s’agit d’une licence libre « à copyleft », assez similaire à la GNU GPL. Son texte est d’une grande clarté et d’une grande précision. Elle est traduite en 23 langues, qui sont toutes d’égale valeur d’un point de vue juridique, et est compatible avec un grand nombre de licences libres (GPL, LGPL, AGPL, MPL, CeCILL, etc.). En résumé, c’est une licence libre de très grande qualité, dont l’utilisation est à considérer sérieusement.

Suite à cet article, j’ai été contacté par le juriste qui dirige le travail sur cette licence. L’échange que nous avons eu a été particulièrement riche et intéressant. Un point m’a semblé potentiellement explosif et j’ai eu envie de le partager ici.

Différence entre GPL et LGPL

Revenons un peu en arrière et parlons de la différence entre les licences GPL et LGPL, qui sont deux licences libres très connues. Pour schématiser, ce sont des licences libres à copyleft qui ont été créées à une époque où le développement se faisait principalement avec des langages compilés (typiquement le C).

Du code sous licence GPL ne peut être lié (« linké » en anglais) qu’avec du code placé aussi sous licence GPL. Donc si quelqu’un crée une bibliothèque de fonctions (une « librairie » pour continuer avec les anglicismes) et la place sous GPL, elle ne pourra être utilisée que par des logiciels qui sont sous GPL.

La LGPL a justement été conçue pour les librairies, pour qu’elles puissent être liées à du code propriétaire (= non libre). Cette licence permet d’avoir du code libre, dont les dérivés restent libres (grâce au copyleft), mais qui peut être intégré à n’importe quel logiciel, quelle que soit sa licence (libre ou propriétaire).

Droit des interfaces

Comme je le disais plus haut, la EUPL est similaire à la GPL. Mais l’Union européenne ne propose pas de licence similaire à la LGPL.

J’ai demandé pourquoi le cas de figure traité par la LGPL n’a pas été pris en compte par la EUPL. La réponse est que, dans le droit européen (directive 2009/24/CE, paragraphes 10 et 15), les interfaces ne sont pas soumises au copyright.

On peut remplacer le terme « interface » par « API ». On peut imaginer sans effort que la définition d’une API web n’est effectivement pas protégeable : un contrat d’interface ne représente pas une implémentation. Cela garantit l’interopérabilité entre des logiciels indépendants les uns des autres. Concrètement, un logiciel propriétaire peut se connecter à une API REST et utiliser cette API pour échanger des données, même si le code qui est derrière cette API est sous licence libre.

Par extension, lorsqu’un programme utilise une librairie externe, le « linking » pourrait être vu comme l’utilisation d’une interface, et donc ne pourrait pas être protégé pour garantir l’interopérabilité.
Entendons-nous bien : si j’utilise le conditionnel, c’est parce qu’il s’agit d’un point de vue qui ne fait pas consensus. En Europe, il semblerait que cette règle s’applique. Par contre, la FSF (Free Software Foundation) considère que le fait de lier deux logiciels propage la licence GPL de l’un vers l’autre. Cette vision est d’ailleurs combattue par d’autres américains comme Lawrence Rosen.

Remise en question des licences libres

Si on met toutes choses ensemble, si on emboîte les concepts comme les pièces d’un puzzle, on en arrive à l’idée qu’il n’est pas possible d’empêcher un code propriétaire de s’interfacer avec une librairie sous licence GPL.

En fait, quelle que soit la licence d’un bout de code, rien n’empêche de l’utiliser à partir d’un autre bout de code, même si leurs licences sont censées être incompatibles ! Voilà qui remet en question une bonne partie de l’utilité des licences libres (je vous disais que c’était potentiellement explosif)…

C’est d’ailleurs pour cette raison que la licence EUPL n’a pas d’équivalent à la LGPL. Quelle que soit la manière utilisée par un code propriétaire pour s’interfacer avec du code libre (API REST, linking entre fichiers compilés, fichier PHP copié au milieu du projet), il est possible d’argumenter le fait que cet interfaçage est une cloison étanche du point de vue des licences.

Le seul cas qui semble incompatible avec cette vision est lorsque le code est directement compilé ensemble. Mais cela peut être contourné en le découpant en librairies séparées qui font appel les unes aux autres.

Allons un peu plus loin

Intéressons-nous aux langages « modernes », ceux qui sont interprétés et/ou compilés à la volée (PHP, Python, Lua, Javascript, Ruby, Perl, etc.). Dans ces langages, l’équivalent d’une bibliothèque de fonctions n’est pas un fichier compilé avec lequel un programme va être lié ; c’est un ou plusieurs fichiers contenant du code source, auxquels le programme va accéder. Chaque fichier contient sa propre interface, sous la forme des signatures des fonctions, des objets et des méthodes qu’il contient.

Si chaque fichier est vu comme étant un élément autonome, qui offre sa propre interface, et que l’accès à une interface ne propage pas la licence, cela veut dire qu’il peut être copié au milieu du code propriétaire, toujours sans violation de licence. Tant que les fichiers ne sont pas modifiés, il n’y a plus de différence entre les fichiers sous licence libre et ceux sous licence propriétaire, ils font tous partie du projet de manière identique.

Le copyleft est-il encore utile ?

La notion de copyleft est utilisée par la FSF pour dire que lorsqu’un code sous GPL est utilisé dans un projet, l’ensemble du projet doit se retrouver sous licence GPL. C’est l’aspect « viral » du copyleft.

Mais si on considère que les interfaces sont imperméables aux licences, et que chaque fichier porte sa propre interface, que reste-t-il du copyleft ?
Il reste qu’il s’applique toujours aux fichiers eux-mêmes. En cas de modification d’un code source placé sous licence libre à copyleft, la version modifiée doit rester sous la même licence. La communauté continue à bénéficier du travail qui est effectué sur ce code.

Par contre, la viralité du copyleft est profondément remise en question. Il ne suffit plus que du code sous copyleft soit utilisé dans un projet pour qu’il propage sa licence à l’ensemble du projet.

Je ne m’explique pas que cette question ne soit pas plus médiatisée, alors que la directive européenne a été publiée en 2009.