Debian Is Setting Rules for AI-Generated Code

The Debian community is attempting to draw a formal boundary around AI-assisted development.

On July 24, a Debian developer introduced a General Resolution proposal on the use of large language models, asking the community to decide whether contributors should be allowed in the future to use LLMs and generative AI to write code, documentation, and announcements, or even to participate in bug reports and internal email discussions.

As of July 26, the matter remains at the proposal and discussion stage. This does not mean Debian has already banned or formally accepted AI-generated content. The three options before the community represent three distinctly different approaches to governance: a comprehensive ban; permission with contributors assuming full responsibility; and rejection in principle with exceptions allowed in practice.

This is not a simple vote for or against AI. What Debian really needs to resolve is an issue that has already entered the everyday workflows of open-source projects: when contributors cannot prove whether a piece of code came from themselves, a model, or training examples memorized by that model, can the copyright declarations, license propagation, and accountability mechanisms on which traditional open-source collaboration relies still function properly?

Three Proposals Represent Three Fundamentally Different Views of Risk

The three options in the proposal are not merely different phrasings of the same rules. They reflect fundamental disagreements over whether generative AI can be controlled.

Proposal A: Completely Ban AI-Generated Official Contributions

The strictest option would prohibit the use of LLMs or other generative AI tools for official software code, documentation, and announcements. Even if developers inspect, modify, and approve model output, they would still be prohibited from submitting it to Debian.

The rationale behind this proposal is straightforward: human review can determine whether code works, but it may not be able to establish the code’s copyright provenance.

A model might generate an apparently ordinary function, but contributors are usually unable to answer several critical questions:

• Was the implementation assembled on the fly by the model, or is it an approximate reproduction of training material?
• If it closely resembles a project protected by a restrictive license, does Debian have the right to continue distributing it?
• Do the model provider’s terms of service actually transfer sufficiently comprehensive rights to the user?
• If a copyright dispute arises, who can provide provenance evidence comparable to a Git commit history?

In addition, LLMs can generate deprecated APIs, outdated package configurations, and code that appears plausible but fails in edge cases. For an ordinary application, this might merely cause a production outage. For a project like Debian, which sits upstream of vast numbers of servers, cloud images, and downstream distributions, errors can rapidly propagate through the software supply chain.

Proposal A has the advantage of clarity: reviewers would not need to determine whether a particular use of AI was “minor enough.” Its disadvantage is equally obvious: it would be nearly impossible to verify effectively.

Developers can disclose that they used AI, but they can also choose not to. After code has been repeatedly rewritten, no reliable tool can determine from the text alone whether a model was involved in generating it. More practically, much of the upstream software packaged by Debian may already have been developed with AI assistance. Even if Debian’s own maintainers never use AI, it would still be difficult to provide a certificate of “AI-free” development for the entire upstream dependency chain.

In other words, a comprehensive ban would be easy to write into policy but difficult to implement.

Proposal B: AI May Be Used, but Submitters Cannot Shift Responsibility to the Model

The second option would allow contributors to use AI-assisted development but require the person pressing the submit button to assume full responsibility.

Submitters would need to confirm that the content can be distributed under licenses accepted by Debian, check whether it contains third-party code, and take responsibility for its quality, security, and copyright compliance. Contributions involving AI would also need to be labeled accordingly.

In practice, this option extends the accountability model that open-source communities already use: tools may change, but the responsible party cannot.

In the past, developers might have found a piece of code through a search engine, a forum answer, or another project. Copying that code into a project did not eliminate the obligation to review its license merely because “a search engine recommended it.” Proposal B attempts to treat LLMs as similar tools, except that their results are more complete, their sources more opaque, and their output more likely to create the illusion that “the model created this originally.”

This option most closely resembles the actual workflows of today’s development teams. AI can help explain unfamiliar code, generate tests, organize changelogs, or produce an initial patch, but its output cannot enter the repository without review. Maintainers review the final submission, and the project holds the submitter accountable—not a model that cannot participate in mailing-list discussions, much less respond to security advisories.

The difficulty with Proposal B, however, is that being “fully responsible” does not mean being “capable of proving provenance.” A developer may sincerely believe that an output poses no copyright problems while having no way to inspect a proprietary model’s training data. Disclosure labels can improve transparency, but they cannot automatically resolve questions of unknown provenance.

Proposal C: Avoid AI in Principle, but Acknowledge That a Comprehensive Ban Is Unrealistic

The third option is more of a compromise between political principles and engineering realities.

It argues that LLMs have serious problems, should not become part of Debian, and certainly should not replace human contributors. At the same time, it acknowledges that many developers and upstream projects have already begun using AI, making complete isolation from generative AI effectively impossible. Contributors should therefore avoid using it wherever reasonably practicable, handling and disclosing necessary uses on a case-by-case basis.

This option would impose stricter rules on internal project communications: internal emails, bug reports, and articles should be written by humans without AI assistance. Package maintainers, meanwhile, could decide whether packages under their responsibility would accept code involving AI. Contributors who violate the rules could face warnings or community sanctions.

The value of Proposal C lies in its acknowledgment of reality, but it may also carry the highest enforcement costs.

What exactly does “avoid wherever possible” mean? Would using a model to translate an email count? Would contributors need to disclose using AI to summarize build logs, generate a regular expression, or complete a single line of test code? If different maintainers apply different policies to different packages, contributors would need to understand an ever-changing map of rules.

A comprehensive ban would at least be simple, while comprehensive permission with accountability would provide a clearly responsible party. “Opposed in principle, with case-by-case exceptions,” however, would transfer much of the burden of judgment to maintainers.

Debian’s Primary Concern Is Traceability, Not Coding Ability

Interpreting this dispute as “an established open-source community rejecting new tools” would miss the real issue.

Debian is not testing whether LLMs can produce a working patch. Today’s mainstream models can certainly perform many development tasks, particularly boilerplate code, unit tests, first drafts of documentation, and fixes for common errors. The issue is that open-source projects require more than code that works: contributions must also be legally modifiable, maintainable over the long term, and redistributable.

In traditional open-source collaboration, a piece of code usually has a relatively clear chain of provenance: an author submits a patch and declares that they have the right to contribute it; a maintainer reviews it; Git preserves the modification history; and the license defines how it may subsequently be used. LLMs insert an opaque intermediate layer into that chain.

Model output is neither a conventional reference to a third-party codebase nor entirely equivalent to a developer’s independent creation. It may be statistically generated, may contain structural traces of training material, or, in extreme cases, may reproduce lengthy passages. For Debian, the most difficult problem is not that every output necessarily infringes copyright, but that the project cannot consistently prove that it does not.

AI also changes how maintenance costs are distributed. Generating a patch may take only a few minutes, but reviewing it still requires maintainers to understand the context, run tests, verify licensing, and inspect security boundaries. If large numbers of contributors use models to mass-produce patches that are “80% correct,” the increase in production speed may consume scarce maintainer attention even faster.

It is much like spam: reducing the cost of sending something to nearly zero does not also reduce the cost of receiving and evaluating it to nearly zero.

The Dispute Has Expanded From Model Files to Project Workflows

Debian has previously discussed whether AI models themselves comply with the Debian Free Software Guidelines. One of the central conflicts was whether models that include only weights and inference software—but lack the original training data and complete generation process—can be considered to have modifiable and reproducible “source code.”

This proposal addresses a different layer of the issue: even if the models themselves do not enter Debian’s software repositories, may developers use them to produce content that will?

The distinction is similar to this: the previous debate was about “whether this machine can be placed in the repository as a product,” while the current debate is about “whether this machine can be used to manufacture parts that go into the repository.” The latter question has broader implications because it affects not only model packages but nearly all code, documentation, and communication processes.

It is particularly notable that none of the three proposals limits the issue to code completion. Announcements, documentation, bug reports, and internal emails are also included in the discussion. This shows that the community is concerned not only about vulnerabilities but also about project governance itself.

Mailing lists and bug-tracking systems are both communication channels and records of decision-making. If large amounts of content are drafted by models, the community may find it difficult to determine whether speakers genuinely understand and support the views they submit. For an open-source project that operates through asynchronous discussions and personal reputations, this is not a matter of writing style but of identity and responsibility.

A Comprehensive Ban Would Be Difficult to Enforce; Accountability Is More Likely to Become the Long-Term Baseline

From an enforcement perspective, Proposal B comes closest to providing an institutional foundation that can function over the long term: allow tools into the workflow, but firmly bind responsibility for licensing, quality, and security to the human submitter.

This does not mean that “AI generates it, and a human gives it a quick look” would be sufficient. A genuinely effective accountability framework would require at least several supporting measures:

1. Clearly define the scope of disclosure: Distinguish between code completion, generation of entire sections, translation, summarization, and simple information retrieval, rather than reducing every activity to a vague “AI was used” label.
2. Preserve generation and modification records: For larger patches, retaining prompts, model versions, outputs, and records of human modifications could aid subsequent audits, though care must also be taken not to expose private data.
3. Strengthen provenance checks: Outputs that are unusually complete, show abrupt stylistic changes, or contain distinctive comments should be subjected to similarity searches rather than merely compiled and tested.
4. Restrict sensitive use cases: High-risk components such as encryption, authentication, package signing, and installation scripts should not rely solely on general-purpose model generation and ordinary code review.
5. Control floods of low-quality contributions: Maintainers need the authority to quickly close AI-generated patches that lack validation or whose implementation logic contributors cannot explain. Otherwise, community resources will be consumed performing basic checks on contributors’ behalf.

Proposal C could also serve as a transitional approach, particularly for a community that wants to express caution without imposing an unenforceable ban. Without more specific disclosure standards, however, it could easily produce inconsistent policies from package to package, leaving maintainers to handle disputes on their own.

As for Proposal A, its assessment of copyright and community-culture risks is not unreasonable. It would simply be difficult to verify technically and difficult to isolate at the supply-chain level. An unauditable ban might ultimately punish contributors who disclose their AI use honestly while failing to identify those who do not.

This Vote Could Become a Model for Other Open-Source Projects

Debian is distinctive because it is both a community project and a foundational component of the vast software supply chain. Its policies will affect more than a small number of core developers; they may also be referenced by upstream projects, downstream distributions, corporate compliance teams, and software bill of materials tools.

If Debian ultimately adopts the approach of “AI may be used, it must be disclosed, and submitters bear full responsibility,” other projects will likely adopt similar frameworks and may add model names, the proportion of generated content, and review records to their contribution templates. If it chooses rejection in principle, it will encourage the development of detection, auditing, and contribution standards for AI-free community development—even though such mechanisms would be difficult to make fully reliable.

Over the longer term, open-source communities may need more than a simple AI label. They may need a new provenance-verification framework. Future commit records may need to answer not only “who changed this line of code?” but also “what model was used, which parts did the model generate, what changes were made by humans, and on what basis was the content deemed distributable?”

This would add procedural overhead, but it would be more honest than pretending AI has not entered development environments.

That is precisely where the value of Debian’s discussion lies: it does not treat AI-assisted programming merely as a productivity tool. Instead, it places the issue back within the three concepts at the heart of open-source software—provenance, licensing, and responsibility.

A model can generate a patch, but it cannot sign a contributor’s declaration; it can explain code, but it cannot assume responsibility for incidents on a maintainer’s behalf; it can imitate the language of a community, but it cannot automatically earn that community’s trust.

Whichever option Debian ultimately chooses, it is affirming the same principle: AI may participate in production, but open-source projects cannot automate responsibility along with it.

References

• ITHome: Debian Project Introduces Proposal to Discuss Whether AI Models Should Be Allowed to Participate in Development — Summarizes when the General Resolution was introduced, the three proposed approaches, and their respective accountability and disclosure requirements.