La licence BSL 1.1 (Business Source License) de Vault autorise la grande majorité des usages, y compris le déploiement en production pour votre entreprise. Elle restreint principalement la création d'offres commerciales concurrentes.
Cette page clarifie ce que vous pouvez faire selon votre contexte professionnel.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La différence entre "source-available" et "open source"
- Ce que la licence BSL autorise explicitement
- Les restrictions et cas nécessitant un accord HashiCorp
- Votre situation selon votre profil (entreprise, consultant, éditeur)
Comprendre la BSL 1.1
Section intitulée « Comprendre la BSL 1.1 »Avant de trancher votre cas, il faut savoir ce qu'est réellement la BSL 1.1 : ni une licence propriétaire classique, ni une licence open source au sens de l'OSI. Deux notions suffisent à s'y retrouver, la distinction entre source-available et open source, puis le mécanisme de conversion qui rend la restriction temporaire. Les sections suivantes appliquent ces deux notions à des profils concrets. Ce résumé ne remplace pas le texte officiel de la licence, seul opposable.
Source-available vs Open Source
Section intitulée « Source-available vs Open Source »La licence BSL 1.1 n'est pas reconnue comme open source par l'OSI (Open Source Initiative). HashiCorp la qualifie de "source-available".
| Caractéristique | Open Source (MPL 2.0) | Source-available (BSL 1.1) |
|---|---|---|
| Code source accessible | ✅ | ✅ |
| Modification permise | ✅ | ✅ |
| Usage interne | ✅ | ✅ |
| Redistribution | ✅ | ✅ (avec conditions) |
| Usage commercial | ✅ Sans restriction | ⚠️ Restrictions "competing use" |
| Reconnaissance OSI | ✅ | ❌ |
Le mécanisme de la BSL
Section intitulée « Le mécanisme de la BSL »La BSL 1.1 fonctionne en deux temps :
- Période BSL (4 ans) : restrictions sur les usages commerciaux concurrents
- Conversion automatique : après 4 ans, le code devient MPL 2.0
Concrètement, Vault 1.15.0 est la première version publiée sous BSL : la 1.14 était encore en MPL 2.0. Elle est sortie le 26 septembre 2023, et son fichier de licence fixe la Change Date à « quatre ans après la publication ». Ce code redeviendra donc MPL 2.0 en septembre 2027.
Le point à retenir n'est pas la date elle-même : c'est que chaque version a la sienne, calculée depuis sa propre publication. Une version sortie aujourd'hui restera sous BSL quatre ans de plus. La conversion ne libère jamais la version courante, seulement celle d'il y a quatre ans.
Ce que la licence autorise
Section intitulée « Ce que la licence autorise »Commencer par les autorisations évite un contresens fréquent : la BSL ne bride ni les fonctionnalités, ni le volume, ni la production. L'édition Community reste complète et déployable telle quelle. Les deux tableaux ci-dessous séparent les usages techniques des usages commerciaux, parce que ce sont les seconds qui soulèvent des questions.
Usages expressément autorisés
Section intitulée « Usages expressément autorisés »Ces usages couvrent le quotidien d'une équipe qui exploite Vault pour elle-même. Retenez la colonne Commentaire : la plupart des lignes portent la mention « besoins internes », qui est le critère réellement déterminant.
| Usage | Autorisé | Commentaire |
|---|---|---|
| Déployer Vault en production | ✅ | Pour vos propres besoins internes |
| Utiliser toutes les fonctionnalités CE | ✅ | Aucune limitation fonctionnelle |
| Modifier le code source | ✅ | Pour vos besoins internes |
| Intégrer dans vos applications | ✅ | Vault comme composant de votre infra |
| Former vos équipes | ✅ | Formation interne |
| Distribuer des modifications | ✅ | Sous conditions (voir ci-dessous) |
Usages commerciaux autorisés
Section intitulée « Usages commerciaux autorisés »Gagner de l'argent avec une activité qui s'appuie sur Vault ne pose pas de problème en soi. Les cinq lignes ci-dessous ont un point commun : dans chacune, ce que vous vendez au client est autre chose que Vault lui-même.
| Activité | Autorisé |
|---|---|
| Utiliser Vault pour votre business (e-commerce, SaaS, etc.) | ✅ |
| Stocker les secrets de vos clients (dans votre application) | ✅ |
| Conseiller et déployer Vault chez vos clients (consulting) | ✅ |
| Former des tiers à Vault (formation commerciale) | ✅ |
| Créer des plugins pour Vault | ✅ |
Ce que la licence restreint
Section intitulée « Ce que la licence restreint »Toute la restriction tient dans un seul paragraphe de la licence, l'Additional Use Grant. Il ne parle ni de chiffre d'affaires, ni de nombre d'utilisateurs, ni de secteur d'activité : il vise une forme de distribution précise, le service hébergé ou managé proposé à des tiers. Lisez-le à la lettre avant de conclure quoi que ce soit sur votre cas.
La restriction "Additional Use Grant"
Section intitulée « La restriction "Additional Use Grant" »La BSL 1.1 de HashiCorp contient une restriction spécifique :
"You may not provide the products to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the products."
Traduction concrète
Section intitulée « Traduction concrète »Le tableau applique la clause à quatre modèles économiques courants. La ligne à retenir est la troisième : Vault derrière votre application reste un composant d'infrastructure, alors que Vault exposé à vos clients devient le service que vous leur fournissez.
| Activité | Autorisé ? | Raison |
|---|---|---|
| Offrir "Vault-as-a-Service" à des tiers | ❌ | Concurrence directe avec HCP Vault |
| Créer un "Secrets Manager" basé sur Vault et le vendre | ❌ | Produit concurrent |
| Intégrer Vault dans votre SaaS (backend uniquement) | ✅ | Vault est un composant, pas le produit |
| Revendre du support HashiCorp | ⚠️ | Accord partenaire nécessaire |
Cas limites nécessitant clarification
Section intitulée « Cas limites nécessitant clarification »Si votre modèle inclut l'un de ces éléments, contactez HashiCorp :
- Offre multi-tenant où chaque client a son "Vault"
- Produit de secrets management basé sur Vault
- Service managé de HashiCorp Vault
- Revente de licences ou support
Votre situation selon votre profil
Section intitulée « Votre situation selon votre profil »Quatre profils couvrent la quasi-totalité des questions posées sur cette licence. Identifiez le vôtre et lisez uniquement la section correspondante : les trois premiers aboutissent à un feu vert, le quatrième dépend du modèle exact. Le critère qui les départage reste toujours le même, à qui la fonctionnalité Vault est rendue accessible.
Entreprise utilisant Vault en interne
Section intitulée « Entreprise utilisant Vault en interne »Verdict : ✅ Aucune restriction
Que vous soyez une startup, une PME ou un grand groupe, utiliser Vault pour gérer vos propres secrets est le cas d'usage standard. La licence n'impose aucune contrainte.
Exemples d'usages autorisés :
- Stocker les credentials de vos bases de données
- Gérer les tokens API de vos applications
- PKI interne
- Chiffrement Transit pour vos données
- Secrets dynamiques pour vos environnements
Consultant / Intégrateur
Section intitulée « Consultant / Intégrateur »Verdict : ✅ Autorisé
Le consulting autour de Vault est explicitement permis :
- Auditer une installation Vault
- Déployer Vault chez un client
- Former les équipes d'un client
- Créer des playbooks Ansible pour Vault
- Développer des plugins personnalisés
Ce qui serait interdit :
- Offrir un service managé Vault à plusieurs clients
Éditeur de logiciel / SaaS
Section intitulée « Éditeur de logiciel / SaaS »Verdict : ✅ Généralement autorisé, avec nuances
Si Vault est un composant de votre architecture :
- ✅ Backend de secrets pour votre application SaaS
- ✅ Chiffrement Transit dans votre pipeline
- ✅ PKI pour vos certificats internes
Si Vault devient le produit que vous vendez :
- ❌ "Vault-as-a-Service" pour vos clients
- ❌ "Enterprise Secrets Manager" basé sur Vault
- ⚠️ Contactez HashiCorp pour un accord commercial
MSP / Hébergeur
Section intitulée « MSP / Hébergeur »Verdict : ⚠️ Dépend du modèle
C'est le profil le plus exposé, parce que l'activité d'un prestataire d'hébergement ressemble par nature à un service managé. Tout se joue sur la question de savoir si le client dispose ou non d'un accès à Vault.
| Modèle | Autorisé ? |
|---|---|
| Vault pour votre propre infra d'hébergement | ✅ |
| Cluster Vault par client (dédié) | ⚠️ Zone grise |
| "Vault managé" multi-tenant | ❌ |
Si vous êtes MSP et souhaitez proposer Vault à vos clients, clarifiez avec HashiCorp ou considérez OpenBao.
Comparaison avec les alternatives
Section intitulée « Comparaison avec les alternatives »Si votre modèle bute sur la restriction, ou si votre politique interne exige une licence reconnue par l'OSI, deux solutions comparables existent. OpenBao est le fork de Vault sous MPL 2.0, ce qui garantit une compatibilité forte au moment de la bascule. Infisical est un produit distinct, à évaluer sur ses fonctionnalités et non comme un remplacement direct.
Une nuance à ne pas manquer sur Infisical : on le présente souvent comme « MIT », ce qui est vrai pour le cœur seulement. Son fichier de licence réserve tout le code situé sous un répertoire ee/ à une licence entreprise distincte, et ces répertoires existent bel et bien dans le dépôt. GitHub ne classe d'ailleurs pas le projet en MIT mais en licence « autre ». C'est un modèle open-core : si la fonctionnalité qui motive votre choix vit dans ee/, la licence MIT ne vous couvre pas. Vérifiez fonctionnalité par fonctionnalité.
| Licence | Vault BSL | OpenBao MPL 2.0 | Infisical (open-core) |
|---|---|---|---|
| Usage interne | ✅ | ✅ | ✅ |
| Consulting | ✅ | ✅ | ✅ |
| SaaS (composant) | ✅ | ✅ | ✅ |
| Service managé | ❌ | ✅ | ⚠️ hors modules ee/ |
| Modification/fork | ✅ | ✅ | ⚠️ hors modules ee/ |
| Reconnaissance OSI | ❌ | ✅ | ⚠️ cœur MIT uniquement |
Questions fréquentes
Section intitulée « Questions fréquentes »Ces cinq questions reviennent systématiquement, et quatre d'entre elles reposent sur le même malentendu : croire que le simple fait d'avoir des clients ou de gagner de l'argent déclenche la restriction. Les réponses ci-dessous ramènent chaque fois au véritable critère.
vendez Vault lui-même comme service.
uniquement des licences OSI, vous devez utiliser OpenBao (MPL 2.0) ou une
autre solution.
en production. Si vous redistribuez vos modifications, vous devez les publier
sous BSL (ou attendre la conversion MPL 2.0).
Vous pouvez les licencier comme vous le souhaitez.
De plus, le fork OpenBao existe comme alternative pérenne.
Que faire si vous avez un doute ?
Section intitulée « Que faire si vous avez un doute ? »Un doute sur une licence se règle par écrit, pas par interprétation d'un article de blog. La démarche tient en quatre étapes, dont la première est de loin la plus utile : décrire précisément votre architecture avant de poser la question. Une demande formulée en termes de flux d'accès obtient une réponse nette, une demande formulée en termes de modèle économique obtient une réponse vague.
Étapes recommandées
Section intitulée « Étapes recommandées »Suivez-les dans l'ordre. La quatrième n'est pas un aveu d'échec : basculer sur OpenBao est parfois plus rapide que d'obtenir un accord écrit.
- Décrivez votre usage clairement (qui accède à Vault, comment)
- Consultez la licence complète : HashiCorp BSL FAQ
- Contactez HashiCorp si nécessaire (sales@hashicorp.com)
- Considérez OpenBao si la licence BSL pose problème
Quand contacter HashiCorp
Section intitulée « Quand contacter HashiCorp »Ces quatre situations partagent un point commun : un tiers obtient un accès direct à Vault, ou une contrepartie financière porte sur Vault lui-même. Dans tous les autres cas, la lecture de la licence suffit.
- Votre modèle implique d'exposer les API Vault à des tiers
- Vous envisagez un service managé
- Vous voulez revendre du support
- Votre service juridique demande une clarification écrite
Implications pour votre stratégie
Section intitulée « Implications pour votre stratégie »La BSL est une licence à horloge intégrée : chaque version publiée porte sa propre date de bascule vers MPL 2.0. Une décision d'architecture prise aujourd'hui ne se juge donc pas sur l'état actuel de la licence, mais sur celui qu'elle aura quand la version que vous déployez arrivera en fin de période. Les trois horizons ci-dessous servent à cadrer cette réflexion, pas à prédire le marché.
Court terme (1-2 ans)
Section intitulée « Court terme (1-2 ans) »Rien à changer si votre usage est standard. L'effort utile est documentaire : consigner votre analyse pour la ressortir en audit.
- La licence BSL n'est pas un frein pour la majorité des usages
- Continuez à utiliser Vault CE si votre usage est standard
- Documentez votre analyse de licence (pour les audits)
Moyen terme (2-4 ans)
Section intitulée « Moyen terme (2-4 ans) »C'est la période où les premières conversions vers MPL 2.0 prennent effet et où la maturité d'OpenBao devient mesurable. Le bon réflexe est de surveiller, pas de migrer par anticipation.
- OpenBao mature et peut devenir une alternative viable
- Vault 1.15 devient MPL 2.0 en 2027
- Surveillez l'évolution de HashiCorp/IBM
Long terme (5+ ans)
Section intitulée « Long terme (5+ ans) »À cet horizon, tout le code publié aujourd'hui sera passé sous MPL 2.0. Les projections ci-dessous restent des hypothèses et ne doivent pas fonder un engagement contractuel.
- L'écosystème se stabilisera (Vault BSL + OpenBao MPL)
- Les versions converties seront 100% open source
- Les outils alternatifs (Infisical, etc.) gagnent en maturité
À retenir
Section intitulée « À retenir »- Usage interne = OK : aucune restriction pour votre entreprise
- Consulting = OK : déployer chez vos clients est autorisé
- SaaS (backend) = OK : Vault comme composant de votre stack
- Service managé = Non : offrir Vault-as-a-Service est interdit
- Open source OSI = Non : la BSL n'est pas reconnue par l'OSI
- Conversion automatique : tout code devient MPL 2.0 après 4 ans