Plus de 10 % des packages Python sur PyPI sont distribués sans licence

Imaginez que vous installiez un package Python pris au hasard sur PyPI. Il y a 13,5 % de chances que ce package ne fournisse aucune information sur sa licence. Comme une application Python classique peut facilement compter des centaines de dépendances et de dépendances indirectes, le risque d’utiliser du code sans licence est très élevé. Selon le contexte, les conséquences de l’utilisation d’un logiciel sans licence peuvent aller de négligeables à désastreuses. L’écart est considérable : cet article examine le problème de plus près.

Qu’est-ce que PyPI ?

PyPI est le dépôt central de packages Python le plus utilisé. Il a été créé et est géré par la Python Software Foundation. On y accède généralement à l’aide d’outils de gestion de packages comme pip, pour télécharger et installer des bibliothèques et des applications Python. Le principe est similaire à celui des dépôts de packages d’autres langages, comme npm pour Javascript, RubyGems.org pour Ruby et crates.io pour Rust.

Contexte

Snyk analyse les dépendances des projets logiciels et détecte des problèmes tels que des vulnérabilités de sécurité et des licences inappropriées. Dans ce cadre, l’entreprise m’a récemment chargé de récupérer sur PyPI toutes les métadonnées relatives aux packages et à leurs versions publiées, notamment les informations sur les licences. À partir de ces données, j’ai examiné la situation des licences pour l’ensemble des packages Python sur PyPI.

Vous trouverez ci-dessous les principaux enseignements de cette analyse, puis des recommandations fondées sur ces observations et une description des méthodes utilisées pour les obtenir.

Quelle est la situation des licences dans l’écosystème Python ?

Pour commencer, une petite mise en garde : je ne suis pas avocat. Je suis un ingénieur logiciel expérimenté qui connaît un peu les licences logicielles, mais je ne suis pas spécialiste du sujet. Ce qui suit ne constitue en aucun cas un avis juridique. Si vous en avez besoin, nous vous recommandons de consulter un avocat !

Types de licences

En règle générale, presque toutes les licences de logiciels open source peuvent être réparties en quelques grandes catégories :

• Les licences « copyleft » sont relativement restrictives. Elles comprennent la célèbre licence GPL, ses nombreuses variantes et des licences similaires. Elles permettent d’utiliser le logiciel à pratiquement toutes fins, mais exigent que toute modification que vous apportez soit également rendue publique. De plus, certaines licences copyleft « fortes » exigent, dans certains cas, que le code utilisant un logiciel soumis à ces licences soit lui aussi rendu public.

• À l’inverse, les licences « permissives » permettent de modifier le logiciel sans avoir à rendre publiques ces modifications. Elles sont aussi généralement beaucoup plus simples et comportent moins de restrictions.

• À l’autre extrémité du spectre se trouvent les licences « domaine public », qui n’imposent généralement aucune restriction d’utilisation.

Pour en savoir plus sur les licences copyleft et permissives, consultez un précédent article de notre blog consacré à ce sujet.

Ces dernières années, plusieurs licences « copyleft faible » ont vu le jour. Elles sont principalement destinées aux bibliothèques logicielles et permettent de les utiliser avec peu ou pas de restrictions pour le logiciel qui les utilise. Pour en savoir plus sur la différence entre copyleft « faible » et « fort », consultez la section correspondante de l’article Wikipédia.

Il est également possible, bien que déconseillé, de ne préciser aucune licence. Cela résulte le plus souvent d’un oubli ou d’une méconnaissance, mais, dans de rares cas, c’est intentionnel. En l’absence de licence, l’utilisation du logiciel est simplement régie par le droit d’auteur (de chaque pays !) et par d’autres types de législation, comme le droit des brevets.

Répartition des types de licences

Examinons les types de licences utilisés sur PyPI :

Ces données nous apprennent que :

• La majorité des packages sur PyPI, soit 64 %, utilisent une licence « permissive », comme les licences MIT, Apache 2.0 et BSD à 2 ou 3 clauses .

• 18,5 % utilisent une licence « copyleft fort », comme les licences GPL et AGPL.

• 3 % utilisent une licence « copyleft faible », comme les licences LGPL et MPL.

• Seulement 1 % utilisent une licence « domaine public », comme les licences CC0, WTFPL et Unlicense.

• 13,5 % ne précisent aucune licence.

Ce résultat n’est pas surprenant : il correspond aux tendances générales observées sur GitHub et dans les dépôts de packages d’autres langages.

Les licences les plus courantes pour les packages Python

Quatre licences dominent sur PyPI : MIT, BSD-2-Clause, GPL-3.0 et Apache-2.0.

De nombreuses autres licences sont également courantes (utilisées par au moins 100 packages). Parmi elles, deux sont propres à l’écosystème Python : la licence Python Software Foundation (PSF) et la Zope Public License (ZPL).

Ce que vous devez faire MAINTENANT !

Compte tenu des licences des packages Python sur PyPI, je vous recommande vivement de :

• Vérifier si vous utilisez, directement ou indirectement, des logiciels soumis à des licences « copyleft » et vous assurer que vous en comprenez les implications pour votre code.

  1. Si vous écrivez du code propriétaire (non open source), cela peut représenter un risque juridique sérieux, en particulier avec les licences « copyleft fort », utilisées par plus de 18 % des packages PyPI.

  2. Si vous développez un logiciel open source, ces licences pourraient vous obliger à distribuer votre code selon des conditions similaires.

• Vérifier si certaines de vos dépendances ne précisent aucune licence.

  1. Si vous devez modifier une telle dépendance, ou risquez de devoir le faire à l’avenir, le droit d’auteur pourrait ne pas vous y autoriser.

  2. Les versions futures de ces dépendances incluront probablement une licence, mais vous ne pouvez pas savoir de quel type elle sera.

• Mettre en place un outil automatisé pour vérifier périodiquement ou en continu les licences de vos dépendances.

  1. Au cours du cycle de vie d’un projet, les dépendances sont souvent ajoutées ou modifiées.

  2. Une dépendance peut changer de licence d’une version à l’autre. Une mise à niveau peut donc entraîner un changement de licence.

Pour aller plus loin

Nous n’avons fait qu’effleurer le sujet. Les licences sont peut-être plus importantes que vous ne le pensez : prenez le temps d’en apprendre davantage ! Vous pouvez notamment vous renseigner sur les sujets suivants :

• Licences multiples (environ 500 packages sur PyPI sont proposés sous plusieurs licences)

• Compatibilité des licences

• Logiciels sans licence

• Présentation et explication des licences permissives courantes

• Le cadre juridique de l’open source, et plus particulièrement la section sur le choix d’une licence pour votre logiciel.

Méthodologie

Voici quelques détails sur la collecte et l’analyse des données.

J’ai d’abord collecté les métadonnées de tous les packages sur PyPI et de toutes leurs versions publiées. Cette collecte s’est déroulée sur plusieurs jours, au début du mois d’août 2018. À l’époque, PyPI comptait près de 150 000 packages.

J’ai ensuite extrait les informations de licence de chaque version de chaque package, à partir des champs « license » et « classifiers ». J’ai regroupé ces informations dans une seule structure de données, en triant les versions selon une interprétation inspirée du versionnage sémantique.

J’ai ensuite nettoyé et normalisé les données sur les licences. Je me suis appuyé sur une version du normaliseur de licences SPDX utilisé chez Snyk. J’ai amélioré le normaliseur de manière itérative afin qu’il reconnaisse correctement un plus grand nombre de licences, puis j’ai créé manuellement une grande table de correspondance pour gérer les nombreux cas particuliers.

J’ai ensuite entrepris d’analyser les 18 % de packages sans licence. Je n’avais pas encore examiné les fichiers des versions publiées. J’ai sélectionné au hasard 50 packages sans licence, téléchargé leurs dernières versions et recherché des informations sur les licences. Après avoir recueilli ces informations, j’ai réparti les packages en cinq catégories :

Seuls les packages de la catégorie « Licensed » disposent effectivement d’une licence. Parmi ceux des catégories « training », « throwaway » et « placeholder », la grande majorité contenait du code et aurait pu être utilisée comme dépendance, volontairement ou par erreur (par exemple à la suite d’une faute de frappe). J’ai donc estimé qu’il était raisonnable de considérer ces packages comme réellement dépourvus de licence. En extrapolant à partir de cet échantillon, j’ai estimé qu’environ 18 % × 72 % = 13,5 % des packages PyPI sont sans licence.

Il convient de noter que je n’ai pas effectué d’analyse similaire pour les packages de PyPI disposant d’une licence. Il est probable que de nombreux packages « training », « throwaway » et « placeholder » mentionnent également une licence. Par conséquent, adopter une approche prudente et considérer qu’environ 18 % × 28 % = 5 % des packages « réels » sur PyPI sont sans licence donnerait probablement une estimation très inexacte. Malheureusement, je n’ai pas eu le temps de mener une telle analyse ; je me suis donc limité à celle décrite ci-dessus.

Si vous avez des questions ou des commentaires, je serais ravi d’échanger avec vous ! Vous pouvez me contacter sur Twitter à l’adresse @taleinat.