GCCがLLM生成コードを禁止、GPLv3ライセンス保護のため

GNUコンパイラコレクション（GCC）は、GPLv3ライセンスの法的根拠を保護するため、大規模言語モデル（LLM）によって生成されたコードのコントリビューションを禁止するポリシーを導入した。AI生成コードには著作権が認められないため、ライセンスの強制力が失われるリスクを回避する狙いがある。この決定は、数週間以内にLLM利用に関する投票を控えるDebianなど、オープンソース界隈のガバナンスに大きな影響を与える可能性がある。

■著作権のないコードがGPLの構造的脅威となる理由

GNUプロジェクトでは、フリーソフトウェア財団（FSF）への正式な著作権譲渡が必要なコントリビューションの基準を、コードまたはテキストで約15行としている。この基準を下回るパッチは、著作権の観点からは法的に意味を持たない（独自の創作物とみなすには短すぎる）と判断される。一方、基準を上回る場合、コントリビューターは自身が著作権を保有し、GPLv3の下でプロジェクトにライセンスする権利があることを確認しなければならない。

この基準はAI時代より何十年も前に設けられたものだが、現在のAI問題に不気味なほど正確に当てはまる。米国著作権局は2025年1月、人間の意味のある関与なしに主にAIによって生成されたコードは、AI、開発企業、プロンプトを入力した開発者のいずれによっても著作権保護の対象にはならないとの裁定を下した。米国最高裁判所も2026年3月、この裁定を覆すことを拒否している。

GPLv3プロジェクトにとって、この影響は極めて具体的だ。GPLの強制力は、著作権者（GCCの場合はFSFおよび個々のコントリビューター）が、GPLの条件を遵守せずにプロプライエタリなソフトウェアにコードをコピーした者に対して法的措置をとれることに依存している。もしGCCの一部がAI由来であり、したがって著作権者が存在しない場合、その行については強制メカニズムが機能しなくなる。企業がGCCからAI由来の関数をプロプライエタリ製品にコピーしても、FSFが主張できる著作権がないため、GPLの義務を負わないことになる。そのような関数が積み重なれば、下流のユーザーに変更を同じライセンスで配布することを義務付けるGPLの「ウイルス的」な性質に穴が開き始める。

GCCのポリシーは、そもそもそのような穴が開くのを防ぐための試みである。法的に意味のあるすべてのコントリビューションが人間の著作に由来することを要求することで、プロジェクトは15行の基準を超えるGCCのすべての行に、ライセンスを強制できる明確な著作権者が存在することを保証している。

■ポリシーの具体的な内容

2026年7月29日、GCC運営委員会のDavid Edelsohnはメーリングリストで、AIポリシーワーキンググループの推奨ポリシーを委員会が承認したことを発表した。新ルールの核心となる文言は明確だ。プロジェクトは、LLM生成コンテンツを含む、またはLLM生成コンテンツから派生した「法的に意味のある」コントリビューションを拒否する。ここでいう「法的に意味のある」とは、GNUプロジェクトのメンテナ向けガイドラインの定義に従い、著作権の観点から意味を持つとされる約15行のコードおよび/またはテキストという基準を指す。

この基準は実務上重要である。軽微な修正、1行のパッチ、小さな編集上の変更は、どのように作成されたかにかかわらず引き続き受け入れられる（ただし、同一のコントリビューターによるAI生成の小さな編集が繰り返された場合、累積的にポリシーの対象となる可能性がある）。また、この禁止規定は一見するよりも広範だ。コントリビューターがLLMによって生成された実質的な実装を取り込み、手動でクリーンアップした上で、その結果のパッチをあたかも自分が最初から書いたかのように扱うことはできない。生成されたコンテンツから派生したコントリビューションは、その後の人間の編集にかかわらず、ポリシーの対象であり続ける。

例外規定も存在する。GCCのメンテナは、法的に意味を持たない、または些細な変更であってLLMによって生成されたものを、プロジェクトの通常のコントリビューション要件を満たし、かつLLMの使用が明確に開示されていることを条件に受け入れることができる。著作権的に意味のあるAI生成のテストケースも例外として受け入れられる可能性がある。テストケースは監査が容易であり、問題が発生した場合の置き換えも簡単で、下流のプロプライエタリなコピーの標的になる可能性が低いため、リスクとリターンの計算が異なるからだ。

重要なのは、このポリシーが開発者のワークフローにおけるAIツールの使用を禁止するものではないということだ。開発者は引き続きLLMを使用して、コードベースの理解、アプローチのブレインストーミング、バグの分析、技術の調査を行うことができる。単に、LLMの出力、またはそこから実質的に派生したパッチをコントリビューションとして提出できないだけである。委員会は2027年初頭にこのポリシーを見直す予定だ。

■GCCとLLVM：2つのコンパイラ、2つの哲学

GCCのアプローチは、主要な競合であるLLVMと哲学的に真っ向から対立している。GCCのルールが「出所ベース」（人間が後からどれだけ編集したかにかかわらず、そのパッチがかつてLLMの出力であったかどうか）であるのに対し、LLVMのルールは「プロセスベース」（提出前に人間が実際にそれを読み、理解したかどうか）である。

LLVMは、2025年を通じてLLM支援による迷惑なコントリビューションが増加したことを受け、2026年1月に「ヒューマン・イン・ザ・ループ」ポリシーを採用した。LLVMのフレームワークの下では、コントリビューターはコントリビューションを作成するために任意のツールを使用できるが、他のプロジェクトメンバーにレビューを依頼する前に、LLMが生成したすべてのコードまたはテキストを読んでレビューしなければならず、レビュー中に自分の作業に関する質問に答えられなければならない。コントリビューターは常に作成者であり、自身のコントリビューションに対して完全な責任を負う。

LLVMの選択は、異なる法的現実を反映している。LLVMはGPLではなく、LLVM例外付きのApache License 2.0の下で配布されている。AIの出力がGPLv3プロジェクトにとって脅威となる「著作権の空白」問題は、パーミッシブ・ライセンス（寛容なライセンス）のプロジェクトにとってはそれほど深刻ではない。なぜなら、これらのライセンスは条件を強制するために著作権の所有権に依存しておらず、単に帰属の表示とライセンス条文の保持を要求するだけであり、そのどちらも人間の著作権者を必要としないからだ。

このライセンスの違いが、GCCとLLVMが異なる結論に達した理由を説明している。GCCはAIに対する見解が異なるためにLLVMより保守的になっているわけではなく、異なる根底にある法的義務に対応しているのである。

■Codeberg、Flathub、そしてAIリポジトリ禁止の経済的理由

オープンソース界隈におけるAIコントリビューションへの抵抗のすべてが著作権法に関するものというわけではない。ヨーロッパにおけるGitHubの主要な代替手段となっているベルリン拠点の非営利コードホスティングサービスCodebergは、2026年7月22日に締め切られたメンバー投票の結果、主に生成AIによって書かれたコンテンツを含むリポジトリを禁止した。投票は賛成358、反対144、棄権14で可決され、約50%の投票率で約71%の支持を得た。

Codebergの理由は明確に経済的なものだった。同組織は決定を説明するブログ記事で、ハードウェアコストの上昇を主な要因として挙げている。数年前に約700ユーロ（約806米ドル、約12万8000円）だったストレージドライブは、現在では3,700ユーロ（約4,263米ドル、約67万8000円）近くに高騰し、頻繁に在庫切れになっているという。AI企業のクローラーが無差別にプラットフォームをスクレイピングし、あらゆるIssueのフィルターバリアントやgit履歴のあらゆるポイントを読み取ることでインフラに負荷をかけ、Codebergのボランティア管理者はそれを寄付金の予算から吸収しなければならない。AI生成リポジトリは、実際のメンテナやコミュニティを持たないにもかかわらず、適切に維持されているチームプロジェクトと同じペースでCI/CDやストレージリソースを消費する。

Flask Pythonフレームワークの作成者であり、AI企業Earendilの共同創設者であるArmin Ronacherは、Codebergの禁止措置を「非常に悪い動き」と呼び、ポリシーの文言にある「主に（mostly）」という修飾語が未定義であり、一貫性のない執行を生み出すと主張した。利用規約は現在、「主に生成AIツールによって書かれたコードで構成される」プロジェクトを禁止し、ClaudeとOpenAI Codexを名指ししているが、Codebergは特定のケースにおいて「主に」が何を意味するかを判断する基準を公開していない。

影響力の大きいプラットフォームの中で最初に動いたのは、Linuxアプリケーションの主要リポジトリであるFlathubであり、2026年5月29日付でAI生成の提出物を全面的に禁止した。この禁止措置は、アプリケーションコード、ビルドスクリプト、マニフェスト、メタデータ、ドキュメント、さらにはプルリクエストのテキストにまで及ぶ。GNOMEの拡張機能ホスティングサービスも、品質への懸念と、開発者が提出するコードを説明できる必要があることを理由に、2025年12月に同様の禁止措置を制定していた。

■メンテナたちを駆り立てた背景

これらのポリシーは孤立して生まれたわけではない。組織的な決定の背後には、AI生成の提出物の量と質によって引き起こされた、測定可能なメンテナの信頼の崩壊がある。Linus Torvaldsは、2026年5月のLinux 7.1-rc4リリースの投稿で、カーネルのプライベートなセキュリティチャンネルが、重複したAI生成のバグレポートの洪水によって「ほぼ完全に管理不能」になったと説明した。複数の開発者が同じツールを使用して同じ欠陥を同時に報告し、真に深刻度の高い報告を押しやってしまったのだ。

cURLの作成者であるDaniel Stenbergは、AI生成の提出物が全体の20%に達したことを受け、2026年1月に同プロジェクトのバグ報奨金プログラムを閉鎖した。プログラムの最後の数週間、AIのみによるレポートでプログラムの真の脆弱性を説明したものは一つもなかった。

Linuxカーネル自体はGCCとは異なる答えにたどり着いた。2026年4月、Torvaldsとカーネルメンテナは、貢献する開発者がAIの関与を開示し、出力に対して完全な責任を負い、コードが人間が書いた提出物と同じ品質基準を満たすことを保証する限り、AI支援によるコードを許可するポリシーを確立した。以前はAIの提出を制限していたQEMUは、2026年5月下旬にそれらの制限の緩和を検討していると発表した。Red Hatの仮想化エンジニアであるPaolo Bonziniは、機械的な変更、テスト、ドキュメント、および20行未満の小さなバグ修正についてAIの支援を許可することを提案し、ツールの品質が向上するにつれて全面的な禁止を正当化することが難しくなっていると主張した。

■次はDebianが投票へ

現在、最も影響力のある組織的な決定はDebianの手に委ねられている。2026年7月24日、DebianはDebianのコントリビューションにおけるLLMの使用に関する一般決議（General Resolution）を正式に開始した。議論期間に続いて、すべてのアクティブなDebian開発者による正式な投票が行われると予想されている。5つの競合する提案がテーブルに上がっている。

開発者のMatthias GeigerとJesse Rhodesによって提出された提案Aは、Debianのソースパッケージ、Debianソフトウェア、ウェブリソース、ドキュメント、翻訳、または公式コミュニケーションへのLLM支援によるコントリビューションを一切禁止するという全面的な禁止を求めている。Ian Jacksonによって提案された提案Cは、より広いソフトウェアの世界の多くがすでにAIに依存していることを考えると、全面的な禁止は現在非現実的であることを認めつつ、Debianのコントリビューターに可能な限りLLMの使用を避けるか思いとどまらせるよう求めるという中間的な立場をとっている。3つ目の提案は、Linuxカーネルのモデルと同様の開示要件とコントリビューターの責任基準を設けた上で、AI支援によるコントリビューションを許可するというものだ。

Debianの投票はDebianの枠を超えて重要である。アクティブなLinuxディストリビューションの約70%がDebianに系譜を持ち、Debianが採用するパッケージングポリシーは下流に伝播する傾向がある。もしDebianがLLMのコントリビューションを禁止すれば、その禁止措置は事実上、Linuxエコシステムの大部分のソフトウェアサプライチェーンをカバーすることになる。

現在正式なものとなったGCCのポリシーは、Debianの禁止擁護派に重要な組織的基準点を与えている。Debianが出荷するものの大部分をビルドするコンパイラが、AI由来のコードはGPLv3の強制に対して容認できない法的リスクをもたらすとすでに結論付けているのだ。Debianがこれに同意するかどうか、そしてどのような形で同意するかが、このガバナンスの物語の次の章を定義することになる。

■注目ポイントQ&A

●なぜAI生成コードは他のオープンソースライセンスではなく、特にGPLを脅かすのですか？

GPLの強制メカニズムは著作権の所有権に依存しています。FSFとコントリビューターはGCCの著作権を保持しており、これによりGPLの条件に従わずにプロプライエタリなソフトウェアにコードをコピーした者を提訴する権利が与えられます。米国著作権局は2025年1月に、人間の意味のある関与のないAI生成コンテンツは誰によっても著作権保護の対象にならないと判断しました。AI由来のコードがGPLプロジェクトに混入した場合、誰もその行の著作権を所有していないことになり、所有権がなければGPLを適用できず、ライセンスチェーンに法的な空白が生じます。LLVMが使用するApache License 2.0のようなパーミッシブ・ライセンスは、条件を強制するために同じように著作権の所有権に依存していないため、LLVMはより寛容なAIポリシーを採用することができました。

●GCCに貢献する際、AIツールでまだできることは何ですか？

コードベースの理解、技術の調査、バグの分析、アプローチの議論、または他の人が書いたパッチのレビューにAIツールを使用することは可能です。ポリシーは提出されるコントリビューションの内容を規制するものであり、その過程で使用されるツールを規制するものではありません。また、通常のコントリビューション要件を満たし、AIの関与を開示することを条件に、LLMによって生成された些細な1行のパッチや明らかに意味を持たないパッチを提出することもできます。ポリシーは、その出力が提出物の一部にならない限り、調査、分析、バグの発見と報告、およびパッチのレビューを制限から明確に除外しています。

●なぜGCCは例外としてAI生成のテストケースを許可したのですか？

テストケースが異なる扱いを受ける理由は2つあります。1つ目は、監査が容易であり、後で著作権の問題が発生した場合に削除しやすいこと。2つ目は、下流での商業的なコピーの標的になる可能性が低いことです。企業がGCCからコードを抽出してプロプライエタリ製品で使用することを選択した場合、テスト用のフィクスチャではなく、機能的な実装コードを標的にするでしょう。GCCのメンテナは、テストケースのリスクとリターンの比率が例外を正当化するほど異なると計算しました。ただし、その場合でもAI生成テストの人間によるレビューは引き続き必要です。

●Debianの投票は一般のLinuxユーザーにとって何を意味しますか？

DebianがLLM支援によるコントリビューションの禁止や大幅な制限を採用した場合、それらのルールはDebianの約1,000人のアクティブな開発者（Debianが出荷し、Ubuntuなどの下流ディストリビューションが引き継ぐ何千ものソフトウェアパッケージを維持する人々）が行うパッケージング作業に適用されます。エンドユーザーがポリシーの直接的な影響を受けることはありませんが、ポリシーはどのようなソフトウェアがDebianアーカイブに入り、どのようにレビューされるかを形作り、それが結果としてユーザーに届くソフトウェアのセキュリティとライセンスの完全性に影響を与えます。

元記事: Copyright Void: GCC Bans LLM-Derived Code to Protect GPLv3 License Chain