Debian General Resolution on LLM Usage: Proposals A-D Explained

Overview

Debian の 2026 年 7 月 25 日 の General Resolution 投票では、プロジェクトが大規模言語モデル (LLM) またはその他の生成 AI ツールを含む貢献をどのように扱うべきかという 4 つの競合する提案が提示されています。提案は全面禁止から条件付きの許容枠組みまで幅広く、コミュニティは最終決定前にそれらを議論しています。

Proposal A: outright ban

Proposal A は、LLM やその他の生成 AI ツールの使用または支援を伴って書かれた Debian へのあらゆる貢献を明示的に禁止することを求めています。その範囲は Debian ソースパッケージ、公式プロジェクトソフトウェア、ウェブリソース、ドキュメント、翻訳、公式コミュニケーションをカバーしますが、LLM を使用する上流プロジェクトや AI 関連ソフトウェアは除外します。根拠として挙げられているのは 4 つの懸念です：LLM 出力の著作権ステータスが不明瞭であること、品質と正確性の問題、コミュニティレビューアーへの負担、LLM 訓練データのスクレイピングとリソース消費による倫理的害。疑問を払拭するため、提案は Social Contract に条項を追加し、Debian は LLM を通じて直接作成された貢献を許可しないと述べています。執行は困難であると認められていますが、コミュニティの善意に依存しています。

Proposal B: conditional allowance

Proposal B は、以下の 6 つの条件を満たす場合、AI‑支援貢献（LLM によって部分的または完全に生成されたもの）を許可します：(1) ツールの法的互換性、つまり AI の利用規約が Debian の配布、変更、使用と矛盾しないことを確認する；(2) ライセンスと帰属、出力に含まれる第三者の著作物が該当するオープンソースライセンスの下で使用できることを検証することを要求する；(3) アカウンタビリティ、提出者が技術的価値、セキュリティ、ライセンス遵守、有用性について単独で責任を負うようにする；(4) 開示、AI 生成または AI‑支援作業の相当な部分を目に見える形でマークすることを義務付ける（例：Git トレーラー経由）；(5) 大量または自動変更の事前議論、マスバグフィリングプロセスに似たプロセスで、人間の監視者を置く；(6) 機密性とプライバシー、非公開または機密性の高いプロジェクト情報を露呈する可能性のあるクラウドベースの AI の使用を禁止する。

Proposal C: discouragement with disclosure requirements

Proposal C は outright ban を課さず、すべての貢献者に Debian の作業で LLM を使用しないよう求め、意思決定者に実務的に LLM の使用を控えるよう促し、広いフリーソフトウェアコミュニティにもこの技術を控えるよう求めます。さらに、行動規範に以下の 8 つの要件を追加します：(1) 人間向けのメッセージは LLM の支援なしに人間だけが作成しなければならない；(2) Debian の作業で LLM を使用する場合は開示しなければならない；(3) 個々のプロジェクトとメンテナーは LLM 貢献を完全に禁止でき、その禁止は尊重されなければならない；(4) 違反は行動規範違反として扱われ、迅速かつ適切な懲戒処分の対象となる；(5) 英語を支援なしで書けない貢献者は母国語で書くことができ、人間が書いた英語の要約は歓迎されるが必須ではない；(6) この提案は、上流での使用があるため現在完全禁止は現実的ではないことを認めている。

Proposal D: accept AI contributions for Debian‑specific work

Proposal D は、AI‑支援の実践がすでに使用されていることを認め、貢献者に責任を負わせることを選択し、禁止するのではなくガイドラインを設ける。ガイドラインは、Debian プロジェクト専用のコードと作業（ウェブサイト、アプリケーション、リソース、パッケージ）にのみ適用される。貢献者は、作業が DFSG に適合していることを確認し、提出した作業について単独で責任を負い、その内容を理解し擁護できるようにし、Signed‑off‑by タグと GPG 署名を自分で適用し、本番インフラストラクチャにアップロードするコンテンツについては自分自身が明示的に提出することを確保しなければならない。生成 AI エージェントまたはツールによる支援作業は、適切な場所（コミットメッセージ、変更履歴など）にその旨をマークし、軽量ツール（タブ補完など）は気づかずに使用される可能性があるため、貢献者はルールが適用されるタイミングを評価すべきである。最後に、送信されるデータがプロジェクトにとって機密であるか公開されていない場合は、クラウドベースの AI を使用してはならない。

Community discussion on Hacker News

Commenters highlighted several points of contention and clarification:

• @simonw noted that the page presents three separate proposals (A, B, C) that will be debated and voted on, not a final decision.
• @hkalbasi corrected the claim that LLMs merely produce "syntactically likely combinations" of training data, pointing out that reinforcement learning enables LLMs to go beyond their training data.
• @Meneth observed that Gentoo banned LLMs two years ago and appears to be doing well.
• @rixed wondered what fraction of the upcoming Trixie release already violates the ban proposed in Proposal A.
• @zzo38computer suggested combining elements of Proposal A (limited to contributions that actually involve LLM output or blind trust) with Proposal C for other cases, and questioned the definition of "assistance" in Proposal C.
• @russfink asked whether using Claude Code to find bugs and suggest fixes, while a human edits and tests the source, counts as assistance.
• @mike_hock expressed hope that the community would choose Proposal C.
• @dismalaf questioned whether using Gemini as an ad‑free front‑end to Google search would be considered forbidden "use" or "assistance).
• @mmooss raised concerns about how contributors could verify that LLM output does not contain pre‑existing copyrighted material, noting the practical difficulty and potential liability.
• @nilespotter characterized Proposal D as "use LLMs but don’t tell anyone\
• @sublinear argued that the real issue is lack of discussion justifying changes, not LLMs themselves, and that proper review can mitigate risks.
• @JuettnerDistrib found it ironic that OSS projects consider banning LLMs after OSS enabled their development.
• @TZubiri criticized the proposals for not distinguishing between using LLM output and using LLM assistance for conversation or analysis.
• @Kon5ole predicted that a strict "no LLM" policy will become untenable as LLMs improve, though he acknowledged the ethical concerns about energy use.
• @logicallee summarized the trade‑off: LLMs can generate and test code quickly but may ignore unwritten norms derived from maintainers’ experience.

Conclusion

The Debian project faces a choice between a strict prohibition, a conditional permissive framework, a strong discouragement with disclosure, or an acceptance‑with‑guidelines approach. Each proposal reflects different weightings of copyright risk, quality assurance, community impact, and ethical considerations. The ongoing discussion, as seen in the Hacker News comments, reveals deep uncertainty about enforcement, the meaning of "assistance," and the practicality of a ban given widespread upstream use of LLMs.