Bitwarden bascule ses apps des stores vers une licence commerciale, le GPLv3 reste sur GitHub
Le 9 octobre 2026, Bitwarden annonce que ses applications publiées sur les stores passeront à la version sous licence commerciale, la version GPLv3 restant publiée sur GitHub. Pour les auto-hébergeurs, rien ne change aujourd’hui — mais le mot « actuelles » dans « toutes les fonctionnalités actuelles » mérite une relecture attentive.
9 octobre 2026. RyanL, membre de l’équipe Bitwarden, annonce sur le forum communautaire que les applications publiées sur les stores passeront, à la prochaine release, aux builds sous licence commerciale. GPLv3. La version open source, elle, « continue d’être mise à jour et publiée sur GitHub ». Zéro action requise. Les apps « fonctionneront exactement comme aujourd’hui ». Pourquoi c’est important : Bitwarden ne ferme rien, mais il dessine une frontière nouvelle entre deux versions du même code — et pour les auto-hébergeurs, c’est une frontière à surveiller de près.
Ce qui change concrètement, et ce qui ne change pas
Jusqu’à présent, les stores (App Store, Play Store, extensions de navigateur) distribuaient la version GPLv3 de Bitwarden. Désormais, à la compilation d’une nouvelle release, Bitwarden produit deux versions et les publie toutes deux sur GitHub : une commerciale et une GPLv3. Ce sont les builds commerciaux qui iront sur les stores et sur la page de téléchargement direct.
Le point à retenir pour l’utilisateur lambda est rassurant : rien ne change dans le code visible. L’annonce insiste — et une note d’édition le répète — que les clients des stores sont « construits directement à partir d’un code 100 % publiquement auditable sur GitHub », que « rien n’a été rendu closed source », et que le code reste « lisible, auditable et contribuable ». La nuance tient en une phrase : la licence qui s’applique à ce code change, pas le code lui-même.
La raison invoquée est logistique. Bitwarden avait déjà une licence commerciale depuis un moment, concentrée sur les fonctionnalités d’entreprise — l’annonce cite les programmes FedRAMP et Privileged Controls. Jusqu’ici, un client d’entreprise qui voulait ces fonctionnalités devait aller chercher la version commerciale sur GitHub. Publier le build commercial sur les stores permet à chacun d’obtenir « les fonctionnalités qu’il paie (ou ne paie pas) » depuis le même endroit.
Précisons un point que l’annonce laisse implicite : Bitwarden maintient aussi un serveur auto-hébergé officiel, souvent déployé sous le nom Bitwarden Unified, distinct de Vaultwarden. La bascule annoncée ne modifie ni l’un ni l’autre — elle ne porte que sur les clients. C’est une bonne nouvelle pour l’auto-hébergeur, mais elle ne dit rien des choix futurs de licence du serveur, qu’il faudra surveiller séparément.
« Toutes les fonctionnalités actuelles » : le diable est dans l’adjectif
C’est la phrase qui a fait réagir la communauté, et Ethan Sholly de selfh.st en tête : « toutes les fonctionnalités actuelles sont disponibles dans les deux versions ». Le mot « actuelles » fait tout le travail. Interrogé sur les différences futures, RyanL précise : « certains composants futurs seront publiés sous la licence commerciale et n’existeront que dans ce build », et « les fonctionnalités nouvellement développées seront évaluées au cas par cas ».
Autrement dit, les deux builds sont identiques aujourd’hui, mais ils vont diverger. La question de fond, posée par un membre de la communauté, reste ouverte : ces futures fonctionnalités exclues du build GPLv3 seront-elles encore open source ? Sur ce point, l’annonce n’apporte pas de réponse ferme. C’est le mécanisme classique de l’open core : un cœur libre et une périphérie commerciale qui, elle, se restreint progressivement.
Ce qui ne change pas, en revanche, est affirmé sans ambiguïté : l’auto-hébergement n’est pas touché, le code peut toujours être forké (y compris le code sous licence commerciale), et le plan gratuit « est là pour rester définitivement ». La bascule de licence ne concerne que ceux qui revendent Bitwarden.
Vaultwarden et la question de l’auto-hébergement
Pour l’auto-hébergeur, le point crucial est de comprendre ce qui est touché — et ce qui ne l’est pas. La bascule de licence concerne les clients que Bitwarden distribue sur les stores : l’extension de navigateur, les applications mobiles et le bureau. Le serveur auto-hébergé n’est pas concerné par cette annonce, et les utilisateurs de Vaultwarden, la réimplémentation compatible très populaire, ne verront rien changer dans le fonctionnement de leur coffre.
Reste que le signal est réel. Bitwarden pratiquait déjà la double licence pour le serveur — une licence Bitwarden commerciale aux côtés du GPLv3 — mais les clients étaient restés intégralement GPLv3 jusqu’à présent. Étendre le mécanisme aux applications des stores, c’est déplacer la frontière de l’open core un cran plus loin, vers la périphérie que l’utilisateur touche tous les jours.
Le précédent n’est pas anodin. L’écosystème a déjà vu Redis adopter une licence restrictive, Elasticsearch basculer vers le SSPL, et Terraform passer au BSL avant la naissance d’OpenTofu. À chaque fois, le cœur est resté lisible, et la communauté a réagi en mesurant ce qui restait réellement libre. Bitwarden prend soin, cette fois, de préciser noir sur blanc que « rien n’a été rendu closed source » — mais c’est la trajectoire, plus que l’instant, qui compte.
Pour l’auto-hébergeur vigilant, trois signaux sont à surveiller. D’abord, les release notes GitHub : la première fonctionnalité qui apparaîtra uniquement dans le build commercial marquera le début réel de la divergence. Ensuite, la réponse à la question restée ouverte — ces fonctionnalités futures seront-elles encore lisibles dans le code source ? Enfin, le sort du build GPLv3 lui-même : tant qu’il est publié à chaque release, la promesse « tout reste open source » tient ; le jour où son rythme ralentit, il faudra reconsidérer. Aucun de ces signaux n’est rouge aujourd’hui. Mais une licence est un contrat d’intention, et c’est en la lisant de près qu’on anticipe.
Deux builds, deux usages
| Build GPLv3 (GitHub) | Build commercial (stores) | |
|---|---|---|
| Distribution | Releases GitHub, à charger manuellement | Stores et page de téléchargement |
| Code source | Public et auditable | Public et auditable (même dépôt) |
| Fonctionnalités actuelles | Toutes | Toutes |
| Fonctionnalités futures | Selon licence, au cas par cas | Toutes, y compris commerciales |
| Public visé | Puristes open source | Utilisateur standard et entreprise |
La conséquence pratique pour un utilisateur GPLv3 strict : il devra charger manuellement l’application depuis GitHub à chaque mise à jour, et renoncera aux fonctionnalités payantes placées sous licence commerciale. Pour tous les autres, la bascule est transparente.
Verdict
La recommandation est simple à formuler, mais elle diffère selon votre profil. Si vous installez Bitwarden depuis les stores, vous n’avez strictement rien à faire : le build change de licence, pas de comportement, et votre coffre fonctionne à l’identique. Si vous êtes un puriste de la GPLv3, préparez-vous dès maintenant à charger les releases GitHub manuellement, et acceptez que les futures fonctionnalités payantes vous échappent. Si vous auto-hébergez un serveur compatible comme Vaultwarden, surveillez le rythme de divergence entre les deux builds : rien ne casse aujourd’hui, mais c’est un signal de plus — après Dockhand et sa fenêtre glissante BSL — que la frontière entre le cœur libre et la périphérie commerciale se déplace, projet après projet. La seule chose à ne pas faire est de croire qu’une licence est une formalité sans conséquence : c’est elle qui décide, à terme, de ce que vous pourrez encore auto-héberger.