HashiCorp、Business Source Licenseを採用
(hashicorp.com)- HashiCorpは今後の製品リリースのソースコードライセンスを MPL 2.0 から Business Source License v1.1 に変更し、コミュニティと製品への投資を継続していく方針
- 既存のオープンソースモデルは大きなエコシステムを生み出した一方で、一部ベンダーが コミュニティの成果を商業的に活用 しながら実質的な貢献をしないという問題が拡大したと見ている
- BSL 1.1は、複製・改変・再配布と非商用利用、条件付きの商用利用を認める ソース公開型ライセンス であり、API・SDK・ほとんどのライブラリは MPL 2.0 のままとなる
- エンドユーザー、パートナー、エンタープライズおよびクラウドのマネージド製品の顧客は概ね従来どおり利用を継続できるが、HashiCorpと競合する製品の提供は例外となる
- HashiCorpのコミュニティ製品の上に競合サービスを提供するベンダーは、今後のリリース、バグ修正、セキュリティパッチを統合することが今後は難しくなる
ライセンス変更の範囲
- 今後のすべてのHashiCorp製品リリースのソースコードライセンスが Mozilla Public License v2.0(MPL 2.0) から Business Source License(BSL または BUSL) v1.1 に変更される
- HashiCorp API、SDK、ほぼすべてのその他のライブラリは MPL 2.0 を維持する
- 製品のソースコードと更新は、引き続きHashiCorpのGitHubリポジトリと配布チャネルで公開される
- HashiCorpは、コミュニティ、パートナー、顧客への影響を最小限に抑えつつ、ソースコードを広く共有し無償利用を可能にする方法を目指している
オープンソースモデルと商業化の負担
- HashiCorpが創業当初に製品をオープンソースとして公開した理由は3つあった
- 実務者がソースコードを自由にダウンロードして確認し、自ら問題を解決できるようにするため
- 製品の周囲にエコシステムとコミュニティを築き、幅広い統合を可能にするため
- ユーザーにとって 透明性 が重要だったため
- 10年以上にわたり、無償のオープンソースライセンスで新製品と新機能を提供し、ユーザー・コントリビューター・パートナー・顧客から成る大きなコミュニティが形成された
- 毎年、オープンソース製品の研究開発に 数千万ドル を投資しており、ミッションクリティカルなインフラでHashiCorpと協業する商用顧客がこのモデルを支えてきた
- クラウドプロバイダーと緊密に協力して共同ユーザーと顧客向けの統合を提供し、数百の技術パートナーとも協力してきた
BSL 1.1の適用方法
- BSL 1.1 は、複製、改変、再配布、非商用利用、一定条件下での商用利用を認めるソース公開型ライセンスである
- 近年ではCouchbase、Cockroach Labs、Sentry、MariaDBも同様の道を選んでおり、MariaDBは2013年にこのライセンスを策定した
- Confluent、MongoDB、Elastic、Redis Labsなども、商用利用の制限を含む代替ライセンスを採用した事例として挙げられている
- HashiCorpのBSL適用には、ソースコードの広範で許容的な利用を可能にする 追加利用許諾 が含まれる
- ライセンス策定の過程では、OSSライセンスの専門家や業界のステークホルダーに助言を求め、業界慣行に沿うよう努めた
ユーザー・パートナー・顧客への影響
- エンドユーザーは、HashiCorpと競合する製品を提供する場合を除き、すべての非商用・商用用途でコードを引き続き複製、改変、再配布できる
- パートナーは共同顧客向けの統合を引き続き構築できる
- クラウドサービスプロバイダーとは今後も緊密に協力し、相互技術に対する深いサポートを維持する計画
- エンタープライズおよびクラウドのマネージドHashiCorp製品の顧客には変更はない
- コミュニティ製品を基盤にHashiCorpと競合するサービスを提供するベンダーは、今後のリリース、バグ修正、セキュリティパッチをHashiCorp製品に統合できなくなる
今後の案内
- HashiCorpは、コミュニティ、パートナー、顧客に対する約束は変わらないと表明している
- 追加の質問に向けて frequently asked questions を提供している
1件のコメント
Hacker News の意見
ここから得られる結論は、HashiCorp はもはやオープンソース企業ではないということだけです。
「純粋な OSS モデルとコミュニティの作業を商業的目標に利用しながら、実質的な貢献を返さないベンダー」が存在すること自体は、オープンソースの精神に 100% 合致しています。
それが問題なら、AGPL のように開発者にコード公開を強制するオープンソースライセンスを採用すればよいのです。
これは HashiCorp が、かつてのオープンソースプロジェクトを自分たちだけが商業化できるようにするためのやり方にすぎません。それ自体は構いませんが、そうするなら単にクローズドソースにして、それを認めるべきで、両方を手に入れようとしてはいけません。
ブログ記事は率直ではありません。Terraform プロバイダーに対して何度もアップストリーム修正の貢献を試みましたが、HashiCorp が受け入れたことはなく、フォークを維持せざるを得ませんでした。
HashiCorp はずっと以前に OSS DNA を失っており、今回の措置は棺桶に最後の釘を打ったようなものです。
幸い、時間の経過とともに Terraform プロバイダーの大半の責任をパートナーに移してきたため、プロバイダーのエコシステムは今後も活発でオープンであり続けられることを期待しています。
私はオープンソースを深く信じています。Microsoft で最後に取り組んだプロジェクトも .NET をオープンソースかつクロスプラットフォームにすることで、CTO は TypeScript の創設に関わり、Pulumi も Apache のオープンソースプロジェクトです。HashiCorp はもうそうではないように見えます。
大きな流れとして時代は変わっており、ソース公開は「全部無料で出さなければ本物ではない」というものではなく、作る側と使う側の相互利益関係であるべきだと思います。
ユーザーは動いているものをソースから理解し、拡張できるべきですし、プロジェクトの管理者・保守者・所有者はその作業を続けられるべきです。
これは到達すべき均衡点ではなく、緊張関係の中で維持すべきバランスです。
Wikipedia を確認したところ、HashiCorp は 2021 年 11 月 29 日に IPO 条件を決めたそうです。
ますますこの仮説が正しいように思えてきました。反例でも支持例でも、逸話的な情報は歓迎します。
オープンソースでないからといって、ソースを見られないようにしなければならないわけではありませんし、OSI 承認ライセンスのあらゆる特性を取り除かなければならないわけでもありません。
もちろん自由ソフトウェアであればもっと良かったでしょうが、それはすべてのソフトウェアが自由ソフトウェアならもっと良い、という話と同じです。
問題は、OSI の承認を受けられないライセンスをオープンソースだと装うときに生じます。HashiCorp は今もオープンソースだとは主張しておらず、現在は「ソース公開（source-available）」と呼んでいます。
かなり残念です。個人的には Vault 以外はあまり使っておらず、Terraform は使ったことはありますが、楽しんだり、その上に何かを作ったりはしませんでした。それでもこれは、HashiCorp 製品で最も良いと思っていた点と真逆です。
しかも Vault で私が最もよく使うコードの一部である証明書管理にも貢献しましたが、今後顧客にそのサービスを使ってみるよう勧められるのか、再び貢献するのかを考え直さなければなりません。
VC 資金が枯れつつある時代になり、GPL 系ではないライセンスの最悪の未来が露わになっているように感じます。
いつかその知識を活かしてサービスを作り、自分自身のボスになり、ここまで来るのを支えてくれた OSS に還元し続けるという夢を持って、OSS とその運営だけを意図的に学んできた人たちにとっては、残念なことです。
会社のインフラ全体でアプリケーションのシークレット管理のために Enterprise Vault を実装・運用した経験が豊富にあります。
Vault を導入し契約交渉をしていた数年の間、セールスエンジニアがユースケースに「必要な」機能について不正確または誤解を招く説明をし、守れない長期的な機能の約束をするのを見てきました。
Vault から抜け出す移行が事実上不可能、または危険になり得る統合方法を勧めることもあり、永遠に無料だと思っていた機能を次々と奪っていきました。Okta/MFA ログインが最大の例で、本格的なコンプライアンスはそれなしでは通過しにくく、Vault に大きく依存しているチームはいずれこの機能にお金を払わざるを得ないと HashiCorp が気づいたようです。
全体として強いベンダーロックインのように見え、毎年同じ機能、あるいはより少ない機能に対して、より大きな費用を払うことになりました。エンジニアでさえ説明できない価格体系も、恣意的に変わり続けました。
Vault 自体は優れたソフトウェアだと思いますが、HashiCorp への信頼を失ったため、個人的に重要な用途では依存しないと思います。
文字通りなら変わったことはなく、残念なことではなく賢い選択です。オープンソースコミュニティの善意を繰り返し濫用してきたクラウドプロバイダーから自分たちを守っているのです。
コントリビューターに著作権譲渡を求める OSS プロジェクトは信用すべきではなく、そもそも善意の貢献を受け入れるべきでもありません。
そうでなければ、今日は Apache 2.0 であっても、明日には誰の許可も得ずに商用ライセンスへ変更される可能性があります。メンテナーがコードの 100% を所有しているからです。
商業主体が支える OSS プロジェクトが外部コントリビューターから意味のある量の貢献を受けることは通常まれですが、それでも OSS において考えるべき重要な細部です。
「商用オープンソースモデルが進化しなければ、エコシステムはオープンで自由に利用可能なソフトウェアを提供し続けられない」といった言い方をしながら、BUSL のような非オープンソースライセンスをオープンソースモデルの進化の一部であるかのように示唆するのは、深刻な混同か意図的なミスリードである
意味のある規模の誰かが HashiCorp 製品を使って HashiCorp と実質的に競合したことはあるのか？
[1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U...
Pulumi は任意の Terraform Provider を Pulumi で使えるように変換できるため、Terraform Providers エコシステムが対応するあらゆるインフラを Pulumi プログラムで管理できる
企業がこうした措置を取るのは、Amazon のような会社が自由・オープンソースライセンスを利用して、オープンソースプロジェクトのセルフホスト版を立ち上げるからだ
ctrl+fで “open source” を検索してみると、どこからその表現をやめているかが分かるHashiCorp は今回の変更を、「オープンソース」を維持するためではなく、オープンで自由に利用可能な製品を維持するためのものだと説明している
ライセンスを変更しながらも「オープンソース」のままだとは言わない点では、他よりも正直だと思う。そう呼んだときに受ける反発を分かっているのは明らかだ
@mitchellh が会話に参加していないのが興味深い。以前は HN で直接やり取りしていたし、この決定にも最終的な影響力を持っていたのではないかと思う
全体として敗者の一手に見える。Elasticsearch に何が起きたかを見ればいい。私や大半の人にとって ES はもはや存在しない。気持ちよく OpenSearch に移行したし、哀れな kimchi を振り返ることもない。自分たちの行動のせいで Elasticsearch はもはや関連性を失った
HashiCorp の今回の動きは、Terraform や他のツールの最後のオープンソースライセンス版をフォークしようとする同様の取り組みを引き起こすだろうか？ 作った側がけちで不安になり、共に作り上げてくれたオープンソースコミュニティに敵対的に出るなら、他にどんな選択肢があるというのか
HashiCorp のリーダーシップには極めて失望した。MitchellH と Armon Dadgar はコミュニティをもっとまともに扱うべきだった
2016年に HashiCorp の面接を受け、結局入社を断ったが、その決断を少し後悔したこともあった。今や本性が現れたので、正しい選択だったと確信している
信頼についての言葉があるだろう。信頼を築くには何年もかかり、壊れるのは数秒、回復には永遠がかかる
賢いと思っていた人たちが、ここまで愚かになれることに驚く
多くのことを成し遂げた人を侮辱する必要はない
彼らのソフトウェアはオープンソースだったし、良いものはフォークされるだろうから、HashiCorp を憎む必要はない
「信頼を築くには何年もかかり、壊れるのは数秒、回復には永遠」という言葉にも同意しない。攻撃的すぎる
HashiCorp は素晴らしいものを作り、オープンソースベースの事業を試みた。契約を破ったわけでも非道徳的なことをしたわけでもなく、これは彼らの選択だ
無料資金が終わった後、すべてのオープンソース企業が迎える避けられない結末のように見える。気になるのは文言がかなり曖昧な点だ
HashiCorp は競合製品を「組織外のユーザーや顧客に提供される製品またはサービスのうち、HashiCorp の商用製品・サービスの機能と相当に重なるもの」と見なすという
たとえばコスト見積もりサービスがないので何かを作り、それが有名になったとしよう: https://github.com/infracost/infracost
2年後に Terraform Cloud が追随してきたらどうなる？ 事業を畳まなければならないのか？
だがデータベースのような、より大きな業務中核製品では、セルフホスティングを難しくしたり必須機能に制限をかけたりするなど、はるかに奇妙なねじれが見られる
クローズドソースよりはましだが、理想的ではない。しばらく前から、ライセンスが実用的な逃げ道になる可能性は高いと思ってきたが、広く理解され、公正で、明確でなければならない
「組織外のユーザーや顧客に提供され、機能が相当に重なる製品またはサービス」という表現はつらい。文言上、(1) 不明確で、(2) その曖昧さに対する権限が会社側に傾いており、選択的執行への道を開いている
法的文書に署名する状況で「心配するな、誰も追いかけない」は説得力がない。契約で、現在は穏やかに見える権利や将来行使できる権限を積み上げておくのは、大きな危険信号だと思う
このライセンス自体について、他の人がどう見ているのか気になる
「2年後に Terraform Cloud が追随してくる」は本当に良い指摘だ。会社の範囲は変わる
https://www.couchbase.com/blog/couchbase-adopts-bsl-license/ によると、BSL は通常 1〜4年の間に変更日を設定し、その時点で BSL ライセンスが GPL、AGPL、Apache などのオープンソースである変更ライセンスへ移行するとのこと
なので最も重要な問いは、変更ライセンスが何で、どれくらいかかるのかという点
1年後に MPL 2.0 へ移行するなら問題ない。しかし、はるかに長く、より制限的なら完全な方針転換であり、オープンソース版は最新版から離れすぎて事実上使えなくなる
修正: 4年後に MPL 2.0
https://www.hashicorp.com/license-faq#What's-the-difference-...
セキュリティが関わる場合、4年は事実上「歴史的関心事」にすぎない
4年、MPL 2.0
他社のことは分からないが、こうした会社のソフトウェアが最初から非自由ライセンスだったら今どこにいたのだろう、といつも自問してしまう
これはコードを「盗んで」サービスとして動かそうとする巨大企業だけでなく、エンドユーザーや小さな個人・企業に対しても敵対的だ
HashiCorp のソフトウェアをうまく運用・利用していても、競合と見なされれば HashiCorp があなたを締め出すと決めることができる
例えば https://github.com/hashicorp/vault/blob/main/go.mod#L25
最初から BSL で始めていたら、ここまで広く採用されることはなかったと思う
2か月前の HashiCorp の CLA ページ: https://web.archive.org/web/20230610041432/https://www.hashi...
「HashiCorp が持続可能な事業を作れるようにしつつ、プロジェクトを MPL2 のような自由・オープンソースライセンスのまま維持するため、外部コントリビューターにコントリビューターライセンス契約（CLA）への署名を求めている」と書かれていた
「HashiCorp は非商用ソフトウェアに真の自由・オープンソースソフトウェア（FOSS）ライセンスを適用することを約束する。CLA は、ユーザーが自分のプロジェクトや事業で利用する権利、改変ソースの再公開、完全なフォークなど、標準的な FOSS ライセンスが付与するすべての権利を維持しながら、HashiCorp が製品を安全に商用化できるようにする」とも書かれていた
ページの非法律的な文言は、CLA への署名が HashiCorp プロジェクトをオープンソースに保つ助けになると繰り返し示唆していたが、実際の契約文言はそのような保証をしていなかった点が残念だ
CLA の前提、つまり貢献物が非 FOSS に再ライセンスされる状況が変わったときに、誰かが異議を申し立ててみるべきだ
ほとんどの CLA は非常に淡々としているが、HashiCorp は自社の CLA にいくつも宣言を入れていたので、厄介なことになるかもしれない
そういうものを要求する唯一の理由は再ライセンスであり、すでに FOSS なら再ライセンスしようとする唯一の理由はプロプライエタリソフトウェアへ向かうためだ
Linux は貢献に CLA を要求しない。オープンソースのふりをするこのピエロたちが要求するだけだ
私たちの OSS 会社は Apache 2.0 で、Nomad を中核に据えて作られている
その周辺にいくつかのサービスを付けてゲームサーバーオーケストレーションを提供しているが、これが HashiCorp に「競合製品の提供」と誤解される可能性がある
ライセンスが意図的に曖昧なため、Nomad のバージョンは最後の MPL 版で凍結する予定
CockroachDB も使っていて、あれは BSL だが、私たちはそちらとまったく競合する製品を提供していない
相談してくる人に HashiCorp 製品である Nomad、Consul、Terraform、Packer を引き続き勧める可能性は高いが、今回の変更は残念に聞こえる
気になる人のために簡単な SBOM を維持している: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
Nomad のエンジニアリングリードだ。ライセンスは私の管理外だが、いつか競合と解釈されるのではないかと不安に思っているユーザーは多い
約束はできないが、Nomad が今でもあなたの仕事に合うツールだと確信してもらえるよう、できる限り何でもしてみる
個人的には問題ないと思う。最終目標がSaaSプラットフォームになることなら、もっと多くのオープンソースプロジェクトが最初からBusiness Source Licenseで始まってほしい
大企業が自分たちの金銭的利益のためにオープンソースの精神を乱用し、何も還元せず、悪意をもって振る舞う様子を繰り返し見てきた
公開され利用可能にされたものを使うことを悪意ある行為とは見なさないし、無料で配ることも喜んで行う
そうでないならオープンソースではない。もちろん、すべてのソフトウェアがオープンソースである必要はないので、それはそれで構わない
オープンソースの精神を乱用しているのは、利用について恣意的なルールを作る側だ
それでも最初から明確にしておくほうがよいのは確かだ