Quand le logiciel libre dépend du logiciel privateur
par Richard StallmanLorsqu'un programme est un logiciel libre (libre comme dans liberté de parole), cela signifie qu'il offre à ses utilisateurs les quatre libertés, de telle sorte qu'ils contrôlent ce que fait le programme. Dans la plupart des cas c'est suffisant pour que la distribution du programme soit éthique, mais pas toujours. D'autres problèmes peuvent apparaître dans des circonstances précises. Cet article vise à décrire un problème subtil dans lequel la mise à jour d'un programme libre requiert l'usage d'un programme privateur.
Si l'utilisation du programme libre dépend inévitablement d'un programme privateur tiers, nous disons que le programme libre est « piégé ». Son code est du logiciel libre et vous pouvez donc en copier certaines parties dans d'autres programmes libres, ce qui donnera de bons résultats, des résultats éthiques. Mais vous ne devez pas exécuter le programme piégé, car cela implique d'abdiquer votre liberté en faveur du programme privateur.
Une personne adhérant aux principes du logiciel libre ne créera pas volontairement un programme piégé. Cependant, de nombreux programmes libres sont développés par des gens ou des entreprises qui ne soutiennent pas particulièrement ces principes ou qui ne comprennent pas le problème.
La dépendance vis-à-vis d'un programme privateur peut prendre diverses formes. La plus basique se rencontre lorsque le langage utilisé n'a pas d'implémentation libre. Les premiers programmes que j'ai écrits pour le système GNU dans les années 80, y compris GNU Emacs, GDB et GNU Make, devaient être compilés avec le compilateur C privateur d'AT&T, car il n'existait pas de compilateur C libre jusqu'à ce que j'écrive GCC. Heureusement, ce genre de problème est le plus souvent de l'histoire ancienne et nous avons désormais des compilateurs et des plateformes libres pour tous les langages utilisés pour écrire des logiciels libres.
Nous pouvons libérer un programme de ce genre de piège en le réécrivant dans un autre langage, ou en fournissant une implémentation libre du langage dans lequel il est écrit. Ainsi, lorsqu'une implémentation libre de Java a été disponible, cela a sorti tous les programmes libres écrits en Java du piège Java.
Ce genre de dépendance est simple à concevoir, car elle résulte d'une situation à un moment donné. À l'instant T, le programme libre P ne pourra pas s'exécuter sans la plateforme privatrice Q. En termes linguistiques, on dira que cette relation est « synchronique ».
Plus récemment, nous avons remarqué un autre type de dépendance dans des programmes de base de données dont on peut compiler et exécuter n'importe quelle version librement, mais dont la mise à jour de la version N vers la version N+1 nécessite un logiciel privateur.
Ceci se produit parce que le format interne de la base de données change entre les versions N et N+1. Si vous avez utilisé la version N de manière intensive, il est probable que vous avez une importante base de données au format N. Afin de procéder à la mise à jour vers la version N+1 de ce logiciel, vous devez reformater votre base de données.
Si vous êtes censé faire ce reformatage en exécutant un logiciel privateur ou en ayant recours au service en ligne du développeur, un SaaSS (service se substituant au logiciel), le programme de base de données est piégé, mais d'une façon plus subtile. N'importe quelle version de ce programme peut être utilisée sans avoir besoin de logiciel privateur ni de SaaSS. Le problème survient lorsque vous tentez d'en faire usage sur le long terme, ce qui implique de le mettre à jour de temps en temps ; ce n'est pas possible sans un logiciel privateur ou l'équivalent. Ce programme de base de données est piégé dans le temps, nous pouvons donc dire qu'il est piégé de manière « diachronique », pour emprunter un autre terme linguistique.
Par exemple, le programme OpenERP (renommé depuis « Odoo »), bien que libre, est diachroniquement piégé. GNU Health, notre logiciel libre de gestion des centres médicaux, utilisait initialement OpenERP. En 2011, le développeur de GNU Health, Luis Falcón, a découvert que la mise à jour vers une nouvelle version d'OpenERP nécessitait l'envoi de la base de données (remplie des données médicales des patients) au serveur d'OpenERP afin d'être reformatée. C'est du SaaSS : il exige de l'utilisateur de GNU Health (un centre médical) qu'il confie son système informatique et ses données à la société développant OpenERP. Plutôt que de s'incliner, Falcón a réécrit GNU Health afin qu'il utilise Tryton à la place.
Utiliser un SaaSS est intrinsèquement équivalent à l'utilisation d'un logiciel privateur contenant des fonctions d'espionnage ainsi qu'une porte dérobée universelle. Ce service peut garder une copie des bases de données que les utilisateurs reformatent. Même si nous pouvons faire confiance à la société assurant le service pour ne jamais divulguer intentionnellement les données à quiconque, sous quelque forme que ce soit, nous ne pouvons pas être sûrs que ces données seraient à l'abri des agences de renseignement de divers pays ou des crackers de sécurité informatique (merci de ne pas les appeler « hackers »).
Lorsqu'un programme est piégé diachroniquement, le libérer de ce piège nécessite plus qu'une simple étape de programmation. Il s'agit plutôt d'un travail récurrent, devant être fait à chaque changement du format de données. Se lancer dans un projet en s'engageant à faire cela régulièrement sur le long terme n'est pas facile. Il est peut-être plus facile de faire pression sur la société pour qu'elle cesse de piéger les utilisateurs, en refusant d'utiliser le logiciel piégé jusqu'à ce qu'elle obtempère. Vu la difficulté de libérer le programme, mieux vaut ne pas l'utiliser du tout.
Il est possible d'essayer un logiciel libre diachroniquement piégé sans recourir à du logiciel privateur, mais si c'est pour faire plus que jouer avec, vous devez vous garder de l'utiliser pour de bon. Entreprises et particuliers trouveront facilement d'excellentes alternatives libres ne souffrant pas d'un tel problème ; pour éviter le piège il suffit de savoir le reconnaître.