ハクソク

世界を動かす技術を、日本語で。

ラグプル、フォーク、オープンソースの封建制

261日前原文(lwn.net)

概要

  • オープンソース開発における パワーダイナミクス の実態
  • リライセンス や フォーク による力関係の変化
  • 主要事例（Elasticsearch, Terraform, Redis等）の分析
  • プロジェクト選定 や ガバナンス の注意点
  • コミュニティ主導の持続可能な開発の重要性

オープンソース開発におけるパワーダイナミクス

  • オープンソース開発では 企業・開発者・ユーザー 間で影響力争いが発生
  • 大手クラウドプロバイダーが 最も強い力 を持つ傾向
  • 貢献者やメンテナーは 小規模企業やユーザーよりも弱い立場
  • クラウドサービス利用の容易さが、 プロジェクトへの還元不足 を招く
  • 小規模企業には リライセンス という対抗手段が存在

リライセンスとラグプル（Rug Pull）

  • リライセンス により利用者・貢献者に不利益が発生
  • 「ラグプル」とは、 企業が突然ライセンスを変更し利用者の立場を不利にする行為
  • 単一企業主導のプロジェクトは ラグプルリスクが高い
  • 企業の経営方針変更や買収で 信頼性が揺らぐ 事例
  • 投資家への説明責任が 収益化圧力・リライセンス につながる

フォークによるパワーバランスの逆転

  • フォーク はコミュニティが力を取り戻すための手段
  • フォークには 人材・リソース が不可欠
  • 大企業やクラウドプロバイダーが フォークを支援 するケースも
  • すべてのリライセンスが 人気フォーク につながるわけではない（例：MongoDB, Sentry）

主要事例分析

  • Elasticsearch ：Elastic社がSSPLにリライセンス、AWSがOpenSearchをフォーク
    • フォーク後もElastic社員中心の貢献体制、OpenSearchはAmazon主導
    • Linux Foundation参加後も外部貢献者の増加は限定的
  • Terraform ：HashicorpがBusiness Source Licenseに変更、OpenTofuがLinux Foundation傘下で誕生
    • OpenTofuは複数企業から新規貢献者を獲得
  • Redis ：SSPLへのリライセンス後、ValkeyがLinux Foundation下でフォーク
    • 外部貢献者がValkeyへ移動し、強力なコミュニティ形成

フォーク・リライセンス後の影響

  • リライセンス直後に GitHubフォーク数が急増 する傾向
  • フォーク側の利用は 本家より少ない が、両者とも開発継続
  • リライセンスされたプロジェクトは 利用者減少傾向
  • 中立的な財団下でのフォークは コミュニティ活性化 につながる場合も

リスク回避とプロジェクト選定のポイント

  • 貢献者ライセンス契約（CLA） は企業側にリライセンス権限を与えるため、注意が必要
  • 開発者証明書（DCO） 利用プロジェクトはラグプルリスクが低い
  • 財団傘下でも 単一企業支配 の場合はリスクあり（例：Cortex→Mimir）
  • 中立的ガバナンス ・複数組織のリーダーシップが望ましい
  • 貢献者層の厚さも 持続性の指標
  • 企業は依存プロジェクトへの 社員貢献 で影響力強化と持続可能性向上

コミュニティ主導の持続性と今後

  • CHAOSSプロジェクト によるプロジェクト評価指標・ガイドラインの活用
  • クラウドプロバイダーの台頭で 封建的構造 が強まる傾向
  • リライセンスでクラウド側の力を抑制できるが、 貢献者の力も奪う 側面
  • 貢献者は フォークで主導権を取り戻す ことが可能
  • フォークの成功事例が企業のリライセンス判断に 影響を与える ケースも
  • 中立ガバナンス と外部貢献者拡大が最良の対策

まとめと推奨アクション

  • プロジェクト選定時は ガバナンス・貢献者構成・ライセンス契約 を確認
  • 中立的な運営体制 ・多様な貢献者が持続性の鍵
  • 企業・個人ともに 積極的な貢献 がプロジェクトの健全性を支える
  • 受け身ではなく、主体的な関与 がリスク低減と影響力強化に直結

Hackerたちの意見

ソースからデフォルトでソフトウェアをビルドするのは、こういう出来事の影響を減らして、力のバランスを変える一つの方法だよね。もしベンダーからバイナリやイメージをインストールしてるなら、フォークに移行するのは大変かもしれないし、リスク評価も必要だしね。でも、既存のビルド環境を新しいリモートからソースを同期させるように切り替えるのは簡単だと思うよ。それに、メンテイナーにリリースを急かしたり、無視されてるバグ修正や機能追加をお願いする必要もないし、必要なものをそのまま選んで持ってくればいいんだ。

└

なんでこれがダウンボートされてるのか分からないけど、同意だわ。ソースからビルドするのもそんなに難しくないしね（sqliteを見てみて）。

└

実際のソフトウェアライセンスによるけど、多くの商業ベンダーはソースコードを提供してるよ。ただ、そのライセンスではコードを好き勝手に使うことはできないんだ。技術的には可能でもね。商業製品では、スクリプト言語が使われることが多いから、そういうことがよくあるんだよね。例えば、エンタープライズコンサルティングでは、コードがプロジェクトの一部として提供されるけど、コンパイルのためにはエージェンシーに縛られることが多い。顧客がその権利のために追加料金を払わない限りね。

└

これが私がGuixを好きな理由の一つなんだ: そのパッケージシステムは、ソースビルドを通常のケースとして扱っていて、バイナリパッケージはキャッシュを通じて利用可能なんだ。だから、パッケージをインストールしようとしてキャッシュされたバイナリがない場合、Guixはその場で喜んでビルドしてくれるよ。ビット単位で再現性があれば、なおさらね。事前にビルドされたパッケージの利点は得られるけど、常に逃げ道があるんだ。これにより、他のすべてのパッケージマネージャーと同じように、パッチを当てたバージョンのパッケージを簡単にインストールできる。専用のビルドインフラは必要ない（もちろん、大規模なフリートにデプロイする場合は、ほとんどのマシンで再ビルドの必要を避けるためにビルドサーバーを設定した方がいいかもしれないけど）。

リライセンスイベントの後には、こういったクローンが増えることが多い。つまり、人々がプロジェクトのハードフォークを考えているってことだね。それか、念のために「スナップショット」を作ってるのかも。多くの人が真剣にフォークのメンテナンスを引き受けようとは思ってないと思うけど…。

CLAがあるプロジェクトは、よりラグプルのリスクが高い。開発者証明書を使っているプロジェクトは、同じ力の不均衡がなく、ラグプルされる可能性も低い。理由を説明する価値があると思う。私の理解では、CLAにサインすると、通常はCLAの受益者に再ライセンスの権利を与えることになる。つまり、「これはGPLプロジェクトで、私の貢献もGPLだけど、あなたが好きなように私の貢献を再ライセンスすることを許可する」ってこと。もしプロジェクトがすでに許可的なライセンスを使っているなら、正直、CLAにサインしても大きな影響はないと思う。誰でもそのコードベースを取って、プロプライエタリにすることができるからね。でも、もしコピーレフトライセンスなら、CLAにサインすることで受益者が同じルールで動かないし、貢献をプロプライエタリにできちゃう！ラグプルを避けたいなら、コピーレフトライセンスを使ってCLAにはサインしない方がいいよ。多くの人が著作権を共有してるから、Linuxをプロプライエタリにすることはできないんだ。許可的なライセンスを使うなら、ラグプルはその一部だよ。

└

許可的なライセンスを使うなら、ラグプルはその一部だよ。確かに。でも、CLAは必ずしもすべての権利を放棄するわけじゃないよ。

└

オープンソースに関しては、ラグプルなんて存在しないよ。GPLのコピーは永遠に残るからね。

└

私の理解では、CLAにサインすると、通常はCLAの受益者に再ライセンスする権利を与えることになる。これを明確にするために言うと、これはサインするCLAの内容による。例えば、CanonicalのCLA（CCLA）には、セクション2.3のアウトバウンドライセンスにこの条項がある。> 私たちは、コピーレフト、許可、商業的、または独自のライセンスを含む、いかなるライセンスの下でも貢献をライセンスすることができます。この権利を行使する条件として、私たちは提出日現在で使用している素材のライセンスの条件の下でも貢献をライセンスすることに同意します。つまり、彼らはあなたの貢献を元のライセンスの下でリリースすることを約束しているということ。言い換えれば、古い貢献を遡って再ライセンスしないってことだね。他のCLAではこの約束がない場合もあるから、何にサインしているのかを理解するのは一般的に良いアイデアだよ。（これはCLAだけでなく、すべての契約に当てはまるからね。）ほとんどのCLAは、貢献者が著作権を保持できるようにしている。（私の理解が正しければ、著作権の移転はCAAにのみ関係している。）だから、あなたが貢献に対して好きなようにできるオプションもあるよ。いずれにせよ、実際の問題は、プロジェクトのオーナーに対する暗黙の信頼を裏切られることだよ。あなたが彼らや他の人たちに自分の作品を寛大に提供したから、将来他の人たちの貢献に対しても同じように返してもらえると思うよね。でもCLAはそれをオープンにして、プロジェクトのオーナーの単独の管理下に置くから、ラグプルの危険があるんだ。ラグプルの後にその貢献の恩恵を受ける唯一の方法は、他の貢献者と直接協力することだね。要するにフォークすることだ。> ラグプルを避けたいなら、コピーレフトライセンスを使ってCLAにはサインしない方がいいよ。これら二つの奇妙で特にひどい組み合わせがある - AGPL + CLA。私は一般的にAGPLの支持者だけど、この組み合わせは許可ライセンス + CLAよりも悪いと思う。コピーレフトライセンスは、アプリケーションを配布した相手に対して、ソースコード（カスタム修正を含む）を要求されたら提供する必要があるんだ。AGPLでは、オンラインサービスの使用も「アプリケーションの配布」の定義に含まれるから、あなたのサービスを使う誰にでもサーバーサイドコードの修正を配布しなきゃいけない。これは良いことだと思う - なぜなら、リソースが豊富な他の誰かがあなたのサービスを改善してホストして、あなたがその改善の恩恵を受けられないってことがないからね。でもCLAがあると、プロジェクトのオーナー（おそらく会社）が未公開の改善を加えた再ライセンス版をホストできる一方で、あなたは同じことをしようとすると自分の改善を公開しなきゃいけない（AGPLのコードを使っているから）。許可ライセンス + CLAの下では同じ問題は起こらないけど、ここで特にひどいことが起こる。上記の問題は、許可ライセンスだけでCLAがないソフトウェアにも影響を及ぼす可能性がある。これがIncusとLXDに起こったことだ。LXDは当初Apacheライセンスの下で、Canonicalと協力してLinuxコンテナコミュニティのもとにあった。ある朝、Canonicalがプロジェクトの管理を決定し、LinuxコンテナコミュニティがそれをフォークしてIncusを作ることになった。その後しばらくの間、両プロジェクトは同じライセンスの下でお互いからコードを借りていた。でもその後、CanonicalがLXDをAGPLv3 + CLAの下で再ライセンスすることに決めた。これにより、ライセンスの不整合のためにIncusがLXDからコードを借りることができなくなり、Canonicalは少し変わった取り決めの下でそれを続けた。詳しくはここで読めるよ: [2] [1] https://canonical.com/legal/contributors/agreement?type=indi... [2] https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-unde...

└

一般的にラグプルの対象になる このオープンソースの純粋主義は有害だよ。プロジェクトは持続可能でなきゃいけない。ハイパースケーラーたちはインターネット全体を吸い上げて、モバイルデバイスのカテゴリを完全に支配してる。私たちはここで小さな開発者がソースが利用可能なOSSやCLA付きのOSSについて言い争ってる。コミュニティがそんなに気にするなら、最後のオープンバージョンを取って自分たちでメンテナンスすればいいじゃん。このネガティブなエネルギーを全部持っていって、大手テック企業の分裂のために戦ってほしい。

└

でもGNUはどうなの？彼らのプロジェクトはCLAにサインする必要があるし、ラグプルはしないと思うけど。

これが今の会社の経営陣をちょっと混乱させてるんだよね。会社はシステムのサポート契約にかなりこだわってて、いくつかのこういうトラブルに遭遇してる。昔のOpscodeのChefとか、CentOSの撤退、VMWare、BroadcomのTanzuにあるもっと厄介なこととか。私たちはこれらの会社にお金を払ってた（VMWareを見てると）、または見積もりを探してて、これらの会社にお金を払うつもりだった。でも突然、あなたの構成管理が年間ほぼ6桁のコストになるってどういうこと？基本的なサービスが、基本的なサポート契約で年間中程度の6桁の範囲になるなんて。ちょっと待って、何なの？それに、またVMWareを見てると、結局それに頼れないってこと？私は代わりに財団を支援したり、普段使ってるOSSのメンテイナーや開発者に直接お金を払うことを勧めてるんだ。そう提案すると、みんなの反応が少し静かになってきたけど。次のVMWareにお金を払うよりは、Proxmoxやqemuの開発者を雇いたいな。

└

その企業がOSPOを設立したのは逆説的じゃない？（OSSを正しい/コミュニティの方法でやるために…正しい/コミュニティ志向の人たちと）こういう二重人格的な状況は、大きすぎる組織の代償だと思う。

貢献者やメンテイナーは、小さな会社よりも力が少ないことが多いし、ユーザーはさらに力がない。もし貢献者やメンテイナーが小さな会社のやり方に不満があれば、プロジェクトをフォークすることができる（リベラルライセンスが前提だけど）し、自分たちのやり方で続けられる。Valkeyはいい例だね（Redisが今Valkeyのコードを使えるようになったけど、その逆はできないっていう面白いライセンスのダイナミクスがある）。 > 私たちは、クラウドプロバイダーが提供するものを使うのが一番簡単な世界を作ってしまった。私の意見では、これが最近の開発コミュニティの大きな問題だと思う。私たちは怠けて、無駄なことに集中してしまってる（「きれいな」/使えないUI、ウェブ体操、LLM、「生産性」など）。過去にはOS（さまざまなBSD）、コンパイラ（gccのバージョン）、データベース（MariaDB）をフォークしたり再実装したりするのに問題はなかった。クールなものをハッキングしてる天才たちがたくさんいるけど、残念ながら、さまざまなヒッピーやエヴァンジェリストの声が大きすぎて、彼らの目立ち方を制限してしまってる。 > ただし、これらのプロバイダーは、サービスに変えたプロジェクトに対して貢献しないことが多く、小さな会社を不満にさせている。これらのプロバイダー（AWSなど）がプロジェクトに対して行う重要な貢献は、しばしば見落とされている - 無料の広告だ。確か、ElasticSearchはAWSがサービスとして提供し始めたときに人気になった。さらに、クラウドプロバイダーは通常、カーネルやgcc、jdkに貢献していて、小さな会社はそこから大きな恩恵を受けている。対照的に、彼ら自身はこれを何もできない。だけど、「大きな怖いクラウド」を非難する方が、自分たちのビジネスモデルを見直すよりも簡単なんだよね。正直に言って、最初からクローズにしておけばいい。誰もそれに触れないし、誰もあなたの邪魔をしないから。

AGPLv3を使ってCLAを許可することの倫理について、スタールマンにメールしたんだ。彼の返事はこれだよ: https://news.ycombinator.com/item?id=42601846 君の言いたいことはわかるよ。元の開発者が協力を妨げる行為をすることができるからね。対照的に、普通のGPLのような他のライセンスを使うと、プログラムのユーザーは誰でもその行為を行えるようになる。ひねくれた見方をすれば、それがより公平に見えるかもしれないけど、実際にはもっと有害だと思う。総合的に見て、AGPLを使う方がいいね。

なんで利益を最大化する必要があるの？今の技術で、1日8時間働く必要なんてないよ。生活の質を維持するためには、せいぜい2〜3時間で十分だと思う。むしろ、みんなの生活を楽にするために働くべきだし、もちろん自分の生活もね。

└

政府や中央銀行が通貨を薄めるよりも早くお金を稼ぐ必要がある。まずはお金を修正しないと、他のことは何も修正できないよ。

最近は、プロジェクトのコミュニティを無視して、プロセスが重い「ガバナンスボード」を設置して、技術者たちに自己脱退させるようなことをしてるよね。それから「安全」の名のもとに厳しいオーウェル的な体制を敷いて、クーデターを支持しない人たちからプロジェクトへのアクセスを剥奪したり、さらにひどいことに、反対意見を言う人たちを排除したりしてる。

オープンソースプロジェクトを新しいライセンスに切り替えただけで rug pull するのは無理だよ。オープンソースの本当の問題は、すべての作品を無料で公開しても、普通の開発者の仕事と同じくらいの生活水準を維持できるユートピアに住んでいないことなんだ。それでも、多くの非メンテナが未来の労働を当然のように期待しているのが不思議。メンテナは来ては去るもの。スポンサーシップがなければ、メンテナの寿命は比較的短くなるし、もっと多くの開発者が許可の少ない形で公開するようになるだろうね。

└

同意するよ。正直言って、これはインセンティブの問題だと思う。もし自分がソフトウェアを作ることがあれば、オープンソースにしたいけど、クラウドプロバイダーや誰かが自分の変更を持っていって、何も返ってこないっていう仕組みがあるんだよね… それが FOSS ライセンスの意味なんだけど、社会として人々があまりにも権利を主張しているように感じる。SSPL ライセンスに反対する声もあるけど、開発者が FOSS にフルタイムで取り組みたいなら、SSPL のようなものが良いかもしれないと思う。オープンソースの貢献者は、自分がやっている仕事に対してお金をもらえないから、悲しいことに無料で働いているんだ。自分も SSPL でコードを書き始めるか、もっと好条件のライセンスが出てきたらそっちにするかもしれない。ソース利用可能ライセンスの用語はちょっと変で、要するに大手クラウドプロバイダーが自分のサービスを売れないようにするための一つの条項が、AGPL を FOSS にし、SSPL を FOSS/ソース利用可能にしないっていうのがね。

└

Mojang と Microsoft のバケツコミュニティに関する悪名高い騒動を思い出すよ。彼らはプロジェクトに対してサポートを提供せず、開発者の何人かを雇った後に「秘密裏に」それを取得して、ボランティアが何年も懸命にそれを維持していたんだ。彼が Microsoft のために何年も無料で働いていたことに気づいたとき、彼は正当に憤慨して、CLA がないことや、バケツが最終的に Mojang のサーバージャーにくっついている性質から、DMCA 通知を使ってプロジェクトを閉じることになったんだ。

ほとんどのオープンソースプロジェクトにおいて、私たちはただのタダ乗りだよ。使わせてもらってるけど、何も返してない。オープンソースは公平な交換じゃなくて、贈り物や他人の宿題をコピーすることなんだ。世界に贈り物をしたいなら、それは素晴らしいけど、何も期待せずにやるべきだよ。世の中にはひどい人たちもたくさんいるし、彼らにも贈り物をしていることを忘れないで。考えを変えるのは全然悪くないよ。ソフトウェアベンダーがライセンスを変更することを「rug pull」と呼ぶのは偏った言い方に思える。彼らがくれた贈り物はまだ全部残ってるし、方向転換したのは残念だけど、永遠に続くものはないからね。

└

「私たちは使わせてもらってるけど、何も返してない。」これは厳密には真実じゃないよ。例に挙げたプロジェクトは、コード、テスト、ドキュメント、そして最も重要なのはマーケティングやエバンジェリズムにおいて貢献があったんだ。これらのプロジェクトは、便利だからといって GitHub に置かれたものではなく、関係する企業は採用を促進するために多額の資金を使っていて、通常は開発者エバンジェリストがスタッフとしていて、技術的な利点やライセンスのメリットを話して人々を説得して使わせていたんだ。単なる「贈り物文化」として位置づけるのはナイーブだし、それを「rug pull」と呼ぶのが偏っているとは言えないよ。Redis の場合、会社は明確に Redis コアのライセンスを常に保持すると約束していたけど、結局そうじゃなかった。それが rug pull だよ。コードや他の貢献を受け入れて、他の FOSS プロジェクトにそのプロジェクトに依存させてからライセンス変更するのは rug pull だ。オープンソースを売りにして採用を積極的にマーケティングしていないプロジェクトを見せてくれたら、それは rug pull じゃないと認めるよ。もし Acme Corp が FOSS ライセンスの下で何かの GitHub レポを持っていて、人々が自然に見つけて採用したなら、それはいいけど、そういう例は知らないな。