AIが書いたコードは著作権なし　GPLが形骸化する仕組みとは

LLMが書いたコードをコミットした瞬間、そのコードはパブリックドメインになる。これは理論の話ではなく、米著作権局が正式に示した見解であり、オープンソース開発の現場ですでに問題が顕在化している。

この記事でわかること：

• なぜAIが生成したコードに著作権が認められないのか
• GPLなどコピーレフトライセンスが空洞化するメカニズム
• 実際に起きたPythonライブラリ「chardet」の再ライセンス問題
• GitHub Copilot訴訟（Doe v. GitHub）の2026年現在の状況
• オープンソース開発者が今すぐ対処すべきこと

LLMの出力物には著作権がない

米著作権局は、AIが生成した成果物は著作権の保護を受けられないと結論づけている。「著作権と人工知能に関するレポート第2部」では、LLMの出力は人間の創造的表現ではないとして、著作権の要件を満たさないと明示した。

理由は明快だ。著作権は「人間が創作した作品」にのみ付与される。プロンプトを入力してコードを得る行為は、アイデアを渡して実行させる行為であり、モデル自体が表現上の判断を行っている。著作権局は「プロンプトは保護されないアイデアを伝える指示にすぎない」と述べている。

「モンキーセルフィー事件」が参考になる。英国の写真家がカメラを設置してサルに自撮りさせたとき、その写真は著作権の対象にならなかった。写真を撮ったのが人間でないためだ。LLMが生成したコードも同じ構造にある。人間がコードレビューをして「良い」と判断しても、そのレビュー行為は著作権の取得には結びつかない。修正した部分のみが著作権の対象になる。

つまり、1,000行のLLM生成コードのうち10行を修正した場合、著作権があるのはその10行だけだ。残り990行はパブリックドメインになる。

コピーレフトが崩れるしくみ

コピーレフトライセンス（GPL・LGPL・MPLなど）の核心は「互恵性」にある。これらのライセンスでコードを公開した場合、派生物も同じ条件で公開しなければならない。Linuxカーネル、Git、WordPress、VLC、Firefoxなど主要なオープンソースプロジェクトの多くがこの仕組みに依拠している。

問題はここから始まる。著作権のないコードは、ライセンスを付与できない。ライセンスとは著作権に基づいた権利の行使であり、著作権が存在しないコードにはライセンスの拘束力が及ばない。

GPLプロジェクトのリポジトリにLLM生成コードが混入すると、その部分は事実上パブリックドメインになる。誰でも自由に使え、クローズドソース製品に組み込んでも互恵義務は生じない。ライセンスファイルにGPLと書かれていても、対象コードがパブリックドメインなら意味をなさない。

これが「コピーレフトの空洞化」だ。プロジェクトが名目上GPLを掲げながら、LLM生成コードの流入によって内側からその効力が失われていく。

chardetで実際に起きたこと

2026年4月、Pythonのキャラクターエンコーディング検出ライブラリ「chardet」でこの問題が現実になった。

https://github.com/chardet/chardet

12年間メンテナーを務めてきたdan-blanchard氏は、Claude Code（Opus 4.6）を使って1週間足らずでchardetを書き直し、バージョン7.0.0としてリリースした。そのうえでライセンスをLGPLからMITへ変更した。目的はPython標準ライブラリへの取り込みにあった（標準ライブラリはMITなど許容ライセンスを要求する）。

これに対し、chardetの原著者であるMark Pilgrim氏が異議を申し立てた。Pilgrim氏は「再ライセンスする権利はない。LGPLで修正されたコードは同じLGPLで配布しなければならない。『完全書き直し』という主張は関係ない。メンテナーは元コードに十分アクセスしており、クリーンルーム実装とは言えない」と指摘した。

メンテナー側はClaudeが生成したコードを「クリーンルーム実装」と主張した。クリーンルーム設計とは、元のコードを一切参照せずに独自に機能を再実装する手法で、Wine プロジェクトが Windows との互換性確保に用いてきたアプローチだ。しかしClaudeはchardetのコードを学習データとして取り込んでいる可能性が高く、その主張が法的に成立するかは不透明だ。

この争いはオープンソースコミュニティに波紋を広げた。既存貢献者からは「私の貢献が無断でパブリックドメイン扱いにされた」という反発が上がっている。

Doe v. GitHub訴訟の2026年時点の状況

AIとオープンソース著作権をめぐる最大の訴訟が、GitHub・Microsoft・OpenAIを相手取ったDoe v. GitHub事件だ。2022年11月に北カリフォルニア地区連邦地方裁判所に提訴され、GitHub Copilotがオープンソースコードを許可なく学習・生成に使っているとして争われた。

2024年6月、Jon S. Tigar裁判官は主要な請求を却下する判決を出した。「Copilotの出力が原告の著作権保護コードと十分に類似しているという証拠がない」とした。ただし2つの請求——オープンソースライセンス違反と契約違反——は存続しており、2026年1月時点でも証拠開示手続きが進行中だ。

DMCA第1202条（著作権管理情報の削除・改変）に関してはDMCA第9巡回控訴裁判所に上訴されており、「同一性要件」の解釈が問われている。

この訴訟の結論次第で、AIが学習データとしてオープンソースコードを使うことの合法性、生成コードへのライセンス義務、フェアユースの適用範囲について重要な先例が生まれる。

Google v. Oracle判決が示す可能性

AI企業側が盾にしているのが2021年の最高裁判決、Google LLC v. Oracle America, Inc.だ。GoogleがAndroidでJava APIを再実装したことがフェアユースと認められたこの判決を根拠に、機能を再実装しているだけであれば著作権侵害に当たらないという主張がある。

ただし、この判決はGoogleが特定のAPIを人間主導で再実装したケースに関するものだ。数百万のリポジトリで学習した モデルが大量に出力するコードに同じ論理が適用されるかは、裁判所がまだ判断していない。

開発者が今やるべきこと

コピーレフトプロジェクトのメンテナーであれば、LLM生成コードのPRをマージする前に著作権の帰属を確認する必要がある。コントリビューターに「このコードは人間が書いたものか」を問う方針をコントリビューションガイドラインに明記することが現実的な対策だ。

AIコーディングツールを使う開発者は、生成された出力を「たたき台」として捉え、自身の判断で構造・ロジック・命名を再構成することで著作権を取得できる状態に近づけられる。ただし著作権局は「レビューして承認する行為だけでは不十分」としているため、実質的な修正が必要になる。

GPLプロジェクトへのAI生成コードの組み込みはライセンス強制力を弱体化させることを理解したうえで、意図的な方針決定が求められる。許可型ライセンス（MITやApache 2.0）のプロジェクトは法的な問題が比較的少ないが、それでも帰属とトレーサビリティの観点から記録を残しておくことが望ましい。

裁判所の判断はまだ出ていない。しかしDoe v. GitHub訴訟が決着するころには、AIコード生成の法的位置づけが大きく動いているはずだ。