アプリストアのBitwardenが変わる — コードは同じなのに、なぜ信頼が揺らぐのか

今回の変更は配信経路の整理なのか、それともオープンソースからオープンコアへ移る第一歩なのか?

導入

2026年10月9日、Bitwardenのコミュニティフォーラムに「Published version update in app stores」という短い告知が投稿された。投稿者はRyanLである。要点は一文に尽きる。次のリリースから、各ストアで配信されるBitwardenアプリは商用ライセンスビルドになる。告知はすぐに安心させる言葉を続ける。ユーザー側の対応は不要で、アプリは今とまったく同じように動作する。GPLv3ビルドは引き続きGitHubで更新・公開され、現在のすべての機能は両方のバージョンで利用でき、無料プランも維持される。

翌10月10日、この告知は「Bitwarden Dual License Model」というタイトルでHacker Newsに投稿され、408ポイントを集めた。反応は穏やかではなかった。Elasticsearch、Terraform、Redisの名前が次々と挙がり、「enshittification」という言葉が何度も登場し、Vaultwardenに移るという人とApple Passwordsに移るという人が同じスレッドに混在した。

興味深いのは、告知の内容と反応の温度差である。告知だけを読めば、変わるものはほとんどない。同じコード、同じ機能、同じアプリだ。しかしパスワードマネージャーという製品では、ユーザーは機能より先に「この会社をいつまで信頼できるか」を読む。本稿ではまず告知とGitHubのライセンス文書をもとに、実際に何が変わるのかを整理し、そのうえでなぜこの小さな変更が大きな不信を招いたのかを検討する。

何が変わり、何が変わらないのか

まず事実関係である。Bitwardenにはもともと二つのライセンスが存在していた。クライアントリポジトリ(bitwarden/clients)のLICENSE.txtは、ソースコードがGPL v3.0またはBitwarden License v1.0のいずれかでカバーされると記している。デフォルトはGPL v3.0で、Bitwarden Licenseのコードは/bitwarden_licenseディレクトリの中にのみ置かれる。サーバーリポジトリのLICENSE_FAQ.mdも同じ構造を説明している。個人向けVaultの中核コード(デスクトップ、Web、ブラウザ、モバイル、CLI)はGPL 3.0、メインサーバーはAGPL 3.0であり、大規模組織向けに設計された一部のモジュールとSSO連携は「ソース公開(source available)」型の商用ライセンスであるBitwarden Licenseに従う。

つまり「デュアルライセンス」というHNのタイトルは、新しい制度を指しているわけではない。実際、あるHNユーザーは、リンク先のページのどこにも「Dual License」という言葉はなく、この変更を正確に表す表現でもないと指摘している(@josephcsible、直接の引用ではなく、コメントの要旨の要約)。

では何が新しいのか。告知に後から追記された説明によれば、Bitwardenは新しいリリースをビルドするたびに、すでに二つのバージョンを作ってGitHubに公開してきた。商用版とGPLv3版である。これまでアプリストアにはGPLv3版を配信していた。その結果、商用機能を必要とするプランの顧客はGitHubに行って商用版を入手しなければならなかったが、会社側の言葉を借りれば、企業や政府の職員にそれを期待することはできない。そこでストアに商用ビルドを置き、誰もが同じ場所から、自分が料金を払った(あるいは払っていない)機能を受け取れるようにする、という説明である。フォーラムの質疑では、Bitwardenダウンロードページの直接ダウンロードも商用ライセンスビルドに切り替わることが確認された。

会社が「変わらない」と明言した点も整理しておこう。ストア版クライアントはGitHub上の100%公開・監査可能なコードから直接ビルドされる。非公開化されたコードはない。商用ライセンスのコードでさえフォークできる。セルフホスティングに変更はなく、今回のライセンス変更はBitwardenを再販する側に影響する。無料プランは恒久的に維持される。そしてGPLv3ライセンスのみを使いたいユーザーは、アプリを自分でダウンロードしてサイドロードすればよいが、その場合は商用ライセンスで提供される有料機能は使えない。

ここまでが告知の表層である。しかしフォーラムの最初の質問ですでに亀裂が見えていた。grbというユーザーが二つのバージョンの間にどんな違いが生じるのかを尋ねると、RyanLは、一部の将来のコンポーネントは商用ライセンスで公開され、そのビルドにのみ存在すること、新たに開発される機能にどちらのライセンスを適用するかはケースバイケースで評価することを答えた。grbはすぐに、「現在のすべての機能」という文の「現在」という語がかなりの重荷を背負っていると返した。会社の追記も同じ方向を向いている。新しいエンタープライズ機能、新しい製品、新市場で戦略的な競争優位をもたらす項目は商用ライセンスの側に置かれる。大半はビジネスプランにのみ該当するが、プレミアムプランの一部機能もケースバイケースの検討によって商用ライセンスになりうる。背景の例としては、FedRAMP関連の発表とPrivileged Controlsの発表が挙げられた。

まとめるとこうなる。今日のコードと機能はそのままである。変わるのはデフォルトの配信チャネルのライセンスと、今後生まれる機能をどちら側に置くかを会社がケースバイケースで決めるという原則である。

「ソース公開」という言葉の範囲と信頼の条件

ライセンス本文が語ること

告知には「Bitwardenは今もオープンソースである」「商用ライセンスのコードもフォークできる」という文がある。これが正確に何を意味するのかは、Bitwarden Licenseの本文を読まなければわからない。クライアントリポジトリのLICENSE_BITWARDEN.txt(2020年9月4日付のバージョン1)を見ると、第2.1条は商用モジュールについて、もっぱら内部開発と内部テストの目的で、かつ非本番環境においてのみ使用できる、限定的・非独占的なライセンスを付与している。第2.3条は、販売、貸与、配布、再ライセンスなど第三者への移転と、商用モジュールを使って競合する製品やサービスを作ることを禁じている。

サーバーリポジトリのFAQはこの点を隠していない。Bitwarden LicenseはOSIの定義上オープンソースライセンスには該当せず、本番環境で使うには有料サブスクリプションが必要だと記している。そしてこの方式がElasticやConfluentといった企業のライセンス手法をモデルにしたものだと自ら明かしている。HNで真っ先にElasticsearchとRedisが引き合いに出されたのは偶然ではない。会社自身がその系譜を参照しているのである。

したがって「フォークできる」という言葉は、技術的には真だが法的には狭い。商用コードを複製して読み、社内で試すことはできる。しかしそれを本番環境で使ったり、他者に配布したりすることは、このライセンスでは許されない。公開監査の可能性は保たれるが、フリーソフトウェアの意味での「改変して使い、共有する自由」は、商用領域では失われる。

この境界が話題になったのは今回が初めてではない。2024年10月、bitwarden/clientsリポジトリに「Desktop version 2024.10.0 is no longer free software」というIssue(#11611)が立てられた。報告者は、デスクトップクライアントのビルドに必要な@bitwarden/sdk-internal依存関係のライセンスに、Bitwarden以外のソフトウェア(互換性のないBitwarden実装を含む)と共に使うアプリケーションの開発にこのSDKを使ってはならない、という条項があると指摘した。Bitwardenの創業者Kyle Spearrin(kspearrin)は、当初はSDKとクライアントは別個のプログラムであると説明し、ビルドできない問題は単なるバグだと答えた。数日後には、SDKのコードを再編成し、クライアントが参照するsdk-internalパッケージを新しいリポジトリに移してGPLライセンスのみを使うようにしたと説明した。そして一文を残した。将来その参照にBitwarden Licenseのコードが含まれるようになった場合は、Web Vaultのビルドで行っているのと同様に、クライアントの複数のビルドバリアントを作る方法を提供する、というものである。

2026年10月の告知は、その一文が2年を経て実行された姿として読むことができる。ビルドバリアントはすでに存在しており、今回はそのどちらがデフォルトの配信チャネルに載るかが変わった。この結びつけは告知自体が明示したものではなく、筆者の解釈である。

Vaultwardenとセルフホスティングのユーザー

今回の議論で最も具体的な不安は、セルフホスティングの側から出てきた。VaultwardenはBitwardenのサーバーAPIをRustで再実装したコミュニティサーバーで、公式のBitwardenクライアントをそのまま接続して使える。セルフホスティングユーザーの多くは、サーバーだけがVaultwardenで、クライアントは公式アプリである。

HNにはこの構造を的確に突いたコメントがあった。約15人規模のチームで何年もVaultwardenを運用してきたというユーザーは、注視すべきはサーバーではなくクライアントであり、クライアントこそがレバレッジだと書いた。モバイルアプリがソースからビルドできなくなれば、セルフホスティングの話はずっと心許ないものになる、という指摘である(@hn3ufz62f7、直接の引用ではなく、コメントの要旨の要約)。別のユーザーは、Vaultwardenと公式のmacOS・iOSクライアントを数年使ってきたが、iOSアプリの自動アップデートがサーバーとの互換性を壊し、Dockerインスタンスを更新しなければならなかったことがあるとして、長期的にこの組み合わせに留まるのは賢明ではないかもしれないと述べた(@fiatpandas、直接の引用ではなく、コメントの要旨の要約)。

フォーラムでも同じ質問が出た。davidmayrというユーザーは、MinIOの件で一度痛い目を見た経験に触れつつ、Vaultwardenのようなサードパーティのチームが今後もプロトコルを使い続けられるのか、商用のブラウザ拡張がオープンソースのクライアントと互換性を保つのかを尋ねた。Bitwarden側のdwbitは、サードパーティのコミュニティサーバーについては変更がなく、彼らはどの機能をサポートし構築するかを引き続き選べると答えた。セルフホスティングのユーザーが二級市民になるのかというWreckageの質問には、セルフホスティングに変更はなく、再パッケージして再販する側にのみ影響があると答えた。しかしWreckageは、むしろ将来が心配だとして、今後の機能がセルフホスティングユーザーにも提供されるのかを改めて尋ねた。セルフホスティングできることは、何かあったときの脱出戦略だというのである。筆者が確認した時点のスレッドでは、この質問への回答は見当たらなかった。

ここで二種類のセルフホスティングを区別しておく必要がある。Bitwardenがエンタープライズ顧客に販売しているセルフホスティングは、自社の公式サーバースタックである。これは有料顧客がいる製品なので、簡単には変わらないだろう。一方Vaultwardenは公式にサポートされた経路ではない。ByteHavenというブログの筆者PPB1701は、VaultwardenはBitwardenが容認してきただけで支持したことはない領域にあり、計算が変われば、告知なしにAPIが少しずつずれて互換性が壊れるという形で容認が終わりうると書いている。ただし本人も、それが差し迫っているとは考えていないと付け加えている。これは一人のブロガーの見通しであり、確認された事実ではない。

セキュリティ製品のライセンスは、なぜ機能より先に読まれるのか

ライセンス変更の告知にこれほど反応する理由を、単に「無料を求める人々の不満」と片づける見方もスレッドにはあった。あるユーザーは、enshittificationという言葉は事実上ツールにお金を払いたくないという意味だと批判し、寄付ではBitwardenのような製品の開発資本はまかなえないと主張した(@rvz、直接の引用ではなく、コメントの要旨の要約)。別のユーザーは、完全なオープンソースのほうが望ましいとしつつも、「全ソース公開、商用利用に一部制限」でもはるかにましであり、大企業がコードを持ち去り流通力で圧倒する問題への現実的な解決策はライセンス変更くらいしかないように見える、と理解を示した(@dannyw、直接の引用ではなく、コメントの要旨の要約)。

こうした反論には一理ある。しかしパスワードマネージャーにおけるライセンスの意味は、データベースや検索エンジンとは異なる。理由は三つある。

第一に、監査可能性と検証可能性は別物である。会社はストア版ビルドが100%公開されたコードからビルドされると言う。しかしあるHNユーザーは、オープンソースのチャネルが維持されたとしても、もはやビルドを検証できなくなるだろうと懸念した(@bigbaguette、直接の引用ではなく、コメントの要旨の要約)。この懸念が技術的に正しいかどうかは、今回の資料だけでは判断できない。商用ビルドも公開コードから作られるのであれば、原理的には再現可能ビルドで確認できるはずだ。ただ、商用コードを本番環境で使う権利を持たない第三者が、その検証をどれほど積極的に行うかは別の問題である。コードは見えるが、そのコードを手に何かをする動機は減る。

第二に、パスワードマネージャーの中核的な価値は離脱可能性である。フォーラムのzfJamesは、いつでもセルフホスティングを選べることが自分の要件であり、それがパスワードを抜け出せない箱に閉じ込められないための安全装置だと書いた。別のユーザーNail1684は、Vaultのエクスポートがなくなる兆候はなく、むしろ最近モバイルアプリにCredential Exchange Protocol/Format(CXP/CXF)が追加されたと反論した。離脱経路がデータ形式のレベルで保証されているなら、ライセンスの重要性は下がる。本当の争点は、その経路がどれだけ長く維持されるかである。

第三に、信頼は個別の出来事ではなくパターンで判断される。ByteHavenのブログは、今回の告知以前からBitwardenに起きた変化を列挙してきた。2026年3月のプレミアム価格の引き上げ、2月のCEO交代(Fast Companyの報道を引用)、4月中旬に個人向けページから「Always free」の文言が消えたこと、5月の社内バリューGRITの再定義などである。これらはそのブロガーがまとめた内容であり、筆者が一つひとつ一次情報で確認したものではない。ただ、HNでこの記事がトップレベルのコメントとして改めて紹介されたこと(@rsyring)は、ユーザーが今回の告知を単独で読んでいないことを示している。ライセンスの告知はそれ自体は小さくても、すでに積み上がった疑念の上に置かれると「最後のパズルのピース」として読まれる。

展望と示唆

今後注目すべき指標は比較的はっきりしている。第一に、GPLv3ビルドに新機能が実際にどれだけ入るか。会社はケースバイケースで評価するとしたが、HNのあるユーザーは、その言葉はオープンコア開発の伝統どおり「新機能はOSS版には入らない」という意味だと解釈した(@PunchyHamster、直接の引用ではなく、コメントの要旨の要約)。どちらが正しいかは、今後数回のリリースノートが答えるだろう。商用限定の機能がエンタープライズ管理、政府対応、権限統制といった組織向け領域に留まるなら、個人ユーザーが体感する変化はほとんどないはずだ。逆にプレミアムの個人向け機能が商用側に移り始めれば、今の不安は現実になる。

第二に、サードパーティクライアントの成長である。HNには、AndroidでKeyguardとVaultwardenの組み合わせに移ったというユーザー(@0l)がいたし、Bitwardenの公式クライアントは常に「その潜在力を想像できる程度には良いが、そこには届かない」状態だったので、コミュニティが代替クライアントを作るきっかけが必要だったという意見(@lucideer)もあった(いずれも直接の引用ではなく、コメントの要旨の要約)。サーバーを再実装したVaultwardenがすでにある以上、クライアントまで独立すれば公式エコシステムへの依存度は大きく下がる。ただし、セキュリティソフトウェアのクライアントを誰が長期にわたって保守し監査するのかは、また別の信頼の問題を生む。

第三に、AI時代のライセンスの実効性という論点もスレッドに現れた。商用機能を作っても、誰かがすぐにLLMでその機能をオープンソース側に再現するだろうという主張である(@charcircuit、@rvz、直接の引用ではなく、コメントの要旨の要約)。興味深い視点だが、パスワードマネージャーにおいて「素早く再現された機能」が信頼を得るには、コードを書くよりはるかに長い時間がかかる。再現コストが下がっても、検証コストは同じだけは下がらない。

組織の視点で整理すると、今すぐやるべきことは多くない。公式ストアのアプリを使う個人ユーザーにとって、告知時点での変化は事実上ない。ただしセルフホスティングを脱出戦略にしているなら、その戦略が公式クライアントとの互換性にどれだけ依存しているかを一度点検しておく価値はある。そしてエクスポート形式(CXFを含む)で実際にVaultを取り出し、別のツールに入れてみるリハーサルは、どんなライセンス告知よりも具体的な安心を与えてくれる。

結論

今回のBitwardenの告知を文字どおりに読めば、すでに存在していた二つのビルドのうちどちらをアプリストアに載せるかを変えた、配信ポリシーの変更である。コードは引き続き公開され、現在の機能は両方にあり、セルフホスティングにも変更はないと会社は繰り返し述べている。その説明はGitHubのライセンス文書ともおおむね整合している。

しかし告知の重みは「現在」という語にかかっている。将来の機能がどちら側に置かれるかはケースバイケースで決まり、その決定権は会社にある。そしてその決定の行き先である商用ライセンスはOSI基準のオープンソースではなく、本番環境での使用と再配布を認めない。2024年のSDK論争で予告されたビルドバリアントが、いまやデフォルトのチャネルになった。

パスワードマネージャーを選ぶとき、人々は機能一覧より先に離脱経路を見る。今回の変更が離脱経路を直接塞ぐわけではない。ただ、その経路が会社の善意にどれほど依存しているかを、改めて可視化した。あなたのVaultを明日別のツールに移さなければならないとしたら、その手順はいま何段階あり、そのうち何段階がBitwardenの決定にかかっているだろうか。

出典: