chardet再ライセンス紛争とReact Foundation創設

2026年3月、OSSエコシステムで性質の異なる2つの出来事が続いた。一方は過去のライセンス決定の法的正当性が問い直される紛争、もう一方は単一企業への依存からの脱却を制度として固める試み。

chardet: オリジナル作者による再ライセンス無効の主張

2026年3月4日、Pythonのエンコーディング検出ライブラリchardetのオリジナル作者Mark Pilgrimが、GitHub issue #327「No right to relicense this project」を開いた。chardet 7.0.0でメンテナーDan Blanchardが主張したLGPL→MITのライセンス変更は法的根拠を欠く、という内容だ。

PilgrimはDive Into Pythonの著者として知られ、MozillaのC++製Universal Character Encoding DetectorをPythonに移植してchardetを作った人物でもある。2011年頃に公のインターネットから姿を消して以来、長らく沈黙していた。その突然の復帰と問題の規模感からHacker Newsで大きな議論に発展した。

chardetの位置づけと依存関係

chardetはPyPIで月間約1.3億ダウンロードを記録する巨大パッケージだ。もともとrequestsの必須依存だったが、requestsはchardetのLGPLライセンスを問題視し、MIT互換のcharset-normalizerへの移行を進めた経緯がある。現在のrequestsではchardetはオプション依存で、charset-normalizerがデフォルトになっている。

とはいえchardet自体の直接利用も膨大で、AI/MLフレームワーク、スクレイパー、APIクライアント、CI環境など広範に使われ続けている。

7.0.0の「完全な書き直し」の実態

メンテナーのDan BlanchardはPR #322で、chardet 7.0.0を「ground-up, MIT-licensed rewrite」としてリリースした。Blanchardは2012年のv1.1以降すべてのリリースを担当してきた人物だ。

書き直しのプロセスについてBlanchard本人がissue #327で説明した内容はこうなる。

まずClaude（Anthropic）のブレインストーミング機能で設計ドキュメントを作成
旧ソースツリーへのアクセスがない空のリポジトリで作業を開始
Claudeに「LGPL/GPLライセンスのコードを参照しないこと」を明示的に指示
結果をレビュー・テスト・イテレーションして完成

リポジトリには設計文書 2026-02-25-chardet-rewrite-plan.md が残っており、各段階の計画が記録されている。Claude Opus 4.6が複数のコミットでco-authorとしてクレジットされており、Claudeはプロジェクトのコントリビューターとして正式にリストされている。

新バージョンは12段階の検出パイプライン（BOM検出、構造プロービング、バイト有効性フィルタリング、バイグラム統計モデル等）を採用し、chardet 6.0.0比で27〜48倍の高速化と96.6%の検出精度を達成した。

コードの類似度について、BlanchardはJPlag（剽窃検出ツール）の結果を提示した。

比較対象	最大類似度
7.0.0 vs 6.x（直前バージョン）	1.29%
7.0.0 vs 1.1（Pilgrim時代の最終版）	0.64%
過去のバージョン間（例: 5.x vs 4.x）	80〜93%

数値だけ見れば、7.0.0は過去のどのバージョンとも全く異なるコードベースになっている。

Pilgrimの反論と「クリーンルーム」の論点

Pilgrimはこれに対して明確に反論した。

彼らにそのような権利はない。これはLGPLの明示的な違反だ。ライセンスされたコードを改変した場合、同じLGPLでリリースしなければならない。

「完全な書き直し」という主張についても「無意味だ」と切り捨てている。メンテナーたちは元のLGPLコードに十分にさらされていた（exposed）のであり、ゼロベースの「クリーンルーム実装」には該当しない、というのが根拠だ。さらに「コードジェネレーターを使ったとしても、追加の権利が与えられるわけではない」とも述べた。

「クリーンルーム実装」とは、著作権のあるコードを見たことがない人間が仕様だけを頼りに独自に実装する手法で、著作権侵害を避けるために使われる。半導体業界でIBM PC互換BIOSを開発したPhoenix TechnologiesやCompaqの事例が有名だ。重要なのは「元のコードに触れていないこと」が前提になる点で、Pilgrimの主張はここを突いている。Blanchardは10年以上chardetのコードベースに浸っていたのだから、クリーンルームとは言えないという論理だ。

加えて、Simon Willison（Datasette開発者）が自身のブログで指摘した重要な事実がある。Claude Codeが作業中にchardetリポジトリ内の metadata/charsets.py を参照した形跡があること、そしてClaude自体がchardetのコードを学習データとして取り込んでいる可能性が極めて高いことだ。

LGPLの伝播ルール

LGPLの伝播がどこまで及ぶかは、そもそも解釈が分かれる領域だ。

flowchart TD
    A["LGPLライブラリを使う"] --> B{"使い方は?"}
    B -->|"動的リンク<br/>(共有ライブラリ .so/.dll)"| C["伝播しない<br/>自分のコードは任意のライセンスでOK"]
    B -->|"静的リンク<br/>(バイナリに組み込み)"| D["LGPLの条件を満たす必要あり<br/>オブジェクトファイル提供 or<br/>リンク手段の提供が必要"]
    B -->|"ライブラリ自体を改変して配布"| E["改変部分はLGPLで<br/>リリースが必要"]
    B -->|"Pythonのimport"| F["法的に曖昧な領域"]
    F --> G["動的リンクに近いという解釈が多い<br/>ただし判例はない"]

C/C++環境では「動的リンクなら伝播しない」という実務上の合意がある程度成立している。FSF（Free Software Foundation）は静的リンクで派生著作物になるという立場だが、裁判所が明確に判断した判例はない。

Pythonの場合、importは実行時にモジュールを読み込む仕組みであり、C/C++の動的リンクに近い。ただしスクリプト言語にはリンクの概念がそもそも当てはまらないため、法的にどう扱われるかは未確定だ。実務的にはPythonのimportは動的リンク扱いで問題ないとされることが多いが、これは慣行であって法的な確定ではない。

chardetの場合に問題になるのは、chardetを静的にバンドルしたり、chardetのコード自体を改変して配布しているケースだ。もし7.0.0のMITライセンスが無効と判断された場合、MITとして組み込んでいたプロジェクトにLGPLの伝播が及ぶ可能性が生じる。

過去の類似判例

ソフトウェアの再実装と著作権をめぐっては、2つの重要な判例がある。

Lotus v. Borland（1996年）では、BorlandがLotus 1-2-3のメニュー階層を独自に再実装した。ソースコードのコピーはなかったが、コマンド名と階層構造はほぼ同一だった。第一巡回区控訴裁判所はメニュー階層を「操作方法（method of operation）」と認定し、著作権保護の対象外とした。最高裁は4対4で割れ、控訴審の判断が維持されたが全国的な判例にはならなかった。

Google v. Oracle（2021年）では、GoogleがAndroid開発のためにJava SEのAPI宣言コード約11,500行をコピーした。最高裁は6対2でGoogleのフェアユース（公正使用）を認めた。APIの「組織的機能」に着目した判断で、APIそのものの著作権性については判断を回避した。

どちらの判例もインターフェースや構造の再実装に関するもので、chardetのケースとは直接一致しない。ただし、「機能的な要素は著作権保護が弱い」という方向性は共通しており、chardet紛争の行方を占う材料にはなる。

コミュニティの議論

この紛争は複数のプラットフォームで活発な議論を引き起こした。

発言者	立場
Simon Willison（Datasette開発者）	「個人的には書き直しは正当だと思う方に傾いているが、双方の主張はどちらも完全に合理的だ」。AIコーディングエージェントが既存の成熟したコードを再実装する場合の縮図と位置づけた
Armin Ronacher（Flask開発者、Sentry）	ブログ記事「AI And The Ship of Theseus」で、テセウスの船のパラドックスに例えた。コピーレフトは著作権との摩擦に依存しているため、AIで簡単に書き直せる時代には実効性が失われるという見解
Bruce Perens（Open Source Definition起草者）	The Registerの取材に「火災報知器を叩き割って引っ張るレベルだ」と危機感を表明。AIによるコード再実装がライセンス体系全体を無効化しうると警告
OSnews	「The great license-washing has begun」を掲載。コピーレフトのコードをAIに入力して別ライセンスで再配布する行為を「ライセンスウォッシング」と命名

issue #327は現時点でオープンのまま。法的な決着がつくかどうかは不透明で、実際に訴訟に発展するかは別の問題だ。

React Foundation: Linux Foundation傘下でMeta主導から脱却

2026年2月24日、Linux Foundation Member Summitにて、ReactとReact Nativeの開発を担う「The React Foundation」が正式に創設された。React、React Native、JSXなどの関連プロジェクトはMetaの所有を離れ、React Foundationが所有する形に移行する。

Reactは2013年にMeta（当時Facebook）がオープンソース公開したUIライブラリだ。コンポーネントベースの設計と仮想DOMで急速に普及し、現在もWebフロントエンドで最も広く使われている。ただ、Metaが単独で開発を主導し続けることへの懸念は以前から存在した。企業の方針転換や優先度変化がReactの行方を左右しうるという構造的な問題だ。

この動きは2025年10月にMetaのエンジニアリングブログで予告されており、2026年2月に正式発足した。

創立メンバーと資金構造

React Foundationの創立メンバー（Platinumメンバー）は8社。

企業	React エコシステムでの位置づけ
Amazon	AWS Amplify等でReactを採用
Callstack	React Native専門の開発会社
Expo	React Nativeの開発プラットフォーム
Huawei	2025年10月の発表後に参加
Meta	React/React Nativeの開発元
Microsoft	React Nativeを多数のプロダクトで採用
Software Mansion	React Native向けライブラリ群の開発元
Vercel	Next.js開発、Reactエコシステムのホスティング

Metaは5年間で300万ドル以上の資金提供と専任エンジニアチームの継続を表明している。他社の出資規模は公開されていない。

ガバナンス構造

flowchart TD
    LF["Linux Foundation"] --> RF["React Foundation"]
    RF --> Board["理事会<br/>Board of Directors<br/>各Platinumメンバーから代表者"]
    RF --> ED["エグゼクティブディレクター<br/>Seth Webster<br/>元MetaのReact責任者"]
    RF --> TLC["暫定技術リーダーシップ評議会<br/>Provisional Leadership Council"]
    TLC --> TG["正式な技術ガバナンス組織<br/>今後数ヶ月以内に移行予定"]
    Board -.->|"技術方針に<br/>直接介入しない"| TLC

Seth Websterはエグゼクティブディレクターを務める。元MetaのReact部門の責任者で、エンジニアリングエグゼクティブとしてのキャリアを持つ。

重要な設計として、Reactの技術的方針は理事会から独立した組織が決定する。現時点では暫定的な技術リーダーシップ評議会が構成されており、今後数ヶ月以内に正式な技術ガバナンス組織へ移行する予定だ。評議会メンバーの個人名はまだ公開されていない。

公式ブログでは「Reactの技術的方向性は、Reactに貢献しメンテナンスする人々が設定する。どの企業・組織も過剰に代表されないことが重要だ」と明言している。

Linux Foundation傘下の他プロジェクトとの比較

Linux Foundation傘下のJavaScript関連プロジェクトとしてはOpenJS Foundation（Node.js FoundationとJS Foundationが2019年に統合）がある。React Foundationが独立のファウンデーションとして設立されたのは、OpenJS Foundationに合流するのではなくReact固有のガバナンスを維持するためだ。

項目	React Foundation	OpenJS Foundation	CNCF（Kubernetes等）
設立年	2026	2019（統合）	2015
主要プロジェクト	React, React Native, JSX	Node.js, jQuery, webpack等	Kubernetes, Prometheus等
技術ガバナンス	暫定評議会 → 正式組織へ	TSC（技術運営委員会）	TOC（技術監視委員会）
スポンサー構造	Platinumメンバー8社	Platinum/Gold/Silver	Platinum/Gold/Silver/End User

Node.jsがLinux Foundation傘下に移ってから10年以上、大手企業の優先度変化にもかかわらず安定した開発が続いている。Kubernetesも同様で、GoogleからCNCFに移管されたことで特定ベンダーへの依存を脱却した。React Foundationはこれらの先行事例と同じパスを辿る。

リポジトリ移行と今後の予定

今後数ヶ月以内に予定されている作業がいくつかある。

GitHubリポジトリ（現 facebook/react）のReact Foundation管理組織への移行
技術的意思決定のための正式ガバナンス組織の確立
Webサイト・インフラのReact Foundation管轄への移管
React Confのキックオフ

コミュニティの反応

コミュニティの反応は概ね好意的だが、懸念もある。HNやRedditで繰り返し出てきたのはVercelの影響力への警戒だ。「Vercelが実質的にReact開発を支配し、Next.jsへの誘導を強化するのではないか」という見方がある。Redditで最も支持を集めたコメントのひとつは「Vercelは事実上Reactを掌握しており、ユーザーをNext.js→Vercelでのホスティングに誘導することが主な関心だ」というものだった。

ただ、React Foundation側はこの懸念を認識した上で、技術ガバナンスをスポンサー理事会から独立させる設計にしている。実際にどこまで機能するかはこれからの運用次第だ。