🔥 Nouveau : Automatiser la datation de vos logiciels avec l'IP Tower.    Découvrir
Revenir à l'IP Corner

Comment les licences contaminantes peuvent ruiner votre IP

William Fauchoux
CEO Cofondateur @ BlockchainyourIp

Faites attention aux “pièges” cachés dans les licences de logiciels ! Si vous développez un logiciel ou une application, sachez que certaines licences peuvent vous empêcher de commercialiser votre produit comme vous le souhaitez. 

Les chances que vous tombiez sur une licence contaminante sont importantes. En effet, 60% à 80% du code dans les logiciels actuels vient de l'Open Source. Et 22% de ce code est à risques ! Il est ce que l’on appelle "copyleft". Autrement dit, la licence impose que vous redistribuiez votre travail sous la même licence que l'original. 

Prenons l'exemple d'Orange : la société a vendu un logiciel au portail "Mon Service Public" (maintenant service-public.fr). Problème : ce logiciel contenait un bout de code sous licence GNU GPL. Résultat ? Orange a été attaqué en contrefaçon.

Alors, avant de vous lancer tête baissée dans le développement, vérifiez en amont les licences associées au code que vous utilisez. Sans cette vérification cruciale, vous vous exposez à différents risques. Cela peut réduire la valorisation de votre entreprise et compromettre une levée de fonds à la suite d’un audit. Votre entreprise risque également une action en contrefaçon devant le tribunal et une divulgation forcée de son code source. 

Il est donc primordial d’identifier des licences contaminantes. La contamination varie selon que le logiciel est distribué ou non en SaaS. On vous explique tout dans ce guide concret et simple pour vous éviter des erreurs coûteuses.

Logiciel distribué, SaaS, licence contaminante : les définitions clés

Qu’est-ce qu’un logiciel distribué

Un logiciel distribué, c'est une application ou un programme que vous téléchargez et installez directement sur votre propre matériel, que ce soit un ordinateur, un smartphone ou une tablette. Une fois installé, vous pouvez l'utiliser sans nécessairement avoir besoin d'une connexion Internet. 

🔎 En voici quelques exemples couramment utilisés : Microsoft Word, Adobe Photoshop, Google Chrome, Slack, etc.

💡 Bon à savoir : Cela peut aussi être via un logiciel ou une application installé(e) dans le navigateur (une extension) ou grâce à un matériel physique tel qu’un CD-ROM. Certains avocats considèrent que le chargement de l’interface d’un logiciel SaaS dans le navigateur constitue une distribution.

Des logiciels distribués : Microsoft Word, Adobe Photoshop, Google Chrome et Slack

Qu’est-ce qu’un logiciel SaaS ?

Un logiciel SaaS, ou Software as a Service, est accessible depuis n'importe quel navigateur web. Vous n'avez pas besoin de le télécharger ou de l’installer sur votre ordinateur. Rien n’est stocké sur votre matériel. Le logiciel est hébergé sur des serveurs distants, généralement gérés par la société qui a développé le service. Pour y accéder à distance, il vous faut simplement une connexion internet. 

Ces logiciels n'étant pas installés en local chez l’utilisateur, ils ne sont pas considérés comme étant distribués.

🔎 En voici quelques exemples connus : Google Docs, Salesforce, Zoom, Mailchimp, etc.

💡 Bon à savoir : Un logiciel SaaS "on premise" est une version d'un logiciel en ligne que vous installez directement sur vos propres serveurs d'entreprise. Ce choix est souvent fait pour des raisons de sécurité ou de conformité, et est particulièrement populaire chez les grandes entreprises voulant le contrôle total sur leurs données. 

  

Des exemples de logiciel SaaS : Google Docs, Salesforce, Zoom et Mailchimp

Qu’est-ce qu’une licence contaminante ?

Les licences contaminantes, comme la GPL ou la SSPL, imposent des conditions strictes lorsqu'on utilise du code open source.

La licence GPL 

Licence GPL : définition

Si vous intégrez et modifiez du code sous licence GPL dans votre logiciel, et que vous le distribuez, votre version du code doit également être mise à disposition gratuitement. On dit alors que la licence est contaminante, puisque votre code source doit être dévoilé dans son intégralité, dès lors qu’un logiciel GPL est intégré ou lié à votre application. 

💡 Bon à savoir : Concernant la licence GPL, la mise à disposition de votre logiciel en mode SaaS ne compte pas comme une distribution. Les SaaS ont une immunité au GPL, que l’on appelle la SaaS Loophole. Cette immunité n’est valable que pour le code exécuté sur le serveur, qui n’est pas distribué aux utilisateurs. Côté clients, même le chargement dans un navigateur web de votre code compte comme une distribution et contamine donc votre logiciel. 

⚠️ Attention : Lorsque le logiciel SaaS est “On premise”, et est donc installé directement sur les serveurs d’un client, cela compte comme une distribution. 

Licence GPL : exemples 🔎

Libre Office : Si vous modifiez LibreOffice (qui est un logiciel gratuit) et que vous le distribuez, que ce soit via un CD-ROM ou un téléchargement, votre version modifiée doit aussi être gratuite. Ce qui déclenche cette obligation, c'est l'acte de distribution. 

Wordpress et Drupal : Si vous utilisez Wordpress ou Drupal pour faire votre site internet, votre code ne sera pas contaminé puisque, sur Wordpress, votre site est en SaaS. Sachez que Drupal et Wordpress sont tous deux sous licence GPL. Pour les thèmes et plugins WordPress vendus sur Envato Market, la licence est souvent mixte. Le code PHP est sous GPL, mais le CSS et les images peuvent être sous une licence différente parce qu'on les considère comme des œuvres indépendantes. C'est la même histoire pour Drupal : tout code qui interagit directement avec Drupal doit être sous GPL. Mais si votre CSS n’interagit pas avec le CSS de Drupal, pas besoin de le mettre sous GPL.

Busybox : Busybox est une bibliothèque de commandes Unix sous licence GPL. La société créatrice de Busybox a poursuivi en justice des fabricants de télévisions (par exemple, Sony) qui avaient intégré Busybox à leur TV connectée, sans partager leur propre code source. 

Des exemples de Licence GPL : Libre Office, Wordpress, Drupal et Busybox

La licence LGPL 

Si vous modifiez un logiciel sous LGPL, vous devrez redistribuer le code. Toutefois, vous pouvez utiliser une bibliothèque LGPL dans votre application sans avoir à rendre tout le code public, à condition que les utilisateurs puissent remplacer la bibliothèque LGPL par une version modifiée. Pour cela, vous devez lier le code dynamiquement à la bibliothèque LGPL, et ne pas l'intégrer statiquement dans votre application. 

⚠️ Attention : Pour les applications de bureau et mobiles, respecter ces conditions peut être un véritable casse-tête. Ces apps sont souvent livrées packagées en un seul fichier, comme un .exe, et publiées sur des stores. Par conséquent, elles ne sont pas facilement modifiables par les utilisateurs, ce qui pose problème avec la licence LGPL.

La licence AGPL 

Licence AGPL : définition

La licence AGPL est l’évolution de la licence GPL. Elle a été créée notamment pour combler la “lacune SaaS” (ou SaaS loophole), afin que le code reste ouvert. L'AGPL exige que, si un utilisateur interagit avec votre application ou logiciel sur un réseau (typiquement dans un modèle SaaS), cela compte comme une distribution. Cela vous oblige ainsi à rendre votre code source disponible pour les utilisateurs de ce service.

Licence AGPL : exemples 🔎

Airbyte, Getlago, et Plausible sont des exemples d'entreprises utilisant des licences AGPL pour empêcher qu’un fork de leur code ne soit monétisé. 

La licence SSPL

Licence SSPL : définition

La licence SSPL peut également être contaminante. Ses conditions d'utilisation sont encore plus strictes.

La SSPL vous oblige à partager l'ensemble du code source de votre service, même si certaines parties de ce service ne sont pas basées sur du code sous licence SSPL.

Licence SPPL : exemples 🔎

MongoDB Atlas : MongoDB est une base de données open source développée gratuitement par une communauté de développeurs. MongoDB, Inc. offre un service premium, clé en main, fondé sur cette base de données, fournissant des fonctionnalités supplémentaires, mais encadrée par une licence plus contraignante. MongoDB est sous licence SSPL, tandis que ses drivers API sont sous Apache. Le but de la SSPL est d'empêcher les géants du Cloud, comme Amazon ou Azure, d'utiliser MongoDB sans payer de licence. 

En résumé, vous pouvez utiliser et modifier du MongoDB gratuitement, mais si vous souhaitez le proposer en tant que service, par exemple DBaaS, vous devrez obligatoirement le rendre accessible à vos utilisateurs. 

💡 Bon à savoir : La majorité des startups utilisent MongoDB. Mais cela ne contamine pas leur code grâce à Apache sous licence MIT qui agit comme un bouclier. Si vous modifiez directement du MongoDB, votre code sera en revanche contaminé.

Évaluez les risques de contamination selon les types de logiciel et de licence

Le cas des logiciels distribués 

Pour les logiciels distribués, évitez les licences de type SSPL, AGPL et GPL si vous le pouvez. La LGPL est plus flexible. Mais, attention ! Elle vous oblige à autoriser des modifications sur le lien dynamique, ce qui n'est pas toujours simple en pratique.

Le cas de logiciels SaaS

Les différences côté serveur et côté client

Côté serveur

Lorsque vous développez un logiciel en SaaS, votre code n’est pas contaminé par une licence GPL. Vous bénéficiez de ce qu’on l’on appelle l’immunité SaaS loophole. La mise à disposition en mode SaaS ne compte pas comme une distribution, puisque le code est exécuté sur le serveur.

⚠️ En revanche, faites attention si vous envisagez d'utiliser des licences de type SSPL ou AGPL ou de proposer une offre On premise.

Côté client 

Concernant la partie client de votre logiciel en SaaS, sachez que le simple chargement dans un navigateur web compte comme une distribution du logiciel. Par conséquent, côté client, votre logiciel est contaminé. 

Si vous prévoyez de proposer une version on-premise de votre SaaS, surtout à des grands comptes, c'est également considéré comme une distribution pour le front-end et le back-end.

💡 Bon à savoir : Évitez les logiciels sans licence d’utilisation spécifiée par le propriétaire ou le créateur. Dans ce cas, le logiciel n'est pas nécessairement gratuit ou open source. Généralement, l’auteur du logiciel est titulaire des droits, ce qui signifie que toute utilisation, distribution ou modification du logiciel sans permission explicite est illégale.

Tableau comparatif complet des cas de contamination selon les différentes licences

Quelles solutions pour détecter proactivement les licences contaminantes ?

Pour détecter les licences contaminantes dans leur code, certaines entreprises sont allées jusqu’à recruter un "Open Source Officer" (aussi appelé “Open Source Officer compliance”). 

Mais il existe d’autres solutions plus faciles à mettre en place. Pour rassurer vos investisseurs et passer les audits en toute sécurité, voici nos 3 conseils pratiques.

Mettre en place une liste de licences contaminantes

Voici 3 étapes clés pour mettre en place votre liste de licences contaminantes :

  • Établissez une liste de licences contaminantes. Détaillez-y précisément dans quels cas le code est contaminé ou ne l’est pas. 🔎Google a, par exemple, banni de son code les licences AGPL, OSL et SSPL. Pour vous aider à réaliser votre liste, vous pouvez consulter leur liste des licences interdites.
  • Diffusez cette liste auprès de tous les membres de votre équipe de développement, y compris les responsables de projet et les décideurs. Faites-en un document facilement accessible, par exemple, sur votre intranet.
  • Les licences peuvent être modifiées et de nouvelles peuvent apparaître. Mettez régulièrement à jour votre liste et assurez-vous que l'équipe concernée soit informée des changements.

Définir une politique de blocage automatique

Pour établir et assurer le respect de votre politique de blocage, vous pouvez : 

  • Définir une politique de blocage automatique pour interdire la mise en production de toute version de code qui vous empêcherait d’utiliser votre service par la suite. 🔎Pour vous aider, vous pouvez, par exemple, vous aider de la fonctionnalité de Gitlab prévue pour accompagner ses utilisateurs à créer des politiques de blocage automatique ; 
  • Utiliser un outil détectant automatiquement tout ajout de licence contaminante par un développeur et éviter la mise en production. Il existe de nombreux outils pour automatiser la vérification des licences. 🔎Par exemple, vous pouvez installer l’outil License Auditor pour scanner votre code. 

Adopter une architecture Micro Service pour limiter la contamination

Adopter une architecture microservices est une stratégie efficace pour limiter les risques de contamination. Pour cela, vous pouvez : 

  • Séparer le code en modules via des API : L'un des avantages des architectures microservices est la modularité. En séparant votre code en plusieurs services distincts qui communiquent via des API, vous isolez les parties du code qui sont sous différentes licences. Distribuer sur plusieurs serveurs : Dans une architecture microservices, les différents services sont répartis sur plusieurs serveurs (exemples : un serveur dédié à la gestion des documents clients, un autre pour le téléchargement de l’outil, etc.). 

Cette organisation réduit fortement le risque qu'une licence "contaminante" affecte l'ensemble du code de votre service.

En résumé, vérifier les licences qui s'appliquent à votre code est une étape préalable cruciale avant la mise en production. Vous éviterez ainsi de vous exposer à des poursuites judiciaires pour contrefaçon ou manquement à des engagements contractuels. 

Mais ce n’est pas suffisant pour assurer la protection de votre code. Une fois développé, il vous faudra également prévenir les risques de copie illicite grâce à différentes solutions pour protéger votre logiciel. La même prudence s’applique pour protéger une application efficacement.

Revenir à l'IP Corner
Plus d'articles

Prêt à intégrer la Blockchain à votre Stratégie IP ?

Inscrivez vous pour une démo de découverte de 30 minutes.
Prendre rendez-vous