Bitwarden、フリーソフトウェアを終了
(github.com/bitwarden)- Bitwarden Desktop 2024.10.0 のビルドで @bitwarden/sdk-internal 依存が必要になり、その SDK のライセンス条項が「Bitwarden 以外のソフトウェア向けアプリや、他の SDK の開発には使用できない」と制限しているため、自由ソフトウェアの要件を満たさなくなったという問題提起がなされた
- 問題提起者は、この制限が GNU の freedom 0 に違反すると主張し、この依存を削除すると desktop-v2024.10.0 と現在の master をビルドできないと述べた
- 再現例として、
bitwarden_licenseディレクトリを削除し、node_modulesを整理した状態でビルドすると、TS2307 エラー 6 件により@bitwarden/sdk-internalと WASM モジュールを見つけられず、build:preloadが失敗する - 一部のコメントでは、この SDK が Desktop だけでなく browser, CLI, web clients でも機能フラグとして使われていると指摘され、Bitwarden 側は SDK とクライアントは別個のプログラムであり、GPLv3 の観点では標準プロトコル通信だけで単一のプログラムにはならないと回答した
- Bitwarden はその後、SDK コードの構成とパッケージングを調整し、GPL/OSI ライセンスのみを含むビルド を可能にしたうえで、クライアントの
sdk-internal参照を新しいsdk-internalリポジトリへ移し、この issue を完了扱いにした
提起された問題: Desktop 2024.10.0 ビルドと SDK ライセンス
- この issue は、Bitwarden Desktop 2024.10.0 がもはや自由ソフトウェアではないという問題提起として立てられた
- 核心となる変更は、Pull request #10974 がデスクトップクライアントのビルドに @bitwarden/sdk-internal 依存を導入したことにある
- この依存のライセンスには次の制限が含まれている
- 「この SDK は、Bitwarden 以外のソフトウェア、Bitwarden と互換性のない実装を含むソフトウェア向けアプリケーションの開発には使用できず、他の SDK の開発にも使用できない」
- 問題提起者は、この条項が GNU の自由ソフトウェア定義における freedom 0 に違反するとみなしている
- また、この依存を除去しない限り desktop-v2024.10.0、そしておそらく現在の master もビルドできないと述べている
再現されたビルド失敗
- 問題提起者は、従来どおり
bitwarden_licenseディレクトリを削除し、整理済みのnode_modulesでビルドを試みた - ビルドは
apps/desktopのbuild:preload段階で失敗した - エラーは、複数ファイルで @bitwarden/sdk-internal モジュールまたは型宣言を見つけられないという
TS2307であるlibs/common/src/platform/abstractions/sdk/sdk.service.tslibs/common/src/platform/abstractions/sdk/sdk-client-factory.tslibs/common/src/platform/services/sdk/default-sdk.service.tslibs/common/src/platform/services/sdk/default-sdk-client-factory.tslibs/common/src/platform/services/sdk/noop-sdk-client-factory.ts
- WASM パスである
@bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasmも見つからないというエラーが発生する - 結果として
webpack 5.94.0は 6 件のエラーでコンパイルに失敗し、npm run build:preloadはコード 1 で終了した
コミュニティの反応と広がる懸念
- あるコメントでは関連 issue として bitwarden/sdk-sm#898 に言及し、Bitwarden がオープンソースをうたいながらプロプライエタリソフトウェアへ移行しているのではないかという懸念が示された
- 別のユーザーは、CLI クライアントの NPM リリースでも同様の問題を 2 か月前に #10648 として報告したが、返答がなかったと述べた
- 一部のユーザーは代替案として、旧バージョンのフォーク、Vaultwarden、Vaultwarden の Web インターフェースを包む Tauri デスクトップアプリなどに言及した
- あるコメントでは、パスワードを扱う製品という性質上「どんな代替でもよい」と移行するのは慎重であるべきで、クライアントのフォークだけではサーバーサービスやサーバーソフトウェア依存の問題が残ると指摘した
- 別のコメントでは、この SDK は Desktop リリースだけでなく browser, CLI, web clients でも機能フラグとして使われており、Bitwarden 2024.10.0 の全バージョンが SDK を利用していると主張された
Bitwarden 側の初期回答
- Bitwarden のメンバーは、クライアントにおける SDK の利用範囲を広げてきたが、目標は SDK の利用が GPL 互換性 を維持することだと回答した
- Bitwarden 側は次の 3 つの根拠を示した
- SDK とクライアントは別個のプログラムである
- 各プログラムのコードは別々のリポジトリにある
- 2 つのプログラムが標準プロトコルで通信するという事実だけでは、GPLv3 の目的上、単一のプログラムにはならない
- ユーザーが試した方法でアプリをビルドできない問題は、今後修正予定の バグ だと説明した
- その後、議論は Bitwarden によってロックされ、collaborator 限定となった
最終的な調整と終結
- Bitwarden は、SDK コードの構成とパッケージング方法を調整し、GPL/OSI ライセンスのみを含む状態 でアプリをビルド・実行できるようにしたと述べた
- クライアントの
sdk-internalパッケージ参照は、新しい sdk-internal repository から取得する形に変更された - 新しい
sdk-internalリポジトリは、Bitwarden が既存クライアントで使用してきたライセンスモデルに従うと説明し、関連情報として LICENSE_FAQ.md を提示した - 現在、
sdk-internal参照は GPL ライセンスのみを使用している - 将来この参照に Bitwarden License コードが含まれる場合は、Web Vault クライアントのビルドと同様に、複数のビルドバリアントを作成できる方法を提供すると述べた
- 既存の sdk repository は sdk-secrets に改名され、Secrets Manager のビジネス製品向けに従来の Bitwarden SDK License 構成を維持する
sdk-secretsリポジトリとパッケージはクライアントアプリで使用されないコードであるため、今後はクライアントアプリから参照されない- この issue は 2024 年 10 月 25 日に completed として終了した
2件のコメント
私はKeepassを愛用していますが、みんながあまりにもBitwardenの話ばかりするので一度使ってみようかと思っていました。でも、このままKeepassを使い続けることにします。サーバー方式ではなく、ファイルさえきちんと保管しておけばいい仕組みなので、可用性もずっと高く、私の好みにはKeepassのほうが合っています。
Hacker News の意見
お金を払ったのはオープンソースを支援するという期待があったからで、そのため LastPass から Bitwarden に移った。
今回の件は、背中に刺さったナイフをひねられるような感じだ。CEO の Michael Crandell は、RightScale を売却した時と似た財務上の転換点に達したので、買収に向けて準備しているように見える: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...
もうそうではないようだ。危険な動きだ。オープンソースには良い性質がたくさんあるが、ここで重要なのはセキュリティだ。企業が不透明なバイナリの塊を安全だと主張するのは、いつも驚かされる。Intel Management Engine もそうだし、今や Bitwarden も IME と Juniper スイッチの仲間入りをしたわけだ。
クローズドソースに進むのは高リスクな選択だ。長い間、ソフトウェアそのものにはお金を払ってこなかったが、セキュリティにはお金を払えるし、実際に払っている。Bitwarden は、私が最も大切で私的な情報だと考えるものを保存するので、お金を払っているのだ。しかし結局はソフトウェアにすぎず、「bitwarden」と呼ぶバイト列がどこから来るかは重要ではない。誰でもフォークして同じバイト列を提供できる。オープンソースソフトウェアだけを使う Bitwarden のミラーを運営するなら、私のお金はそちらに行くだろう。実行中のバイナリと、自分が複数のデバイスにダウンロードするバイナリを同一に再現できるビルド手順まであれば、なお良い。私のパスワードは、オープンソースソフトウェアが管理していない限り安全だとは見なさない。
今回の動きはそれほど驚きではない。Bitwarden はこの数年、エンタープライズ営業の方向へ強く移行し、その間に消費者向けは放置していた。
最近になってようやく、以前の MAUI ベースからネイティブ iOS アプリに変わったが、旧アプリはいろいろな面でかなり浮いていた。今の iOS クライアントも、まだ追いつくべき点が残っている。
ベンチャー投資を受けた後は、売上と利益重視にさらに傾いたように見える。その選択自体が間違いというわけではないが、会社が始まり成長してきたやり方とは、かなり違う方向へ押し進めている。
Proton Pass も少し興味深いが、他の Proton サービスと同様、価格モデルはいつもやや高めだ。しばらく無料の Proton Pass を試しており、Bitwarden が何年も待っていた方向に改善されなかったので、代替に移る価値があるか見てみるつもりだ。
iOS 内蔵のパスワードマネージャーも十分悪くないが、パスワード専用で、他の種類のデータの保存・検索・自動入力には対応していない。
製品を使いにくくすれば、顧客と販売機会を失う。最近 Postman としたひどい電話の数々を思い出す。もう一度電話するくらいなら、今では Hoppscotch の方がずっと良さそうに見える。
CTO の回答によると、SDK の利用範囲をより多くのクライアント事例へ広げてきたが、目標は SDK がGPL 互換性を維持する形で使われるようにすることだという。
SDK とクライアントは別々のプログラムであり、各プログラムのコードは別々のリポジトリにあり、2つのプログラムが標準プロトコルで通信するという事実だけで GPLv3 上の1つのプログラムになるわけではない、と見ている。ここで試みた方法でアプリをビルドできるようにすべき問題は、修正予定の単なるバグだという。
CTO に聞きたいのは、おおよそこういうことだ。「あなた方の弁護士は、これを法的に切り抜けられると見ているのか？」には答えたが、人々が懸念している核心的な質問には答えていない。Bitwarden チームは、多くの人が明示的にオープンソースだからこそ支援し貢献してきたプロジェクトを私有化することに、倫理的問題はないと見ているのか？ パスワード管理は本質的に高い信頼を必要とする事業なのに、オープンソースからクローズドソースへ移るラグプルによって生じる信頼の破綻、フォーク、離脱にどう対処するつもりなのか？ 会社がこうした決定を検討するほど切迫した状況なら、コミュニティが一緒に助け、私有化なしで乗り越える方法はないのか？
CTO として今は心配しているふりをするのが仕事で、とくに対話を閉じられないフォーラムではなおさらだというのは分かるが、現在のアプローチは「法的に可能だと信じており、自分たちの行動に問題はないと見ている」という最悪の懸念を、事実上裏づけている。ユーザーがコードと、それを更新する人々を信頼しなければ収益が出ない会社にとって、まさに間違った雰囲気だ。
「オブジェクトコード形式の著作物の『対応するソース』とは、オブジェクトコードを生成、インストール、実行し、著作物を改変するために必要なすべてのソースコードと、それらの活動を制御するスクリプトを含む。」
オープンソース企業として稼ぐのが本当に難しいことは理解している。だから私も有料顧客の一人だ。
SDK に付けた除外条件は、一時期 Linux カーネルに使われていたBitKeeperバージョン管理ソフトウェアと非常によく似て見える。その結末がどうだったかを見ればよい。
好きだったし、お金も払ったし、友人たちにも勧め、彼らも気に入っていた。
これから KeePassXC に移ろうと思う。Android とデータベースを同期するおすすめの方法は何だろう？ cloudflared を動かしている Raspberry Pi サーバーだけはある。
https://github.com/ProtonMail/WebClients/tree/proton-pass%40...
https://github.com/protonpass/android-pass/blob/1.26.1/LICEN...
SyncThingでKeePassの金庫を必要なデバイスにだけ正確に配布して使っている。自分にはとてもよく機能している。必要に応じて違うかもしれない
KeePassとそのエコシステムは本当に使いたいが、パスワード共有があまり良くない。私と妻は共有パスワードが多く、Bitwardenはその部分がとてもよく機能する。私たちにとって実用的な代替案が何なのか分からない
Keepass2Androidはssh(sftp)、Nextcloudなど複数の方法で同期できる。合う方法を見つけられるはず
KeePassXCとAndroid向けNextcloudクライアントの組み合わせは私には完璧。何年も問題なく使っている
GitHub issueをこれ以上議論できないようにロックしてしまった。可能な代替案の一つはVaultwardenのようだ
https://github.com/dani-garcia/vaultwarden
お金を持った人たちが入ってくると、オープンソースプロジェクトでこういうことが繰り返し起きるのは本当に残念
詳しく見たことはないが、マーケティングだけを見てBitwardenは完全な自由ソフトウェアだと思っていた。ところが2020年ごろから妙なプロプライエタリ要素が入ったように見える
いつかBitwardenへ移行したいと思っていたが、健全なオープンなエコシステムを見つけられないなら、もうしない気がする。どう展開するかは引き続き見守る
評価基準の一つは「家族全員が1Passwordを使って満足しているが、この程度なら彼らを説得して移行できるだろうか」だった。最終的な移行決定は私が下せるが、高齢の両親に新しいことをしてもらうにはユーザー体験が非常に重要だ
結果的に答えはノーだった。全般的にUXが良くないことに加え、BitwardenクライアントはLinux、Mac、Windows、iOSのすべてではるかに遅く、検索からログインまであらゆる面でそうだった。機能も少なく、パスワードの並べ替え、お気に入り、優れた整理ツールといった目立つ部分が欠けており、自動入力もはるかに不安定だった
1Passwordの事業運営や顧客対応には長年大きな不満があった。それでもパスワードマネージャー、今ではパスワード以上のものを入れるシークレットマネージャーに近いツールが日常生活の中心なので、できるだけ苦痛の少ないものを使うべきだと感じ、残念ながら戻った
Bitwardenをオープンソースだから使ったわけではなく、可能な限り最高のパスワードマネージャーを使おうとしただけ。それでもオープンである点は気に入っていたし、Vaultwardenは宝石のような存在だ。本当に、もっと良いフロントエンドを作る時間と実力があればよかったのに
「現時点ではSDKライセンスを調整する計画はありません。独自のF-Droidリポジトリ https://mobileapp.bitwarden.com/fdroid/repo/ への公開は継続する予定です。」
https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
この問題はすでに7月にSDKリポジトリで提起されており、そのSDKは1年以上このライセンスのままだった
iOS、PC、MacでBitwardenを使っている。これから代替を探さなければならない。本当に悲しい日だ
私も年10ドルのプレミアム会員だ。怪しい慣行のせいで失われた売上になるわけだ
エクスポートして別の代替へ移行する方法はある？
https://bitwarden.com/help/export-your-data/
https://support.1password.com/import-bitwarden/
https://proton.me/support/pass-import-bitwarden
他の方法もあるはず
自分にとってより良いKeepass(X,XC)の代替になるかと思って見守っていたプロジェクトだったが、今となっては結局移行しないと思う