Disclaimer : Je suis un développeur, pas un avocat ; cette information est considérée comme correcte, mais n’est pas un conseil juridique ; si vous pensez que quelque chose est incorrect, s’il vous plaît, écrivez un commentaire et nous le corrigerons ensemble🔧

Avant je ne me souciais pas de la licence du paquet npm. Je pouvais vérifier la licence de la dépendance immédiate mais jamais la vérification des dépendances tierces (transitoires).

🚓 Et puis j’ai rencontré des gars du département juridique 🚓

Je crois maintenant que les développeurs devraient avoir une compréhension de base des licences logicielles pour avoir un dialogue constructif avec les équipes juridiques de leurs entreprises. Ce post rassemble une connaissance générale sur les licences Open-Source et comment cela s’applique aux dépendances npm et au développement JavaScript Full-Stack en général.

Découvrons quand vous devriez commencer à vous soucier des licences.

Quand les exigences de licence sont-elles déclenchées ?

Si vous effectuez une liaison avec des bibliothèques open source et que vous distribuez ensuite le logiciel résultant, alors votre logiciel doit être conforme aux exigences des bibliothèques liées.

Regardons de plus près la liaison et la distribution appliquées aux apps JavaScript.

Liaison

Utiliser des bibliothèques tierces signifie normalement les lier :

  • Si vous regroupez (c’est-à-dire avec webpack) votre code avec des paquets open source, cela compte comme une liaison statique
  • Si vous utilisez un paquet open source dans votre application Node.JS (c’est-à-dire. via require) ou le connectez à une page web via une balise script, il s’agit d’une liaison dynamique

Note : lors de la construction d’un bundle ou de l’exécution d’une app Node.JS, vous effectuez le même type de liaison avec les dépendances immédiates (listées dans votre package.json) et transitives (listées dans le package.json de tiers). Les licences de dépendances immédiates et transitives ont le même effet sur votre logiciel.

Ce n’était pas intuitif pour moi avant 🤔

Distribution

La simple utilisation de bibliothèques open source ne déclenche pas nécessairement des exigences de licence. Normalement, les exigences de licence sont déclenchées lorsque vous distribuez un logiciel :

  • Transférer un logiciel entre les employés d’une même entreprise n’est pas une distribution
  • Lorsque les utilisateurs interagissent avec votre Node.JS app sur le réseau, ce n’est pas une distribution pour la plupart des licences open source ; mais c’est une distribution pour les licences Network Protective comme AGPL
  • Poser des fichiers JavaScript sur un serveur web public est une distribution

Quelle licence est ok

La plupart des licences open source tombent généralement dans un de ces types :

  • Domaine public et licences permissives comme le MIT qui vous permettent de faire n’importe quoi sauf de poursuivre l’auteur
  • Licences copyleft ou protectrices comme la GPL empêchent la liaison (voir ci-dessus) avec des logiciels propriétaires ; le cas limite est celui des licences protectrices de réseau comme la GPLv3 d’Affero qui déclenche par interaction sur le réseau ;
  • En entre les deux ci-dessus se trouvent les licences faiblement protectrices comme la MPL qui a moins de restriction pour la liaison dynamique (jusqu’à ce que la bibliothèque soit dans son propre fichier)

Vérifions les scénarios communs pour un développeur JavaScript :

Vous faites une application web

Le plus souvent, vous regroupez tous vos fichiers, y compris les bibliothèques, dans un seul fichier JS et le mettez sur un serveur web. Vous effectuez la liaison statique et la distribution. C’est bien d’utiliser des paquets avec des licences permissives dans un bundle.

Si vous devez utiliser un paquet avec une licence faiblement protectrice comme MPL, vous avez des options :

  1. Chargez la bibliothèque à partir d’un fichier séparé (c’est-à-dire. via une balise de script)
  2. Appliquer une licence open source compatible à votre bundle (mais vérifiez le commentaire ci-dessous et parlez-en à votre équipe juridique avant)

Si votre bundle n’a pas ✨de propriété intellectuelle valorisable✨ alors la seconde devrait convenir. Je ne crois pas que les concurrents bénéficieront de votre code obfusqué. Mais si le bundle contient effectivement une propriété intellectuelle de valeur, alors appliquer la licence open source, c’est en accorder la libre utilisation.

Vous faites une applicationNode.JS

Dans ce cas, vous connectez normalement les bibliothèques via un appel require(). Il s’agit d’une liaison dynamique. C’est bien d’utiliser des licences permissives et même faiblement protectrices. Assurez-vous simplement que les paquets restent dans leurs propres fichiers avec les licences respectives.

Si vous fournissez uniquement SaaS et que vous ne distribuez pas d’une autre manière, vous pouvez utiliser même les paquets avec une licence Protectrice. Pour de nombreuses licences Protectrices, l’interaction avec le réseau ne constitue pas une distribution. L’exception est les licences Network Protective comme Affero GPLv3

Vous faites un paquet Open Source NPM

Normalement, vous connectez les dépendances des tiers via un package.json. À ma connaissance, lister les dépendances dans le package.json ne peut pas être considéré comme une liaison. La liaison sera effectuée par un développeur d’applications qui utilisera votre paquet sur une étape de construction ou d’exécution.

Si vous ne voulez pas confondre les utilisateurs du paquet, assurez-vous que toutes les dépendances (immédiates et transitives) ont des licences compatibles avec la licence de votre paquet.

Typiquement, les licences des dépendances devraient être plus permissives ou du même niveau de permissivité que la licence de votre paquet.

Par exemple, si votre paquet a la licence Apache 2.0, vous pouvez utiliser les dépendances avec la licence MIT et BSD. Mais vous ne devriez pas utiliser les dépendances avec la licence MPL1.1 ou LGPLv3, car elles ont un copyleft plus fort.

Une flèche de la case A à la case B signifie que vous pouvez combiner des logiciels avec ces licences ; le résultat combiné a effectivement la licence de B, éventuellement avec des ajouts de A ; image issue des travaux de David A. Wheeler

Lorsque vous devez mettre des bundles ou des sources tierces dans un paquet NPM, n’oubliez pas de lister les licences et les droits d’auteur des tiers. La plupart des licences open source exigent une reconnaissance de l’auteur.

De plus, c’est une bonne pratique de spécifier une expression SPDX valide dans votre licence package.json. Je crois que ce champ doit être obligatoire pour la publication sur npm.org.

Comment vous le comprenez

De nombreuses équipes commencent à penser aux licences lorsque le logiciel est prêt à être expédié. J’ai utilisé l’utilitaire ScanCode pour cela. Il va vraiment dans chaque dossier de votre projet et essaie de détecter chaque licence ou copyright.

Capture d’écran de https://github.com/nexB/scancode-toolkit

Vous devez probablement utiliser cet outil ou un outil similaire avant de distribuer votre application. Assurez-vous que vous vérifiez suffisamment et pas trop :

  • installez toutes vos dépendances de production avant d’exécuter l’outil
  • assurez-vous que devDependencies ne sont pas vérifiées par l’outil ; normalement, vous ne distribuez pas avec vos dépendances de développement ;

Note : si vous êtes, comme moi, en train de regarder les licences des packages après avoir intégré le package dans votre app, vous pouvez vous retrouver dans une situation difficile.

Exécution de ScanCode juste avant la date limite ; image de https://giphy.com

Comment vous le découvrez avant qu’il ne soit trop tard

Je me demandais, quel est le meilleur moment pour apprendre les licences de dépendance des paquets. Pour moi, le flux normal de découverte des paquets est :

🔍 Google 👉 npm.org 👉 GitHub 👉 $ npm install

Malheureusement npm.org ne traite pas vraiment les dépendances transitives. Il existe des outils web comme http://npm.anvaka.com/ ; mais il ne correspond pas à mon flux de découverte de paquets et j’oublie toujours de l’utiliser. Je pensais que le meilleur moment pour apprendre les dépendances des paquets est lorsque vous tapez $ npm install <pkg>

C’était ma pensée lorsque j’ai construit un outil CLI appelé npm-consider qui analyse le paquet avec toutes les dépendances transitives avant de l’installer ou même de le télécharger.

https://github.com/delfrrr/npm-consider

Pour vous épargner une commande, il enveloppe $ npm install et a les mêmes arguments. Si vous êtes d’accord avec les dépendances, choisissez simplement Installer et il exécutera npm install comme d’habitude. Si vous êtes concerné choisissez Details et voyez tout l’arbre des dépendances:

Showing details when installing component of popular geospatial library Turf.js ; notez que le paquet lui-même a une licence Permissive, mais l’une des dépendances transitives a une licence AGPL ; vous ne pouvez pas vraiment l’utiliser pour un logiciel propriétaire;

Je crois que cette fonctionnalité doit faire partie de la CLI de npm. Si vous êtes d’accord, veuillez ⭐️ projet sur GitHub et je ferai avancer l’idée.

Sources

Je liste mes sources au cas où vous voudriez revérifier mes conclusions:

  • Comprendre le modèle de dépendance de npm
  • La licence open source : Ce que chaque technologue devrait savoir | Opensource.com
  • Les différentes licences et les commentaires à leur sujet
  • La diapositive sur la licence Free-Libre / Open Source Software (FLOSS)
  • Centre de licences | ifrOSS
  • Comparaison des licences de logiciels libres et open-source – Wikipédia
  • Bibliothèque (informatique) – Wikipédia

Si cet article vous a été utile, s’il vous plaît 👏 et peut-être que je vais écrire un autre 😀

.