Idées reçues
Ce que les équipes supposent, face à ce qu'exigent les licences
L'open source est souvent perçu comme une autorisation de livrer. En pratique, chaque bibliothèque, police, SDK ou script que vous embarquez est une licence, avec des règles de mention, d'attribution ou de copyleft qui varient selon le composant.
Les fiches ci-dessous confrontent les suppositions courantes à ce que ces licences exigent réellement, avant qu'un client, un auditeur ou un acquéreur ne pose la question.
Dernière mise à jour : 2 juillet 2026
Open source ne veut pas dire absence d'obligations légales.
Cela signifie que les obligations sont standardisées, publiques et exécutoires, souvent sans que personne dans l'équipe ne les ait lues.
Supposition
« C'est de l'open source. On peut le livrer. »
Réalité
Chaque composant vient avec des conditions. Les licences permissives exigent tout de même des mentions de copyright et de licence dans les distributions. Les licences copyleft peuvent exiger des offres de code source, la propagation de la licence et une analyse de distribution. Pas une note de bas de page sur un wiki.
Supposition
« On est en SaaS, donc les licences ne s'appliquent pas. »
Réalité
Certaines obligations sont allégées pour un usage réseau uniquement ; beaucoup ne le sont pas. La GPL, la LGPL, l'attribution Apache dans les programmes d'installation, la redistribution de polices et l'attribution des ressources comptent toujours. Et les clients continuent de demander ce que vous livrez et ce que vous embarquez.
Supposition
« Le juridique s'en occupera si c'est important. »
Réalité
Le juridique ne peut pas mettre en œuvre ce que l'ingénierie n'a jamais inventorié. Les listes de paquets changent à chaque sprint ; les polices, icônes et SDK n'y apparaissent souvent jamais. Le temps que le juridique soit impliqué, la version est déjà sortie.
Supposition
« On a un fichier LICENSE dans le dépôt. »
Réalité
La licence de votre dépôt, c'est la vôtre. Pas celle de vos dépendances. Un unique fichier d'attribution vieux de trois ans ne décrit pas ce que vos clients téléchargent aujourd'hui.
Supposition
« npm update, c'est juste un patch, la conformité ne change pas. »
Réalité
Une montée de version peut changer la licence effective, ajouter du copyleft, ou remplacer entièrement les obligations. Les mises à jour de routine sont l'une des façons les plus courantes dont la conformité se rompt sans que personne ne le remarque.