Suport technique et veille technologique

Équilibrer l'ouverture et les revenus : naviguer dans le contrat moral dans le monde en évolution du logiciel libre.

Dans le paysage technologique actuel, qui évolue rapidement, l'esprit des logiciels libres et des projets à code source ouvert est mis à l'épreuve. Alors que les entreprises cherchent à monétiser leurs efforts, l'équilibre entre le maintien de l'ouverture et la génération de revenus est devenu de plus en plus complexe. Dans cet article de blog, nous nous pencherons sur les défis auxquels est confrontée la communauté du logiciel libre, en explorant divers modèles commerciaux, le concept de « contrat moral » et la manière dont certaines entreprises peuvent abuser du système.

Je discuterai également des alternatives telles que l'Open Core et les licences d'utilisation équitable, et je me demanderai si elles sont en accord avec les principes initiaux du logiciel libre. En examinant ces questions, j'espère éclairer le débat en cours et inspirer d'autres discussions sur la manière de préserver les valeurs fondamentales du mouvement du logiciel libre tout en assurant sa durabilité dans l'ère moderne.

Ce billet ne vise pas à gagner un concours de "pureté", mais plutôt à comprendre et à relever les défis liés au maintien de l'esprit du logiciel libre dans une ère qui a considérablement évolué depuis sa création.

Mes deux casquettes : En tant que PDG et cofondateur d'une entreprise spécialisée dans les logiciels libres, et en tant qu'utilisateur quotidien de logiciels libres, j'ai une perspective unique sur les défis et les opportunités du mouvement des logiciels libres. Mon double rôle me permet non seulement de savoir comment maintenir une entreprise dans ce secteur, mais aussi d'apprécier la valeur des logiciels libres du point de vue de l'utilisateur. Ce point de vue a alimenté ma passion pour la promotion et la défense des principes fondamentaux du logiciel libre, tout en assurant la subsistance des 40 personnes de mon entreprise qui dépendent également de son succès.

L'essence du logiciel libre

Avant d'aborder les aspects commerciaux, il est essentiel de comprendre les principes sous-jacents ou « l'esprit de la loi » qui régissent les logiciels libres. Les fondements du logiciel libre sont évidents dans la première licence de logiciel libre, connue sous le nom de General Public License (GPL). Cette licence incarne l'idée que les utilisateurs doivent être libres d'utiliser, de copier, de modifier et de redistribuer les logiciels, le code source étant accessible à tous en tant que connaissance partagée pour l'ensemble de l'humanité.

Mais quelle était l'intention derrière ces règles ? Richard Stallman voulait avant tout empêcher les entreprises de prendre le contrôle des logiciels dans les années 1980. La GPL constituait une protection contre ce phénomène, comme l'explique David A. Wheeler :

David A. Wheeler affirme que le copyleft fourni par la GPL a été crucial pour le succès des systèmes basés sur Linux, en donnant aux programmeurs qui ont contribué au noyau l'assurance que leur travail profiterait au monde entier et resterait libre, plutôt que d'être exploité par des sociétés de logiciels qui n'auraient rien à donner en retour à la communauté.

Pour moi, cette déclaration résume l'essence du logiciel libre : l'utiliser comme on le souhaite tout en contribuant au bien commun.

Qu'en est-il des licences plus permissives, telles que la licence MIT, qui impose des restrictions minimales à la réutilisation, même au sein d'un logiciel propriétaire ? En règle générale, la licence MIT convient aux « petits modules » ou aux composants de bas niveau qui peuvent être intégrés universellement. Toutefois, elle est moins pertinente pour les « produits » autonomes. Dans cet article, je me concentrerai sur le « logiciel final » plutôt que sur les petits composants qui l'utilisent.

L'idée de rendre la pareille peut sembler naïve à certains, mais je crois qu'elle constitue le fondement de la coopération, qui nous permet à son tour de progresser efficacement en tant que groupe, civilisation ou société. Cette conviction personnelle est étayée par des preuves scientifiques, bien que cet article ne soit pas un document scientifique.

Malgré l'évolution des règles d'octroi de licences (par exemple, via la licence publique générale Affero v3 ou d'autres licences), certaines entreprises tentent obstinément de les exploiter ou de les contourner à des fins personnelles. Si la majorité des entreprises suivent cet exemple, cela pourrait menacer l'existence du logiciel libre tel que nous le connaissons. Ceci étant dit, revenons à notre sujet central : générer des revenus à partir de projets open-source sans compromettre l'esprit du logiciel libre.

Open Source ou logiciel libre ? Pour reprendre les termes du premier créateur du logiciel libre : « les deux termes décrivent pratiquement la même catégorie de logiciels, mais ils représentent des points de vue fondés sur des valeurs fondamentalement différentes. L'open source est une méthodologie de développement ; le logiciel libre est un mouvement social ». Cette distinction subtile est cruciale, comme je pourrais l'explorer plus avant dans cet article.

Open Source, entreprise et collaboration

L'Open Source et les logiciels libres ne sont pas uniquement l'apanage des amateurs. Si les amateurs jouent un rôle crucial dans le lancement d'idées, le développement de preuves de concept innovantes et la création de logiciels exceptionnels, les projets de plus grande envergure nécessitent souvent des fonctionnalités, une assistance et des corrections de bogues plus étendues. Ces demandes sont généralement satisfaites par des équipes soutenues par des entreprises ou des organisations caritatives. Par exemple, le noyau Linux est partiellement soutenu par la Fondation Linux, avec Linus Torvalds à la tête du projet.

L'un des avantages d'avoir une organisation qui travaille sur un logiciel, plutôt qu'un individu ou plusieurs individus issus de différentes entités, est l'efficacité accrue en termes de rapidité de publication et de prise de décision. Avec une équipe dédiée, la collaboration est souvent plus rapide et des choix clairs peuvent être faits lorsqu'il y a un rédacteur principal ou une personne désignée pour résoudre les problèmes ou prendre des décisions. Une analogie pertinente serait un programme militaire multiétatique, où il peut être plus difficile et plus coûteux d'obtenir des résultats qu'avec un seul chef ou un programme national.

En fin de compte, l'Open Source et les entreprises peuvent coexister harmonieusement. En effet, l'apport de ressources financières permet d'embaucher plus de personnes, d'étendre les projets et d'améliorer la qualité.
Cependant, tout n'est pas parfait dans ce scénario. S'il est possible de générer des revenus sans compromettre l'esprit du logiciel libre, certains peuvent abuser du système à leur profit. Dans la section suivante, nous explorerons les modèles commerciaux qui s'alignent sur les principes originaux du logiciel libre.

Différentes approches de la monétisation

Si vous voulez un rappel des 10 critères à respecter pour être défini comme Open Source, consultez cette liste simple établie par l'Open Source Initiative.

Il existe plusieurs façons de monétiser les logiciels libres. Examinons tout d'abord l'approche « originale » libre/libre/Open Source, où le logiciel lui-même est accessible, libre d'utilisation et peut être revendu :

1. La « méthode RedHat » : ce modèle repose sur l'assistance et l'assurance qualité, en vendant effectivement une « version stable ». Les autres sources de revenus sont la formation, la certification et l'assurance. Ce modèle « vanille » est difficile à reproduire sans atteindre une masse critique.
2. La « méthode SaaS » : votre logiciel est entièrement open source, sans restriction de fonctionnalités, et utilise généralement des licences de type GPL. En tant qu'éditeur principal, vous pouvez le déployer comme service en ligne, souvent sous la forme d'une offre SaaS. Bien que tout le monde puisse l'héberger lui-même sans limitations, il peut être long et difficile de parvenir à la stabilité sans connaissances approfondies : cette approche manque d'assistance et de garanties. La formation et la certification peuvent apporter des revenus supplémentaires.
3. La « méthode hybride » : si vous ne pouvez pas proposer votre logiciel en mode SaaS, comme une plateforme de virtualisation sur site, vous pouvez l'intégrer à des services SaaS supplémentaires. Cette approche « hybride » combine des aspects des modèles Red Hat et SaaS. Les appliances dédiées, virtuelles ou physiques, permettent un meilleur contrôle de l'ensemble de la pile : l'approche clé en main. Chez Vates, ce modèle est appliqué à XCP-ng et Xen Orchestra dans le cadre de la pile de virtualisation Vates, qui comprend une appliance virtuelle et des offres de support. La formation et la certification sont également des possibilités supplémentaires.

J'ai l'intention de rédiger un article approfondi explorant les nombreuses méthodes de mise en œuvre d'une approche hybride. Bien qu'il existe d'innombrables combinaisons possibles, ce futur article visera à apporter de la clarté au milieu de la complexité et à aider les lecteurs à naviguer dans le sujet.

À mon avis, ces trois méthodes sont conformes à l'esprit du mouvement original des logiciels libres. Dans tous les cas, un individu peut utiliser l'ensemble du logiciel, même sans soutien. Les utilisateurs peuvent s'auto-former, devenir des utilisateurs experts ou même des contributeurs sans aucun investissement financier. Seuls les services tels que l'intégration, l'assurance qualité, les offres SaaS, etc. sont payants.

Ces modèles sont-ils durables ? Je pense que oui, comme le démontrent Red Hat et notre propre expérience. Cependant, ils sont difficiles à mettre en œuvre car certaines entreprises peuvent exploiter le système. S'il est difficile de parvenir à un « véritable » Open Source, existe-t-il des modèles plus simples ? Pourquoi d'autres modèles semblent-ils mieux fonctionner et pourquoi des conflits surgissent-ils parfois entre les entreprises concernant leur utilisation des logiciels libres ?

Comme dans tout système, des abus sont possibles au détriment de l'intérêt général. Les logiciels libres ont été créés dans les années 1980, bien avant l'ère des clouds publics et des SaaS. Si les utilisateurs sont libres d'utiliser le logiciel sans restrictions, services ou assistance, les particuliers ou les entreprises peuvent profiter de tout gratuitement. Cela est conforme aux principes du logiciel libre et favorise l'esprit de communauté. L'une des meilleures retombées des logiciels libres est la création de liens entre les individus par le biais de leur utilisation. Si les produits propriétaires peuvent également créer des communautés, la différence essentielle réside dans la possibilité de modifier et d'améliorer le logiciel et de partager ces changements avec d'autres. Cela encourage le principe fondamental du logiciel libre : le développement collaboratif.

Qu'est-ce qui constitue un abus de système ? C'est une question d'échelle et de contrat moral.

Le contrat moral

Avec l'expression « contrat moral », je cherche à définir une frontière particulière. L'expression se compose de deux mots : « contrat » et « moral ». Commençons par « contrat ». Ce contrat est conclu entre deux parties : l'utilisateur du logiciel et l'entité principalement responsable de son développement, que nous appellerons le contributeur principal.

Le terme « moral » fait référence à des actions qui, sans être illégales, peuvent être considérées comme nuisibles au bien commun. En d'autres termes, on peut abuser du système sans enfreindre la loi, mais cela reste moralement discutable.

Sur la base de cette définition, nous pouvons tirer une première conclusion : les logiciels libres peuvent être utilisés de manière abusive par l'une ou l'autre des parties concernées, l'éditeur principal du logiciel ou l'utilisateur final. Voyons comment.

Abuser des logiciels libres en tant qu'« utilisateur final »

L'utilisateur final est un particulier ou une entreprise qui utilise un logiciel libre. L'esprit du logiciel libre, cependant, n'est pas conçu pour protéger le logiciel contre les utilisateurs individuels. Son objectif initial était d'empêcher les entreprises de l'exploiter sans y contribuer en retour.

La distinction entre les particuliers et les entreprises réside dans leur échelle, leurs objectifs et leur potentiel d'action collective. Les particuliers utilisent des logiciels à plus petite échelle et ne peuvent pas générer directement des profits massifs. En revanche, les entreprises peuvent coordonner leurs ressources et leurs actions pour poursuivre des intérêts susceptibles de nuire au bien commun, ce qui nécessite un contrat moral pour maintenir l'esprit du mouvement du logiciel libre.

Maintenant que nous savons que les entreprises peuvent abuser des logiciels libres, comment le font-elles ? Analysons un exemple pour comprendre comment cela peut se produire.

Le premier cloud public

Faire dépendre toute une entreprise d'un logiciel libre sans jamais y contribuer est une façon d'en abuser. C'est la raison même pour laquelle la licence GPL a été créée. « Exploiter » signifie ne pas fournir de retour d'information, de documentation, de contributions au code, ou même ne pas reconnaître son utilisation. Si cette pratique est légale, elle n'est pas morale. Le degré d'immoralité dépend de l'ampleur de l'abus.

Dans notre exemple, Amazon a créé AWS en utilisant Xen comme hyperviseur mais n'a jamais contribué à une échelle proportionnelle aux bénéfices qu'ils ont tirés de leur cloud. L'écart entre les revenus générés grâce au logiciel libre et le niveau de contribution est immense : des centaines de milliards de revenus contre peut-être quelques millions d'investissements, de contributions en amont ou de publicité pour Xen.

Cela a été possible grâce à une « faille » dans la GPLv2 : comme AWS n'a jamais redistribué le logiciel, mais seulement le service qui le complète, elle n'était pas légalement tenue d'y contribuer. Cette question a été abordée dans la GPLv3, mais comme il s'agit d'un dérivé de Linux, le projet Xen était et est toujours sous GPLv2. Amazon a décidé d'exploiter cette faille. Si une petite partie de ses revenus avait été injectée dans le projet Xen, son ampleur aurait pu être bien plus grande.

D'un autre côté, la mauvaise utilisation de Xen par rapport à l'esprit du logiciel libre aurait pu démontrer son évolutivité et sa fiabilité. On pourrait dire qu'il vaut mieux que le logiciel soit utilisé, même s'il va à l'encontre des principes du logiciel libre, que de ne pas être utilisé du tout, tant que cela ne met pas en péril l'avenir et la durabilité du projet.

En réalité, nous discutons du concept d'équité, qui est une valeur subjective qui varie d'une personne à l'autre. Il n'existe pas de formule universelle pour déterminer ce qui est équitable ou non. Le cas d'AWS est un exemple extrême, mais il permet d'illustrer les différentes perspectives sur le continuum de « l'équité » dans le contexte des logiciels libres et des projets open source.

Les entreprises plus petites se livrent également à ce type de comportement, mais à plus petite échelle, ce qui entraîne moins de dommages. Par exemple, certaines entreprises utilisent notre pile gratuitement sans rien partager, alors qu'elles en tirent tous leurs revenus. Bien que cette pratique soit légale et constitue un « jeu » valable, elle rompt le contrat moral, car la généralisation de ce comportement finirait par tuer le produit ou le forcerait à adopter un modèle autre que celui de l'Open Source « intégral ».

Le « vrai » modèle de logiciel libre fonctionne tant que les gens paient pour un service, quel qu'il soit. Il incombe aux entreprises qui créent ces logiciels ouverts de communiquer et de générer suffisamment de valeur perçue par le biais de leurs services pour être payées. Il est possible de parvenir à cet équilibre délicat, et tout le monde est gagnant si le contrat moral reste intact.

Cependant, en réponse à des violations potentielles de ce contrat moral (ou à la crainte de telles violations), certains éditeurs ont choisi un modèle alternatif. Nous allons maintenant examiner pourquoi cette voie alternative peut être une pente glissante par rapport à l'esprit originel du mouvement du logiciel libre.

Abuser des logiciels libres en tant qu'éditeur de logiciels

En réponse à la première catégorie d'« abuseurs » (les « utilisateurs finaux »), certains éditeurs de logiciels ont conçu une solution pour assurer le paiement de l'utilisation de leur code partiellement libre. Cette approche, connue sous le nom d'« Open Core », est considérée par certains comme un moyen « équitable » de redistribuer la valeur puisque les utilisateurs sont tenus de payer. En réduisant la liberté des logiciels, le modèle Open Core vise à empêcher les entreprises de rompre le contrat moral. Si l'idée peut sembler séduisante à première vue, il est important d'examiner les implications de cette approche.

Open Core is the new shareware

Pour moi (et pour l'OSI), l'Open Core n'est pas vraiment un logiciel libre, car les utilisateurs n'ont pas toutes les libertés pour faire ce qu'ils veulent avec le logiciel. Seul le « noyau » est ouvert, et la définition du « noyau » peut être utilisée de manière abusive. Dans certains cas, presque toutes les fonctionnalités importantes ne sont pas incluses dans le noyau, ce qui rend le logiciel presque inutile si l'on ne paie pas pour le reste. Cela ressemble plus à une « démo » ou à un shareware, ce qui s'écarte de l'esprit originel du logiciel libre. Mais est-ce une mauvaise chose ?

À mon avis, oui, c'est mauvais : Open Core diminue la valeur et l'attrait des logiciels libres dans le seul but d'augmenter les revenus de l'éditeur principal. Certains appellent même cela de l'« open source washing », similaire au « green washing » des entreprises qui font semblant de s'engager réellement à réduire leur impact sur le climat. En bref, vous pensez qu'il s'agit d'un logiciel libre, mais ce n'est pas le cas. Certaines entreprises se réclament de l'Open Source alors qu'elles n'offrent que l'Open Core. Même certains fonds d'investissement promeuvent l'Open Core parce que c'est un moyen facile de gagner plus d'argent tout en paraissant « ouvert ».

Du moins, certaines entreprises se sont alignées sur cette réalité : par exemple, essayez de chercher le mot « Open » sur https://about.gitlab.com. Bonne chance. GitLab a commencé à être un noyau ouvert relativement tôt dans son développement et est progressivement devenu de moins en moins ouvert. Aujourd'hui, il ne semble plus se soucier d'être « ouvert ». C'est un exemple typique d'une pente glissante : lorsque vous commencez avec Open Core, il y a moins d'incitation à publier de nouvelles fonctionnalités dans le « core ». Avec le temps et les nouvelles versions, le logiciel devient de plus en plus propriétaire.

Néanmoins, l'Open Core est un continuum complet : il va de quelques fonctionnalités fermées à presque toutes les fonctionnalités fermées ou parfois presque toutes les fonctionnalités ouvertes mais sans la liberté de les utiliser comme on le souhaite. Pour moi, le vrai problème de l'Open Core est le glissement progressif vers des produits propriétaires, car la tentation est grande. Ce raccourci a pour effet pernicieux de tuer lentement mais sûrement le logiciel libre. Est-il possible d'adopter l'Open Core tout en conservant la même proportion de logiciels libres et en prenant des décisions responsables quant à l'accessibilité des fonctionnalités (voir ci-dessous) ? Peut-être, mais il est peu probable que la plupart des entreprises qui optent pour l'Open Core parviennent à cet équilibre.

Un autre problème intéressant avec l'Open Core : il a tendance à garder les fonctionnalités de sécurité dans la partie non libre : voir le grand « SSO Wall of Shame » pour comprendre à quel point ce modèle d'Open Core peut entrer en conflit avec la sécurité. Note : ce mur est très obsolète, et la liste des acteurs honteux devrait déjà être 10 fois plus grande qu'elle ne l'est actuellement.

Licences d'utilisation équitable ou de code équitable

Les licences d'utilisation équitable ou de code équitable, également appelées « licences d'utilisation durable », constituent une autre alternative à l'Open Core. Avec ces licences, vous supprimez une liberté des licences originales de logiciels libres : la liberté de commercialiser ou de revendre le logiciel comme vous le souhaitez. Si vous l'utilisez à des fins internes (au sein de votre entreprise), c'est très bien. Si vous souhaitez créer un service à partir de ce logiciel, par exemple l'héberger et le vendre, vous ne pouvez pas le faire.

Cette approche est intéressante, car elle permet aux particuliers d'utiliser le logiciel comme ils le souhaitent tout en limitant la capacité des entreprises à l'exploiter sans contribution. Cependant, elle rend également moins attrayante la contribution d'une entreprise, car il est moins intéressant de construire des choses autour d'un logiciel verrouillé.

À mon avis, les licences « fair-use » ou « fair-code » sont un moindre mal par rapport à l'Open Core. Ce modèle peut avoir du sens pour certains logiciels faciles à revendre, comme un logiciel de base de données qui pourrait être vendu par un grand fournisseur tiers de services en cloud. Il est probablement moins dangereux pour le logiciel libre que l'Open Core.

Malheureusement, j'ai vu des entreprises combiner à la fois l'utilisation équitable et l'Open Core, ce qui, à mon avis, est très proche d'un logiciel propriétaire. C'est encore pire parce que les utilisateurs peuvent être incités à utiliser des logiciels qu'ils croient ouverts alors qu'ils ne le sont pas. Par exemple, https://n8n.io affiche « Full source code available » et « Self host-able » sur son site web, alors qu'il n'offre que quelques fonctionnalités ouvertes (un petit noyau ouvert et la plupart des fonctionnalités fermées) et qu'il utilise une licence d'utilisation équitable.

L'aveu d'un échec ?

S'agit-il d'une incapacité des licences de logiciels libres à protéger les concepts initiaux à l'ère de l'informatique dématérialisée, du SaaS, etc ? Peut-être. Mais il existe de nombreuses façons de maintenir l'ouverture tout en gagnant de l'argent. Il sera intéressant d'explorer ces approches dans un prochain article, en mettant en lumière la manière dont les entreprises peuvent trouver un équilibre entre le maintien de l'esprit du logiciel libre et la réussite financière. La clé consiste à trouver des solutions innovantes qui respectent le contrat moral et préservent les principes fondamentaux du mouvement du logiciel libre.

Le mouvement Open Core découle de deux facteurs : premièrement, une réaction à la rupture initiale du contrat moral par les utilisateurs finaux, et deuxièmement, le désir de prendre un raccourci pour éviter la difficulté de monétiser les logiciels libres.

En tant qu'éditeur de logiciels libres ayant créé une entreprise à partir de zéro avec 40 personnes travaillant sur des produits entièrement libres, je sais que c'est difficile. Nous avons réussi à nous développer et à gagner des millions tout en préservant l'esprit originel du logiciel libre. Cela demande peut-être plus d'efforts que de prendre le raccourci du noyau ouvert, mais je ne pense pas que nous soyons uniques, et d'autres peuvent réussir de la même manière. Cela implique de résoudre plus de problèmes, d'améliorer la communication et de rendre la proposition de valeur claire.

Les logiciels libres sont partout, et si nous voulons qu'ils le restent, il faut se battre pour eux. En tant qu'éditeur de logiciels, notre mission est de trouver des moyens de maintenir l'ouverture tout en apportant plus de valeur à notre service, en augmentant la visibilité de notre travail et en faisant comprendre à nos utilisateurs, particuliers et entreprises, que tout notre travail est possible grâce au contrat moral. De nombreux utilisateurs de la communauté le comprennent parfaitement. Pour les entreprises, il est de notre responsabilité de créer un produit qui n'a aucun sens s'il est utilisé sans payer, même si le client ne se préoccupe pas des logiciels libres.

***

• Ce texte est une traduction d'un article intitulé « The moral contract » et publié sur virtualize.sh.
• Auteur : Olivier Lambert, PDG et co-fondateur de Vates.
• Date : 4 mai 2023
• Le blog d'Olivier Lambert

• Image d'illustration : Wikimedia Commons - Licence : CC BY-SA 4.0 International

Retrouvez-moi sur Mastodon →