Debian LLM Usage Proposals: Balancing Stability and AI Integration

The Debian project is currently evaluating four competing proposals to determine how Large Language Models (LLMs) and generative AI should be integrated into—or excluded from—the development of the operating system. These proposals reflect a fundamental tension between maintaining Debian's reputation for stability and the practical reality of AI's proliferation in software development.

Proposal A: Total Prohibition of LLM Contributions

Proposal A seeks to expressly forbid any contributions to Debian written with the assistance of LLMs or generative AI tools. This proposal suggests adding a specific clause to the Debian Social Contract to formalize this ban.

Scope and Rationale

The ban would apply to Debian source packages, official project software (such as lintian), web resources, documentation, translations, and official communications. It explicitly excludes upstream projects that use LLMs, AI-related software, and upstream security fixes.

The rationale for this prohibition is based on four primary concerns:

1. Copyright and Licensing: The legal status of LLM output is considered unclear, which conflicts with the Debian Free Software Guidelines (DFSG) requirement for absolute clarity in licensing.
2. Quality and Accuracy: Proponents argue that LLMs produce "syntactically likely combinations" rather than verified facts, leading to hallucinations and outdated packaging syntax that would be unfit for upload.
3. Community Health: There is a concern that LLM-dependent new contributors will not learn the intricacies of Debian packaging, placing an undue review burden on experienced developers and leading to burnout.
4. Ethics: The proposal cites the unethical scraping of the web by AI companies, the environmental cost of training models, and the resulting Denial of Service (DoS) attacks on public web resources.

Proposal B: Regulated Acceptance of AI Assistance

Proposal B allows AI-assisted contributions provided they meet strict conditions regarding legality, accountability, and transparency. Rather than a permanent ban, this proposal views the project's position as an evolving statement that can change without requiring a new general resolution.

Requirements for AI Contributions

Under Proposal B, contributions are permitted if the following conditions are met:

• Legal Compatibility: Tool terms must not conflict with Debian's distribution or modification rights.
• Licensing Verification: Contributors must verify they have the right to submit any pre-existing copyrighted materials included in the AI output.
• Full Accountability: The human contributor assumes sole responsibility for the technical merit, security, and license compliance of the submission.
• Disclosure: Significant use of AI tools must be disclosed (e.g., via a Git trailer like Generated-By:).
• Bulk Change Coordination: Automated or bulk changes must be discussed with the community prior to submission.
• Privacy: Sensitive or non-public project information (such as embargoed security reports) must not be transmitted to cloud-based AI providers.

Proposal C: Discouragement and Targeted Restrictions

Proposal C requests that contributors avoid LLMs as far as practical, while imposing a strict ban on AI-generated human communication. This approach acknowledges that a total ban is impractical because many upstream projects already use LLMs.

Key Mandates

• Human-Only Communication: Messages to humans—including bug reports, mailing list posts, and blog posts—must be drafted solely by humans without LLM assistance.
• Disclosure: Any use of LLMs for Debian work must be disclosed.
• Project Autonomy: Individual maintainers or projects within Debian may implement their own total bans on LLM contributions.
• Code of Conduct: Violations of these requirements would be treated as violations of the Debian Code of Conduct.

Proposal D: Responsibility-Based Guidelines for Debian-Specific Work

Proposal D accepts AI contributions for work done specifically for the Debian project, placing the burden of verification entirely on the contributor. It explicitly states that Debian does not endorse or recommend generative AI but acknowledges its prevalence.

Guidelines for Implementation

• DFSG Compliance: All AI-assisted work must comply with the Debian Free Software Guidelines.
• Submitter Responsibility: The submitter must fully understand the work, be able to defend it, and manually apply all GPG signatures and Signed-off-by tags.
• Marking: AI-assisted work should be marked in the commit message or changelog, though lightweight tools like tab-completion (e.g., Copilot) are treated with more leniency.
• Data Security: Cloud-based AI must not be used for sensitive or non-public project data.

Community Perspectives and Synthesis

Discussion among the community highlights several critical points of contention regarding the enforceability and philosophy of these policies:

The Enforceability Gap

Several contributors noted that a total ban (Proposal A) is essentially unenforceable. As one observer noted, many developers have AI tooling so deeply integrated into their IDEs that stripping it out for a single project is impractical. Others argue that a "statement of intent" is sufficient to guide a community acting in good faith.

The Review Burden vs. Productivity

There is a divide between those who see AI as a "tsunami of slop" that will overwhelm human reviewers and those who believe AI can help high-quality developers realize their visions faster. One community member argued that LLMs do not necessarily lower code quality but rather highlight those who are "just going through the motions," suggesting that the rigor of the review process—rather than the tool used to write the code—is the primary safeguard.

Legal and Ethical Concerns

Critics of AI integration point to the "unclear legal status" of LLM output as a dealbreaker for a project as conservative as Debian. Conversely, others question how a contributor could possibly verify that an LLM has not included copyrighted snippets from a third party, suggesting that the requirements in Proposal B may be technically impossible to satisfy.