Bitwarden SDK、独占ライセンスからGPLv3へ再ライセンス
(github.com/bitwarden)- Bitwarden
sdk-internalのコミットdb648d7は SDK のライセンス文言を整理した変更であり、HN では 独占ライセンスから GPLv3 への再ライセンス の事例として扱われている - ルートの
LICENSEは 295行削除・20行追加 で大幅に置き換えられ、新たに追加されたLICENSE_GPL.txtとLICENSE_SDK.txtがライセンス構成の中心となっている - Rust ワークスペースは
bitwarden_license/*をメンバーに含め、bitwarden-smの依存パスをbitwarden_license/bitwarden-smに移動 bitwarden-smクレートはディレクトリ移動が主な変更で、複数のsrcファイルは 内容変更なしの rename として処理されているbitwarden-sm/Cargo.tomlはワークスペース共通値の代わりに../../LICENSE_SDK.txtを直接参照し、そのクレートのライセンスファイルを明示している
コミットで変わったこと
bitwarden/sdk-internalのコミットタイトルは “Improve licensing language”- HN のタイトルはこの変更を “Bitwarden SDK、独占ライセンスから GPLv3 へ再ライセンス” と紹介している
- GitHub diff にはライセンスファイルの差し替えと Rust ワークスペース構成の変更があわせて含まれている
ライセンスファイルの再構成
- ルートの
LICENSEファイルは 20行追加、295行削除 と表示される- GitHub は大きな diff を標準ではレンダリングしないため、全文は本文に表示されない
- 新しいファイル
LICENSE_GPL.txtが追加された- 変更量は 674行追加、0行削除
- 新しい
LICENSE_SDK.txtも追加された- 変更量は 295行追加、0行削除
- 変更対象一覧には Kotlin と Swift 側の
LICENSE_GPL.txtも含まれるlanguages/kotlin/sdk/src/main/resources/META-INF/LICENSE_GPL.txtlanguages/swift/LICENSE_GPL.txt
Rust ワークスペースのパス変更
- ルート
Cargo.tomlのワークスペースメンバーが拡張された- 既存:
members = ["crates/*"] - 変更後:
members = ["crates/*", "bitwarden_license/*"]
- 既存:
- ワークスペース依存関係の
bitwarden-smパスもあわせて変更された- 既存:
crates/bitwarden-sm - 変更後:
bitwarden_license/bitwarden-sm
- 既存:
- これにより
bitwarden-smは従来のcrates配下ではなくbitwarden_license配下から参照される
bitwarden-sm の移動とライセンス指定
crates/bitwarden-sm/Cargo.tomlはbitwarden_license/bitwarden-sm/Cargo.tomlに rename されたbitwarden-sm/Cargo.tomlのライセンス指定方法が変わった- 既存:
license-file.workspace = true - 変更後:
license-file = "../../LICENSE_SDK.txt"
- 既存:
- このクレートはワークスペース共通のライセンスファイル設定ではなく、
LICENSE_SDK.txtを直接指定している
コード変更よりパス再配置に近い diff
bitwarden-smの複数の Rust ソースファイルは 内容変更なしで移動 されたclient_projects.rsclient_secrets.rslib.rsprojects/create.rsprojects/delete.rs
- ファイルツリーでは、プロジェクトおよびシークレット関連モジュールも
bitwarden_license/bitwarden-sm/src配下へ移動した対象として表示されている - 本文に表示された rename 項目は、コード修正ではなく パス再配置とライセンス構成の変更 に主眼がある
2件のコメント
免罪符 ++;
Hacker Newsのコメント
安堵した。会社がどうにか生き残れたとしても、もう開発者に好かれる会社であり続けるのは難しかっただろうし、その代償は大きかったはず
Bitwardenが自由／オープンソースソフトウェア（FOSS）であることが自分たちの競争優位であり、そのおかげで大きな好意を得ているのだと理解してくれたことを願う。そもそも自分が、完全に最高というわけでもない製品をわざわざ使っている理由もそこにある
FOSSだったときは「最も信頼されるパスワードマネージャー」という大胆な主張もある程度は正当化できたが、KeePassを別にしても、FOSSでなければまったくそうではない
今でもこの会社をどう見るべきか確信が持てない。アプリが今後も自由ソフトウェアであり続けるという信頼は多少生まれたが、会社そのものへの信頼は少し削がれたし、まだ公式コミュニケーションも見ていない
1億ドルの投資を受けることが長期的にユーザーにどう利益をもたらすのか分からない。最もありそうなのは機能の肥大化やサービス悪化だと思う
Bitwardenはフォークしやすそうには見えない。C#でできた複雑なシステムで、Vaultwardenの存在は大きな助けになるとはいえ、クライアントアプリはまた別の問題だ
ユーザーに敵対的な行動を防ぐ保護策としては、オープンソースそのものの次にフォーク可能性が重要だと思う。それでもうまくいってほしい。最近Bitwardenを使い始めたが、ここまでのユーザー体験はKeePassよりずっと良かった
Bitwardenがその部分を自由／オープンライセンスに戻してくれて感謝している
ただし一般ユーザーには、もうBitwardenを勧めていない。Firefox内蔵のパスワードマネージャーが十分良くなったからだ
それでも、より高度な機能が必要だったり、Webブラウザ内蔵のパスワードマネージャーを信頼しない人には、いつでもBitwardenを勧める。KeePassXCに同期を組み合わせるのは一般ユーザーには難しすぎる
たとえば、秘密の質問への回答、関連するメールエイリアス、配偶者のスマホのPINのような、Webサイトではない秘密の値を暗号化ストレージに入れておく場所が必要だ
Firefoxのパスワードマネージャーは「ユーザー名」と「パスワード」の2フィールドしかなく、あまりに基本的すぎる。一般ユーザーにとってより良いユーザー体験は、Firefoxに一部の秘密を、別のアプリに残りを分けて保存することではなく、1つのアプリにすべての秘密を集約することだ
モバイルでは使いづらく、プラットフォーム依存で、ローカル専用の同期されていないデータを失いやすい。複数デバイスで使うのも、特に仕事の環境ではより複雑になる
その一方で、人は各デバイスにアプリをインストールして、そのアプリに処理させるやり方はたいていよく理解している
そうなればパスワードはFirefoxだけの機能ではなく、Mozillaアカウントの一部になる。Bitwardenはこの点で優れており、打ち負かすべきモデルに近い
Mozillaには、ブラウザ統合が事実上の標準搭載である一級機能だという利点があるだろうが、Firefoxだけを独占的に使うのでなければ、単一ブラウザがパスワード管理の場として適しているとは思いにくい
Bitwardenは、ブラウザを開いたままでもパスワードへのアクセスを「ロック」状態にしておけるのが良い。以前見たときのFirefoxは、パスワードが必要なくても起動時にマスターパスワードを入力しなければならず、金庫のロック解除がブラウザ起動に結びついているだけで見送る理由になった
Bitwardenは会社で承認されており、セルフホスティングが可能で、ブラウザとモバイルデバイス全般の多数のアプリのログインをサポートしている
モバイルアプリでもモバイルWebサイトでもブラウザサイトでも、たいてい問題なく動く。クレジットカード、セキュアメモ、秘密の質問の回答の大文字小文字、アカウント復旧やログイン情報のような任意情報も保存できてかなり良い
Firefoxのデバイス間タブ同期が壊れているのを知っているだろうか？ 8月24日から壊れたままで、まだ修正されていない https://bugzilla.mozilla.org/show_bug.cgi?id=1913795
タブすらデバイス間で同期できないのなら、パスワード同期を信頼するのは難しい
Bitwardenがここで方針修正したのは良かった。他のパスワードマネージャーへ移るのを楽しみにしていたわけではないので、かなり満足している
パスワードマネージャーを変えるのは面倒なので、もう絶対に移らなければならないという感覚がなくなって助かった
Bitwardenは今でも素晴らしいが、今後数年は見守る必要がある。BitwardenはもともとLastPassの奇妙な動きを避けるための代替として始まったことを忘れてはいけない
ただ、なぜこのGitコミットがリンクされているのかは分からない。むしろ関連する議論を見たい https://github.com/bitwarden/clients/issues/11611
根拠として、Bitwardenはスポンサー付きのYouTuberは勧めないが、スポンサーされていないYouTuberはいつも勧めるパスワードマネージャーだ
Bitwardenが耳を傾けてくれて感謝している。こういう出来事はオープンソースのビジネスモデルにも希望を与える
関連リンク: https://github.com/bitwarden/clients/issues/11611#issuecomme...
以前の議論: https://news.ycombinator.com/item?id=41893994
かなり効果的で、オープンソースらしいやり方で対応したように見える。変な小細工なしで解決してよかったし、おかげでBitwardenから移行する面倒を避けられそう
まだ完全に解決したわけではない。一部は再ライセンスされたが、一部は以前の非自由ソフトウェアSDKライセンスのまま残っている
例: https://github.com/bitwarden/sdk-internal/commit/db648d7ea85...
Bitwardenはもともと完全なGPLv3ではなく、常にオープンコアだったし、それは理解できる。結局のところ、売るものは必要だから
正しい方向に動いたこと自体は評価できる。数日間はBitwardenがどうするのかまったく明確ではなかった
自社製品をオープンソースとして公開している数少ない企業の一つだ。今はまだ疑ったり説教したりする段階ではまったくない
歓迎すべき変化ではある。それでも、ライセンスであまりに賢く立ち回ろうとしている感じは残る。特にGPLコードと独占ライセンスコードを結合するやり方が、今回の騒動の根本原因だったように思える
オープンコアモデルは、GPLと独占コードを組み合わせた成果物を配布しないホスティングサービスのほうがうまく機能する。クライアントコードでオープンコアをやるのは、誤解や混乱を招く余地が大きすぎるように見える
それでもうまく収まってほしい。良い製品だ