このプロジェクトを再ライセンスする権利はない
(github.com/chardet)chardetの原著者である Mark Pilgrim が、プロジェクトにおける LGPLライセンス違反 を指摘し、最近のバージョン 7.0.0 で行われた MITライセンスへの変更 の撤回を求めた- 彼は、メンテナーが「全面的な書き直し」だと主張していても、元のコードに 直接さらされた状態で作成された派生物 である以上、LGPLを維持すべきだ と明言した
- 複数の開発者が、AI支援による書き直し が実際に「クリーンルーム実装(clean room implementation)」に当たるのか、そして LLMが元のコードを学習していたかどうか を議論した
- 一部では API互換性 と フェアユース(fair use) の可能性にも言及があったが、多くは 著作権侵害の可能性 と AIコード生成の法的な不確実性 を懸念した
- 今回の議論は、AIが生成したコードの著作権責任、オープンソースプロジェクトのライセンス変更手続き、メンテナー権限の限界 をめぐる重要な先例として注目されている
Mark Pilgrimによる問題提起
- Mark Pilgrim は、自身が
chardetの 原著者 であり、プロジェクトは LGPLライセンス で配布されてきたと明記した- 彼は、バージョン 7.0.0で「再ライセンスする権限がある」とするメンテナーの主張 は誤りだと指摘した
- LGPLの下にあるコードは、修正されても 同一ライセンス で公開されるべきであり、「全面的な書き直し」という主張には 法的根拠がない と強調した
- 「コード生成器の追加」が新たな権利を与えるものではないと明言した
- Pilgrim は、プロジェクトを 元のLGPLライセンスに戻すこと を要求した
コミュニティの初期反応
- あるユーザーは、AI支援の書き直し以前のバージョンのフォーク があるか質問し、別のユーザーが 6.0.0バージョンへのリンク を提示した
- 一部は「法的には Mark が正しい」と同意し、LGPL違反の可能性 を認めた
- 別のユーザーは「AIによる書き直しは避けられないトレードオフだ」として、実務的な観点 に言及した
法的議論: API、著作権、フェアユース
- あるユーザーは Google LLC v. Oracle America, Inc. の判例を引用し、APIも著作権保護の対象 であると述べた
- API互換性を理由にした書き直しは、フェアユースの要件を満たさなければ違法 となり得ると説明した
- これに対し別のユーザーは、Googleの件ではフェアユースが認められた と反論した
- 議論は API互換性のある書き直しの適法性 と AI生成コードの著作権上の位置づけ へと広がった
AIコード生成とクリーンルーム実装をめぐる論争
- 一部では、「AIが元のコードを学習していた可能性」があるなら クリーンルーム実装は成立しない と指摘された
- LLMが
chardetのコードを学習していたかどうかが、法的判断の核心 になり得る
- LLMが
- 別のユーザーは、「AIが入力と出力だけを基準にコードを生成したのであれば可能かもしれない」と主張した
- しかしこれに対しては、「そうであればライセンス自体が無意味になる」という反論が出た
- AIコードにおける 著作権責任の不明確さ と ライセンス順守の検証の難しさ が主要な争点として浮上した
ライセンス互換性とGPLをめぐる議論
- 一部は MITライセンスが GPLと互換性がない と主張したが、別のユーザーが FSFの公式文書 を引用し、MIT(Expat)はGPL互換 であると説明した
- しかし、LGPLコードをMITへ再ライセンスすることは依然として違反 であるという点では多くの意見が一致した
- また別のユーザーは、「LGPLコードによって築かれた名声やリポジトリを維持したまま契約だけ捨てることはできない」と指摘した
AI学習データと信頼の問題
- 複数のユーザーが、「Claude が LGPLコードを学習していないと信じられるのか」と疑問を呈した
- AIモデルの 学習データを追跡できないこと が法的リスクとして挙げられた
- 一部は、「AIコードに盗用の可能性が含まれるなら、使用自体を避けるべきだ」と主張した
- 研究の引用を通じて、AIコードの2〜5%が既存コードの複製である可能性 を示す統計も提示された
プロジェクトのアイデンティティとメンテナー権限
- 一部は、「過去のコントリビューターのコードがすべて削除されているなら、新バージョンは独立している可能性がある」と主張した
- しかし、「名前と評判をそのまま使うのは不適切だ」という反論もあった
- 「著作権は表現を保護するのであって、名前を保護するものではない」という意見も示された
- メンテナーが 既存コードをすべて削除していたなら 法的違反ではないかもしれないという見解もあったが、明確な証拠は示されなかった
コミュニティの総合的な見方
- 複数のユーザーが Mark Pilgrim と Dan Blanchard の双方の貢献を尊重しつつ、AI・著作権・オープンソースガバナンス の複雑な問題を認識すべきだと述べた
- 議論は、AIコード生成の法的責任、プロジェクトのライセンス変更の正当性、オープンソースメンテナー権限の限界 などへと広がった
- 一部では、「v7.0.0をフォークしてLGPLに戻そう」という提案も示された
主要な争点の要約
- LGPL → MIT 変更の適法性: 原著作者の同意なしには不可能だという意見が多数
- AIによる書き直しの著作権上の位置づけ: 学習データへの露出の有無によって派生物と見なされる可能性
- クリーンルーム実装かどうか: AIが元のコードを参照していないことを立証する必要がある
- プロジェクト名・評判の利用問題: 同じ名前での再配布には法的・倫理的な論争がある
- AIコードの信頼性: 盗用リスクとサプライチェーン安定性への懸念
この問題は、AIが生成したコードの著作権とオープンソースライセンス順守 をめぐる代表的な事例であり、今後 AI開発ツールの法的責任の枠組み に影響を与える可能性がある
1件のコメント
Hacker Newsの意見
Pilgrim は クリーンルーム の概念を誤解していると思う
「完全な書き直し」という主張は重要ではない。法的には独立した実装は可能だ。
クリーンルームは単に訴訟を簡略化するための手続き的装置にすぎず、原本コードに触れていてはならないという法的要件ではない。
実際、Linux も Unix の内部構造を知っていたが、独立に実装された
JPlag の低い類似度は、盗用ではないことを示す説得力のある証拠 に見える
「コードベースを知っているなら書き直しも著作権侵害だ」という主張は完全には妥当ではない
内部知識は 特許の領域 であって、著作権とは無関係だ。
ただし、原本コードをそのまま横に置いて文面だけ変えるようなやり方は侵害だ。
AI が原本コードを見て似たコードを生成したなら、それは事実上 並行複製 と見なされる可能性が高い。
しかし、原本を見ずに完全に新しく書くなら可能だ。ただし法的防御が難しいため、企業の立場ではリスク要因と見なすべきだ
特許は独立発明であっても侵害になりうるが、著作権は 創作の独立性 が核心だ。
ただし、すでに見たことのある作品と同一の成果物を作ったなら、陪審員を説得するのは難しい
結局、類似性があれば 証拠の優越(preponderance of evidence) 基準で侵害と判断される可能性が高い
一方で原作をまったく知らなければ、独立創作として認められる
アイデア自体は保護されないが、表現は保護される。
LLM が学習過程で原本コードを見ていたなら、法的にはグレーゾーンだ
核心は LGPL 違反かどうかだ。
新しいコードが原本に基づいているなら、二次的著作物と見なされ、LGPL を維持しなければならない。
「完全な書き直し」だと主張しても、原本コードに触れていたなら ライセンス違反 になりうる
クリーンルームは単なる訴訟防御のための手続きであり、立証責任は原告側 にある。
Linux や GNU ツールも Unix を知っていたが合法だった
コンサルティング中に興味深い事例を見た。
ある SaaS 企業のエンジニアが Claude Code で自社アプリをリバースエンジニアリングし、API 互換バックエンド を1週間で作った。
「競合がこうしたらどう守るのか？」と聞かれた
コード自体がビジネスの中核なら、すでに危うい。
競争を心配するより、より良い製品を作ることが重要だ
今や「Slack や Drive を再実装しよう」が 非現実的ではない時代 だ
API は公開されたインターフェースなので保護対象ではない
IBM BIOS や DOS の リバースエンジニアリング事例 のように、独立実装は合法だ
メンテナーは 受託者(trustee) であって所有者ではない。
原作者のライセンスを勝手に変えてはならない。
完全に新しく作ったコードなら、新しい名前でプロジェクトを始めるべきだ。
「既存バージョンを固定しろ」というような発言は コミュニティ精神に反する
2021年のコメントですでに「chardet は LGPL ベースなので再ライセンス不可」と言及されていた。
それを知りながら書き直したなら 無謀な決定 であり、原作者に対する 無礼 だ
AI が原本コードを見た状態で書いたなら、クリーンルーム実装 ではない。
もし2つの AI チームを置き、一方が仕様を作り、もう一方が実装するなら大丈夫だろうか？
IBM 時代の先例には従っているが、モデルがすでに原本で学習されていれば依然として問題だ
ただし、仕様に 表現的要素が含まれないことを検証 しなければならない
学習データに原本が含まれている状況では、比較自体が無意味 だ
「Wikipedia をコピペして単語を少し変えれば大丈夫ですか？」という冗談のように、
結局 意図的な回避 は不可能だ。
依存関係のバージョンを固定しなければならないほど、信頼が難しい時代だ
しかし法律は 総合的判断 を重視する。
裁判所は「証拠の優越」基準で判断し、単に単語を置き換えただけでは新しい作品にならない。
原本が不可欠だったなら、二次的著作物と判断される可能性が高い。
学習データに原本が含まれているなら、著作権侵害訴訟 は避けられないだろうと予測している
一方で、Mark Pilgrim が再び登場したのが興味深い
彼の Wikipedia ページ には「インターネットから姿を消した」逸話がある。
彼の Python 本は今でも勧める価値がある
「AI が GPL コードで学習されているなら、すべての AI コードが GPL 汚染(taint) されているのでは？」という驚きがある
米国のクリーンルーム手続きは単なる 訴訟短縮のための戦略 だ