AIによって特定のソフトウェアとほぼ同じ機能を再実装させ、その結果としてライセンスまで変える、いわゆるライセンスウォッシュとも評され得る行為ができるのか？という論点は以前から繰り返し語られてきた。しかし、研究目的の再実装の議論はさておき、これまでは実際に実用的なツールで大規模な再実装が行われ、しかも同じプロジェクト名のままライセンス変更まで行われた事例はほぼなかったと思う。ところが、2026年3月、Pythonの文字エンコーディング検出ライブラリであるchardetにおいて、まさにそのような事態が起きたのである。公開文書上においてchardet 7.0.0はAI支援による「Ground-up, MIT-licensed rewrite」(MITライセンスによる最初からの書き直し)と位置付けられ、従来のGNU LGPLからMITライセンスへと切り替えられている。そして、chardetの原作者を名乗るMarkがそのライセンス変更に異議を唱え、そこを起点として大きな騒動となっている。本稿では、そのライセンス変更の是非を中心に分析する。
なお、本稿は公開されたリリースノート、再実装プラン(rewrite plan)と再実装デザイン(rewrite design)、イシュー、その他の公開ファイルの外形のみに基づいて整理する。ソースコード全体の実質的類似性を精密に比較し、分析するものではない。したがって、本稿は確定的な法的結論ではなく、公開資料から見える範囲での法的・実務的な整理であることに注意してほしい。
English Version: https://shujisado.org/2026/03/10/can-you-relicense-open-source-by-rewriting-it-with-ai-the-chardet-7-0-dispute/
chardetで実際に起きたこと
chardetはPythonの文字エンコーディング検出ライブラリであり、公式Changelogでは、2006年の1.0が「Python 2 port of Mozilla’s universal charset detector」と説明されている。つまり、元々の出発点はMozilla系における実装を移植したものであり、その原作者はMark Pilgrim(以下Mark)である。
その後、プロジェクトは長く維持され、直近では2026年2月22日に6.0.0がリリースされている。6.0.0では依然として旧系統のchardetであり、7.0.0のリリース文書でも「previous versions were LGPL」と明記されている。そして、今回の問題となっているAIによる再実装版である7.0.0は2026年3月2日にリリースされ、その直後の3月4日には 7.0.1 も通常のバグ修正・改善のリリースとして出されている。つまり、7.x系は単発の実験ではなく、そのまま継続的なリリースとして開発されている。
問題の7.0.0について、公開されたChangelogとREADMEでは非常に率直に説明されている。そこでは7.0.0を「Ground-up, MIT-licensed rewrite of chardet. Same package name, same public API」と説明し、同じ名称、同じAPIのままMITライセンスへ切り替えたことを前面に出している。AIへの指示となるrewrite planにも、目的として「Build a ground-up, MIT-licensed, API-compatible replacement for chardet 6.x」と明記されている。現在のメンテナーであるDan Blanchard側(以下Dan)の公開文書から読み取れる基本線は、「同じpublic APIを持つ別実装を一から作ったのだからMITライセンスとして扱える」というものである。
これに対し、2026年3月4日、Markはプロジェクトにイシューを立て、自らをchardetの原作者だと名乗ったうえで7.0.0の現在のメンテナー陣に “relicense”(再ライセンス)する権利はなく、これはGNU LGPLへの明示的違反であると主張した。さらに、メンテナー陣側は旧コードに十分接してきたのであり、これはclean room implementation(クリーンルーム実装)ではないとも述べ、元のライセンスへ戻すよう求めている。イシューは2026年3月9日時点ではOpenのままであり、AssigneeもMilestoneも付いていない。原作者であるMarkは、公開タグ上では2008年の1.0.1までは関与が確認でき、少なくともMarkの原始的寄与部分について著作権が残っている可能性が高い。
* note: GitHub上でMarkを名乗るアカウントは、ほぼ空の状態であり、本人であるかどうかを確認できず、また、Mark Pilgrimは2011年にインターネットの公的活動から引退しているとされるが、ここでは本人が投稿したとみなして分析する。
問題点の整理
原作者のMark側の視点から見ると、まず中心に来るのは著作権侵害である。7.0.0が旧chardetの複製または翻案、米国法で言えば“derivative work”に該当するのであれば、LGPLの射程の枠外に出てMIT化したという説明はかなり苦しくなる。LGPL 2.1自体も、許諾の範囲外でLibraryやその”derivative works”を複製、改変、再ライセンス、頒布してはならず、そのような試みは無効で権利は自動終了すると定めている。また、Libraryまたはそれに基づく”work”を改変・頒布することでライセンスを受諾したものと扱っている。
もちろん、この著作権侵害以外に原作者側からは、LGPLを契約と捉えた場合の契約違反、さらにはコモンロー上の商標権や不正競争観点での名称使用や継続性に関する別の主張も考え得るのだが、本件ではDan側が「全部書き直した独立実装だ」と主張し得る以上、結局のところ著作権侵害の有無が本丸である。契約論は補助線にはなり得るが、7.0.0が本当に旧著作物の複製でも翻案でもない独立実装ならば、LGPLの拘束をどこまで及ぼせるかは急に難しくなる。その逆に、複製または翻案が認められれば、LGPLは一気に重く効いてくることになる。
その意味で、本稿では本件の中心を著作権侵害とすることを前提とした検討を行う。
rewrite planと公開ファイル外形から見た再実装過程
著作権侵害の成立を検討することになるが、自分はソースコード解析の専門家ではないということは先に明らかにしておく。本件は、突き詰めるとComputer Associates v. Altai で確立されたAFCテストのような分析が必要なのだと思うが、そこまではコード比較の専門領域であり、自分が口を出すところではないだろう。したがって、ここでは公開されているrewrite planとその他のファイルの外形から見て、依拠性の事情がどこまで見えるか、そして類似性の推認がどこまで可能かを整理するに留める。
依拠性から見た評価
日本法では、著作権侵害成立の検討において最高裁判例に基づいた「依拠性」と「類似性」の判断が整理軸となっている。一方、米国法においてはもう少し段階が細かく検討され、“access, copying, substantial similarity, protectable expression”(依拠、事実上の複製、実質的類似性、保護されるべき表現)に分かれて語られるのだが、実務的にはやはり「元の著作物に接してそれを土台にしたのか？」「著作権保護される表現を取り入れたのか？」が核心的な侵害成立要件である。そして、米国法では17 U.S.C. §102(b)により、ソフトウェアの“idea, procedure, process, system, method of operation”(アイデア、手順、プロセス、システム、操作方法) そのものは保護対象外であり、保護されるのはあくまで表現のみである。Google v. Oracleなどの一連の訴訟においても、その制約がソフトウェアの著作権侵害を語る上で重要であることを改めて示している。
それらを踏まえ、公開されている再実装に使用したrewrite planの内容を見ていくと、依拠性については原作者であるMark側の主張がかなり筋が通っているように見える。Task 3のEncoding Registryにおいては、“Era assignments MUST match chardet 6.0.0’s chardet/metadata/charsets.py”(eraの割り当てはchardet 6.0.0の chardet/metadata/charsets.py と一致する必要があります) と書かれ、さらに “Fetch that file and use it as the authoritative reference”(このファイルを取得し、正式な参照として使用してください)、“Reference the chardet 6.0.0 charsets.py file … for the complete list of encodings and their era assignments”(エンコーディングとそのeraの割り当ての完全なリストについては、chardet 6.0.0のcharsets.pyファイルを参照してください) とまで記されている。つまり、少なくともregistry.py周辺については、旧版のcharsets.pyを明示的に見て、それを権威ある参照として一致させる指示が存在する。これはクリーンルーム実装の主張をかなり弱める材料となる。
さらにrewrite planには、テストデータ取得を行う手順も存在する。最終的な7.0.0のscripts/utils.pyでは、tests/data を https://github.com/chardet/test-data.git から shallow clone する仕組みになっており、その test-data リポジトリの README には、データは “pulled out into its own repo since licensing can be an issue”(ライセンスの問題が発生する可能性があるため、独自のリポジトリにまとめました) とされ、各testファイルはそれぞれのパブリッシャーの著作権だと記されている。ここから分かるのは、少なくとも再実装したメンテナー側自身がtest dataのライセンス問題を意識していたということである。
なお、Dan自身は再実装プロセスについてMarkのイシューへのコメントにて丁寧に説明しており、その中で「古いソースツリーにアクセスできない空のリポジトリから作業を開始し、ClaudeにはLGPL/GPLライセンスのコードをベースに一切作業を行わないよう明確に指示した」と述べている。確かにrewrite designの中ではそのような指示があるが、rewrite plan側で参照する以上は依拠がないとは言いにくい。
また、そもそも論となるが、AIがトレーニングデータとして利用していた可能性も考慮の余地があるだろう。Anthropicの公式文書では、Claudeはインターネット上の公開情報を含む混合データで訓練されたと説明されている。一方、個別のトレーニングデータセットは公開されていないため、GitHub上で公開されていたchardetのコードが学習対象に含まれていたかは確認できないものの、その可能性自体を否定することもできない。日本では慶應大学の奥邨教授によって人間による依拠とAIによる依拠という「二段の依拠」というフレーズで説明されているが、AI自身が既にそのコードでトレーニングされているのであれば既にそのコードへ依拠しているのであり、クリーンルーム実装が成り立たないという考え方もあるだろう。
これらの事実を総合すると、再実装が元の実装を依拠していないとまでは言いにくい。公開資料だけでも、旧プロジェクトへの接触と参照はかなり見えており、自分の感覚としてはこれを強い意味でのクリーンルーム実装と呼ぶのは無理がある。一般にクリーンルーム実装とは、少なくとも元実装の表現に直接触れない形で仕様化と実装を分離するものであり、その意味でも今回のrewrite planはその主張を弱めていると言えるだろう。
類似性から見た評価
もっとも、依拠性が強く見えることと直ちに著作権侵害が成立することは別問題である。米国法における著作権侵害の判断は日本法より厳密であり、何が保護される表現なのかを細かく見る。Feist v. Ruralでは、事実の編集物はそれ自体当然に保護されるわけではなく、保護されるとしても事実そのものではなく選択、体系化、配列の創作性のある部分だけだと述べた。さらに、Computer Associates v. Altaiは、ソフトウェアの非文言侵害では抽象化・濾過・比較テスト(AFCテスト)によって、保護されない要素を先に落としてから比べるとした。つまり、米国法では単にプログラムの論理構造や機能が似ているだけでは直ちに著作権侵害とはならず、その類似性が保護される創作表現に該当するのかを厳しく精査されるのである。
そこで、今回の再実装のAIへの指示であるrewrite planにて明示的に参照が指示されている旧6.0.0のcharsets.pyを見ていくと、Charset dataclassの中に name, is_multi_byte, encoding_era, language_filter を持つメタデータ表となっている。その一方、新7.0.0のregistry.pyは、EncodingInfoを使い、era, is_multibyte, python_codec, languages などを持つ、より拡張されたメタデータ構造になっている。外形上、両者は「エンコーディングごとの属性を持つ表」であるという点で近いが、項目構成や表現形式は同一ではない。
そもそも、charsets.pyはその多くがメタデータの表であり、これは事実に近い性質であって保護される表現ではないという主張も成り立つが、表の選択・分類・割当に人間の創造性が認められれば、それを複製し、registry.pyに実質的に取り入れれば類似性の判断が成り立つ余地がある。ここで重要なのは、エンコーディング名の集合、eraの概念、対応するPython codec名、言語とのひも付けのかなりの部分は、機能、規格、あるいは事実に近い領域でもあるということである。仮にregistry.pyが旧charsets.pyを参照して作られていたとしても、それだけで再実装した7.0.0全体が旧chardetの複製または翻案とまでは言い切れないだろう。少なくとも米国法では、似ているだけでなく、「その似ている部分が保護される表現なのか」がさらに問われるからである。Dan側から見れば、rewrite plan に旧版参照があるとしても、それは機能互換やデータ整合のための参照に過ぎず、保護される表現の取り込みを意味しない、という反論が中核になる。
一方でDan側は、JPlagというソースコード盗用検出ツールを使用し、再実装である7.0.0と過去のバージョンを比較し、最大類似度が1.29%であったとMarkのイシューへの返答で報告している。他のバージョン間の最大類似度は43%から93%の範囲であったことを考慮すると、コード全体の類似性評価において定量的には類似性が低いという評価となり得る。実際、多くの開発者は全く違う実装と受け取るだろうし、このような分析はソースコードの侵害の判断において一定の説得力を持つと考えられる。しかし、著作権の世界における侵害の判断はごく一部の保護される表現の取り込みでも成立し得ることを考慮すると、このような類似判定はあくまで説得力のある材料という位置付けになるのだろう。
これらを整理すると、公開資料だけから導ける結論は限られると言わざるを得ない。再実装した7.0.0が元コードに依拠している可能性は高いと考えられるが、保護される表現をどの程度取り込んだのかは外形だけで簡単に判断できるわけではないからである。これ以上は、法的な観点におけるコード比較の専門的分析の領域であり、少なくとも自分が推測で書けるような性質のものではないだろう。
結論
公開資料だけからの暫定評価を先に述べれば、本件は再実装された7.0.0を「独立実装と断言するには苦しいが、直ちに著作権侵害と断定するには足りない」事案であると考える。
法的評価
法的に見ると、現時点の公開資料だけでも原作者であるMark側に有利な材料はそれなりに多いと言える。特にAIへの指示となるrewrite planにおいて、旧charsets.pyを authoritative reference(権威ある参照)として使う指示があることは重いと言える。クリーンルーム実装だと断言する根拠は弱いと推測され、少なくともaccess、日本流に言えば依拠性に近い事情についてはMark側の主張の方が説得力があるだろう。
しかし、それだけで複製または翻案が成立すると断定するのは早過ぎるだろう。米国法では、アイディアや手順ではなく、保護される表現の取り込みが必要であり、編集であれば保護は薄くなりやすい。再実装の7.0.0全体が旧chardetの“derivative work”(派生物)だと言い切るには、この程度の分析では足りない。逆に言えば、実際の精密なコード比較の結果、保護される表現をほとんど含まないことが明らかになれば、Dan側の独立実装論も十分に成り立つと考えられる。
charsets.py自体は6.0.0系リリースでDanにより新規作成・整備されたファイルとみる余地が強く、その限りでDanの著作物と主張し得る。ただし、それは旧chardet全体の権利処分権を意味しない。もしcharsets.pyが旧著作物に依拠した”derivative work”であれば、Danに認められるのは新規付加部分に限られ、Markを含む既存権利者の権利を消すことはできないだろう。また、charsets.pyが6.0.0系リリースにてDanの著作物たり得ることと、それを権威ある参照として再実装の土台に置いたプロセスが今回の再実装におけるクリーンルーム性を弱めることは両立する。
ということで、実装のごく一部だけでの検討であるが、依拠がAIへの指示で明確であるcharsets.pyにスポットを当てて著作権侵害性を検討すると、原作者であるMark側の主張と現メンテナーのDan側の主張の双方に強みはある。少なくとも依拠についてはMark側の主張が強いと考えられることは事実であり、保護される表現が新実装で組み込まれていることが立証されるのであれば侵害は成立し、同時にライセンス違反ともなり得るだろう。Dan側からすれば、少なくともそのファイルには自らの寄与が大きいという反論もあり得るし、事実しか記述されず表現は含まれないという反論は可能と考えられる。また、仮に原作者の権利が及んでいたとしても実質的に再実装には表現までは含まれていないという反論もできるだろう。繰り返しになるが、このような立証には専門的な分析が必要なケースであり、法域によって異なる判断が出てもおかしくない。明確に言えることは、今回の再実装は少なくとも強い意味でのクリーンルーム実装とは言い難いということであって、これ以上の判断は現状では難しい。
また、仮に著作権侵害が全面的に否定されたとしても、契約論が完全に消えるわけではないのでその観点での争点もあり得る。LGPL 2.1は改変・頒布による受諾を前提としており、米国ではオープンソースライセンスの条件違反が契約または著作権侵害として成立するかが長年に渡って争われてきた。Artifex v. HancomではGPLをめぐって契約違反と著作権侵害の双方が主張され、SFC v. VizioでもGPL/LGPLをめぐる契約的争点が現在も継続されている。もっとも、本件ではやはり中心は著作権侵害であり、契約論だけで全部を片付けられる事案ではないが、AIによる再実装が激増すると考えられる以上、著作権侵害だけで片付けない姿勢が今後必要になることに留意する必要があるだろう。
コミュニティ運営および倫理面の評価
GitHub上で同じリポジトリ名・同じ頒布経路を維持できることと、旧プロジェクトの実装全体を自己の判断だけで再ライセンスできることは別問題である。前者は特にコミュニティが大きいほどダウンストリームへの様々な影響が及ぶものであり、法的評価とは別にコミュニティ運営および倫理面での評価はより厳しくあるべきだろう。仮に本件が法廷で「著作権侵害までは認められない」という結論になったとしても、いわば同じ機能を果たすが再実装と称される全く異なるソフトウェアを同名のまま同一プロジェクトのアップデートとして扱うことの妥当性まで当然に正当化されるわけではないことには留意が必要である。
7.0.0は公開文書上、自ら”Same package name, same public API”(同じパッケージ名、同じ公開API)と主張している。しかも、Mark側が異議をイシューで述べた後も、7.0.1が通常のバグ修正・改善リリースとして開発が継続されている。現時点では少なくともMark側の主張が受け入れられず、そのまま新系統がプロジェクトの後継を名乗って走っている状態である。
私見を述べれば、今回の件は法的に白か黒かとは別に、本来は別のツールとしてリリースすべきだったと考える。AIによって全面的な再実装を行い、内部アーキテクチャも完全に変え、ライセンスまでコピーレフトからパーミッシブへ変更するのであれば、それはもはや単なる「アップデート」であるとは思えない。どうしても同じプロジェクト名を維持するなら、少なくとも元のライセンスへ戻し、継続性に関するコミュニティの疑念を減らす方向の方が混乱は少なかったはずである。
さいごに
AIによる再実装はこれから確実に激増するだろう。だが、そのことと既存のプロジェクトを同名のままアップデートとしてリリースして良いかは別問題である。そもそも法的に争える余地が残る以上は慎重に進めるべきであるし、たとえ法的に白であっても、組織のコンプライアンス、下流利用者の理解に大きな混乱を持ち込むことになる。コピーレフトからパーミッシブに変更されることを歓迎する者が一定数存在するのは事実であるが、オープンソースから非オープンソースへの再実装も同じ手法でなり得ることを認識したほうが良いだろう。
私の感覚としては、AIによる完全な再実装は原則として別ツールとして扱うべきである。少なくとも、人間による長年の継続的な開発物とAIによる別実装を同じプロジェクトの同じリリース系統の下で曖昧に混ぜるべきではない。ライセンスもそのコードの来歴と性質に見合ったものを選ぶべきであり、元の人間のソフトウェアと連続であるかのように見せる行為は避けるべきである。また、AIによる全面的な再実装を既存プロジェクトの後継としてリリースするのであれば、旧実装に対して貢献した全ての権利者と下流の利用者に対し、コードの来歴、参照した旧資産の範囲、ライセンス変更の根拠、旧権利者との関係、互換性と非互換性の範囲を公開時点で明示する説明責任があるだろう。
参考
chardet 7.0.0 release: https://github.com/chardet/chardet/releases/tag/7.0.0
chardet 7.0.1 release: https://github.com/chardet/chardet/releases/tag/7.0.1
No right to relicense this project, Mark Pilgrim: https://github.com/chardet/chardet/issues/327
Dan側の反論: https://github.com/chardet/chardet/issues/327#issuecomment-4005195078
Chardet Rewrite Implementation Plan: https://github.com/chardet/chardet/blob/925bccbc85d1b13292e7dc782254fd44cc1e7856/docs/plans/2026-02-25-chardet-rewrite-plan.md
Chardet Rewrite Design: https://github.com/chardet/chardet/blob/925bccbc85d1b13292e7dc782254fd44cc1e7856/docs/plans/2026-02-25-chardet-rewrite-design.md
GNU Lesser General Public License, version 2.1: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.en
17 U.S. Code § 102: https://www.law.cornell.edu/uscode/text/17/102
@OKMRKJによる「二段の依拠」解説: https://x.com/OKMRKJ/status/1702944463314907400
Shuji Sado 