HashiCorp が最近、Terraform 製品をより厳格な商用ライセンスに切り替えることを決定したが、これは、自社製品の市場展開に対するコントロール強化を求める最後の企業ではないかもしれない。

「閉鎖：オープンソースライセンスは突然持続不可能になったのか？」からの翻訳。

どうやら私たちはこの議論を避けてきたようです。オープンソースソフトウェアは実際には誰のものなのでしょうか？法的に言えば、オープンソースソフトウェアは依然としてそのオリジナルの作者の所有物です。ソフトウェア開発コミュニティが享受する権利は、ソフトウェアライセンスを通じて作者によってのみ付与されるものです。

このようなライセンスは、クリエイターがソフトウェアの背後にあるアイデアに対する独占権を主張できないことを意味するのでしょうか？さらに重要なのは、ソフトウェアによって創出された市場をクリエイターが独占的に所有することを妨げているのでしょうか？

一方で、同じ疑問も同様に妥当です。スタートアップ企業が新しい未開拓市場に参入する唯一の方法がオープンソース ライセンスである場合、そのイノベーションに関するコードを作成する開発者コミュニティも、そのイノベーションのメリットの一部を享受するべきでしょうか?

このコミュニティは、このイノベーションに直接アクセスし、他のプラットフォームに移植して他者が利用できるようにすることは可能でしょうか？もし可能になった場合、クリエイターは顧客離脱について正当な主張をすることができるでしょうか？

現在表面化している問題は、Terraformに貢献する開発者と開発元であるHashiCorpとの間の亀裂に端を発しています。8月、HashiCorpはTerraformおよびその他の製品のライセンスモデルを、非常に寛容なMozilla Public License 2.0から、簡潔かつ明確なMariaDB Commercial Source Code License 1.1へと変更すると発表しました。

HashiConf 2023にてHashiCorp CEOのデイブ・マクジャネット氏

ビジネスソースライセンス

BUSLはナプキンに書けるほど短い。最も重要なのは最初の文だ。「あなたは、ライセンスされた著作物を複製、改変、二次的著作物の作成、再配布、および非営利目的で使用する権利をここに付与されます。」ここで重要なのは「非営利目的使用」というフレーズだ。これは次のように解釈できるし、また解釈すべきである。「ライセンサーの規定に従い、当社の書面による承認がない限り、当社の製品への貢献から商業的利益を得ることはできません。ただし、当社が指定する条件に従う場合に限ります。」（HashiCorpとデータベースメーカーのMariaDBは、この記事に関するコメントを控えた。）

しかし、HashiCorpの今回の動き（2021年12月にナスダックに株式を公開）は、オープンライセンスからの逸脱としては明らかに初めてではなく、今後も同様の状況が続く可能性が高い。最近では以下のような事例が見られた。

• Red Hat は、RHEL コードの提供を商用顧客のみに制限しています。
• 2018 年、MongoDB は Server-Side Public License (SSPL) を開始しました。これは、コードに貢献するすべての人に、他の人がコードを実行するために必要なすべてのものを公開することを要求する「ソース利用可能」ライセンスです。
• Redis のコード使用制限は、メモリ キャッシュとデータベース拡張モジュールを具体的にターゲットにしており、後に編集されたオンライン投稿では、(AWS ElastiCache については明示的に言及せずに)「クラウド プロバイダー」が再パッケージ化された独自のホスティング サービスを通じて利益を得ようとしていると主張しました。

ここでは、より深い疑問があります。非常に寛容なライセンスの下でも、ソフトウェア製品の作成者に、製品の周りに形成される市場やエコシステムを独占的に所有および運営する権限や許可を与えるべきでしょうか?

もしそうであれば、オープンソースライセンスはホスティングサービスを活用して、オープンソース自体が避けようとしているベンダーロックインを実現できるのかという疑問が生じます。しかし、もしそうでないとしても、開発者はいつでも独自の製品を中心としたマーケットプレイスを構築できます。また、交渉手段としてそうする権利を保持することもできます。

この影響力は、ライセンサーを制約し、条件変更の脅迫を阻止するために活用できます。また、ライセンサーが自社のソフトウェアが設定する標準規格を中心に形成されるエコシステムから利益を得ようとした場合、開発者はオプションを行使することもできます。

最近、次のようなことも起こりました。

• 昨年 7 月、SUSE は最新の公開 RHEL コードをフォークし、最新バージョンの Red Hat CentOS とは異なり、RHEL と互換性のある新しいディストリビューションを構築しました。
• 2021年、Amazon Web ServicesはElasticsearchをフォークしてOpenSearchと名付けました。これは、AmazonがElasticsearchに追加された新しい用語によってクラウドプラットフォーム上でサービスとして検索を提供する能力が制限されると述べたことに対応したものとされています。
• コミュニティのメンバーは、ライセンス条項が許可なく変更されたと信じているため、Node.js を何度もフォークしています。

おそらく最も典型的な例は、2015年にGoogleが初期のコンテナエコシステムをDockerからKubernetesへと効果的に移行した時でしょう。これは非常に迅速かつスムーズに行われ、市場に劇的な変化をもたらしたため、当時の市場アナリストたちは何が起こっているのか理解するのに苦労しました。

オープンさが相対的なものならば、善意にも限界がある。投資家の視点から見て、組織が自らの資産価値を下げずに開発コミュニティにどれだけのオープンさを提供できると期待できるだろうか？技術の利用から誰が利益を得るべきかをコントロールすることが不可能なら、そもそも技術を発明した意味は何だったのだろうか？

非生産的

この問題に対するHashiCorpの立場は非常に明確です。2022年10月にThe New Stackのアレックス・ウィリアムズ氏とのインタビューで、HashiCorpのCEOであるデビッド・マクジャネット氏は、同社がTerraform Console（コード言語のインタープリターとなるインフラストラクチャ）を構築したのは、プロジェクトをオープンソース化するためだと述べています。

「しかし、明確にしておきたいのは、彼らはHashiCorpによって100％コントロールされているということです」とマクジャネット氏は断言した。

本当にそうなのでしょうか？ Terraform開発者コミュニティ全体からの即座の反応は、HashiCorpを放棄し、Terraformの最新のオープンソースライセンスを採用し、それを中心にOpenTofuという新しいプラットフォームを構築し、Linux Foundationに寄贈することでした。さらに重要なのは、これらの開発者が、Terraformをサポートする製品やプロジェクトとともにOpenTofuに移行し、Terraformエコシステムの大部分を実質的に全く新しいプラットフォームに移行したことです。

OpenTofuの主要な貢献者の一人であるPawel Hytry氏は、The New Stackとのインタビューで次のように述べています。「Infrastructure as Codeに基づいてインフラを展開する企業は、オープンソースであり続けるという前提で事業を展開しています。つまり、彼らは自信を持って何年もかけて、このフレームワークに基づいたインフラを構築してきたということです。」

「しかし、その前提は崩れてしまったのです」とハイトリー氏は続けた。「私の見解では、より広範なエコシステムにとって、もしその前提が崩れたとしても、オープンソースの代替手段が常に存在することになるということです。」

「これは本当の転換点になると思う」とブリガムヤング大学のヒュー・W・コルトン法学教授クラーク・アセイ氏はコメントした。

「オープンソースソフトウェア運動は、長年にわたり、明らかに商業化が進んできました。ボランティアコミュニティと、プロジェクトを主導する組織、プロジェクトを買収する組織、あるいはプロジェクトを指導する組織との関係には、相当な負の力関係が存在しています。こうした出来事は、ソフトウェア開発を過去20～30年とは全く異なる方向へと押し進める可能性があります。」

これは合法ですか？

HashiCorp はオープンソースからより厳格なライセンスに切り替えることで何らかの法律に違反したのでしょうか?

アメリカ合衆国建国以来、法判例により、アイデアや手法の創作者はその使用に関して独占権を主張する権利を有しています。しかし、そのような手法がパブリックドメインに指定されると、誰も法的にそれを独創的であると主張することはできなくなります。

周知のとおり、オープンソースソフトウェアはパブリックドメインではありません。開発者は、ライセンスを通じてオープンソースとしての利用を許可する権利を留保しています。技術的には、これはソフトウェアのオープンソースとしてのステータスが永続的であるとは想定できないことを意味します。しかし、ライセンスの文言からライセンシーがライセンス期間が無制限であると誤解した場合、後から新たな制限を追加することは、元のライセンス条項や声明に違反しているとみなされる可能性があります。

言い換えれば、ソフトウェア配布のオープン性を保証する法律は存在しません。しかしながら、ソフトウェアの元の利用可能条件に違反することは違法となる可能性があります。より広い意味で言えば、ベンダーが元の許可ライセンスと矛盾する形で、許可ライセンスから制限ライセンスに切り替えることは合法でしょうか？

「必ずしも合法というわけではありません」と、レッドハットの上級法律顧問であり、GPL第3版の共著者でもあるリチャード・フォンタナ氏は答えた。「状況次第です」

フォンタナ氏は、このソフトウェアは著作権所有者によってのみ所有されており、そのコンポーネントはライセンスに基づいて他者によって提供されておらず、さまざまなライセンス オプションが用意されていると説明しています。

オープンソースライセンスからプロプライエタリライセンスへの切り替えは一つの選択肢です。しかし、GPLバージョン3のような典型的なオープンソースライセンスは永続的かつ取消不能です。このようなライセンスに課せる条件は限られていますが、Fontana氏が述べているように、「これらの条件にはコミュニティの承認を得た制限があります」。

「これらの条件を遵守する限り、ライセンスは永続的です」とフォンタナ氏はThe New Stackに語った。「そのため、オープンソースソフトウェアのライセンサーは、既に付与されたライセンスを取り消すことはできません。ただし、ライセンサーにその権利がある場合、将来の修正、新たな変更、または補足のために別のライセンスを使用することは可能です。」

フォンタナ氏は具体的な事例には触れず、仮想ライセンサーが既に公開されているライセンス条件に制限を課す権利を有しないと判断される可能性は十分にあると付け加えた。その理由の一つとして、コードベースに社外またはドメイン外からの貢献が蓄積されており、それら自体がライセンサーにライセンス供与されていることが考えられる。

「こうした措置を取る企業は、非常に慎重な傾向があると思います」とフォンタナ氏は述べた。「しかし、こうしたことが起こると、社会は真剣に『本当に彼らにはこんなことをする権利があるのだろうか？』と疑問に思うのです。こうした疑問は、時に非常に深刻なものとなるのです。」

BYU の Asay 氏に同じ質問をしたところ、同氏は「はい、法的には許可されています」と答えましたが、いくつか注意すべき点も付け加えました。

「人々は長年にわたりこれらのプロジェクトに協力し、場合によっては多大な時間とリソースを投入してきました。それは主に参加者間の規範と信頼関係に基づいており、全員がある程度同じ認識を持っていたからです」とアセイ氏はThe New Stackに語った。「しかし厳密に言えば、著作権法の下では、組織が作品、共著、または著作物の多くの著者の一つとみなされる限り、非常に緩やかな条件でライセンスを付与し、その後で非常に厳しい条件を選択することも可能です。」

Asay 氏 (彼の兄弟 Matt 氏は New Stack の寄稿者だった) は、クリエイターと寄稿者の関係について説明しました。この関係は、時間の経過とともに外部の観察者や一部のジャーナリストには曖昧に思えるかもしれませんが、法的な観点からは一般的にはそうではありません。

これが起こると、作成者とライセンシーの間の最初の違反は信頼関係の違反となります。

しかし、アセイ氏の見解では、共著者とみなされるかどうかの境界線が曖昧になることは不可能ではない。外部寄稿者が作品のコンテンツの大部分を提供しているという判断を支持する判例が存在する。

今日私たちの運命を決定づける多くの要因と同様に、この判例は私たちの影響範囲外からもたらされるかもしれません。それは、2000年にジェフリー・アールムハメッド氏がスパイク・リー監督を提訴した際の、米国第9巡回控訴裁判所の判決です。アールムハメッド氏は、自身が直接関与したコンテンツの量に基づき、リー監督のドキュメンタリー映画『マルコムX』の「共同著作者」となったと主張しました。したがって、彼は映画の収益の一部を受け取る権利があると信じていました。（1976年著作権法では「著作者」を明確に定義していませんでしたが、その後の判例法では、プロデューサー、監督、さらには編集者までもが「著作者」として分類されるようになりました。）

第9巡回控訴裁判所の判決は、明確な契約がない場合に誰かが作品の共著者としての資格があるかどうかを判断するための3点のテストを確立したため、誰も喜ばなかったかもしれない。

• 個人または団体が全体の作業に対して持つ制御の度合い。
• 全ての当事者が協力する意思があることを示す確かな兆候（信頼の実質的な理由が存在することを前提とする）
• 各参加者の研究への貢献を評価するための計算式がありません。そうでなければ、誰かが共著者ではないと判断されてしまいます。

アセイ教授は、開発者が共同で行動するか単独で行動するかは、具体的な状況によって異なるため、未解決の問題であると述べた。ライセンスは契約ではないため、開発者が共同著者ではないと明記されていない場合、この問題は依然として未解決である。さらに、オープンソースライセンスの対象となる製品に販売価格が設定されていない場合、または収益が発生している場合、当事者間でどのように分配するかという問題は無関係となる可能性がある。

究極的には、この問題はソフトウェアの存在から誰が最も利益を得るかによって決まるかもしれません。このジレンマを解決するには、最高裁判所が現在躊躇している判断が必要になるかもしれません。それは、ソフトウェア市場の基盤となるプラットフォームは、ソフトウェア自体の一部なのか、ということです。言い換えれば、エコシステムは、自らに生命を与えるものを吸収し、具現化しているのでしょうか？

集中化された共有サービス

「Terraformはオープンソースであり続けるという前提で構築されました」とOpenTofuのPawel Hytry氏は説明します。「それが前提です。私たちにはコミュニティがあり、共にこのプロジェクトを構築しています。もちろんHashiCorpが原動力となっていますが、他にも貢献者がいます。つまり、Infrastructure as Codeに基づいてインフラを展開する企業は、それがオープンソースであり続けるという前提で事業を展開しているということです。だからこそ、彼らは自信を持って何年もかけて、このフレームワークに基づいたインフラを開発しているのです。」

Hytry氏の主な役割は、SpaceliftのCEOです。Spaceliftは、Terraform、Red Hat Ansible、Pulumiなどを対象とした、Infrastructure as Code（ICC）ポリシーエージェントと管理プラットフォームを設計する企業です。HashiCorpはプロダクションクラスタ管理プラットフォームVagrantで知られていますが、Terraformの知名度も高めました。しかし、Spaceliftをはじめとする類似製品の登場によって、Terraformの知名度と正当性が確立されたと言えるでしょう。

つい最近まで、HashiCorpも同じ主張をしていたかもしれません。1年半前、まさにこの出版物で、HashiCorpは「育成コミュニティ」を構築するモデルとして称賛されました。寄稿者のエミリー・オミエ氏が指摘したように、企業間の関係がより取引的なグループとは対照的でした。

Hytry氏によると、HashiCorp Terraformレジストリに登録されている設定モジュールの公式プロバイダーになりたい組織は、Terraform専用のモジュールを独占的に開発することを事前に約束する必要があるとのことです。これは、HashiCorpとの関係はMozilla General Licenseによって定義されていると既に信じているプロバイダーにとっては意外な話かもしれません。

「そこで、独自のオープンレジストリを構築しました」とハイトリー氏は続けた。「まるで猫とネズミのゲームのような感じです…大手クラウドプロバイダーは、自社のプロバイダーやコネクターを利用して独占状態を築くことに同意するはずがありません。」

OpenTofuのインフラストラクチャ定義、つまり「プロバイダー」レジストリは現在GitHubでホストされていますが、GitHubは一時的なホストであるという報告もあります。今のところ、変革エコシステムの一時的な拠点となっている可能性があります。

プロバイダを取り巻く状況に馴染みのない方にとって、10月10日のHashiConf基調講演におけるMcJannet氏の言葉は全く異なる解釈をされるかもしれません。同氏は、Terraform商用製品のライフサイクルにおける「オープンソース」の役割について、引き続き「オープンソース」と呼ぶ役割を説明しました。講演の後ろのスライドでは、ライフサイクルを3つのフェーズに分け、最後の2つが商用ライフサイクルの部分を表していました。

マクジャネット氏は、顧客と契約を結んだ当初、約6ヶ月間、方向性を見失い、プラットフォームチームは混乱に陥り、セキュリティモデルも宙ぶらりんの状態だったと説明した。「まさにその時期に、当社のオープンソース製品が利用されました。多くの場合、クラウドネイティブ製品よりも多く利用されたでしょう。既に実現していた広範な統合によって、コアコンセプトの標準化が進んだからです」とマクジャネット氏は語った。

「そうなると、必然的に誰かが主導権を握る必要が出てきます」と彼は続け、「そして、そこに何らかの秩序をもたらすためにコアチームが任命されるのです」と続けた。秩序が確立されることで、顧客とのコラボレーションはより統合され、管理しやすく、トランザクション化されると彼は続けた。CEOは、このコアチーム、つまりプラットフォームチームは、同社がTerraformを導入したことの自然な帰結であると説明した。

「これは常に当社の製品哲学の礎となってきました」とマクジャネット氏は述べた。「明確に申し上げますと、当社のオープンソース製品は常にユーザーの『バージョン1.0』の問題を解決するために設計されており、商用製品は――世界中の2,000人以上のユーザーから長年にわたり要望が寄せられていたため――会社全体の集中型共有サービスとして運用するというニーズに応えるものとなっています。」

これは倫理的でしょうか？

「オープンソースソフトウェアについて話すとき、そこには様々な倫理体系が関わっていると感じます」と、Red Hatのリチャード・フォンタナ氏はこの質問に答えました。「ある意味では、プロジェクトのライセンスを、非常に寛容なオープンソースライセンスから、オープンソースではない、より制限の厳しい非オープンソースライセンスに変更する権利があるなら、それはある程度、基本的な倫理と言えるでしょう。私たちには、ルールの範囲内で特定の行動を促進する法制度があります。」

しかし、Fontana 氏は、オープンソースの文脈ではこれがより複雑になると主張しています。

「ライセンスの変更が物議を醸すような場合、『切り替えを誘発する』という表現をよく耳にします。これは潜在的な倫理的問題を示唆していると思います。」

フォンタナ氏は、マクジャネット氏のプレゼンテーションスライドと一致するトレンドが生まれつつあると見ている。スタートアップ企業は、開発コミュニティをうまく構築できるまでは、GPLv3よりも寛容で、MPLに近い、非常に寛容なオープンソースライセンスを主張しているのだ。「そもそもオープンソースライセンスを使っていないのであれば、おそらくプロジェクトを中心とするコミュニティの構築はうまくいかないでしょう。オープンソース化を妨げるような制限的なライセンスを使っていたら。」と彼は言う。

ベンダーがコミュニティからの好意と前向きな期待を築くには、数年かかることがあります。そして、完全に合法的な行動として、ベンダーはライセンスを非オープンソースライセンスに変更します。「ここには倫理的な問題があると思います」とフォンタナ氏は言います。「難しい問題だと思います。一つは、コミュニティに十分な通知を与えているかどうかです。ライセンス変更の必要性を感じさせる問題について、コミュニティにフィードバックする機会を与えているでしょうか？オープンソースプロジェクトへの期待を醸成するのにこれほど多くの時間を費やした後で、別のモデルに切り替えるのは問題だと思います。」

マクジャネット氏がそのような通知を行ったと断言できます。例えば、アレックス・ウィリアムズ氏との明確な面談においてです。面談から得られる手がかりは「通知」と解釈できるでしょうか？それとも、そのような通知は法的なレターヘッドを用いた書面で行う必要があるのでしょうか？これは、裁判官が対応すべき法的問題です。裁判官について議論を始めてもよろしいでしょうか？

「オープンソースコミュニティは、主に仕様と信頼、そして広く受け入れられた定義と理解の上に成り立っていると思います」とクラーク・アセイ氏は述べた。「しかし、その信頼が失われ始めると、ゲームのルールを定義する仲裁者、つまり誰か、あるいは何かが必要になります。以前は、ゲームはこれらの仕様に基づいていました。もしそれらの仕様が消えてしまったら、それに代わる何かが必要になります。それに代わるものは、著作権法や特許法のデフォルト値かもしれません。しかし、オープンソースに関する訴訟は長年多くないため、その一部は非常に曖昧なものになるでしょう。裁判所がこの分野に介入し、これらの事実すべてに対処することは、明確なガイドラインを提供するのに役立ちます。しかし、このガイドラインはすぐに歪んでしまう可能性もあります。」

「人々はオープンソースを求めています。オープンソースの自由を求めているのです」とOpenTofuのHytry氏は言います。「彼らは他のものに依存したくないのです。個人、ユーザー、そして企業は、特にフレームワークの本来の意図や構築したものに反するような他者への依存を好みません。したがって、企業の規模に関わらず、最終的にはオープンソースが勝利するでしょう。」