HashiCorp adopte la Business Source License
(hashicorp.com)- HashiCorp va faire passer la licence du code source de ses futures versions de produits de la MPL 2.0 à la Business Source License v1.1, afin de poursuivre ses investissements dans la communauté et ses produits
- Le modèle open source existant a permis de créer un vaste écosystème, mais HashiCorp estime que le problème s’est aggravé avec certains fournisseurs qui exploitent commercialement le travail de la communauté sans apporter de contribution réelle
- La BSL 1.1 est une licence source-available qui autorise la copie, la modification, la redistribution, les usages non commerciaux et certains usages commerciaux sous conditions ; les API, SDK et la plupart des bibliothèques restent sous MPL 2.0
- Les utilisateurs finaux, partenaires, clients enterprise et clients des produits managés dans le cloud peuvent globalement continuer leurs usages existants, sauf lorsqu’il s’agit de proposer des produits concurrents de HashiCorp
- Les fournisseurs qui proposent des services concurrents basés sur les produits communautaires de HashiCorp auront désormais plus de difficulté à intégrer les futures versions, corrections de bugs et correctifs de sécurité
Périmètre du changement de licence
- La licence du code source de toutes les futures versions des produits HashiCorp passe de la Mozilla Public License v2.0 (MPL 2.0) à la Business Source License (BSL ou BUSL) v1.1
- Les API, SDK et presque toutes les autres bibliothèques HashiCorp restent sous MPL 2.0
- Le code source des produits et les mises à jour continueront d’être publiés dans les dépôts GitHub et les canaux de distribution de HashiCorp
- HashiCorp vise une approche qui permette de partager largement le code source et d’en autoriser l’usage gratuit, tout en minimisant l’impact sur la communauté, les partenaires et les clients
Modèle open source et pression de la commercialisation
- Lorsque HashiCorp a été fondée, elle a publié ses produits en open source pour trois raisons
- Les praticiens devaient pouvoir télécharger et examiner librement le code source, et résoudre eux-mêmes les problèmes
- Il fallait créer un écosystème et une communauté autour des produits afin de permettre de nombreuses intégrations
- La transparence est importante pour les utilisateurs
- Pendant plus de dix ans, l’entreprise a fourni de nouveaux produits et fonctionnalités sous licence open source gratuite, ce qui a fait naître une grande communauté d’utilisateurs, de contributeurs, de partenaires et de clients
- Elle investit chaque année des dizaines de millions de dollars dans la R&D de produits open source, un modèle rendu possible par des clients commerciaux qui collaborent avec HashiCorp sur des infrastructures critiques
- Elle a travaillé étroitement avec les fournisseurs cloud afin de fournir des intégrations pour les utilisateurs et clients communs, et a également collaboré avec des centaines de partenaires technologiques
Modalités d’application de la BSL 1.1
- La BSL 1.1 est une licence source-available qui autorise la copie, la modification, la redistribution, les usages non commerciaux et les usages commerciaux sous certaines conditions
- Ces dernières années, Couchbase, Cockroach Labs, Sentry et MariaDB ont suivi une voie similaire ; MariaDB a développé cette licence en 2013
- Confluent, MongoDB, Elastic et Redis Labs sont également cités comme exemples d’entreprises ayant adopté des licences alternatives incluant des restrictions d’usage commercial
- L’application de la BSL par HashiCorp inclut une autorisation d’usage additionnelle permettant une large utilisation permissive du code source
- Dans le cadre de l’élaboration de la licence, l’entreprise a consulté des experts des licences OSS et des parties prenantes du secteur afin de s’aligner sur les pratiques de l’industrie
Impact pour les utilisateurs, partenaires et clients
- Les utilisateurs finaux peuvent continuer à copier, modifier et redistribuer le code pour tous les usages non commerciaux et commerciaux, sauf s’ils proposent un produit concurrent de HashiCorp
- Les partenaires peuvent continuer à créer des intégrations pour les clients communs
- L’entreprise prévoit de continuer à travailler étroitement avec les fournisseurs de services cloud afin de maintenir une prise en charge approfondie de leurs technologies respectives
- Il n’y a aucun changement pour les clients enterprise et les clients des produits HashiCorp managés dans le cloud
- Les fournisseurs qui proposent des services concurrents de HashiCorp sur la base de produits communautaires ne pourront plus intégrer les futures versions, corrections de bugs et correctifs de sécurité aux produits HashiCorp
Suite
- HashiCorp affirme que ses engagements envers la communauté, les partenaires et les clients restent inchangés
- Pour les questions supplémentaires, HashiCorp met à disposition une foire aux questions
1 commentaires
Avis sur Hacker News
La seule conclusion à en tirer ici est que HashiCorp n’est plus une entreprise open source
Le fait qu’il existe des « fournisseurs qui exploitent le modèle OSS pur et le travail de la communauté à des fins commerciales sans apporter de contribution réelle en retour » est 100 % conforme à l’esprit de l’open source
Si c’est un problème, il suffit d’adopter une licence open source qui oblige les développeurs à publier leur code, comme l’AGPL
Ici, c’est simplement une manière pour HashiCorp de faire en sorte que ses anciens projets open source ne puissent être commercialisés que par eux ; en soi, pourquoi pas, mais dans ce cas il faut passer en source fermé et l’assumer, pas essayer d’avoir le beurre et l’argent du beurre
Le billet de blog n’est pas honnête. Nous avons essayé à plusieurs reprises de contribuer des correctifs upstream aux providers Terraform, mais HashiCorp ne les a jamais acceptés, si bien que nous avons dû maintenir un fork
HashiCorp a perdu son ADN OSS depuis longtemps, et cette décision enfonce le dernier clou dans le cercueil
Heureusement, avec le temps, ils ont transféré la majeure partie de la responsabilité des providers Terraform à des partenaires ; j’espère donc que l’écosystème des providers pourra rester actif et ouvert
Je crois profondément à l’open source. Mon dernier projet chez Microsoft a été de rendre .NET open source et multiplateforme ; notre CTO a participé à la création de TypeScript ; et Pulumi est aussi un projet open source Apache. HashiCorp ne semble plus être dans ce cas
Globalement, les temps ont changé, et je pense que la publication du code source devrait relever d’une relation mutuellement bénéfique entre ceux qui créent et ceux qui utilisent, plutôt que de « si vous ne donnez pas tout gratuitement, ce n’est pas authentique »
Les utilisateurs doivent pouvoir comprendre et étendre ce qui tourne à partir du code source, et les responsables, mainteneurs et propriétaires du projet doivent pouvoir continuer à faire ce travail
Ce n’est pas un point d’équilibre à atteindre, mais un équilibre à maintenir sous tension
En vérifiant Wikipédia, HashiCorp aurait fixé les conditions de son IPO le 29 novembre 2021
Cette hypothèse me paraît de plus en plus juste. Les anecdotes, qu’elles soient des contre-exemples ou des cas allant dans ce sens, sont les bienvenues
Ce n’est pas parce que ce n’est pas open source qu’il faut nécessairement empêcher de voir le code, ni retirer toutes les caractéristiques d’une licence approuvée par l’OSI
Bien sûr, cela aurait été mieux si c’était du logiciel libre, mais c’est aussi vrai de dire que tout serait mieux si tous les logiciels étaient libres
Le problème apparaît quand on fait passer pour open source une licence qui ne peut pas être approuvée par l’OSI. HashiCorp ne prétend toujours pas que c’est open source et parle désormais de « source disponible » (source-available)
C’est assez décevant. Personnellement, à part Vault, je n’ai pas beaucoup utilisé leurs produits ; j’ai essayé Terraform, mais je ne l’ai pas apprécié ni construit quoi que ce soit dessus. Or cela va exactement à l’encontre de ce que j’aimais le plus dans les produits HashiCorp
J’ai même contribué à une partie du code que j’utilise le plus dans Vault, la gestion des certificats ; je dois maintenant réévaluer si je peux encore recommander ce service à des clients à l’avenir, et si je contribuerai à nouveau
Avec l’assèchement du financement par capital-risque, on a l’impression de voir se révéler le pire avenir possible pour les licences qui ne sont pas de type GPL
C’est triste pour les personnes qui ont délibérément appris l’OSS et son fonctionnement avec le rêve d’utiliser un jour ces connaissances pour créer un service, devenir leur propre patron, et continuer à rendre à l’OSS ce qui les a amenées jusque-là
J’ai beaucoup d’expérience dans la mise en œuvre et l’exploitation de Vault Enterprise pour la gestion des secrets applicatifs à l’échelle de l’infrastructure d’entreprise
Pendant les années où nous avons adopté Vault et négocié les contrats, j’ai vu des ingénieurs commerciaux tenir des propos inexacts ou trompeurs sur les fonctionnalités « nécessaires » à nos cas d’usage, et faire des promesses de fonctionnalités à long terme qu’ils ne pouvaient pas tenir
Ils recommandaient aussi des modes d’intégration qui pouvaient rendre une migration hors de Vault pratiquement impossible ou risquée, et ils ont continué à retirer des fonctionnalités que nous pensions gratuites pour toujours. La connexion Okta/MFA en est le plus gros exemple : il est difficile de passer une conformité sérieuse sans elle, et HashiCorp semble avoir compris que les équipes fortement dépendantes de Vault finiraient par devoir payer pour cette fonction
Dans l’ensemble, cela ressemblait fortement à de l’enfermement fournisseur, et chaque année nous payions davantage pour les mêmes fonctionnalités, voire moins. Même les ingénieurs ne savaient pas expliquer la politique tarifaire, qui changeait sans cesse de manière arbitraire
Je considère Vault lui-même comme un excellent logiciel, mais comme j’ai perdu confiance en HashiCorp, je ne pense pas m’y appuyer personnellement pour des usages critiques
Pris au pied de la lettre, rien n’a changé, et ce n’est pas décevant : c’est un choix intelligent. Ils se protègent des fournisseurs cloud qui ont abusé à répétition de la bonne volonté de la communauté open source
Il ne faut pas faire confiance aux projets OSS qui exigent des contributeurs qu’ils cèdent leurs droits d’auteur, et ils ne devraient même pas accepter des contributions de bonne foi au départ
Sinon, même si c’est sous Apache 2.0 aujourd’hui, cela peut devenir commercial demain sans demander la permission à personne, parce que le mainteneur possède 100 % du code
Il est généralement rare qu’un projet OSS soutenu par une entité commerciale reçoive une quantité significative de contributions externes, mais cela reste un détail important à garder en tête dans l’OSS
Dire que « le modèle open source commercial doit évoluer pour que l’écosystème puisse continuer à fournir des logiciels ouverts et librement utilisables », tout en laissant entendre que des licences non open source comme la BUSL feraient partie de l’évolution du modèle open source, relève d’une grave confusion ou d’une volonté délibérée d’induire en erreur.
Quelqu’un d’une taille significative a-t-il déjà utilisé des produits HashiCorp pour concurrencer réellement HashiCorp ?
[1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U...
Pulumi peut convertir n’importe quel Terraform Provider pour l’utiliser dans Pulumi, ce qui permet de gérer avec des programmes Pulumi toute l’infrastructure prise en charge par l’écosystème des Terraform Providers.
Si les entreprises prennent ce genre de mesures, c’est parce que des sociétés comme Amazon utilisent des licences libres et open source pour monter des versions auto-hébergées de projets open source.
ctrl+f, on voit à partir de quel moment ils cessent d’employer l’expression.HashiCorp explique ce changement non pas comme un moyen de rester « open source », mais de maintenir des produits ouverts et librement utilisables.
Je trouve qu’ils sont plus honnêtes que d’autres, dans la mesure où ils ne disent pas rester « open source » tout en changeant de licence. Ils savent manifestement les réactions que cela provoquerait s’ils l’appelaient ainsi.
Il est intéressant que @mitchellh ne participe pas à la discussion. Par le passé, il échangeait directement sur HN, et j’imagine qu’il a eu une influence déterminante sur cette décision.
Globalement, cela ressemble à un coup de perdant. Il suffit de voir ce qui est arrivé à Elasticsearch. Pour moi et pour la plupart des gens, ES n’existe plus. Je suis passé avec plaisir à OpenSearch, sans un regard pour le pauvre kimchi. Par ses propres actions, Elasticsearch n’est plus pertinent.
Ce mouvement de HashiCorp va-t-il déclencher un effort similaire pour forker les dernières versions sous licence open source de Terraform et de ses autres outils ? Quand les créateurs deviennent mesquins et anxieux, et se montrent hostiles envers la communauté open source qui les a aidés à construire tout cela, quelles autres options reste-t-il ?
Je suis extrêmement déçu par la direction de HashiCorp. MitchellH et Armon Dadgar auraient dû mieux traiter la communauté.
J’ai passé des entretiens chez HashiCorp en 2016 et j’ai finalement refusé de les rejoindre ; il m’est arrivé de regretter un peu cette décision. Maintenant que leur vraie nature se révèle, je suis convaincu d’avoir fait le bon choix.
Il y a cette phrase sur la confiance : il faut des années pour la construire, quelques secondes pour la briser, et une éternité pour la regagner.
C’est stupéfiant de voir des gens que je pensais intelligents se montrer aussi stupides.
Inutile d’insulter quelqu’un qui a accompli beaucoup de choses.
Leurs logiciels étaient open source, et les bons projets seront forkés, donc il n’y a pas besoin de détester HashiCorp.
Je ne suis pas non plus d’accord avec la formule « il faut des années pour construire la confiance, quelques secondes pour la briser, et une éternité pour la regagner ». C’est trop agressif.
HashiCorp a créé d’excellentes choses et a tenté de bâtir une activité sur de l’open source. Ils n’ont pas rompu de contrat ni fait quoi que ce soit d’immoral ; c’est leur choix.
On dirait l’issue inévitable pour toutes les entreprises open source une fois l’argent gratuit terminé. Ce qui me dérange, c’est que la formulation est assez vague.
HashiCorp définit un produit concurrent comme « tout produit ou service fourni à des utilisateurs ou clients extérieurs à l’organisation et dont les fonctionnalités recoupent substantiellement celles des produits ou services commerciaux de HashiCorp ».
Imaginons par exemple qu’il n’existe pas de service d’estimation des coûts, que quelqu’un en crée un et qu’il devienne populaire : https://github.com/infracost/infracost
Que se passe-t-il si, deux ans plus tard, Terraform Cloud arrive avec la même chose ? Faut-il fermer l’activité ?
Mais pour des produits cœur de métier plus importants comme les bases de données, on voit des contorsions beaucoup plus étranges : rendre l’auto-hébergement difficile, limiter des fonctionnalités essentielles, etc.
C’est mieux que du code fermé, mais ce n’est pas idéal. Je pense depuis un moment qu’une licence pourrait être une issue pragmatique, mais elle doit être largement comprise, équitable et claire.
La formulation « produits ou services fournis à des utilisateurs ou clients extérieurs à l’organisation et dont les fonctionnalités se recoupent substantiellement » fait mal. Sur le texte, elle est (1) floue et (2) donne à l’entreprise le pouvoir d’interpréter cette ambiguïté, ouvrant la voie à une application sélective.
Dans un contexte où l’on signe un document juridique, « ne vous inquiétez pas, nous ne poursuivrons personne » n’est pas convaincant. Accumuler dans un contrat des droits qui paraissent bénins aujourd’hui ou qui pourront être exercés plus tard est pour moi un énorme signal d’alerte.
Je serais curieux de savoir ce que les autres pensent de cette licence elle-même.
Le point sur « Terraform Cloud arrive deux ans plus tard » est vraiment pertinent. Le périmètre d’une entreprise change.
D’après https://www.couchbase.com/blog/couchbase-adopts-bsl-license/, la BSL prévoit généralement une date de changement située entre 1 et 4 ans, moment auquel la licence BSL bascule vers une licence de changement open source comme la GPL, l’AGPL, Apache, etc.
La question la plus importante est donc de savoir quelle est cette licence de changement et combien de temps cela prend.
Si cela passe à MPL 2.0 au bout d’un an, ça va. Mais si c’est beaucoup plus long et plus restrictif, c’est un revirement complet, et la version open source sera tellement éloignée de la version la plus récente qu’elle deviendra de fait inutilisable.
Correction : MPL 2.0 au bout de 4 ans.
https://www.hashicorp.com/license-faq#What's-the-difference-...
Quand la sécurité est en jeu, 4 ans relèvent en pratique du simple « intérêt historique ».
4 ans, MPL 2.0.
Je ne sais pas pour les autres entreprises, mais je me demande toujours où en seraient ces sociétés si leurs logiciels avaient été sous licence non libre dès le départ.
C’est hostile non seulement aux grandes entreprises qui voudraient « voler » le code pour le proposer en service, mais aussi aux utilisateurs finaux, aux petites personnes et aux petites entreprises.
Si vous exploitez et utilisez avec succès un logiciel HashiCorp et que vous êtes considéré comme un concurrent, HashiCorp peut décider de vous bloquer.
Par exemple https://github.com/hashicorp/vault/blob/main/go.mod#L25
S’ils avaient commencé directement avec la BSL, je ne pense pas qu’ils auraient été adoptés aussi largement.
La page CLA de HashiCorp il y a deux mois : https://web.archive.org/web/20230610041432/https://www.hashi...
Elle disait que « pour permettre à HashiCorp de bâtir une activité durable tout en faisant en sorte que les projets restent sous des licences libres et open source comme MPL2, nous demandons aux contributeurs externes de signer un accord de licence de contributeur (CLA) ».
Elle disait aussi que « HashiCorp s’engage à appliquer de véritables licences de logiciel libre et open source (FOSS) aux logiciels non commerciaux. Le CLA permet à HashiCorp de commercialiser ses produits en toute sécurité, tout en conservant tous les droits accordés par les licences FOSS standard, comme le droit pour les utilisateurs de les utiliser dans leurs propres projets ou activités, de republier les sources modifiées et de réaliser un fork complet ».
Il est décevant de constater que le texte non juridique de la page suggérait à plusieurs reprises que signer le CLA aidait à maintenir les projets HashiCorp open source, alors que le texte contractuel réel n’offrait pas une telle garantie.
Quelqu’un devrait contester la situation quand l’hypothèse du CLA, à savoir que les contributions soient relicenciées en non-FOSS, change.
La plupart des CLA sont très arides, mais HashiCorp a mis plusieurs déclarations dans le sien, ce qui pourrait les mettre dans l’embarras.
La seule raison d’exiger ce genre de chose, c’est le relicenciement, et si le projet est déjà FOSS, la seule raison de vouloir le relicencier est de passer à du logiciel propriétaire.
Linux n’exige pas de CLA pour les contributions. Seuls ces clowns qui font semblant de faire de l’open source l’exigent.
Notre entreprise OSS est sous Apache 2.0 et s’est construite autour de Nomad comme cœur du système.
Nous y avons ajouté quelques services pour fournir de l’orchestration de serveurs de jeu, ce qui pourrait être interprété à tort par HashiCorp comme une « offre de produit concurrente ».
Comme la licence est volontairement ambiguë, nous allons figer la version de Nomad sur la dernière version MPL.
Nous utilisons aussi CockroachDB, qui est sous BSL, mais nous ne proposons absolument aucun produit qui concurrence ce dernier.
Il est très probable que je continue à recommander les produits HashiCorp, Nomad, Consul, Terraform et Packer, aux personnes qui me demandent conseil, mais ce changement semble décevant.
Pour ceux que cela intéresse, nous maintenons un SBOM simple : https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
Je suis responsable de l’ingénierie de Nomad. La licence échappe à mon contrôle, mais beaucoup d’utilisateurs craignent de ne pas savoir si, un jour, cela pourrait être interprété comme de la concurrence.
Je ne peux rien promettre, mais je ferai tout mon possible pour vous aider à être convaincu que Nomad reste l’outil adapté à votre travail.
Personnellement, je ne vois pas de problème. Si l’objectif final est de devenir une plateforme SaaS, j’aimerais que davantage de projets open source démarrent dès le départ sous Business Source License
J’ai vu à maintes reprises de grandes entreprises abuser de l’esprit de l’open source pour leurs propres intérêts financiers, sans rien rendre en retour, et agir de façon malveillante
Ils ne considèrent pas comme malveillant d’utiliser ce qui a été rendu public et disponible, et acceptent volontiers de le distribuer gratuitement
Sinon, ce n’est pas de l’open source. Bien sûr, tous les logiciels n’ont pas besoin d’être open source, donc cela peut aussi très bien se défendre
Ceux qui abusent de l’esprit de l’open source, ce sont ceux qui inventent des règles arbitraires sur son utilisation
Cela dit, il vaut mieux être clair dès le départ