Les pièges de certains composants open source

🇫🇷 – dimanche 9 janvier 2022

Mots clés : #opensource, #FLOSS, #GitHub, #licences, #social

D'ordinaire nous aimons utiliser des bibliothèques tierces dans nos projets, ces “librairies” que l'on retrouve par exemple sur des forges logicielles publiques comme GitHub et GitLab. Rares sont les logiciels qui ne possèdent pas une once de FLOSS (Free Libre and Open Source Software) à l'intérieur. Le plus souvent, on retrouve dans chaque projet des composants FLOSS, que ce soit pour se faciliter la vie, écrire des tests unitaires ou gérer une base de données par exemple. On a vite tendance à prendre l'outil le plus connu, le plus répandu, ou à faire des réflexions trop rapides pour choisir ce dont on a besoin, et pourtant il y a des pièges à éviter.

Tout le monde est juriste, évidement !

Beaucoup (trop) d'entre nous ne considèrent pas suffisamment la licence qui est appliquée à la libraire choisie ; par paresse intellectuelle, par pure fainéantise, par certitude de bien comprendre les licences, par oubli, ou par excès de confiance. On fait tous la boulette, et on en tire des leçons ensuite, ce n'est pas si anormal quand encore aujourd'hui dans les établissements de formation à l'ingénierie logicielle ou “les écoles de codage” on en parle assez peu, ou pas assez, voire pas du tout. Merci les formations au rabais vendeuses de rêves laissant leurs apprenants se fracasser sur le mur de la réalité.

Toutefois, parmi les pièges dans lesquels chacun et chacune peuvent plonger, il y en a particulièrement qui sont beaux. Et grossiers. Et pourtant, beaucoup de personnes se font avoir, et ne finissent par réagir que lorsque le sujet est médiatisé. Avant de se jeter sur le dernier composant à la mode, regardons en détails les pièges, en commençant par les licences évidemment.

Des clauses déloyales dans les licences

Par exemple, il y a quelques années, on pouvait trouver les frameworks React de Facebook / Meta sous une curieuse licence “BSD + Patents”. Le truc, c'est que cette licence possède des clauses relatives aux brevets (une vague idée ici). Si j'exagère et grossis les choses, le fait de chercher des noises en justice à Facebook à l'époque pouvait faire tomber le droit que vous aviez d'utiliser ses cadriciels (j'adore ce mot). Pot de terre contre pot de fer dans du béton armé, embêter Big F peut revenir à vous interdire d'utiliser ses technos, donc à retirer beaucoup de produits. Une fois la chose médiatisée, finalement Facebook changea son fusil d'épaule et utilisa la licence MIT.

Bref, attention aux clauses déloyales des licences !

Des changements radicaux de licences

Récemment encore, c'est HashiCorp qui changea brutalement la licence de son produit phare nommé Terraform, et l'entreprise est dans son bon droit. Le passage de la licence MPL 2.0 à la Business Source License a été fait avec fracas, justifié maladroitement par l'entreprise et décrié par la communauté open source. MongoDB a eu droit aussi auparavant à son concert de casseroles avec le passage à la SSPL. Pour aller plus loin, MariaDB propose cette page de FAQ sur la BSL. Benoit Sibaud (un chouette collègue chez Orange !) a rédigé et diffusé un billet abordant les “virevoltantes valses de licences libres et non libres dans les bases de données”, très instructif ! En d'autres termes, attendez-vous à peut-être voir des revirement de situations dingues sur les licences appliquées !

Le truc, c'est que quand bien même une entreprise décide d'agir ainsi, elle reste tout de même légalement dans l'obligation de satisfaire les demandes qui concernent les licences anciennement appliquées. Autrement dit, si à un instant T un composant C était sous une licence libre L (admettons GPL 3.0), mais que plus tard cette licence passe à une bullshit licence BL, si vous avez eu le composant sous licence L vous êtes en droit de demander les sources (si L l'autorise évidement), même si elles ne sont pas accessibles publiquement. Bon courage donc.

On peut ainsi imaginer jouer la prudence, et se dire que si on utilise des composants FLOSS, dans le doute, au cas où, on pourrait garder une copie du code source. J'apprécie beaucoup cet article de Geoffrey Dorme qui vous donnera davantage de motivations à le faire. En plus cloner les dépôts Git d'une organisation GitHub c'est facile pour l'instant.

Imaginez maintenant, malgré les trahisons précédentes, que certaines technos soient si répandues qu'elles en deviennent presque indispensables pour des entreprises, au hasard les frameworks comme React. Rien n'empêche Facebook / Meta du jour au lendemain de changer la licence, de rendre l'exploitation de l'outil payante, et de monter un vrai business model dessus. Un magnifique coup à jouer maintenant que le place est faite dans l'écosystème logiciel. Impossible ? C'est vite oublier le ramdam lorsque Oracle avait mis en place son JDK payant.

Mais il y a d'autres pièges plus gros encore...

L'ajout de clauses additionnelles

Prenons par exemple une librairie Java bien connue, qui est utilisée en production : Realm Java (la situation a été corrigée depuis, mais a trainé un bon moment tout de même pour que ce soit notable).

À première vue, si on regarde le README vaguement, on voit ceci :

On peut alors en déduire que le composant est sous licence open source Apache 2.0. Sauf que trop de gens s'arrêtent là. Car que si on jette un œil au fichier de licence, on trouve certes des références à la licence Apache 2.0, mais aussi un autre élément d'enfoiré : l'export compliance.

Vous pouvez retrouver le diff du commit sur GitHub, je vous met ci-dessous le contenu scélérat de cette clause, qui rend la licence non conforme à la définition donnée par l'OSI, donc plus open source du tout.

Pour celles et ceux qui n'ont plus assez de caféine dans le sang pour comprendre, voici un résumé : si on se retrouve sur une liste noire du gouvernement américain, que ce soit dans un pays, ou individuellement, ou dans une entreprise détenue par une personne dans cette liste noire, on ne peut pas utiliser ce produit.

En soit, quel est le soucis ?

Et bien le soucis est que l'on peut avoir des applications critiques ou indispensables, ou son produit tout bêtement qui, si un jour le client, l'éditeur, le pays, les actionnaires etc. sont dans le collimateur des États Unis d'Amérique, peuvent être dégagées des boutiques d'applications, avec toutes les conséquences que ça implique.

On peut espérer que ça n'arrivera jamais, ceci dit l'ère Trump a montré qu'il ne fallait pas grands choses pour que des fous furieux mettent la pagaille à l'échelle mondiale en interdisant l'usage de produits. Et le contexte international actuel ne rassure pas non plus vis à vis de la Russie. Demandez leur avis aux iraniens, cubains, ukrainiens ou chinois.

Bref, dit autrement, quand vous utilisez une librairie FLOSS, regardez sur GitHub la section dédiée à la licence. Si le texte “View licence” apparaît au lieu du nom de la licence, il y a deux cas de figure :

• le texte a été modifié (souvent les copyrights) ou décoré faisant que GitHub s'y perd ;
• il y a du texte en plus dans le fichier. Ceci pouvant être des détails sur d'autres licences appliquées ou d'anciens contributeurs, ou des clauses additionnelles.

Et oui, tout ça en droit français est valable.

Mais où ailleurs peut-on se faire avoir ?

La plaie de l'excès de social dans les forges logicielles

Et si on regardait le nombre de commits ?

Déjà, pour “évaluer” un composant FLOSS, on peut regarder par exemple la vie de son code source. Ainsi, si un projet a des commits faits régulièrement, on serait en droit de se dire qu'il est toujours vivant. Toutefois la contraposée est fausse car on peut très bien avoir des projets FLOSS qui semblent “vivoter”, avec peu de commits réguliers mais qui fonctionnent très bien, tout simplement car le projet en lui-même peut être maintenu ponctuellement, discrètement, mais efficacement.

D'ailleurs regarder la date et le nombre de commits est aussi une fausse bonne idée, car par exagération on pourrait croire qu'un projet qui a beaucoup de commits est un projet de qualité, et fiable, ce qui est absurde. Dans la mesure où des outils comme Git permettent le squashing, les merge commits et le rebasing, on remarque bien que se fier uniquement à un historique de commits n'est pas viable. De plus, doit-on vraiment prendre en compte les commits et pull requests ridicules qui arrivent lors du Hacktoberfest quand celles et ceux qui les proposent veulent juste profiter du moment pour avoir un joli badge sur le profil GitHub par pur opportunisme ?

Est-ce que pour l'exemple ci-dessous le projet est vivant ou mort ? On peut s'y fier ou pas ? Pour faire des confettis, c'est suffisant ?

Et Si On RegArDaIt LeS LiKes eT LeS FoLlOwErS ?

Les réseaux sociaux ont amené du pire dans GitHub avec les “likes” et les compteurs de “followers”.

Cet autre piège à éviter consiste à se contenter de regarder ces nombres de stars et de forks d'un projet sur la forge logicielle que l'on veut. Avec l'avènement des réseaux sociaux, on veut “liker”, “booster”, “up-voter” ou “starrer” des projets que l'on aime bien, ou que l'on pourrait aimer, ou pour faire plaisir au gars derrière qu'on connait. Mais en soit, ni le fonctionnel ni la qualité du projet ne sont par essence et par définition concernés. Il en est de même pour les forks ; il est courant de voir des utilisateurs en crééer juste... au cas où, pour grossir son profil GitHub, ou pour faire une pull request un jour ou pas. Surtout ou pas. Quand au nombre de “followers” du développeur principal, en quoi le fait qu'il en ait 2 300 au moins soit rassurant ? Le personnage peut être tout à fait exécrable, pénible voire même adepte de la pizza avec des patates dessus, pourquoi afficher cette fausse notoriété qui n'apporte rien ?

Est-ce que l'exemple ci-dessous est un gros projet ? Un truc balèze ? Non, c'est juste un programme affichant un train à vapeur si on se trompe de commande (moi j'adore).

Oh, et puis, bien évidemment, on peut acheter des “stars” sur GitHub à prix réduit ! La plaie du social jusqu'aux forges logicielles, et à portée de main. Cet article est très instructif sur le sujet.

Environnement et qualité, beau code ou infect projet

On regarde les issues et requests ?

Un autre élément à considérer avec prudence est le nombre de issues et de pull requests / merge requests. En effet, un projet qui en possède beaucoup peut être un projet très vivant, comme aussi un projet qui est très à l'abandon mais avec une base d'utilisateurs réclamant des choses ou voulant contribuer sans personne derrière pour valider. Ou alors peut être victime de trolls, comme ce fut le cas pour le dépôt contenant l'algorithme de recommandations de Twitter. Prudence donc si on ne regarde que ces éléments sans les contextualiser.

On regarde les contributeurs ?

Chose intéressante aussi à voir, les contributeurs, ces petites mains visibles fournissant un incroyable travail.

Si vous utilisez un composant FLOSS avec un faible nombre de contributeurs, il est possible que derrière ce projet il n'y ait presque personne en dehors de quelques passionnés dévoués (bénévolement le plus souvent) à leur projet (pour la gloire plus que pour l'argent). Il faut donc se demander si le fait que le projet repose sur un tout petit nombre de contributeurs est bloquant ou pas. Pour une librairie affichant de confettis c'est peut-être un élément peu pertinent. Mais pour votre couche de chiffrement, est-ce une bonne idée de compter sur un seul péquin derrière ?

D'ailleurs, question bête, est-ce que l'on suppose que la source de vérité est... fiable ? Car pour être affichés comme contributeurs sur un projet GitHub, il faut apparaître à certains endroits dans les commits. Quid des personnes voulant rester anonymes ? Des personnes en pair-programming ? Ou d'une organisation faisant que le mainteneur principal s'acharne maladroitement à garder un historique Git propre et donc fait du copier/coller des pull requests mais en gardant à jour le fichier AUTHORS par honnêteté intellectuelle ? Ou des robots qui exécutent des tâches automatisées sur le dépôt et qui figurent dans les contributeurs ?

Ci-dessous un exemple, avec le projet Amaroq. A-t-on vraiment 13 contributeurs ou 1 seul ? D'ailleurs peut-on vraiment se contenter de mesurer l'activité par le nombre de commits ? Non, évidemment.

En parlant de commits et des contributeurs, peut-on vraiment faire confiance aux contributions ? Il y a des projets FLOSS qui exigent des signatures cryptographiques des commits d'une part, et que le Developer Certificate of Origin soit appliqué d'autre part. Engager les responsabilités de chacun et s'assurer que les commits soient intègres ne semble pas une mauvaise idée, mais a-t-on toutes et tous l'habitude de le faire ? Non. Méconnaissance ou fainéantise ?

La doc ?

D'ailleurs, on peut aussi regarder les échanges qui ont lieu dans les issues, les Slack ou Mattermost. Pour ce composant FLOSS qui vous intéresse, peut-être ne seriez-vous jamais amenés à échanger avec les mainteneurs derrière. Mais si vous voulez contribuer, êtes-vous prêts à dialoguer avec une équipe ayant une organisation pyramidale ? Ou concentrée sur un développeur quasi-messianique à qui tout le monde demande son avis et attend son accord ? Est-ce que l'ambiance est délétère dans le projet ?

On regarde le code source alors ?

Par ailleurs, jetez un œil aussi au code source en lui-même.

Si vous avez un projet iOS écrit en Swift, avec uniquement des compétences en Swift dans votre équipe, seriez-vous prêt à soumettre des pull requests sur un composant écrit en bon vieux Objective-C à la papy ? Si une librairie JavaScript vous plait pour faire des jolies animations, ça vous tente vraiment de l'utiliser sachant qu'elle va tirer jQuery et que vous êtes fiers de vous en être débarrassés y'a 2 ans ? Si le CERT signale de vulnérabilités critiques, et que le composant que vous voulez est concerné, comment et à quelle vitesse sont corrigées ces failles ? Il y en a certaines qui ne le sont toujours pas ? Et ils feront comment si le Cyber Resilience Act passe ? Si on voit plusieurs issues sur des vulnérabilités non corrigées, remontées par Dependabot ou Snyk peut-on nécessairement en conclure que ce composant est dangereux alors qu'un autre sans de telles choses le serait moins même si finalement il pourrait n'avoir en place aucun outil de détection ?

Les gens c'est bien aussi non ?

Truc rigolo, vous connaissez le développeur / grand chef derrière le composant que vous voulez ? Car peut-être politiquement engagé ou susceptible, ou impulsif, ou infect, et qu'il va saboter son projet ou pas, quitte à se faire virer de GitHub. Impossible ? Voyez plutôt.

D'ailleurs, pourquoi c'est là ?

Ce n'est pas parce que le code est sur GitHub, avec une licence libre ou open source que forcément cela a été fait avec une volonté de respecter la philosophie de l'un ou la méthodologie de développement de l'autre.

Par exemple le code a très bien pu être publié juste pour des raisons de transparence totalement opportuniste comme l'algorithme de recommandation de Twitter, maintenant X. Ou alors le code est publié car il embarque un composant sous licence à copyleft fort qui implique une mise à disposition du code source. D'autres projets peuvent être open source pour attirer des contributeurs très rapidement et aussi éviter toute polémique en pleine période de crise, tant sur le manque de fonctionnalités que sur le fonctionnement, sans pour autant avoir des perspectives sur le long terme. Ou alors certains projets décident de se mettre en open source pour faire comme les concurrents et tout avoir public et sans vraiment de contributions venant de l'extérieur, pour le moment, ce qui est dommage car la qualité du produit est là. Ou juste pour montrer ce qu'ils savent faire mais avec des licences ni libre ni open source, pour avoir quelques contributions mais juste avec le code source public. C'est trompeur, mais correct. Mais on a aussi des dépôts open source car une communauté s'est formée autours de l'outil, et là c'est chouette. Plus chouette qu'exposer des projets comme des design system alors que les seuls utilisateurs pourraient être des filiales ou partenaires, qui se serviront gratuitement, plutôt que d'être facturés.

Bref... ce n'est pas parce que le produit est joli sur la vitrine, bien placé en tête de gondole avec un emballage coloré qu'il faut forcément sauter dessus. C'est bien de regarder la date limite de consommation, les ingrédients, les excipients et les origines.

Du coup...

Du coup, il n'y a pas de bons ou de mauvais composants FLOSS. Et non, cette réflexion n'est pas de la “branlette intellectuelle”, bien au contraire. Certains composants sont d'apparence plus fiables que d'autres, il faut les juger par leur efficacité mais pas uniquement ceci dit. Il faut rester prudent sur les licences altérées, bâtardes ou simplement sur leur nature intrinsèque. S'intéresser à l’environnement, à l'ambiance, aux commits et au code source est une bonne chose également.

Il faut aussi envisager le fait qu'un projet finisse par mourir, que sa core team abandonne, que le moteur s'épuise. N'attendez pas pour les soutenir. N'attendez pas pour contribuer. N'hésitez pas les soutenir s'ils défendent des causes justes. L'open source c'est comme une kombucha : c'est super de récupérer une souche mère pour faire vos boissons, mais c'est mieux de partager vos souches filles à d'autres personnes pour qu'elles fassent pareil. À rester dans votre coin tout finira par pourrir et vous n'en tirerez plus grands choses. Prenez, améliorez, partagez et profitez.

Si vous voulez quelques pistes pour aborder les projets FLOSS, je vous partage ce support documenté, factuel et juste.

— Dernière mise à jour : mercredi 17 octobre 2023 Précédemment sur paper.wf —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.