整理 | 屠敏
出品 | CSDN（ID：CSDNnews）
Claude Code を使って 5 日間で 10 年以上運営されてきた古いコードベースを書き直した後、プロジェクトのメンテナーは直接オープンソースライセンスを LGPL からより permissive な MIT に変更した。
最近、Python の classic エンコーディング検出ツール chardet がこれにより論争の中心となっている。
さらにドラマチックなのは、このライブラリの新バージョンがリリースされた後、2011 年以降公の場から姿を消していた原作者が突然現れ、メンテナーにすぐにライセンスを元に戻すよう要求したことだ。
それに対してメンテナーは、新バージョンは AI を使ってゼロから書き直したものであり、旧バージョンとは無関係だと主張している。
こうして、AI によるコードの書き直しにおける所有権とライセンスルールを巡る論争が火を吹いた。
原作者は引退、メンテナーが就任
簡単に言うと、chardet は Python エコシステムで非常に一般的に使われているテキストエンコーディング検出ライブラリで、バイトストリームのエンコーディング（UTF-8、GBK、ISO-8859-1 など）を自動で識別するのが核心機能だ。
一見ニッチに見えるが、実際には多くのプログラムの基盤コンポーネントとなっている。Python の requests ライブラリをインストールしたことがあるなら、おそらくこのライブラリが裏で静かに動作している。以前の統計では、chardet の年間ダウンロード数は 8.54 億回に達している。
このライブラリは 2006 年に開発者 Mark Pilgrim によって最初に作成され、LGPL ライセンスで公開された。
オープンソースライセンスに詳しい開発者ならご存じの通り、LGPL は改変と配布を許可するが、二次配布や商用利用には厳しい制約があり、派生作品は通常同じライセンスを継続しなければならない。
原作者は数年のメンテナンス後、2011 年に完全に公の場から姿を消し、chardet のメンテナンスは他の人に引き継がれた。
その中で Dan Blanchard は最も重要なメンテナーの一人で、2012 年 7 月の chardet 1.1 バージョン以降のすべてのリリースを担当し、約 700 回のコミットを寄与している。2 位のメンテナーはわずか 48 回しかコミットしていない。
Claude の助けを借りて、メンテナーは 5 日間で chardet ライブラリの完全な書き直しを完了した。
先週、Dan Blanchard は chardet 7.0 バージョンをリリースし、GitHub のプロジェクトページでこれは「完全に書き直されたバージョンで、MIT ライセンスを採用している」と宣言した。
さらに、パッケージ名と公開 API は変更せず、chardet 5.x／6.x と直接置き換え可能で、速度が速く、精度も向上している。Python 3.10 以上をサポートし、実行時の依存はなく、PyPy でも動作する。
ここで問題となるのは、MIT ライセンスは LGPL よりもはるかに許容範囲が広く、ソフトウェアを自由に使用・変更・複製・配布でき、商用ソフトウェアに組み込むことも可能だが、オリジナルの著作権表示を残すだけでよいということだ。
ライセンス変更の理由について、Dan Blanchard は外部メディアのインタビューで、長年にわたり chardet を Python 標準ライブラリに組み込みたいと思っていたが、旧ライセンス、性能、精度の制約により実現できなかったほか、時間が不足していたため進展が見られなかったと説明した。
「今は Claude があれば、約 5 日間でやりたいことを実現できる」と Dan Blanchard は述べた。
それゆえ、彼は Claude Code を使って chardet 7.0 バージョンを書き直し、リリースした。
原作者の「突然の登場」抗議：元のコードへの不正な再ライセンスを拒否
新バージョンがリリースされてからわずか 2 日後、GitHub 上で「Mark Pilgrim」というニックネームのユーザーが投稿し、自分こそが chardet の原作者だと主張し、長年のメンテナーと貢献者に感謝を示しつつも、Dan Blanchard が MIT ライセンスでバージョン 7.0 を公開したことは LGPL コードの不正な再ライセンスであり、オープンソースライセンスに直接違反すると指摘した。
彼は今回のライセンス変更に明確に反対している。
以下が彼が GitHub issue に投稿した全文である。
こんにちは、私は Mark Pilgrim です。『Dive Into Python』や『Universal Character Encoding Detector』などの著作を覚えておられる方もいらっしゃるでしょう。私も chardet の最初の作者です。
まず、現在のメンテナーおよびこれまでこのプロジェクトに貢献し続けて改善に尽力してくれたすべての方々に感謝したい。これはまさにフリーソフトウェアが成功裏に発展した典型的な事例だ。
しかし、最近誰かが私に思い出させた。7.0.0 バージョンのリリースにおいて、メンテナーは自分たちにこのプロジェクトの「再ライセンス（relicense）」を行う権利があると主張している。実際にはそのような権利はなく、これは GNU Lesser General Public License（LGPL）への明確な違反である。
LGPL の規定によれば、ライセンスが与えられたコードを変更して配布する場合でも、引き続き同じ LGPL ライセンスを使用しなければならない。メンテナーはこれが「完全な書き直し（complete rewrite）」だと主張しているが、これは事実とは異なる。なぜなら彼らは以前から元のライセンスコードに広く接触していたからであり、つまり「クリーンルーム実装」（元のコードに一切触れずに独立して実装すること）とは言えない。開発途中に複雑なコード生成器を組み込んだとしても、それによって自動的に追加のライセンス権が得られるわけではない。
したがって、私はここに正式に求める。プロジェクトのライセンスを元のバージョンに戻してほしい。
結局、誰のコードなのか？誰が決定権を持つのか？
まず、Mark Pilgrim が声明で言及した「クリーンルーム」について簡単に説明する。
コンピュータエンジニアやプログラマーは長年にわたり、著作権で保護された元のコードを直接コピーすることなく、リバースエンジニアリングによって機能を実現してきた。簡単に言うと、著作権を侵害しない前提でソフトウェアの挙動と機能を「模倣」することだ。過去には、この手法は一般的に「クリーンルーム（clean room）」の原則に従っていた。つまり、元のコードに一切接触しない人が機能を再実装し、その結果生まれたコードがオリジナルの派生作品とならないようにする。
Blanchard は返答の中で、自分が chardet を10年以上メンテナンスしており、確かに長期間にわたり元のコードベースに接触してきたことを認めた。
従来のクリーンルーム手法では、通常2つのグループを厳密に分離することが求められる。一方のグループは元の実装を理解し、もう一方のグループが新しい実装を記述し、その間は完全に隔絶されている必要がある。
客観的に見て、このプロジェクトにおいて Blanchard はこうしたクリーンルームの隔離要件を満たしていない。
しかし Blanchard は、クリーンルーム手法自体はただの手段であり、その目的は最終的に生成されるコードが元のコードの「派生作品」でないことを保証することにあると考えている。つまり、クリーンルームは目標を達成するための方法であり、目標そのものではない。
今回のケースでは、彼は直接的な技術的測定によって最終的な結果が同じ目標を達成していることを示すことができる。すなわち、新しいコードは構造的に古いコードから独立しており、単なる開発プロセスの保証に頼っているわけではない。
そこで彼は、コード類似度検出ツール JPlag を使ってデータを示した。chardet 7.0 バージョンのファイルと 6.0 バージョンの対応ファイルの最大類似度はわずか 1.29% である一方で、5.2 バージョンから 6.0 バージョンにかけては一部のファイルで類似度が最大 80% に達している。
Blanchard は強調する。自分はゼロから新しいコードベースを作り上げ、古いファイルを直接移動させたわけではない。
もし過去に元のコードに接触したという事実だけで、一度の書き直しを無効とみなすなら、あらゆる LGPL プロジェクトのメンテナーは将来、異なるライセンス下で同じ機能を再実装しようとすることはほぼ不可能になるだろう。最終的なコードが元のコードとどれほど違っていても関係なく。
私は LGPL の要件がそうであるとは思わないが、異なる解釈にも耳を傾けたい。私の見解では、核心となる問題は「新しいコードが古いコードから派生しているか（すなわち派生作品か）」ということだ。これまでに挙げた証拠を見る限り、それは当てはまらない。
AI はどのように関与したのか
完全な透明性を保つため、Blanchard は今回の書き直しの具体的なプロセスをさらに共有した。
私は Claude の「superpowers brainstorming」機能を使って設計書を生成し、その中で私が採用したいアーキテクチャと実装方針を詳しく説明した。
この設計書は、今回の書き直しのために私が設定した一連の要件に基づいている（これらの要件は最初に私の携帯のメモ帳に書き留められ、リポジトリにはコミットされていないが、ここでは背景説明としてリストアップする）。
外部 API との互換性を維持する
プロジェクト名は chardet のままとする。これは新しい実装で元の chardet を置き換える計画だからだ
GPL または LGPL のコードには一切基づかない
テストデータにおいて、chardet と同等のエンコーディング検出精度を維持する
言語検出は必須ではないが、実装が容易であれば、あるいは他の設計の副産物として得られる場合は実装してもよい
高性能かつメモリ効率が高い：マルチコア CPU を効果的に活用できる
実行時の依存がない
PyPy と CPython の両方を必ずサポートする
設計はきれいで最新式である
訓練によって得られた統計モデルを使用する場合、データ取得元は Hugging Face の load_dataset API を用いるべきだ
どの訓練コードでも、開発过程中頻繁に再訓練できるようにデータはローカルにキャッシュすべきだ
頻繁にパフォーマンスベンチマークを実施する
CPython 3.12 では巨大なディクショナリリテラルのインポートが非常に遅くなるため、Such 大量の巨大なディクショナリリテラルの使用を避ける
その後、Blanchard は次のように述べた。完全に空のリポジトリで開発を開始し、旧コードベースへのアクセスは一切行わない。同時に、Claude に対してはっきりと指示した。GPL または LGPL ライセンスのコードには一切基づかないで実装せよと。
続いて、彼自身が Claude を使って生成されたコードの各部分をレビューし、テストを行い、繰り返し改良した。
ただし、Blanchard も正直に認めている。自分はこれらのコードを一行ずつ手書きしたわけではないが、全体を通じてアーキテクチャ設計、コードレビュー、そして各ステップの改良プロセスに深く関与してきた。
私はこれを理解している。これは新しい分野であり、長年にわたって存在したオープンソースプロジェクトの書き直しに AI ツールを使うことは、当然ながら正当な疑問を呼ぶ。しかし現在の証拠を見る限り、状況は明確だ：バージョン 7.0 は独立した作品であり、LGPL コードベースの派生作品ではないため、MIT ライセンスの使用は正当化される。
論点：AI が生成したコードの境界線を定めるのは難しい
Blanchard が独立したコード生成を目指していても、依然として複雑な要因が残っている。
まず第一に、一部のネットユーザーが指摘したように、Claude が chardet 7.0 バージョンの書き直しにおいて、早期バージョンの chardet の一部のメタデータファイルを明らかに使用していたことが判明した。これにより業界の開発者は、この新バージョンが本当に「派生版」なのか疑問を呈している。
一方、Claude モデルは訓練時に大量の公開ウェブデータを吸収しており、その中には早期の chardet オープンソースコードも含まれている可能性がある。これが意味する所、AI が生成したコードがオリジナルの派生作品であるかどうかはまだ論争中である。
さらに、人的要因もある。新バージョンのコードは Claude が生成したものだが、前述の通り Blanchard は「私は Claude を使って結果の各部分をレビューし、テストし、繰り返し改良した……自分はコードを一行ずつ手書きしたわけではないが、設計・レビュー・改良の全プロセスに深く関与している」と述べている。早期の chardet コードに精通した人物がこのように深く新コードのレビューに関与することも、このバージョンが本当に全く新しいプロジェクトと言えるかどうかに影響を与える可能性がある。
さらに挙げると、Blanchard のすべての操作は chardet ライブラリと同じパッケージ名、同じリポジトリ、同じ PyPI エントリ内で行われた。何よりも重要なのは、新バージョンの名前もまだ chardet であるということだ。
ネットユーザーの意見
この事件はオープンソースコミュニティで広範な議論を呼び起こし、AI 時代の根底にあるルールの欠如を直接的に指している。
Blanchard に対する非難を擁護する声もある：
Blanchard は一人でこのライブラリをメンテナンスしており、資金も協力者もサポートもない。chardet チームの他の二人は 2017 年末には更新を停止しており，そのうちの一人は 2012 年以降コミットが全くない。原作者は 2011 年にインターネット上の痕跡を完全に消去した。これは Python エコシステムで最も依存されているパッケージの一つであり，ただ一人の個人が趣味の時間で支えている状態だ。今この人物が皆が好ましくないことをしたため，突然みんながガバナンス，ホスティング，フリーソフトウェアの精神について熱く語り始めた。
また，ユーザーの Armin Ronacher は『AI とテセウスの船』という記事を書いた。彼は AI による書き直しを，GPL から finalmente 脱出する道筋だと見なしている。なぜなら GPL は共有を制限すると考えているからだ。
すべてのコードを捨ててゼロから始めれば，最終的な振る舞いが同じであっても，それは新しい船である。
ただし，多くのネットユーザーは次のように考えている：
Copyleft ライセンスのコードをそのモデルに訓練させた AI に食わせ，機能的に等価な出力を生ませて，「見てくれ，類似点はない」と言う。類似性検出ツールで一致するトークンが見つからなくても，それが作品の独立を意味するわけではなく，ただ単に洗白が効いただけだ。この手法が合法だとすれば，現存するすべての Copyleft プロジェクトは Claude を一度走らせるだけで MIT ライセンスに変更でき，さらにはクローズドソースにもなる。賛否両方とも成立し得る。
GitHub のディスカッション欄では，さらに鋭い指摘がある。「Windows の漏洩したソースコードを大規模言語モデルに渡して書き直し，それをオープンソースとしてリリースするのは受け入れられるか？受け入れられないなら，なぜ chardet のケースは違うのか説明してほしい。」メカニズムはまったく同じで，唯一の変数は著作権者に同情するかどうかだけである。
フリーソフトウェア財団（FSF）の執行役員 Zoë Kooyman は次のように述べた：
「AI モデルは再実装すべきコードを吸収しているため，本当に『クリーン』な状態は存在しない。」
一方は典型的なオープンソースライセンスの底線であり，もう一方は AI が助ける開発の新たな現実である。オリジナルの作者が姿を消し，一人で十年以上メンテナンスした後，このプロジェクトは誰のものになるのか？新しい chardet のライセンスは結局誰が決めるのか，あなたはどう思うか？
参考：
https://github.com/chardet/chardet
https://github.com/chardet/chardet/issues/327#issuecomment-4005195078
https://shiftmag.dev/license-laundering-and-the-death-of-clean-room-8528/
https://www.theregister.com/2026/03/06/ai_kills_software_licensing/