Rug pull, forks et féodalisme open source

• Synthèse sur la manière dont les dynamiques de pouvoir de l’écosystème open source fonctionnent entre entreprises, développeurs et utilisateurs, ainsi que sur l’impact des tactiques de rug pull (relicensing) et de fork qui viennent les bousculer
• Alors que les grands fournisseurs cloud exercent une forte influence, les projets centrés sur une seule entreprise peuvent redistribuer le pouvoir via un changement de licence, et les forks apparaissent en réponse
• L’analyse de cas comme Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey et Puppet→OpenVox montre différents schémas de recomposition communautaire et de migration des contributeurs
• L’adoption d’un CLA, la domination par une seule entreprise et le moment du transfert à une fondation sont présentés comme des signaux de risque de rug pull, tandis qu’une gouvernance neutre et l’élargissement de la base de contributeurs institutionnels sont recommandés comme stratégies de réponse
• En conclusion, le relicensing peut servir de moyen de contrepoids face au cloud, mais il affaiblit aussi les droits des contributeurs, tandis que la possibilité d’un fork agit comme un frein sur les décisions des entreprises

---

Structures de pouvoir dans l’open source, rug pulls et forks

• Dans l’écosystème du logiciel open source, grandes entreprises, PME, contributeurs et utilisateurs exercent chacun un pouvoir pour influer sur l’orientation du logiciel et son modèle économique
• Les grands fournisseurs cloud, en particulier, finissent par disposer d’un pouvoir considérable et tendent à dominer les petites entreprises comme les communautés
• Dans ce contexte, des déplacements de pouvoir se produisent soit quand l’entreprise de développement ou la société propriétaire du projet change la licence du logiciel (rug pull), soit quand la communauté ou une autre entreprise lance un fork

Vue d’ensemble des dynamiques de pouvoir et des tactiques

• Dans l’univers open source, les grands fournisseurs cloud exercent le plus fort pouvoir de canal et de distribution, créant une structure qui exploite petites entreprises, contributeurs et utilisateurs
  • À la manière du contrôle des terres à l’époque féodale, les fournisseurs cloud transforment les logiciels open source en services tout en évitant de contribuer
  • Les petites entreprises assurent l’essentiel du travail de développement, mais se retrouvent désavantagées par l’usage gratuit qu’en font les fournisseurs cloud
• Par la tactique du rug pull, les petites entreprises relicencient leur logiciel pour répondre aux fournisseurs cloud, mais cela cause souvent des dommages encore plus importants aux contributeurs et aux utilisateurs
  • Quand les fournisseurs cloud transforment un projet en service sans contribuer, le pouvoir des petites entreprises s’affaiblit
  • Le relicensing nuit aux utilisateurs, mais un fork peut permettre de rééquilibrer le rapport de force
• Dans les projets pilotés par une seule entreprise, le risque de rug pull est élevé, ce qui oblige à évaluer la réputation de l’entreprise, même si cela peut devenir caduc en cas de fusion-acquisition ou de faillite
  • La pression des investisseurs peut conduire à un relicensing pour accroître les revenus, surtout en situation de concurrence avec les fournisseurs cloud
  • En adoptant une licence plus restrictive, l’entreprise tente de rendre plus difficile la monétisation par des tiers et de déplacer le rapport de force
• La création de forks à la suite d’un rug pull constitue une forme d’action collective rebelle pour reprendre du pouvoir, mais le manque de personnel et de ressources fait peser un fort risque d’échec
  • Les grandes entreprises ou les fournisseurs cloud peuvent soutenir un fork grâce à leurs ressources, mais même les forks populaires ne réussissent pas toujours
  • Il existe aussi des cas sans fork, comme MongoDB ou Sentry ; à l’inverse, l’acquisition de Puppet par Perforce et la fermeture du développement ont provoqué le fork OpenVox

Comparaison des principaux cas

Dawn Foster analyse, données à l’appui, divers rug pulls, forks et leurs effets ultérieurs. (Une partie des résultats est publiée sous forme de dataset dans un notebook Jupyter.)

• Elasticsearch → OpenSearch
  • En 2021, après le relicensing en SSPL d’Elastic, AWS a organisé le fork OpenSearch
  • Chez Elastic, la part des contributeurs internes a peu varié avant et après le fork, tandis qu’OpenSearch reste marqué par une contribution dominée par Amazon
  • L’analyse indique qu’après le transfert à la Linux Foundation en 2024, on n’a pas observé de forte hausse des contributions externes
• Terraform → OpenTofu
  • En 2023, juste après le passage au BSL de HashiCorp, OpenTofu a été lancé sous l’égide de la Linux Foundation
  • Terraform a conservé un modèle de contribution toujours centré sur l’interne, tandis qu’OpenTofu a rapidement attiré de nouveaux contributeurs issus de plusieurs entreprises
  • Ce cas suggère qu’un fork porté par les utilisateurs et le lancement immédiat sous fondation neutre favorisent la formation d’une communauté active
• Redis → Valkey
  • En 2024, juste après le passage de Redis à la SSPL, une grande partie des contributeurs externes existants a migré vers Valkey
  • Redis constituait avant le fork un cas atypique avec une forte part de contributions externes ; après le fork, ces contributions externes sont tombées à zéro, tandis que Valkey a démarré comme une communauté fédérant plusieurs entreprises
• Puppet → OpenVox
  • Après le rachat par Perforce (2022), le développement et les releases ont été fermés et leur fréquence a diminué, poussant la communauté à lancer le fork OpenVox

Observations et métriques issues des données

• Après un rug pull, on observe souvent une hausse brutale du nombre de forks GitHub, interprétée comme un signal indirect d’une réflexion autour d’un hard fork
  • À long terme, l’original et le fork tendent à avancer en parallèle, mais l’analyse observe une baisse d’usage de l’original relicencié
• Le lancement sous l’ombrelle d’une fondation aide à attirer des contributions au démarrage d’un nouveau projet, mais un transfert a posteriori peut avoir un effet limité
  • Le cas OpenSearch suggère qu’un simple transfert ne garantit pas à lui seul une forte hausse des contributions externes

Signaux de risque et lignes directrices

• L’usage d’un CLA (Contributor License Agreement) est un signal qui concentre dans l’entreprise le pouvoir de relicensing et accentue le déséquilibre de pouvoir
  • Les projets fondés sur le DCO (Developers Certificate of Origin) tendent à présenter un risque de rug pull plus faible
• Il faut examiner la gouvernance : la domination par une seule entreprise et la concentration du leadership sont des facteurs de risque
  • Les projets dotés d’une fondation neutre, d’un leadership multi-institutionnel et d’une base de contributions externes large sont avantagés du point de vue de la durabilité
• L’ampleur et la profondeur de la base de contributeurs constituent aussi un critère d’évaluation central
  • Les entreprises ont intérêt à détacher directement des contributeurs vers les projets dont elles dépendent afin de renforcer à la fois leur influence et leur durabilité
  • Les métriques et le guide pratique de CHAOSS peuvent être utilisés pour diagnostiquer et améliorer la santé d’un projet

Recommandations sur la communauté et la gouvernance

• L’orientation vers une gouvernance neutre et l’élargissement du nombre de contributeurs externes constituent des moyens concrets de freiner les rug pulls
  • La simple possibilité d’un fork augmente déjà le coût d’une décision de relicensing pour une entreprise et agit comme mécanisme dissuasif
• En réponse à une question de Hazel Weakly sur les garde-fous, l’intervenante cite les succès de Valkey et OpenTofu comme cas réels ayant poussé à reconsidérer des relicensings
  • Dirk Hohndel souligne que le fait d’attirer davantage de contributeurs externes accroît le risque de rug pull et augmente donc le risque managérial associé à une telle décision

Conclusion

• À mesure que l’influence des grands acteurs du cloud grandit, l’écosystème open source prend de plus en plus une structure féodale
• Le changement de licence permet de contenir la puissance des fournisseurs cloud, mais produit en contrepartie un affaiblissement des droits des contributeurs communautaires
• Les contributeurs et les utilisateurs disposent toutefois du fork comme moyen de riposte, ce qui distingue fondamentalement l’open source du féodalisme historique
• La possibilité concrète d’un fork influe sur les décisions futures des entreprises ; les succès de Valkey et d’OpenTofu ont même conduit certaines entreprises à abandonner leurs projets de rug pull
• En définitive, la neutralité de la gouvernance et l’activation des contributeurs externes sont la clé pour prévenir les rug pulls et maintenir un écosystème sain

Références

• Slides de présentation : Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

Comme les forks ne sont pas encore faciles à réaliser pour le moment, j’aimerais qu’il existe parmi les organisations liées à l’open source des structures qui puissent aider sur ce point.

[GN⁺]

Avis Hacker News

• Les projets qui utilisent des CLA (Contributor License Agreement) voient plus souvent se produire des rug pulls (quand les efforts des contributeurs sont appropriés par une minorité), alors que cet déséquilibre est moins marqué dans les projets qui utilisent un DCO (Developers Certificate of Origin). Signer un CLA revient à donner au projet le droit de relicencier le code que j’y ai contribué. Autrement dit, même si je contribue à un projet GPL sous GPL, la licence peut ensuite être modifiée. Si la licence est déjà permissive, le CLA a peu d’effet, mais avec une licence copyleft (par ex. GPL), cela devient injuste, car seule la partie ayant fait signer le CLA peut se réserver une propriété exclusive. Pour éviter un rug pull, mieux vaut utiliser une licence copyleft et éviter les CLA. Avec une licence permissive, il faut comprendre que le rug pull fait « partie du jeu »
  • Les projets GNU demandent eux aussi un CLA, mais je ne pense pas qu’ils le fassent avec l’intention de provoquer un rug pull
  • Je veux préciser que signer un CLA ne donne pas automatiquement l’intégralité des droits de relicenciement ; cela dépend du texte de chaque CLA. Par exemple, une clause du CLA de Canonical (lien) promet que ma contribution sera aussi fournie selon la licence existante. Il est important de lire et comprendre le CLA. Dans la plupart des cas, le droit d’auteur reste au contributeur, qui conserve donc le droit de faire ce qu’il veut de sa contribution. Le problème de fond est que la confiance envers le propriétaire du projet peut être rompue. Le CLA donne au propriétaire le contrôle, ce qui augmente le risque de rug pull. Pour y répondre, il faut en pratique forker et collaborer soi-même pour en tirer un bénéfice. Quand une licence copyleft est combinée à un CLA (par ex. AGPL + CLA), cela peut être encore plus nuisible qu’une licence permissive + CLA. L’AGPL impose de publier le code source même en cas de mise à disposition comme service, mais avec un CLA, le propriétaire peut exploiter un service fermé sans publier ses améliorations. On l’a vu dans des cas réels comme Incus et LXD, où la combinaison entre licence et CLA a provoqué une fracture de la communauté et limité le partage de code (cas détaillé)
  • À mon avis, le phénomène de rug pull n’existe pas dans l’open source. Une copie GPL existe pour toujours
  • Les licences permissives augmentent bien la possibilité d’un rug pull, mais un CLA ne donne pas toujours tous les droits
  • Je ne pense pas qu’il soit sain de considérer de manière excessivement puriste et négative le discours autour du « rug pull » dans l’open source. Un projet doit être durable. Dans une situation où les grands fournisseurs cloud dominent l’infrastructure, il vaudrait mieux que les petits développeurs consacrent leur énergie à atténuer les monopoles des grandes entreprises plutôt qu’à se disputer sur l’open source ou les projets à CLA
• Les contributeurs et mainteneurs ont souvent encore moins de pouvoir que les petites entreprises. Cela dit, avec une licence libérale, si on est mécontent, on peut forker et suivre une autre voie. Le cas de Valkey montre à quel point les changements de licence autour de Redis sont intéressants. J’ai l’impression qu’aujourd’hui, toute la communauté des développeurs s’est trop habituée aux services cloud et manque de la volonté qu’elle avait autrefois pour forker ou réimplémenter activement des OS, compilateurs, DB, etc. On oublie aussi souvent que des entreprises cloud comme AWS ont accru la visibilité de certains projets en les proposant comme service (par ex. la popularité d’ElasticSearch après son arrivée chez AWS). Le cloud contribue aussi au kernel, à gcc, au jdk, etc., ce qui profite indirectement aux petites entreprises. Plutôt que d’accuser trop facilement les grands acteurs du cloud, il vaudrait mieux repenser le business model lui-même. Si tout avait été fermé dès le début, personne ne s’y serait intéressé
• Si vous ne recevez pas le logiciel sous forme de binaire, mais que vous le compilez directement depuis le code source, vous êtes mieux armé face à des événements comme un rug pull. Les utilisateurs qui installent via les binaires ou images du fournisseur ont du mal à basculer vers un fork, alors qu’il est relativement simple de faire pointer l’infrastructure de build vers de nouvelles sources. On peut aussi intégrer soi-même les correctifs ou fonctionnalités nécessaires, ce qui réduit la dépendance à la maintenance du fournisseur
  • C’est précisément pour cela que j’aime Guix. La compilation depuis les sources est le mode par défaut, avec en plus des paquets binaires fournis via un système de cache. S’il n’y a pas de binaire, le système compile directement les sources de façon reproductible. On peut aussi installer facilement des versions patchées avec le même gestionnaire de paquets, sans avoir besoin d’une infrastructure de build séparée. À grande échelle, il est plus efficace d’avoir un serveur de build
  • Je ne sais pas pourquoi il y a des votes négatifs, mais je suis d’accord. Compiler depuis les sources n’est généralement pas difficile (voir sqlite)
  • En pratique, les restrictions varient selon la licence du logiciel. Même parmi les logiciels commerciaux qui fournissent le code source, beaucoup n’autorisent pas librement sa modification. Par exemple, certains produits commerciaux basés sur des langages de script, ou des prestations de conseil d’entreprise où le code est remis au client mais le droit de compiler fait l’objet d’un paiement séparé
• Après le rug pull d’Elasticsearch, le fait qu’Amazon contribue directement à un fork open source (OpenSearch) peut être vu comme un résultat partiellement positif, même si ce n’était pas l’intention initiale. Mais le déséquilibre entre contributeurs et bénéficiaires dans les grandes entreprises, qui fragilise les projets, reste un sujet essentiel
  • Utiliser un logiciel dans le respect de sa licence n’est pas un problème. Au contraire, quand des développeurs ou des startups misent sur des licences permissives en ne pensant qu’à la diffusion et à la croissance, puis se plaignent lorsque les grands acteurs du cloud arrivent, c’est contradictoire. On ne peut pas tout avoir
  • Le résultat recherché par Elastic était davantage de revenus liés aux licences, mais beaucoup d’utilisateurs sont passés au fork, ce qui a affaibli la confiance envers Elastic. La concurrence entre OpenSearch et ElasticSearch peut même être positive pour l’écosystème, mais les deux produits ne sont désormais plus compatibles et la position d’Elastic s’est affaiblie
  • Les licences copyleft comme AGPL/GPL imposent le partage du code et peuvent créer une boucle de rétroaction même sans licence propriétaire
• Il n’est pas si facile de faire un rug pull à un projet open source simplement en changeant de licence. Le problème plus fondamental est la réalité : nous ne vivons pas dans une utopie où chacun peut travailler gratuitement tout en conservant une qualité de vie suffisante. Sans mainteneur, la demi-vie d’un projet ne peut qu’être courte, et sans sponsoring, la bascule vers des licences plus fermées va s’accélérer
  • Cela me rappelle le cas de la communauté Bukkit avec Mojang/Microsoft. Au cours du recrutement de développeurs, l’entreprise a racheté discrètement le projet et a laissé un bénévole travailler pendant des années sans rémunération, jusqu’à ce qu’il utilise le DMCA pour provoquer l’arrêt du projet. Plus de détails ici : blog
  • Au fond, c’est une question d’incitations. Même si on crée soi-même un logiciel open source, les acteurs du cloud peuvent facilement le récupérer et en tirer de l’argent. Je sais bien que c’est le sens même des licences FOSS (Fully Open Source Software), mais j’ai le sentiment que la société s’est trop habituée au travail gratuit. C’est pourquoi des approches nouvelles comme la SSPL (Source-available licensing) me paraissent de plus en plus attirantes. Le fait que l’AGPL soit foss et la SSPL non à cause d’une seule clause me semble relever d’une confusion terminologique
• Je comprends que les utilisateurs vivent mal les rug pulls, mais les entreprises qui développent et maintiennent réellement un projet ont elles aussi des limites financières et se retrouvent avec très peu d’options. Sans modèle de revenus, un changement de licence devient inévitable. Parmi les alternatives possibles : financement participatif, réduction de la charge de travail, vente de produits dérivés, ou annonce préalable d’un changement si aucun financement supplémentaire n’arrive. Article connexe
  • Le fond du problème, c’est qu’on a publié sous licence OSS pour attirer des utilisateurs, puis changé brutalement vers une licence plus fermée. Si le projet n’avait jamais été OSS, il n’y aurait pas eu ce sentiment de trahison. Le problème, c’est d’avoir commencé en OSS pour attirer des utilisateurs, puis d’avoir changé ensuite
  • Mongo, Elastic, Redis, Hashicorp, etc. n’étaient pas en grande difficulté financière au moment de leur rug pull. Dans le cas de Hashicorp, cela a peut-être même servi à augmenter sa valeur en vue d’un rachat
• Ces derniers temps, on voit aussi davantage de cas où l’on met en avant des conseils de gouvernance et des modes de fonctionnement plus réglementés pour pousser les techniciens à partir d’eux-mêmes, puis réprimer les opinions contraires et révoquer leurs droits sur le projet. Une atmosphère orwellienne au nom de la « sécurité » est réellement en train de s’installer dans certaines communautés
• Presque tous les utilisateurs d’open source sont des passagers clandestins. Nous utilisons librement des projets sans rien leur apporter. L’open source peut être vu comme un cadeau sans contrepartie, ou comme une culture consistant à s’inspirer des devoirs des autres. Si l’on veut contribuer au monde, il faut le faire de bon cœur, sans attendre de récompense. Employer l’expression rug pull pour parler d’un changement de licence reflète aussi un biais. Après tout, nous avons déjà reçu le code ; même si le changement de direction est regrettable, rien n’est éternel
  • L’idée selon laquelle « nous utilisons la plupart du temps sans rien rendre » n’est pas totalement exacte. En réalité, beaucoup de projets ont bénéficié de contributions variées : code, tests, documentation, marketing, évangélisation, etc. Ces projets ne sont pas de simples développements confidentiels apparus par hasard sur GitHub ; des entreprises y ont investi beaucoup d’argent et ont activement recruté des développeurs évangélistes pour promouvoir leurs atouts techniques et de licence, afin d’élargir leur base d’utilisateurs. Dans un tel contexte, recevoir massivement du code et des contributions, puis changer brusquement de licence alors que d’autres projets FOSS en dépendent, c’est précisément ce qui est critiqué comme un rug pull. Si un projet avait été publié sans marketing, par hasard sur GitHub, puis adopté naturellement, il ne serait probablement pas au cœur d’une polémique sur le rug pull. Mais je n’ai presque jamais vu ce genre de cas
  • Je ne pense pas que ce soit une fatalité. Des entreprises ou d’autres acteurs disposant de moyens peuvent renforcer la pérennité des projets open source dont ils dépendent en contribuant financièrement et techniquement. On peut par exemple créer un Open Source Program Office, analyser l’ensemble des logiciels utilisés et de leurs dépendances, investir du temps de contribution et du financement, et encourager ce type de culture dans tout le secteur
• Dans l’entreprise où je travaille actuellement, les dirigeants sont eux aussi déstabilisés par les épisodes de rug pull. Nous avons toujours insisté pour disposer de contrats de support, mais des situations similaires se sont répétées avec Chef, CentOS, VMWare, Broadcom, etc. Nous étions prêts à payer, pourtant le simple support de base finit par coûter plusieurs milliers, voire dizaines de milliers de dollars par an, sans pour autant inspirer confiance. Dans ce contexte, j’ai l’impression qu’il vaudrait mieux soutenir une fondation ou embaucher directement, de façon régulière, des mainteneurs OSS. J’étais autrefois sceptique face à cette idée, mais elle séduit de plus en plus. Personnellement, plutôt que de payer VMWare, j’embaucherais des développeurs Proxmox ou qemu
  • Je pense que c’est la bonne idée. Il est important d’examiner tous les logiciels utilisés et leurs dépendances, puis de garantir leur durabilité au moyen de contributions en temps de développement et en financement, tout en diffusant cette attitude dans le reste du secteur
  • Fait intéressant, les entreprises citées ont effectivement créé des Open Source Program Offices pour agir davantage dans un esprit communautaire, mais à mesure que les organisations deviennent trop grandes, cette forme de duplicité — entre communauté et intérêts de l’entreprise — semble être un coût inévitable
• Forker n’est pas facile : il faut des personnes et des ressources pour réussir. L’open source ne fonctionne au fond que lorsqu’il y a beaucoup de contributeurs. Si un fork meurt, cela signifie qu’il y avait trop de passagers clandestins dans le projet. Le plus gros problème d’un rug pull est à mes yeux qu’il s’apparente à de la publicité mensongère. Attirer des clients avec l’open source, puis revenir sur cette promesse lorsqu’elle devient défavorable, pose un vrai problème moral. En revanche, l’arrêt des contributions en lui-même ne m’inquiète pas. Personne n’a l’obligation de rester éternellement sur un projet, et il est naturel qu’un individu ou une entreprise s’en retire à un moment donné.