13 Décembre 2023
Un tour d’horizon des protections de la base de données
Lire l'article
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.
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.
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.
Les licences contaminantes, comme la GPL ou la SSPL, imposent des conditions strictes lorsqu'on utilise du code open source.
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.
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.
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 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.
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 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.
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é.
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.
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.
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.
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.
Voici 3 étapes clés pour mettre en place votre liste de licences contaminantes :
Pour établir et assurer le respect de votre politique de blocage, vous pouvez :
Adopter une architecture microservices est une stratégie efficace pour limiter les risques de contamination. Pour cela, vous pouvez :
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.
