LLM Usage in Debian: Three Proposals

Proposal A is "expressly forbid any contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools."

Proposal B is "The Debian project allows AI-assisted contributions (partially or fully generated by an LLM), provided the following conditions are met [...]"

Proposal C is "request that all contributors to Debian avoid the use of LLMs in their Debian work" without an outright ban.

While doesn't matter much in the rest of the policy, this is a common misconception among AI skeptics. It is not the case for a long time (since RL is used heavily in the training) and a LLM may go beyond its training data.

  > Documentation and translations added by Debian contributors

However, in the case of item 4 of Proposal C, there are multiple kind of "assistance" that is possible; not all of them involve contributing the output of LLMs (e.g. the assistance might be to check for a mistake such as if a paragraph seems to be redundant or is incomplete or something like that; the result from the LLM might be incorrect but you will have to decide by yourself what (if anything) to do about it when writing your message). Even if some kind of assistance should not be banned entirely, it should still be discouraged (like the rest of Proposal C says). (Also, there are other programs that can sometimes be used for the assistance; e.g. sometimes ordinary spelling/grammar checking will do (although that won't find that an incorrect word that is spelled like a correct word in the correct grammar).)

I do not use LLM/generative-AI for any purpose, and would not accept contributions including their output into my projects, and would discourage other uses. (This seems to be similar to Proposal A and Proposal C.)

We are in the "cool new toy, let's make slop" phase, but we already see how careful use of LLM's can make high quality code faster and better than humans can do solo.

Once they are over the learning threshold, every good developer I know actually likes to use LLM's, as they allow them to realize their visions faster. If Debian has a "no LLM" policy I think they will eventually only have devs who like to type.

I should add that of course the "immoral companies burning too much energy" argument has actual merit, no matter how useful LLM's are or aren't. But I don't think Debian should die on that hill, as the only difference it will make is that we no longer have Debian.

Think about how far we've come over the past three years. Programming with AI in ten years will be utterly unfathomable. It would be like showing Fable 5 to someone a decade ago. It will be unbelievable.

In twenty years, programming by hand might be somewhat akin to writing assembly today: a skill that a limited number of programmers understand, and fewer still actively practise. Writing code by hand will become the new "I want to be close to the metal."

Perhaps by 2050, the concept of a Linux "distro" will be obsolete, replaced by a GPL-licensed local AI that just directly assembles everything from scratch to meet your exact specifications. Instead of relying on a predefined package manager, it traverses a distributed network of trust to find suitable candidate parts, downloading and verifying every line of source code before compiling it all locally. Trust would be rooted in the local AI's ability to understand and evaluate it, meaning that what replaces the distro are the groups competing for the best models.

Perhaps by 2070, nobody even writes or distributes code any more. The future kernel and web browser aren't code, they're descriptions of verifiable intent. A software project is really an extremely detailed description of what the software is meant to do. Your local GPL-licensed AI would decide how to write, assemble, patch, optimise, and integrate it for your hardware and your threat model. That would also blur the distinction between kernels, operating systems, and applications. The AI doesn't construct a computing environment as we know it today with discrete applications. It builds a coherent system that satisfies all requirements, rebuilding parts whenever your priorities change.

Downloading compiled code? Implicitly trusting someone else's source code? These will become the things people only do on hardware that is sufficiently air-gapped from any outside influence.

I think that's an unfortunate framing & I think A would be the best option for the opposite reasons. If they go with Proposal A, people will absolutely use AI tooling to contribute to Debian. This might be in bad faith (unlikely but possible), but it will also be done in good faith through a number of avenues:

1. people having a saturation of LLM tooling integrated into their development environment to such an extent that it can't help touching everything they code - an infrequent Debian contributor is unlikely to change their entire dev setup, stripping out, turning off & limiting various ai tooling configs, just to comply with one project's social contract.

2. some people will mislead themselves by reframing the social contract's stated intent to suit their own world view. Maybe they'll subconsciously ignore the "or other generative AI tools" & just avoid direct chatbots, categorising some other LLM assistive tooling as out of the scope of the ban. Or perhaps they'll reframe it in terms of generation: using LLM agents to investigate, understand & guide them in their work while they actively type out each line of code committed (occasionally copypasting from an LLM response but never granting it repo write access): "This doesn't count, right?".

3. Some contributors might simply not read the social contract carefully enough, miss this line, & innocently forget to mention their LLM usage when pushing patches.

And ultimately, that's all ok. That's the reality of the world we live in: the social contract is ultimately "social", it's not intended to be strictly enforcable, it's a statement of intent aimed at a community who are assumed to be (& generally are) acting in good faith.

LLM tools are great - they open up amazing new horizons of what individual devs can achieve, which is positive for open source in particular. But they also come with an incredible upscaling of open source review burdens & I think anything "less" than Proposal A actively invites a tsunami of slop.

On the other hand, they can produce and test anything anyone asks in minutes, as well as find security issues that lay dormant at the seams for decades.

There is no great answer here.

When the changes are small and properly reviewed, there's no point in caring how it was done. It should be trivial to write, but difficult to approve and merge.

Projects as significant as Debian should own the fact that they are indeed a bureaucracy and take inspiration from what has always worked long before LLMs.

Shouldn't OSS be the first to benefit? Or should OSS be a bedrock of carefully curated code untouched by AI slop?

Let the Salesforces and the Atlassians of the world destroy themselves with poor quality vibecode driven teams.

Using LLM to scan for security holes is another issue altogether.

> LLM output has very unclear legal status: it may be possible to copyright on its own merits, or not; it may be affected by all of the licenses and copyrights in the training data, or not. Debian Policy and the DFSG require absolute clarity for licensing and copyright[1][2]. Software and other contributions written conventionally by humans with unclear copyright or license status are not allowed in Debian; LLM output should not have a special exception to this.

The way the proposers portray it, this problem is a dealbreaker. Is the problem as portrayed? Do LLM vendors attempt to copyright the output?

Proposal B tries to solve one aspect of it:

> 2. Licensing and Attribution: If any pre-existing copyrighted materials (including pre-existing code licensed as free software) authored or owned by third parties are included in the AI tool’s output, prior to contributing such output to the project, the contributor should verify they have the right to submit it under the relevant open source license.

> 3. Accountability: Contributors assume full responsibility for their contributions, including vouching for the technical merit, security, license compliance, and utility of their submissions. The contributor remains solely accountable for the entirety of these contributions. Contributors should fully understand the proposed changes and be prepared to justify them.

How can a contributer know if LLM output includes "pre-existing copyrighted materials (including pre-existing code licensed as free software) authored or owned by third parties"? They can't be familiar with all pre-existing code in the world.

Maybe Debian could provide a search engine that looks for copyright violations, but do they really want to take responsibility for an issue with the risk of high liability? What if their search engine fails - maybe they could be sued for that too.

Also, that doesn't seem to address the IP of the LLM vendor.

We've accepted compilers, static analyzers, and code generators because the maintainer is still responsible for the final result. The interesting question is whether LLMs fundamentally change that responsibility, or just change the kinds of mistakes reviewers need to look for

Elementary, Redox and Gentoo already banned it. Nix and Fedora allow it with disclosure. Now Debian and Arch are debating whether to adapt or seal their fate alongside Gentoo. Nix and Fedora got it right. Debian and Arch are deciding whether they want to remain relevant or fade into irrelevance.

Using LLM encourages data theft or unethical acts.

What if Claude goes down on approach? Or you run out of OpenAI tokens just before touchdown? What’s the point of having a named pilot if the control of the aircraft is in someone else’s hands, in part or in whole?

With actual pilots you have to take an exam and pass a practical test to prove you are competent. It’s a part of the analogy that could apply well to the real world Debian project.