Pourquoi la SSPL est néfaste
- La SSPL (Server Side Public License) est une licence terrible pour tous les utilisateurs, les entreprises et, de manière générale, pour la communauté
- Les produits sous licence SSPL ne sont pas open source, visent à tuer les concurrents du cloud et des services managés, à augmenter les prix de l’hébergement et à détruire l’open source
- Le but de la SSPL est peut-être moins de combattre les grandes entreprises que de reverser de l’argent aux investisseurs
Qu’est-ce que la SSPL
- La SSPL est une licence introduite en 2008 par MongoDB, Inc pour restreindre l’usage de MongoDB
- Des produits comme Elasticsearch, Kibana et Graylog utilisent désormais eux aussi la licence SSPL
- Selon l’article 13, si vous souhaitez fournir directement le produit à des clients, vous devez rendre publiquement disponible le « code source du service »
Pourquoi la SSPL est néfaste pour tout le monde
- La SSPL a été présentée comme une bonne solution pour empêcher quelques entreprises cloud malveillantes de tirer profit sans contribuer à la communauté, mais il s’agit en réalité d’une menace contre la liberté et d’une licence faite pour tuer les concurrents
- Cette licence ne fait que confiner dans des produits commerciaux ce qui était auparavant open source, en le cachant derrière un faux esprit de « gratuité ». Il faudrait peut-être désormais appeler ce type de logiciel du logiciel « freemium »
- MongoDB, Elasticsearch, Kibana et Graylog ne sont plus des produits open source, et ces entreprises peuvent désormais décider entièrement de qui a le droit de proposer leurs produits à des clients. Cela revient à éliminer les concurrents
- Elles peuvent désormais fournir leurs propres solutions d’hébergement cloud sans concurrence, sans publier leur code source, et tuer la concurrence ainsi que l’innovation avec les tarifs qu’elles définissent
- Pour nous, clients, cela signifie que nous n’avons plus vraiment le pouvoir de choisir notre fournisseur cloud
- Mécaniquement, les prix de l’hébergement vont augmenter, et notre seule option sera à peu près de disposer d’une équipe dédiée pour gérer l’hébergement sur notre propre infrastructure. Exactement ce que nous cherchions à éviter depuis des années grâce aux solutions d’hébergement cloud
Les entreprises qui utilisent la SSPL
- Les produits MongoDB utilisent la licence SSPL depuis 2018, avec MongoDB, Inc derrière eux
- Les produits Elasticsearch utilisent la licence SSPL depuis 2021, avec Elastic NV derrière eux
- Les produits Graylog utilisent la licence SSPL depuis 2020, avec GrayLog, Inc. derrière eux
Quelques questions que nous devrions nous poser
- Comment une entreprise qui n’utilise plus l’open source peut-elle exiger des autres qu’ils « redonnent à la communauté » ?
- Comment une entreprise qui ne publie pas le code source de ses propres services cloud peut-elle exiger des autres qu’ils publient leur code source ?
- Comment une entreprise peut-elle affirmer que l’open source fait partie de son ADN tout en utilisant une licence non open source ?
- Sur plus de 3 000 employés, combien partagent réellement leur travail et leur code source avec la communauté ? (Spoiler : beaucoup moins)
- Est-ce une entreprise technologique qui veut partager avec la communauté, ou une entreprise commerciale qui cherche à augmenter les revenus de ses investisseurs ?
Les affirmations trompeuses à propos de la SSPL
- L’argument « Je ne suis pas un fournisseur cloud, donc cela ne me concerne pas » doit laisser place au constat que ce sujet concerne en réalité tout le monde
- L’argument « Ces entreprises ont besoin d’argent pour survivre » doit être compris ainsi : gagner de l’argent avec l’open source n’est pas mauvais, mais la SSPL n’est pas la bonne solution
- L’argument « Les concurrents existent toujours. La SSPL est négociable » signifie en réalité qu’une entreprise qui contrôle le marché peut fixer les prix et les conditions de ses concurrents
- L’argument « La SSPL combat les grands acteurs du cloud et est bénéfique aux petites entreprises » doit reconnaître que la SSPL peut en réalité pousser de petits concurrents à la faillite et à la disparition
Conseils aux projets open source
- La SSPL peut sembler être une bonne solution au départ, mais il est recommandé de ne pas faire cette erreur
- Si certains fournisseurs cloud posent problème, on ne peut pas les ignorer et nous devons tous nous battre ensemble. Sortir du monde de l’open source pour mener ce combat n’est pas une bonne méthode
- Si la rentabilité est nécessaire, utilisez des licences enterprise et du support premium : « si vous avez besoin d’assistance, nous avons la meilleure équipe pour cela. »
- Utilisez une licence copyleft afin que les entreprises puissent redonner à la communauté : « si vous modifiez notre code, partagez-le avec la communauté »
- Si vous choisissez malgré tout la licence SSPL… alors vous :
- perdrez de nombreux contributeurs indépendants ainsi que des contributeurs salariés de grandes entreprises
- trahirez les contributeurs qui ont travaillé à améliorer le logiciel open source
- quitterez le monde de l’open source pour développer un logiciel partiellement payant (freemium)
- associerez votre produit à un très mauvais buzz
- perdrez le bénéfice des très nombreux acteurs qui contribuent à promouvoir votre produit dans le monde entier, ce qui accroîtra le besoin de support premium
3 commentaires
On peut le choisir parce qu’il est open source, mais il arrive aussi qu’on l’écarte de la liste des options pour cette même raison.
C’est sans doute une licence née du fait qu’AWS a repris MongoDB pour créer DynamoDB, donc ceux qui apprécient l’open source peuvent la trouver un peu suspecte.
Ce serait intéressant de la comparer aussi à l’AGPL.
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/
Comme l’indiquent le nom de domaine et le nom du site
SSPL is BAD, il s’agit d’un site web créé avec une intention bien précise.Il pousse aussi parfois le trait de façon assez excessive. À lire avec les avis de Hacker News ci-dessous.
Avis de Hacker News
Il existe des objections de principe à la SSPL, mais aussi une compréhension de son contexte d’apparition. Certains critiquent la description de l’article 13, jugée davantage sensationnaliste qu’objective.
La SSPL serait mauvaise pour les utilisateurs, car elle favoriserait les monopoles et réduirait la participation de la communauté, ce qui finirait par affecter tous les utilisateurs.
Il est naturel que les gens cherchent à gagner de l’argent, et chacun peut choisir de ne pas utiliser de projet sous SSPL. Certains avancent qu’un logiciel publié sous licence SSPL vaut mieux que pas de logiciel du tout.
L’écosystème actuel est très différent de celui d’il y a 10 ans, et certains veulent permettre aux petites entreprises de survivre à la concurrence et de grandir. Des licences comme la BSL (Business Source License) ne sont peut-être pas parfaites, mais peuvent être vues comme une tentative de trouver une voie médiane saine.
Certains trouvent étrange de critiquer la SSPL sans mentionner l’AGPL. Ils pointent aussi du doigt les personnes qui veulent utiliser du logiciel libre sans vouloir contribuer.
Selon certains, il ne faut pas pencher systématiquement d’un côté ou de l’autre, mais aborder chaque cas séparément. La SSPL peut être bénéfique pour certaines entreprises qui cherchent à survivre face aux géants du cloud, mais néfaste pour d’autres qui cherchent à exploiter leurs contributeurs.
Il serait interdit de proposer directement aux clients les produits MongoDB, Elasticsearch et Graylog. Le mot « directement » dans la SSPL laisserait une marge de débat juridique, ce qui inquiète certaines personnes.
La FSL (Functional Source License) est présentée comme une bonne alternative, avec conversion automatique en Apache 2.0 ou MIT au bout de 2 ans. Elle est simple, publie le code source et offre un moyen raisonnable pour qu’une entreprise SaaS puisse fonctionner.
Correction d’une information erronée affirmant que la SSPL aurait été introduite en 2008. En réalité, elle a été introduite en 2018.
Critique d’une vision unidimensionnelle de l’avenir du droit d’auteur.