Avec la multiplication des projets open source, la gestion des licences devient de plus en plus compliquée. Une étude réalisée par ClearlyDefined sur 5 000 packages applicatifs sous licence open source démontre que seulement 5 % d’entre eux sont suffisamment documentés pour éviter les ambiguïtés de droits.
De l’extérieur, l’utilisation d’un projet open source peut paraître simple : il suffit de télécharger les paquets que l’on souhaite depuis le dépôt git assigné. En réalité, c’est bien plus complexe que cela. Lors d’une conférence menée pendant l’Open Source Summit Europe 2020, Philippe Ombredanne, CTO de nexB une société spécialisée dans l’audit de logiciels tiers et open source, est revenu sur les particularités des licences ouvertes.
« Le principe de licence est l’essence des logiciels libres et ouverts. Sans licences, ils n’existeraient même pas, c’est ce qui définit l’open source », assure Philippe Ombredanne. « Je peux corriger les bugs, les vulnérabilités, mais même si j’ai accès au code, je ne peux pas corriger la licence associée : seulement les auteurs peuvent le faire », ajoute-t-il.
De même, si l’information sur les droits d’utilisation n’est pas claire, alors il est difficile d’utiliser des composants open source, que l’on soit un développeur indépendant ou une entreprise, voire un éditeur, selon le CTO de NexB.
Philippe Ombredanne est le cofondateur du projet SPDX, un format de fichier dédié à la standardisation de licences et de ClearlyDefined, qui comprend plusieurs outils open source pour documenter, corriger et sécuriser le code. Il développe également ScanCode, une boîte à outils open source sous l’égide de l’OCI pour détecter les licences et les copyrights dans le code.
Open source oui, ambiguë aussi
« Contrairement aux licences propriétaires où chaque contrat est unique, le succès de l’open source provient du fait que nous avons développé des standards : si je cite Apache, GPL ou BSD, les développeurs savent tout de suite de quoi je parle, pas besoin de relire les mentions légales ».
« Contrairement aux licences propriétaires où chaque contrat est unique, le succès de l’open source provient du fait que nous avons développé des standards. »
Philippe OmbredanneCTO, nexB
Mais les problèmes de licence restent courants. Parfois, la mention « redistribuable » ou « sous les termes » d’une licence comme la GNU peuvent créer des ambiguïtés. Dans d’autres cas, les mentions légales sont masquées derrière une terminologie utilisée dans le code, évoque le cofondateur de SPDX, qui donne l’exemple de la dénomination GPL v2 en ASCII [Module_license (« \x47\x50\x4c\x20\x76\x33 »)].
Problème, les paquets tiers se multiplient. « Si vous utilisez des containers Docker, vous intégrez des centaines de milliers de paquets de systèmes avec votre code dans l’image docker », illustre Philippe Ombredanne. « Cela signifie que vous avez des milliers d’auteurs du code et des milliers de licences potentiellement différentes », ajoute-t-il.
C’est ce constat qui a donné naissance à des outils d’automatisation, pour vérifier rapidement les licences et éviter les mauvaises surprises, autant dans les dépôts des projets open source que ceux des entreprises, d’autant plus qu’ils ont aujourd’hui tendance à se confondre. Désormais, les plus gros contributeurs sont des éditeurs et des fournisseurs tels que Google, AWS, SAP ou encore Microsoft.
« Vous devez connaître la licence qui se réfère à un bout de code avant de l’employer à quoi que ce soit. »
Philippe OmbredanneCTO, nexB
« Vous devez connaître la licence qui se réfère à un bout de code avant de l’employer à quoi que ce soit », prévient Philippe Ombredanne.
Cependant, même avec la présence de standards de partage de licences comme SPDX, les caractéristiques de licences ne sont pas toujours correctement identifiées. Pour prouver ses dires, le CTO de nexB a participé à la réalisation d’une étude consacrée à environ 5 000 paquets applicatifs sous licence open source dans le cadre du projet ClearlyDefined. Seulement 5 % de ces paquets gem (ruby), maven (java), npm (Node.js), nuget (.Net) et pypi (Python) observés, disposent d’une documentation « quasi parfaite », complète et sans ambiguïté. « Cela veut dire, et ce n’est pas très satisfaisant, que 95 % de ces packages auraient besoin d’une révision, d’une clarification concernant les licences associées », estime le responsable.
Dans le détail, l’équipe derrière ClearlyDefined a étudié 4 892 paquets. Le score médian de clarté est de 45 sur 100 et seulement 194 paquets obtiennent un score d’au moins 80, correspondant à une bonne documentation.
Les informations explicites sur les licences open source se trouvent généralement dans les manifestes ou les scripts des builds. Il s’agit de mentions, de notices, de label ou du texte en partie reproduit dans le code ou dans une documentation associée. Ensuite, il faut se fier à des indices : adresses mail, noms, constructions de code spécifiques, etc.
Des efforts à effectuer dans la plupart des projets open source
Selon les principes évoqués par le spécialiste, la clarté d’une licence est identifiable quand ses spécificités sont nommées dans les premières lignes de la documentation. Ensuite, le deuxième critère d’une bonne documentation consiste à nommer ces droits dans le code source en utilisant des standards comme SPDX.
« Il peut y avoir plusieurs variantes d’une même licence, comme MIT. »
Philippe OmbredanneCTO, nexB
« Idéalement, la licence documentée dans un fichier texte et celle documentée dans le code sont utilisées ensemble », recommande le CTO dans sa présentation. L’emploi de licence reconnu est un quatrième critère (Apache, GPL, BSD, MIT, GNU, etc.). Enfin, dernier critère, la présence des licences elles-mêmes qui sont parfois purement et simplement oubliées au profit de simples mentions du nom de la licence. Or, « il peut y avoir plusieurs variantes d’une même licence, comme MIT » prévient le CTO.
Dans le cadre de l’étude, chaque critère a un score. Le premier vaut pour 30 points, le deuxième 25. La consistance de la licence, l’utilisation des standards référencés dans le SPDX et la présence des textes disposent de 15 points chacun. Il en ressort que le score médian des packages, npm et pypi sont identiques (60), mais que ceux associés à nuget (30), et maven (27) sont moitié moindres. Nuget et maven sont plus anciens, mais Philippe Ombredanne explique que ces paquets sont souvent distribués sous forme de binaires, sans licences associées, tandis que les packages gem et npm contiennent plus régulièrement les standards SPDX, ce qui est moins vrai pour pypi.
Les contributeurs de ClearlyDefined ont fait le même exercice sur un échantillon de 10 millions de packages. Ils obtiennent des scores médians similaires ; seulement maven s’en sort mieux (60), nuget perd 15 points et pypi descend légèrement (51 sur 100), si l’on compare cette étude à la précédente.
L’automatisation à la rescousse
Philippe Ombredanne évoque plusieurs techniques utilisées pour scanner le code et le texte afin de trouver ces informations. La première consiste à rédiger manuellement des modèles de textes agissant comme des proxys pour retrouver les licences. La seconde consiste en une approche probabiliste basée sur une métrique de similarité, comme une distance entre les éléments. Celle-ci doit permettre de retrouver le texte de licence ou la notice la plus proche du bout de code dont on cherche la parenté.
« La méthode la plus efficace consiste à effectuer une comparaison exhaustive par paire de tous les textes et échantillons de licences que vous pouvez trouver sur le Web appliquée à votre code », assure le CTO. C’est la meilleure technique employée dans les projets ScanCode et ClearlyDefined, mais c’est « la combinaison de ces techniques qui vous assure de ne pas oublier une licence ».
Par exemple, ScanCode comprend une bibliothèque de 20 000 licences et permet à partir de cette ontologie et d’algorithmes de machine learning de repérer des problèmes depuis une détection automatique des textes et des indices recherchés.
Un besoin d’éducation
Cependant, la machine ne peut pas tout faire, les contributeurs et les comités doivent encourager les bonnes pratiques pour éviter les conflits de licences et les confusions à cause de bouts de code potentiellement semi-propriétaires. Le CTO évoque une campagne pour nettoyer les licences du kernel Linux. Après deux ans et demi, 60 000 fichiers ont un identifiant SPDX, et de plus de 1 000 manières pour indiquer les droits utilisés, les développeurs sont passés à 61 expressions. Ce travail d’éducation est également en cours dans la communauté Python.
Les entreprises et les organisations du secteur public sont elles aussi encouragées à faire ce travail. Un tel inventaire permet d’évaluer l’adoption du code ouvert, mais aussi d’éviter de possibles tempêtes juridiques, et de statuer de la réversibilité, de la portabilité d’une solution adoptée à l’échelle d’une entreprise.
