ラグプル、フォーク、そしてオープンソース封建主義

• オープンソース生態系における権力力学が企業・開発者・ユーザーの間でどのように作用しているのか、そしてそれを揺るがすラグプル（再ライセンス）とフォークという戦術の影響を整理
• 大手クラウドプロバイダーが大きな影響力を持つなか、単一企業中心のプロジェクトは再ライセンスによって権力を再配置でき、それへの対抗としてフォークが登場
• 事例分析ではElasticsearch→OpenSearch、Terraform→OpenTofu、Redis→Valkey、Puppet→OpenVoxなどで、それぞれ異なるコミュニティ再編とコントリビューター移動のパターンが見られる
• CLA採用、単一企業による支配、財団への移管時期などはラグプルの危険信号として示され、中立的ガバナンスと複数組織による貢献層の拡大が対策として推奨される
• 結論として再ライセンスはクラウドへの牽制手段になり得る一方、コントリビューターの権限も同時に弱め、フォークの可能性が企業の意思決定に対する抑止力として機能する

---

オープンソースにおける権力構造とラグプル、フォーク

• オープンソースソフトウェア生態系では、大企業、中小企業、コントリビューター、ユーザーなどがそれぞれソフトウェアの方向性と収益構造に影響を与えるための権力を行使している
• とくに大手クラウドプロバイダーがかなり大きな力を持つようになり、中小企業やコミュニティより優位に立つ傾向がある
• このような状況で、開発元またはプロジェクトを所有する企業がソフトウェアライセンスを変更（ラグプル）したり、逆にコミュニティまたは他企業がフォークを進めたりすることで、権力移動が起こる

権力力学と戦術の概観

• オープンソースの世界では、大手クラウドプロバイダーが最も強いチャネル・配布の権力を行使し、中小企業やコントリビューター、ユーザーを搾取する構造が形成される
  • 封建主義時代の土地支配のように、クラウドプロバイダーはオープンソースソフトウェアをサービス化しながら貢献を回避する
  • 開発作業の大半は中小企業が担うが、クラウドプロバイダーによる無償利用のため不利な立場に置かれる
• ラグプル戦術として中小企業がソフトウェアを再ライセンスしてクラウドプロバイダーに対抗するが、これはコントリビューターやユーザーにより大きな被害をもたらす
  • クラウドプロバイダーがプロジェクトをサービス化しながら貢献しないことで、中小企業の権力が弱まる
  • 再ライセンスによってユーザーに不利益が生じるが、フォークを通じて権力バランスを再調整できる
• 単一企業主導のプロジェクトではラグプルのリスクが高く、企業の評判評価が必要だが、M&Aや倒産によって無意味になることもある
  • 投資家の圧力により、収益拡大のための再ライセンスが発生し、特にクラウドプロバイダーと競合する場合により頻繁となる
  • より制限的なライセンスによって他社の収益化を難しくし、権力移動を試みる
• ラグプルによって生じるフォークの生成は、反乱的な集団行動として権力回復の手段となるが、人員と資源の不足で失敗するリスクも大きい
  • 大企業やクラウドプロバイダーが資源を使ってフォークを支援できるが、人気のあるフォークが常に成功するわけではない
  • MongoDBやSentryのようにフォークが起こらなかった例もあり、PerforceによるPuppet買収後の開発非公開化がOpenVoxフォークを引き起こした

主な事例比較

Dawn Fosterはさまざまなラグプル、フォーク、そしてその後の影響をデータによって分析している。（Jupyterノートブックのデータセットとして結果の一部を公開）

• Elasticsearch → OpenSearch
  • 2021年のElasticによるSSPLへの再ライセンス後、AWSがOpenSearchフォークを組織した
  • Elasticでは社内コントリビューター比率がフォーク前後で大きく変わらず、OpenSearchではAmazon主導の貢献が継続している傾向が見られる
  • 2024年のLinux Foundationへの移管後も、外部貢献の急増は観察されなかったという分析である
• Terraform → OpenTofu
  • 2023年のHashiCorpによるBSL移行の直後、OpenTofuがLinux Foundationの下で発足した
  • Terraformは依然として社内中心の貢献を維持した一方、OpenTofuには複数企業からの新規コントリビューターが急速に流入した
  • この事例は、ユーザー主導のフォーク + 中立財団の発足が活発なコミュニティ形成に有利だったことを示唆する
• Redis → Valkey
  • 2024年のRedisによるSSPL移行直後、既存の外部コントリビューターの多くがValkeyへ移った
  • Redisはフォーク前に外部貢献比率が高かった例外的なケースであり、フォーク後は外部貢献が0へ急減し、Valkeyは複数企業連合のコミュニティとして出発した
• Puppet → OpenVox
  • Perforceによる買収（2022年）後、開発・リリースの非公開化とリリース頻度の縮小が起こり、それに対応してコミュニティがOpenVoxフォークを推進した

データ観察とメトリクス

• ラグプル後にはGitHubのフォーク数急増がよく観察され、これはハードフォーク検討の動きに対するプロキシ信号と解釈される
  • 長期的には本流とフォークが並行して前進する傾向があるが、再ライセンスされた本流は利用減少の傾向が観測されるという分析である
• 財団の傘下での立ち上げは新規プロジェクト初期の貢献獲得に有利だが、事後的な移管は効果が限定的な可能性がある
  • OpenSearchの事例は、移管だけで外部貢献の急増が保証されるわけではないことを示唆している

危険信号とガイドライン

• CLA（Contributor License Agreement）の使用は、企業に再ライセンス権限を集中させて権力の不均衡を拡大するシグナルである
  • DCO（Developers Certificate of Origin）ベースのプロジェクトは、比較的ラグプルのリスクが低い傾向にある
• ガバナンスの点検が必要であり、単一企業による支配とリーダーシップの偏在はリスク要因である
  • 中立財団、複数組織のリーダーシップ、外部貢献の裾野を持つプロジェクトは、持続可能性の面で有利である
• コントリビューター基盤の幅と深さも重要な評価項目である
  • 企業は依存しているプロジェクトに直接コントリビューターを送り込むことで、影響力と持続可能性を同時に強化する必要がある
  • CHAOSSのメトリクス・プラクティショナーガイドは、プロジェクトの健全性診断・改善に活用できる

コミュニティ・ガバナンスへの提言

• 中立的なガバナンス体制への誘導と外部コントリビューターの拡大が、ラグプル抑止の実効的な手段である
  • フォークの可能性そのものが、企業の再ライセンス決定コストを高め、抑止力として作用する
• Hazel Weaklyの安全装置に関する問いに対し、発表者はValkey・OpenTofuの成功が再ライセンス再考を促した実例に言及している
  • Dirk Hohndelは、より多くの外部コントリビューターを呼び込むことがラグプルのリスクを高め、経営判断上のリスクを大きくすると強調した

結論

• 大手クラウド事業者の影響力が高まるなか、オープンソース生態系は次第に封建主義的な構造へと変化している
• ライセンス変更はクラウド事業者の力を牽制するが、その過程でコミュニティコントリビューターの権限が弱まる副作用が生じる
• しかしコントリビューターとユーザーには、フォークという反撃手段が存在し、これは封建時代とは異なるオープンソース固有の力である
• フォークの現実的な可能性は企業の将来の政策決定に影響を与え、実際にValkeyやOpenTofuの成功事例に刺激されて一部企業がラグプル計画を撤回したケースもある
• 最終的に、プロジェクトのガバナンス中立性と外部コントリビューター活性化が、ラグプル防止と健全な生態系維持の鍵である

参考資料

• 発表スライド: Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

フォークがまだ簡単ではない状況なので、オープンソース関連団体の中にこれを手伝ってくれるところがあればいいですね。

[GN⁺]

Hacker Newsのコメント

• CLA（Contributor License Agreement）を使うプロジェクトでは rug pull（貢献者の努力が少数によって私有化される現象）がより頻繁に起きる一方、DCO（Developers Certificate of Origin）を使うプロジェクトではこうした不均衡が少ない、という指摘。CLAに署名すると、プロジェクトに自分の貢献コードを再ライセンスする権利を与えることになる。つまり、GPLプロジェクトにGPLの貢献をしても、ライセンス変更が可能になる。すでにパーミッシブライセンスであればCLAの影響は大きくないが、コピーレフト（例: GPL）の場合は、CLAに署名した側だけが排他的所有を可能にできるため不公平になる。rug pullを防ぐには、コピーレフトライセンスを使い、CLAへの署名を避けるのがよい。パーミッシブライセンスでは rug pull は「ゲームの一部」だと理解すべき
  • GNUプロジェクトもCLAを要求するが、彼らが rug pull を意図してそうしているわけではないだろうと思う
  • CLAへの署名が必ずしも再ライセンス権全体を与えるわけではなく、CLAごとに異なることを明確にしておきたい。たとえば Canonical の CLA（リンク）の条項では、自分の貢献は既存ライセンスのままでも提供されることが約束されている。CLAを読んで理解することが重要。ほとんどのCLAでは著作権は貢献者に残るので、自分の貢献を自分の望むように扱う権利は残る。根本的な問題は、プロジェクトオーナーへの信頼が損なわれうること。CLAはオーナーに統制権を与えるため、rug pull のリスクを高める。rug pull に対処するには、実際にはフォークして自分たちで協業しないと利益は得られない。コピーレフトライセンスにCLAが加わった場合（例: AGPL + CLA）は、むしろパーミッシブライセンス + CLA より有害になりうる。AGPLはサービス提供でもソース公開義務が生じるが、CLAによってオーナーはクローズドなサービスを運営しつつ改善点を公開しなくてよくなるため。実際に Incus と LXD の事例のように、ライセンスの組み合わせとCLAによってコミュニティ分裂やコード共有の制限が起きた経験がある（詳細事例の記事）
  • オープンソースに rug pull という現象は存在しないという見方。GPLのコピーは永遠に残る
  • パーミッシブライセンスを使うと rug pull の可能性は高くなるが、CLAが常にすべての権利を与えるわけではないという指摘
  • 「rug pull」という否定的な言説をオープンソースに対して過度に純粋主義的に適用するのは健全ではないと思う。プロジェクトは持続可能でなければならない。大手クラウド事業者がインフラを独占している状況では、小さな開発者がオープンソースやCLAベースのプロジェクトで争うより、そのエネルギーを大企業の独占緩和に注ぐほうがよいという考え
• コントリビューターとメンテナーは、小規模企業よりもさらに力が弱いことが多い。それでもリベラルなライセンスなら、不満があればフォークして新しい道を進める。Valkey の事例のように、Redis をめぐるダイナミックなライセンス変化は興味深い。開発者コミュニティ全体として、最近はクラウド提供サービスに安住し、かつてのようにOS、コンパイラ、DBなどを新たにフォークしたり実装したりする積極性が不足しているのが問題だと感じる。AWS のようなクラウド企業がサービスとして提供することでプロジェクトの認知度を高めてきた点も、しばしば見落とされる（例: ElasticSearch は AWS 提供後に人気化）。クラウドが kernel、gcc、jdk などに貢献することで、小規模企業も間接的に利益を得ている。安易に大手クラウドだけを責めるのではなく、ビジネスモデルそのものを見直したほうがよい。最初からクローズドで始めていれば誰も気にしなかったはず
• 使うソフトウェアをバイナリで受け取るのではなく、ソースコードから自分でビルドすれば、rug pull のような出来事への対応力が上がる。ベンダーのバイナリ/イメージでインストールする利用者はフォークへの移行が難しいが、ビルド基盤を新しいソースに切り替えるのは比較的簡単。必要な修正や機能を自分で反映して使えるので、保守依存が減る
  • Guix を好む理由がまさにこの仕組み。ソースビルドが基本で、キャッシュを通じてバイナリパッケージも提供される。バイナリがなければ自分でソースを再現可能にビルドする。パッチ版も同じパッケージマネージャーで簡単にインストールでき、別途ビルド基盤は不要。大規模配布環境ならビルドサーバーを置くほうが効率的
  • なぜ反対票があるのかわからないが同意する。ソースビルドはたいていそれほど難しくない（sqlite 参照）
  • 実際にはソフトウェアライセンスによって制限が異なる点も指摘されている。商用ソフトウェアでもソースを提供するものはあるが、ライセンス上自由に加工できない場合が多い。たとえばスクリプト言語ベースの商用製品や、企業向けコンサルティングで顧客にソースを渡してもコンパイル権限は別料金という事例がある
• Elasticsearch の rug pull 後、Amazon が自らオープンソースフォーク（OpenSearch）に貢献するようになったのは、当初の意図とは違っていても、ある程度の成果と見なせる。しかし、大企業が貢献者と受益者の不均衡によってプロジェクトの不安定性を招くことも重要な論点
  • ライセンス順守の範囲でソフトウェアを使うこと自体は問題ではなく、むしろ開発者やスタートアップが普及と成長だけを見てパーミッシブライセンスを活用し、大手クラウドが参入した段階で問題視するのは自己矛盾だという見方。両取りはできない
  • Elastic が望んだ結果はライセンス売上の増加だったが、多くのユーザーがフォークへ移行し、Elastic への信頼低下が起きた。むしろ OpenSearch と ElasticSearch の競争はエコシステムにとってプラスかもしれないが、いまや両製品は互換性が失われ、Elastic の立場も弱まっている
  • AGPL/GPL のようなコピーレフトライセンスは、独占ライセンスがなくてもコード貢献を強制することでフィードバックループを作れる
• オープンソースプロジェクトは、ライセンスを変えただけで rug pull が簡単にできるわけではない。もっと根本的な問題は、誰もが無償で働いても十分な生活の質を保証されるようなユートピアではないという現実。メンテナーがいなければプロジェクトの半減期は短くならざるをえず、スポンサーシップがない限り、よりクローズドなライセンスへの移行は加速するだろう
  • Mojang/Microsoft と Bukkit コミュニティの事例を思い出す。開発者の雇用過程でプロジェクトをひそかに買収し、ボランティアが何年も無報酬で働く状態にした末、その人物が DMCA を使ってプロジェクトを停止させた。詳しい事例: blog
  • 結局はインセンティブの問題。自分でオープンソースソフトウェアを作っても、クラウド事業者が簡単に持っていって収益化できる。FOSS（Fully Open Source Software）ライセンスの構造がそういう意味だとは理解しているが、社会が無償労働に慣れすぎていると感じる。だからこそ SSPL（Source-available licensing）のような新しい方式が次第に魅力的になるのだろう。条項が一つ違うだけで AGPL は foss、SSPL は foss ではないというのは、用語として混乱を招くと感じる
• rug pull に落胆するユーザーの気持ちは理解できるが、実際にプロジェクトを主導して開発・保守する会社にも財務的な限界があり、選択肢は限られる。収益モデルがなければライセンス変更も避けられない。代案として、クラウドファンディング、作業量の縮小、グッズ販売、追加資金がなければクローズド化すると事前告知することなど、いくつかの可能性が考えられる。関連記事
  • 不満の本質は、OSSとして公開してユーザーを増やしたあとで、突然ライセンスをクローズド寄りに変えたことにある。最初からOSSでなければ裏切られた感覚もなかっただろうが、ユーザー獲得のためにOSSで始め、後から変更したことが問題
  • Mongo、Elastic、Redis、Hashicorp などは、rug pull の時点でも深刻な資金難だったわけではない。Hashicorp の場合は買収価値を高める戦略だった可能性もある
• 最近は、ガバナンスボードの設置や規制を強めた運営方針などを掲げて、技術者が自発的に離れるよう誘導したうえで、反対意見を抑圧し、プロジェクト権限を取り消す事例が増えている。実際に「安全性」を掲げたオーウェル的な雰囲気がコミュニティに持ち込まれている
• ほとんどすべてのオープンソース利用者はフリーライダーだ。私たちはプロジェクトに何の貢献もしないまま自由に使っている。オープンソースは見返りのない贈り物、あるいは他人の宿題を参考にする文化とも言える。世の中に貢献したいなら喜んですべきだが、どんな報酬も期待すべきではない。ライセンス変更を rug pull と表現するのも偏った見方だ。いずれにせよ、私たちはすでにコードを受け取っており、方向性が変わったのは不幸でも、世の中に永遠のものはない
  • 「私たちはたいてい何も返さずに使っている」という主張は完全には事実ではない。実際には多くのプロジェクトで、コード、テスト、文書、マーケティング、エバンジェリズムなど幅広い貢献が行われてきた。こうしたプロジェクトは、GitHub に偶然置かれた静かな開発物ではなく、企業が多額の費用を投じて積極的にデベロッパーアドボケイト（エバンジェリスト）を雇い、技術やライセンスの利点を広めてユーザープール拡大に努めてきたものでもある。そうした環境で大規模にコードや貢献を受け入れておきながら、突然ライセンスを変更し、他の FOSS プロジェクトが依存している時点でその約束を破るから rug pull だと批判される。もし別途マーケティングもなく、GitHub に偶然公開されて自然に採用されたプロジェクトなら、rug pull 論争の対象にはならないだろう。しかし、そのような例はほとんど見たことがない
  • 必ずしもそういう構造である必要はない。企業や資金力のある主体が、自ら依存するオープンソースプロジェクトに財政的・技術的貢献を行い、持続性を高めることはできる。Open Source Program Office の設置、利用しているすべてのソフトウェアと依存関係の分析、貢献者の時間投資や資金支援、同業他社にもこうした文化を促すといった方法がある
• 現在勤めている会社でも rug pull 問題のために運営陣が混乱している。これまで常にシステムのサポート契約を重視してきたが、Chef、CentOS、VMWare、Broadcom などで似た状況が繰り返されている。費用を払って使うつもりだったのに、基本的な保守サービスだけで年間数千〜数万ドルに達し、それでも信頼できない。こうした状況では、むしろ財団を支援したり、定期的に OSS メンテナーを直接雇用したりするほうがよいと感じる。以前はそうした提案に懐疑的だったが、徐々に支持が高まっている。個人的には VMWare に費用を払うより、Proxmox か qemu の開発者を雇いたい
  • 正しい発想だと思う。使っているすべてのソフトウェアと依存関係を見直し、開発時間や資金の貢献を通じて持続可能性を確保し、同業界にこうした姿勢を広めることが重要
  • 興味深いことに、挙げられた企業はコミュニティ重視を目指してオープンソース・プログラム・オフィスを作ったが、組織が大きくなりすぎると二重性（コミュニティと企業利益の乖離）が生じるのは当然の代償だと感じる
• フォークは簡単ではなく、人とリソースがあって初めて成功する。オープンソースは結局、貢献者が多いときにだけ機能する仕組みだ。もしフォークが死ぬなら、そのプロジェクトにはフリーライダーが多すぎたということになる。rug pull の最大の問題は、実質的には虚偽広告だという点だと思う。オープンソースとして顧客を集めておきながら、自分に不利になるとその約束を破るのは道義的に問題がある。しかし、貢献停止そのものは心配していない。誰にも永遠にプロジェクトに残る義務はないので、個人や企業がやめるのも自然なことだ