Dans mon entreprise, on utilise des logiciels libres. Il arrive qu’on aie besoin de modifier ces logiciels tiers, pour gérer un cas spécifique ou pour une meilleure intégration dans l’application.
Et parfois, en se lançant dans ce genre de travaux, on tombe sur une surprise :
Il existe des logiciels libres dont il est presque impossible d’utiliser les libertés sans une quantité déraisonnable de travail.
Je ne parle pas d’openwashing ici, cette technique qui consiste à faire croire qu’un logiciel est libre mais ne l’est pas. Non, je parle de programmes véritablement libres (sous licence Apache ou MIT généralement, notre code n’étant pas libre ça ne peut être des licences contaminantes comme la GPL) mais dont les subtilités font que… visiblement quelqu’un ne veut pas que les libertés soient trop utilisées. On notera déjà que c’est souvent des logiciels dont il existe une version avancée commerciale.
Les libertés d’exécution et de redistribution sont généralement faciles à appliquer ; le problème survient souvent quand on veut étudier le programme et l’améliorer. Voici quelques exemples de techniques utilisées ; certaines peuvent être expliquées par un simple manque de volonté d’adhérer à l’esprit du logiciel libre ou par une mauvaise organisation interne ; d’autres s’approchent du sabotage. Dans tous les cas, la licence est respectée à la lettre.
Toutes les techniques ci-dessous ont été croisées dans des cas réels (heureusement pas toutes sur le même projet) :
Aucune documentation technique
Il n’existe aucune documentation technique d’aucune sorte. Selon la taille du logiciel, ça peut être plus ou moins gênant (je vous laisse imaginer quand le workspace du projet fait plusieurs centaines de Mo).
Parfois, rien qu’obtenir une version exécutable du logiciel à partir des sources est un calvaire.
Une version avancée consiste à utiliser des frameworks, compilateurs ou réglages exotiques, sans que ce soit documenté publiquement.
Les dépendances cachées
Les dépendances du projet vont par défaut se télécharger depuis un serveur qui appartient à la même organisation que le projet, et pas depuis les dépôts standards. Et surprise, ce serveur ne contient (en public) que les dernières versions des dépendances.
Au pire, ces dépendances sont elles-mêmes libres, on peut toujours aller les chercher et les compiler à la main, mais la quantité de travail pour obtenir une version fonctionnelle explose dès qu’on veut autre chose que la toute dernière version. Et je ne parle pas de la galère quand on veut mettre à jour un fork depuis l’origine.
Le faux dépôt de sources
Celle-ci est subtile : le dépôt des sources public n’est d’évidence pas un dépôt de travail, puisqu’il ne contient qu’un seul commit par version, sans le moindre commentaire. Ça n’est pas gênant tant qu’on essaie pas de maintenir un fork.
La version avancée, qui consiste à ne fournir les sources que sous la forme d’un dossier compressé sans le moindre historique, semble avoir à peu près disparue, du moins dans mon domaine.
Le tapis et le labyrinthe mouvant
Deux variantes d’une même technique :
- Les sources peuvent être planquées à un endroit inaccessible, voire carrément absentes du site éditorial – rien, pas même un lien, pas même une mention claire de la licence : si tu ne sais pas déjà que le logiciel est libre… tu le découvres en lisant la licence après avoir donné toutes tes informations pour la fameuse « version de démonstration 30 jours ».
- Le site change tout le temps, et la manière d’accéder aux sources n’est jamais la même d’un mois sur l’autre.
À noter que quelques entreprises ne fournissent les sources qu’aux clients de l’entreprise, ce qui est généralement autorisé.
Une variante intéressante du point 2, c’est quand le logiciel change régulièrement de grands pans de son architecture.
Le code qui fait des suppositions sur l’environnement de développement
Généralement à base de chemins en dur dans le code ou de réglages spécifiques à un IDE. C’est rare, mais on en croise…
La ressource libre-mais-déposée
Ici ça s’applique plus aux ressources qu’au code, principalement aux logos : votre ressource est libre, mais est une marque déposée. Il y a plein de cas où on ne peut pas l’utiliser. Par exemple, le logo GNU n’illustre pas cet article, parce que, je cite (le gras est d’origine) :
Ce dessin est utilisable conformément à la GNU FDL v1.3, à la licence Art libre ou à la Creative Commons CC-BY-SA 2.0 (résumé en français ici). Toutefois, c’est aussi un logo déposé du projet GNU. Si vous voulez vous servir de cette tête de GNU pour mettre en lien un site web de la Free Software Foundation ou du projet GNU, n’hésitez pas ; de même, vous n’avez pas besoin de permission supplémentaire pour l’utiliser dans des contextes qui parlent de GNU de manière positive et exacte. Pour tout autre usage, veuillez au préalable demander la permission à licensing@fsf.org.
Et donc ce logo est disponible sous 3 licences libres différentes, mais a des restrictions très fortes sur l’usage qui peut en être fait. C’est en fait valable avec à peu près tous les logos et toutes les marques – et les règles d’utilisations de logos et marques d’entreprises peuvent être bien plus restrictives.
La conclusion de tout ceci ?
Qu’un logiciel soit libre n’impose pas que son développeur doive vous faciliter l’application des libertés.
C’est quelque chose qu’on croit trop souvent, de même qu’on mélange souvent « libre » et « gratuit ».
