Le 10 août 2023, HashiCorp a fait passer tout son portfolio de la MPL 2.0 à la Business Source License 1.1. Terraform, Vault, Nomad, Consul : du jour au lendemain, le code source restait visible mais l'usage devenait contraint. La BSL interdit d'offrir un produit concurrent à partir du code. Terraform a accouché d'OpenTofu en quelques semaines. Vault, lui, a donné OpenBao. Si vous opérez un coffre de secrets en production, la question n'est plus théorique : la prochaine version majeure de Vault que vous installerez ne portera plus la licence ouverte sous laquelle vous avez adopté l'outil.
La bascule BSL, et pourquoi ça compte
La Business Source License n'est pas open source. L'OSI ne la reconnaît pas. Elle autorise la lecture du code et l'usage interne, mais elle pose une clause de non-concurrence : vous ne pouvez pas bâtir un produit qui rivalise avec l'offre commerciale de l'éditeur. Le texte prévoit une bascule automatique vers une licence ouverte au bout de quatre ans, version par version, mais cette fenêtre glissante ne règle rien pour qui veut une base saine maintenant.
Le motif affiché par HashiCorp tenait en une phrase : les fournisseurs cloud revendaient Vault en service managé sans contribuer. Le même grief que Redis a invoqué pour justifier son propre changement de licence, traité dans notre comparatif Valkey contre Redis. La réponse de la communauté a été identique aussi : un fork, vite. Le manifeste OpenTF a dépassé les 33 000 étoiles en quelques semaines, plus de 100 entreprises se sont engagées. Pour Vault, le sillage a suivi.
Puis IBM a racheté HashiCorp. Annonce le 24 avril 2024, 6,4 milliards de dollars de valeur d'entreprise, vote des actionnaires le 15 juillet 2024, clôture début 2025. Un éditeur indépendant qui change de licence, c'est déjà un signal. Le même éditeur absorbé par un géant du logiciel propriétaire, c'est un second signal dans la même direction. Rien n'oblige IBM à durcir Vault, mais rien ne l'en empêche non plus. Sur le terrain, une DSI qui décide d'une dépendance critique ne parie pas sur la bonne volonté future d'un propriétaire.
OpenBao, ce que c'est exactement
OpenBao est un fork de Vault 1.14.0, la dernière version publiée sous MPL 2.0 avant le basculement. La MPL 2.0 est une licence ouverte reconnue par l'OSI, copyleft faible, sans clause de non-concurrence. Vous modifiez, vous redistribuez, vous opérez en service managé, sans rien demander au légal.
La gouvernance suit le modèle qui a fonctionné pour OpenTofu. Le projet a rejoint LF Edge sous l'égide de la Linux Foundation en avril 2024, puis l'OpenSSF (Open Source Security Foundation) comme projet sandbox en juin 2025. Une fondation neutre, pas une entreprise. C'est la différence structurelle qui compte pour qui a été échaudé : une fondation ne se fait pas racheter, et la feuille de route ne dépend pas d'un objectif trimestriel de revenu.
Côté livraison, le projet tient son rythme. La première version GA, la 2.0.0, est sortie le 16 juillet 2024. Les versions mineures se sont enchaînées, jusqu'à la 2.5 début 2026. Fait notable au passage : la dynamique reprend celle d'OpenTofu, communauté et fournisseurs cloud qui poussent le même fork, loin du récit « nous contre eux ». Le code circule.
La compatibilité, en pratique
Parti de Vault 1.14, OpenBao en conserve l'API HTTP, la CLI et le format de stockage. Pour la plupart des usages, c'est un remplacement direct. Les commandes bao répondent comme les commandes vault, les chemins de secrets sont les mêmes, les politiques HCL se chargent à l'identique. Un client applicatif qui parle à l'API Vault parle à OpenBao sans modification de code. Les patterns d'intégration restent ceux décrits dans notre guide Vault pour la gestion des secrets applicatifs.
La divergence commence après le point de fork. OpenBao trace sa propre route : suppression de dépendances non libres héritées, ajout de fonctionnalités propres, nettoyage du code. Vault continue la sienne sous BSL. Les deux restent largement interopérables sur le cœur, mais l'écart se creusera, exactement comme entre Valkey et Redis. Le piège classique : tabler sur une compatibilité éternelle. Si vous dépendez d'un secrets engine ou d'un plugin spécifique de l'écosystème Vault entreprise, vérifiez sa présence côté OpenBao avant de bouger. Pour un usage KV, PKI, base de données dynamique ou transit, la bascule est triviale.
Migrer un coffre de secrets, ce n'est pas migrer un cache. Le coffre porte les clés du royaume : credentials de bases, certificats, tokens d'API. La règle qu'on applique : on monte une instance OpenBao de prérecette, on restaure une copie du backend de stockage, on rejoue les politiques, on teste l'unseal et la rotation, on valide chaque client applicatif, puis seulement on bascule. La logique d'un cluster Vault en haute disponibilité ne change pas : Raft reste Raft, le quorum reste le quorum, on remplace les nœuds un par un. Le séquençage initial, lui, suit les principes d'un déploiement Vault propre : auto-unseal configuré, audit device actif, politiques au moindre privilège.
Rester sur Vault ou passer à OpenBao
Pour un déploiement neuf, OpenBao d'abord. Licence MPL 2.0 ouverte, gouvernance de fondation, compatibilité API totale avec ce que vous connaissez de Vault, et aucune question à poser au juridique. Le sens du courant est le même que pour Terraform et Redis : quand une fondation reprend un projet abandonné par son éditeur, l'inertie de l'écosystème finit par jouer pour le fork.
Pour un Vault OSS existant qui tourne bien en 1.14 ou 1.15, pas de précipitation. Le binaire ne va pas s'arrêter de fonctionner, et une migration de coffre bâclée fait plus de dégâts qu'un risque de licence théorique. On planifie : inventaire des secrets engines et des plugins, test de restauration sur prérecette, validation des clients, puis bascule sur fenêtre de maintenance. Ce qu'on surveille en continu, c'est la divergence fonctionnelle entre les deux projets, parce que c'est elle qui fixera la date butoir réelle, pas la licence.
Le seul cas où l'on reste sur Vault entreprise : une dépendance réelle à une fonctionnalité commerciale (réplication multi-datacenter Performance, HSM intégré, namespaces) que le contrat IBM couvre déjà. Sinon, le vrai risque n'a jamais été technique. Il est contractuel, et il a déjà fait basculer un projet.
Migrer un coffre de secrets critique sans coupure, ça se cadre comme tout changement de moteur en production : inventaire, test de restauration, bascule nœud par nœud, rollback documenté. Si votre Vault porte les credentials de toute votre infra et que la bascule vous inquiète, c'est précisément le genre d'opération qu'on cadre et exécute en infogérance sans interruption de service. Pour la mécanique de chiffrement des secrets au repos en amont du coffre, voir aussi notre guide SOPS pour chiffrer les secrets dans Git.
Sources
- OpenBao, site officiel : la documentation du projet, la licence MPL 2.0 et la feuille de route.
- Meet OpenBao, an Open Source Fork of HashiCorp Vault, The New Stack : genèse du fork et point de gouvernance.
- OpenTofu Announces Fork of Terraform : l'annonce du fork jumeau, même dynamique de licence.
- How HashiCorp's license shakeup seeded an open source rebel, The Register : chronologie de la bascule BSL d'août 2023 et de la réaction communautaire.
- IBM to Acquire HashiCorp, communiqué SEC Form 8-K : les chiffres officiels du rachat (6,4 milliards, avril 2024).
