■ 1. 本稿の概要と分析範囲
- AIによって既存ソフトウェアとほぼ同じ機能を再実装しライセンスを変更する「ライセンスウォッシュ」とも評され得る行為の是非が本稿の主題
- 対象事案はPythonの文字エンコーディング検出ライブラリchardetにおいて2026年3月に起きたAI支援による再実装とGNU LGPLからMITライセンスへの変更
- 分析の対象はリリースノート・再実装プラン・イシューその他の公開ファイルの外形に限定しソースコード全体の実質的類似性の精密比較は行わない
- 本稿は確定的な法的結論ではなく公開資料から見える範囲での法的・実務的な整理である
■ 2. chardetで実際に起きたこと
- chardetはPythonの文字エンコーディング検出ライブラリであり2006年の1.0がMozilla系の実装をPython 2に移植したものであり原作者はMark Pilgrim（以下Mark）
- 2026年2月22日に6.0.0がリリースされ依然としてGNU LGPLが適用されていた
- 2026年3月2日に7.0.0がリリースされ「Ground-up MIT-licensed rewrite of chardet. Same package name same public API」と説明されGNU LGPLからMITライセンスへ切り替えられた
- 2026年3月4日には7.0.1が通常のバグ修正・改善リリースとして公開され7.x系は継続的な開発として位置づけられている
- 現在のメンテナーDan Blanchard（以下Dan）の主張は「同じpublic APIを持つ別実装を一から作ったのだからMITライセンスとして扱える」というもの
- 2026年3月4日にMarkがイシューを立て自らをchardetの原作者と名乗ったうえでrelicenseする権利はなくGNU LGPLへの明示的違反であると主張した
- Markはこれをclean room implementationではないと述べ元のライセンスへ戻すよう求めた
- イシューは2026年3月9日時点でOpenのままでありAssigneeもMilestoneも付いていない
■ 3. 問題点の整理
- 本件の中心的論点は著作権侵害であり7.0.0が旧chardetのderivative work（派生物）に該当するかが核心的争点
- 著作権侵害以外にLGPLを契約と捉えた場合の契約違反やコモンロー上の商標権・不正競争の観点での主張も考え得る
- 7.0.0が旧著作物の複製でも翻案でもない独立実装であればLGPLの拘束をどこまで及ぼせるかは難しくなる
- 複製または翻案が認められればLGPLは一気に重く効いてくる
■ 4. 依拠性から見た評価
- 著作権侵害成立の検討にあたっては日本法では「依拠性」と「類似性」米国法では「access copying substantial similarity protectable expression」が核心的判断軸となる
- 米国法では17 U.S.C. §102(b)によりソフトウェアのアイデア・手順・プロセス・システム・操作方法そのものは保護対象外であり保護されるのは表現のみ
- 依拠性についてはMark側の主張がかなり筋が通っている:
- rewrite planのTask 3においてchardet 6.0.0のcharsets.pyをauthoritative reference（権威ある参照）として使う指示が明記されている
- scripts/utils.pyではtests/dataを旧プロジェクトのtest-dataリポジトリからshallow cloneする仕組みが採用されている
- test-dataリポジトリのREADMEにはライセンスの問題が発生する可能性を認識した記述があり再実装側がライセンス問題を意識していたことが示される
- Dan自身は「古いソースツリーにアクセスできない空のリポジトリから作業を開始しClaudeにはLGPL/GPLライセンスのコードをベースに一切作業を行わないよう指示した」と述べているがrewrite plan側で旧版を参照している以上依拠がないとは言い難い
- AIのトレーニングデータとして旧chardetが含まれていた可能性があり慶應大学の奥邨教授が指摘する「二段の依拠」という観点からもクリーンルーム実装が成り立たないという考え方がある
- 公開資料だけでも旧プロジェクトへの接触と参照は確認でき強い意味でのクリーンルーム実装と呼ぶことは困難
■ 5. 類似性から見た評価
- 米国法における著作権侵害判断では保護される表現の取り込みが必要であり単にプログラムの論理構造や機能が似ているだけでは侵害とはならない
- Computer Associates v. AltaiのAFCテスト（抽象化・濾過・比較テスト）によれば保護されない要素を先に除いた上で類似性を判断する
- rewrite planで参照が指示された旧6.0.0のcharsets.pyはCharsetデータクラスにname is_multi_byte encoding_era language_filterを持つメタデータ表であり新7.0.0のregistry.pyはEncodingInfoにera is_multibyte python_codec languagesなどを持つより拡張された構造になっている
- charsets.pyの多くはメタデータの表であり事実に近い性質のものであるが選択・分類・割当に創造性が認められれば類似性判断が成立する余地はある
- Dan側はJPlagを使用した分析により7.0.0と過去バージョンの最大類似度は1.29%であり他バージョン間の43%から93%と比較して定量的には類似性が低いと報告している
- コード全体の類似性評価では独立実装と受け取ることが可能であるが著作権上はごく一部の保護される表現の取り込みでも侵害が成立し得る点に留意が必要
- 保護される表現の取り込みの程度については公開資料のみでの判断には限界があり法的な観点からの専門的なコード比較分析が必要
■ 6. 結論 - 法的評価
- 公開資料からの暫定評価として本件は「独立実装と断言するには苦しいが直ちに著作権侵害と断定するには足りない」事案
- Mark側に有利な材料:
- rewrite planで旧charsets.pyをauthoritative referenceとして使う指示があることはクリーンルーム実装の主張を弱める
- 少なくともaccessおよび依拠性に近い事情についてはMark側の主張の方が説得力がある
- Dan側の反論として有効な材料:
- charsets.pyは6.0.0系リリースにてDanが新規作成・整備したファイルでありDan自身の著作物と主張し得る
- 旧版参照は機能互換やデータ整合のための参照に過ぎず保護される表現の取り込みを意味しないという反論が可能
- 再実装において保護される表現は含まれていないという反論もできる
- ただしcharsets.pyが旧著作物に依拠したderivative workであればDanに認められるのは新規付加部分に限られ既存権利者の権利を消すことはできない
- 仮に著作権侵害が全面否定されてもLGPL 2.1の受諾を前提とした契約論での争点も残り得る
- Artifex v. HancomやSFC v. VizioなどGPL/LGPLをめぐる法的争点事例が参照される
- 明確に言えることは今回の再実装は強い意味でのクリーンルーム実装とは言い難いということであり法的確定判断には専門的分析が必要
■ 7. 結論 - コミュニティ運営および倫理面の評価
- 同じリポジトリ名・頒布経路を維持できることと旧プロジェクトの実装全体を自己の判断だけで再ライセンスできることは別問題
- 仮に法廷で著作権侵害が認められなかった場合でも同じ機能を持つ全く異なるソフトウェアを同名の同一プロジェクトのアップデートとして扱うことの妥当性が自動的に正当化されるわけではない
- Markの異議表明後も7.0.1が継続リリースされており現時点ではMarkの主張が受け入れられないまま新系統がプロジェクトの後継を名乗って走っている状態
- AIによる全面的な再実装を行い内部アーキテクチャも完全に変えライセンスまでコピーレフトからパーミッシブへ変更するのであれば別のツールとしてリリースすべきであった
- どうしても同じプロジェクト名を維持するなら少なくとも元のライセンスへ戻す方向が混乱を最小化する選択であった
■ 8. AI再実装に関する今後の論点と提言
- AIによる再実装はこれから激増すると考えられるが既存のプロジェクトを同名のままアップデートとしてリリースすることの適否はその事実とは別問題
- コピーレフトからパーミッシブへの変更が歓迎される側面があるとしてもオープンソースから非オープンソースへの再実装も同じ手法で可能になることへの認識が必要
- AIによる全面的な再実装は原則として別ツールとして扱うべきであり人間による継続的開発物とAIによる別実装を同じプロジェクトの同じリリース系統の下で混ぜるべきではない
- AIによる全面的な再実装を既存プロジェクトの後継としてリリースする場合には以下の情報を公開時点で明示する説明責任がある:
- コードの来歴
- 参照した旧資産の範囲
- ライセンス変更の根拠
- 旧権利者との関係
- 互換性と非互換性の範囲