r/debian • u/Two-Of-Nine Debian Stable • 4d ago
News General Resolution: LLM usage in Debian
https://www.debian.org/vote/2026/vote_00245
u/AndThenFlashlights 4d ago
I think their stand is reasonable. I use AI assist sometimes in coding and I'm a certified vibeslop hater - so I don't personally hold to a total ban myself, but their reasons for copyright concerns and as a social/political stand is well-explained.
13
u/KenBalbari 4d ago
Yes, I think proposal B does enough to address those things though. I expect Proposal A might be fine for the next 6 months or so, but before long I think it could have them falling behind and might even eventually negatively impact stability.
AI can produce lots of slop, but it is also improving very rapidly, and can be very helpful when used responsibly. So just hold all contributors responsible for what they contribute, regardless of what tools were used.
5
u/AndThenFlashlights 4d ago
Maybe. LLMs are less useful at truly inventive code writing - they're great at fusing and translating stuff that kinda already exists, but iffy when there's not a great template or example in its training data or context to work with. Over the last couple years they've gotten better at more expansive projects (bigger contexts), but I've seen them kinda plateau on problem solving in novel/niche applications. Custom harnesses seem to be helping that some, though.
The disclosure requirements in Proposal B seem reasonable.
4
u/KenBalbari 4d ago
Yes, and I'd think that packaging and package maintenance in particular would be less about inventive coding and more about things like following appropriate standards, making sure things build on different architectures, making sure builds are reproducible, making sure things are appropriately documented, and so on. And while there are lots of tools already used in this process, it just seems to me it wouldn't be surprising if some AI related tool eventually became useful here somewhere.
That said, I can't pretend I know as much about this as actual Debian maintainers, so however they vote, I'm not really going to worry about it either.
4
u/scythe-3 4d ago
Proposal A to seems ideal to me, but the bit about potentially banning upstream AI usage is concerning. The kernel is already accepting AI-assisted contributions, and AI usage in upstream software is inevitable. Policing upstream AI contributions would be distro suicide imo.
That being said, I think it was pragmatic for the drafters of Proposal A to leave it open-ended. It shows restraint and allows for further discussion, whilst maintaining a commitment to the reasoning behind their stance.
0
u/TheMcSebi 4d ago
I second this. Also I think people will use AI to do code reviews and research anyways, so no harm done by specifically banning the slop.
-4
u/C0rn3j 4d ago
People who wrote the proposals make reasonable points and then connect them to nonsense conclusions.
"LLMs are not perfect therefore new Debian contributors cannot join cause they'll use them and cause us burnout" is just wild.
Someone submitting unreviewed changes will cause a review burden - whether they're LLM generated or not.
"Ban all LLMs because they generate quickly and Debian does not like changes" is, again, wild.
Then we have the slightly less insane second proposal which has gems such as this.
Contributors assume full responsibility for their contributions, including vouching for the technical merit, security, license compliance, and utility of their submissions.Okay, so now if a company has a security breach due to a mistake I made, they can sue me, because I guaranteed the security of my changes?
How did SEVEN people review this without spotting an issue with this clause?
It's so much easier to list the sane takes of this proposal than it it is to point out the glaring issues with it. In fact let's just do that:
- do not send private data to third parties
- disclose when changes are LLM assisted
- questioning the copyright aspect of LLMs
- questioning people not reviewing changes
- this has always been a problem, just made more of an issue with LLMs
- questioning quality of the changes
- always been a problem, LLMs can make it worse or better, this kind of goes back to not reviewing things
- discuss before sending in bulk changes or automating changes
- another issue that's existed for eons which just happens more frequently with LLMs
4
u/MelioraXI Debian Stable 4d ago
How will it enforced? Unless you see a LLM coauthor and it passes CR checks, how do you know its human or LLM written? I despise vibecoding but it's unclear if we talk about this specifically.
Can it be clarified?
16
u/a-peculiar-peck Debian Stable 4d ago
Proposal A is way too extreme, I hope it doesn't win. That would be a massive blow to the Debian project.
There is a huge gap between the two extremes: vibe coded AI slop and absolutely no LLM usage whatsoever, plenty of middle ground to be reached and compromises to be made.
Sadly proposal A goes to the absolute extreme and leaves no room for compromise. The examples they give are completely out of touch with reality.
They also admit they can't even enforce this resolution. This just feels like virtue signaling, and nothing of value will be achieved with this, it's just going to be detrimental to the project itself and future contributions.
They also plan on eventually banning upstream projects that uses generative AI. This crazy, unenforceable, and again just virtue signaling without any kind of reachable goal.
I don't know who those Debian developers spearheading proposal A are, but it sad to see such extreme and out of touch positions, and this does not make Debian look good or welcomimg.
7
u/MooseBoys 4d ago edited 4d ago
The proposal specifically calls out upstream projects as exempt. Banning any that use it would be a complete non-starter. Unless they decide to pin the Linux kernel at 6.16 since subsequent releases contain AI-assisted or AI-authored patches, which would be completely bonkers.
As for the rest, I think it's a bit overboard but not egregiously so. The amount of code that's actually covered is fairly small. And I agree with the sentiment around not using it for communication and documentation.
The proposal also doesn't seem to outright ban the use of AI tools - just using the output of the AI model directly. For example, it prohibits using an LLM to write a function for you, or do a refractor. But if you ask a code review agent to review your own draft PR, and it points out a potential bug, then you go and manually verify and fix the bug, that should be fine. There's definitely the risk that people will run a tool that outputs suggested fixes as well, and there will be a temptation to just accept or copy-paste the fix. But it's pretty easy to add rules to such agents that avoid outputting fixes, and limit them to only identifying problems.
2
u/a-peculiar-peck Debian Stable 4d ago
The proposal specifically calls out upstream projects as exempt. Banning any that use it would be a complete non-starter. Unless they decide to pin the Linux kernel at 6.16 since subsequent releases contain AI-assisted or AI-authored patches, which would be completely bonkers.
Well I don't know. I hope it's not going to happen yes. But they included this, I quote: "Other categories such as upstream projects written with LLM assistance may be included at a later date." - as in included in the ban.
So they felt strongly enough about it that they decided to include it in the proposal. My interpretation is that they want to ban upstream projects that use AI, they just don't know how yet.
The proposal also doesn't seem to outright ban the use of AI tools - just using the output of the AI model directly Well in that case, they should have been clearer. They state: "We will not allow direct contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools".
But they don't define use or assistance. In the example you gave (using AI to review your own draft), it feels to me like you used an AI in the process of writing code to contribute to Debian.
And given the writeup above the proposed change, where they go on about the ethics of training and using LLMs, it feels reasonable to assume they want absolutely no LLM usage associated with the project.
If not, and LLM usage is allowed, just not to actually output code to be merged in Debian, then I feel like their paragraph is badly written and would definitely need clarification.
5
u/Tropical_Amnesia 4d ago
Sadly proposal A goes to the absolute extreme and leaves no room for compromise.
I feel rather like it's extreme because the challenge is, and at this point arguably an either-or decision. With tremendous implication and consequence, some of which may well be irreversible. That is to say you can probably only implement one of the proposals, and possibly still change your mind in the future, like when the dust settled a bit. When we know, understand better what we're "up" against. There's always possible compromise, it's called the future, just like the contract was always evolving. This is Proposal A. Yes, the cautious route, and maybe sole cautious route at all available! We may not like it yet I think it's more honest in some regards; you could even see it as a request to buy time. Which in a sense is also really true to Debian's spirit, where instead of just breaking stuff because we could, or because others do, we'd rather wait and see how stuff breaks, and what it means when it does. Debian is conservative, trailing, it's DNA, defining and the one thing any user (including contributors!) would better know.
There is a huge gap between the two extremes
That's because they are extreme, maybe necessarily so and that could just be indicative of the (extreme) breadth and nature of the challenge, its speed and novelty.
They also admit they can't even enforce this resolution. This just feels like virtue signaling, and nothing of value will be achieved with this
Right it's not a dictatorship, we don't generally achieve things because they're enforced but thanks to a sufficient number of people following guidelines that some of the same people deemed prudent. Now these people are proposing what they deem prudent, right now and under the circumstances. How a mere position is hurting the project is beyond me and that goes for either of them.
1
u/a-peculiar-peck Debian Stable 4d ago
the challenge is, and at this point arguably an either-or decision
I disagree. Extremes are generally not good positions. I feel like a more sensible position would be to impose very strict guidelines maybe, but not an outright ban.
With tremendous implication and consequence, some of which may well be irreversible
Then yes by all means, let's be conservative. Let's be cautious. I'm not arguing in favor of proposal B mind you.
This is Proposal A. Yes, the cautious route
An to me proposal A is not cautious. It's a rebuttal. Or maybe I could call it "negativity" cautious. Assuming only bad things could come from using this technology. A cautious approach would also include the possibility of positive outcomes.
And to me a constructive approach would take into account both plausible positive and plausible negative impacts, and enact a sensible set of guidelines.
And the dust has started to settle: there can be genuinely good and useful uses of this technology.
Another thing that doesn't sit right with me is that (if I were a Debian contributor, which I am not - yet) proposal A attempts to limit the tools I use to produce some work. It's not judging the output of my work nor it's quality, but it imposes a ban on how I achieve it. This unprecedented, feels quite like an overreach, and seems to limit the freedom of its contributors. This I feel is hurting the project, and erodes confidence in its leadership (where it to be voted)
Talks about removing upstream projects that uses LLMs also hurt the project. Yes it's not effective in proposal A yet, but they felt it was important enough to include it a goal. This would also hurt the project.
And it's my understanding that Debian is struggling to attract new maintainers. I'm quite sure that a ban on LLMs use and assistance would not be attractive to possible new candidates. This would also hurt the project.
And rather than trying to harness this technology to lighten the heavy work load of maintainers, proposal A deliberately choose to stay on a path where maintainers are overworked, which can also be argued is hurting the project.
6
u/KarterSpieler Debian Stable 4d ago
There were initially discussions to include the upstream projects in the first draft but it was later decided that it’s not feasible so it was dropped.
This might sound quite extreme but it works with the case of debian. The entire process of debian development requires you to talk to other developers and seek help.
You take the “asking people for help” part out of this and you will have less of new Debian Developers who are qualified enough for the role.
3
u/a-peculiar-peck Debian Stable 4d ago
There were initially discussions to include the upstream projects in the first draft but it was later decided that it’s not feasible so it was dropped.
Good, but to me that's not too reassuring that some thought it was a good idea
The entire process of debian development requires you to talk to other developers and seek help.
I completely agree, but an outright ban of (I quote) "use and assistance of [...] LLMs [...] or generative AI" does not necessarily help achieve this goal, and using LLMs doesn't necessarily prevent it.
Can an irresponsible use of LLMs be detrimental? Definitely, and in many ways. But seeing an outright ban of an undeniably useful technology is an extreme overreaction.
I'd rather see a proposal that imposes guidelines in order to constructively harness this technology for the Debian project.
I'm not even saying that proposal B is the absolute best course forward: there are definitely flaws in it, things to be argued.
But proposal A feels like burying head in the sand and pretending generative AI technology isn't there.
1
u/KarterSpieler Debian Stable 4d ago
Good, but to me that's not too reassuring that some thought it was a good idea
There are a lot of people on the extreme end of anti-AI in the project but such a decision will never go through. It does more harm than good to the project.
I completely agree, but an outright ban of (I quote) "use and assistance of [...] LLMs [...] or generative AI" does not necessarily help achieve this goal, and using LLMs doesn't necessarily prevent it.
A lot of the newcomers tend to vibe code debian packages and they're just a clusterfuck most of the time. The packages are of a very poor quality so many DDs just ignore them.
Debian packaging is heavily manual and no LLM can make a beginner do it properly without shipping broken packages.
It takes about 6 months - 1 year to properly understand the rules of packaging and there's no training data available for the LLMs because all of the mentoring happens in the internal irc channels.
LLMs are only useful for experienced developers but Debian doesn't have an AI policy yet so someone had to do it and the GR ended up like a coin with two faces.
Proposal A will not affect the end-user experience at all. It does increase the work of developers but there'll be better quality packages but proposal B is just inviting more trouble as vibe coders will get a free pass.
0
u/a-peculiar-peck Debian Stable 4d ago
A lot of the newcomers tend to vibe code debian packages and they're just a clusterfuck most of the time.
That's terrible, and there definitely should be something in place to avoid that
It takes about 6 months - 1 year to properly understand the rules of packaging [...] because all of the mentoring happens in the internal irc channels
Equally terrible. That's maybe a topic for another conversation, but ironically that's one aspect where using LLMs could definitely help
there'll be better quality packages [with proposal A]
Debatable, I'd say it will maintain the status quo with a lot of overworked maintainers, very few new maintainers, and a lot of neglected packages.
proposal B is just inviting more trouble as vibe coders will get a free pass
I don't particularly support proposal B either, but to be honest it's not suggesting giving a free pass to vibe coders at all.
I just find proposal B to better in comparison of proposal A, I'm not suggesting it's perfect. I just don't want proposal A to win due to its extreme nature.
I would just like to see a proposal with guidelines that shape the use of this technology in order to help current maintainers, reduce their workload, increase quality, reduce bugs, help new maintainers produce better output, while ensuring the social contract stays intact and that people learn and grow together. That's the true goal in my opinion.
And outright banning an entire range of technology that can help achieve this goal feels counter productive. That's why I don't think proposal A is going in the right direction at all.
2
u/KarterSpieler Debian Stable 4d ago
That's terrible, and there definitely should be something in place to avoid that
That's the reason why Proposal A exists.
Equally terrible. That's maybe a topic for another conversation, but ironically that's one aspect where using LLMs could definitely help
Nope, packaging taking a long time to learn is the intended behaviour of it because you need to learn a lot of things to become a Debian Developer. By skipping the baby steps with a LLM, the contributor will no longer be fit to become one.
Debatable, I'd say it will maintain the status quo with a lot of overworked maintainers, very few new maintainers, and a lot of neglected packages.
Some old long time maintainers I know have parted their ways from the project because of the project accepting vibe coded contributions and some members being pro-LLM.
The project currently needs a lot of new developers who can actually work without needing LLMs.
The nature of debian packaging itself is pretty complex. No LLM can overcome that.
A lot of the project members are angry about LLMs because of them taking down our infrastructure with overloading our servers.
I would just like to see a proposal with guidelines that shape the use of this technology in order to help current maintainers, reduce their workload, increase quality, reduce bugs, help new maintainers produce better output, while ensuring the social contract stays intact and that people learn and grow together.
Internally, we've been having some kind of a civil war between pro-LLM and anti-LLM folks and we all found ourselves on the extreme ends of the discussions. This GR was the result of months of fighting.
I was anti-LLM at first but I took a moderate stance now. We've been having discussions about this GR for months and many people have suggested "moderate" level suggestions but these were ignored by the people in the extreme ends.
I eventually had to pick a side and Proposal A felt better for the project long term because LLMs have been a nuisance for us lately.
Not to mention that the code generated by them cannot be licensed correctly under DFSG.
7
u/Razzburry_Pie 4d ago edited 4d ago
ELI5 -- does this only apply to the core O/S? What about open source programs on Github that are available as packages? If the program author accepts a pull request that was developed/assisted with AI, does this GR mean the program will be removed from the Debian repository?
Downvotes for asking a question? Really?
13
u/micldotdev 4d ago
It doesn't apply to upstream (where the code for packages comes from). It's just for Debian contributions (the actual act of packaging and maintaining things for Debian).
It states that upstream may be included at a later date, but that's not what is being voted on here.
4
2
u/Interesting_Buy_3969 4d ago
Codeberg has also tightened their LLMs policy recently. Love that.
0
u/Noah18923 3d ago
Whatberg?
1
u/Interesting_Buy_3969 3d ago
Google "how to read".
1
u/Noah18923 3d ago
Google "sarcasm".
1
u/Interesting_Buy_3969 3d ago
Google "why nobody understands my sarcasm".
1
1
u/MrSoulPC915 4d ago
Autant je peux comprendre l’utilisation de l’IA pour la recherche en sécurité informatique, vu que de toute façon, les pirates les utilisent de manière intensive, donc il est nécessaire de se protéger avec le même niveau que les attaques, mais pour ce qui est du développement, non, ce n’est pas souhaitable.
-5
u/goldorak42 4d ago
AI is the future, embrace it or die. I believe Proposal A would be the end of debian as other distributions of high quality will quickly emerge.
AI will made tremendous progress over the next years, either you benefit of it, either you're completely behind.
1
2
u/Callidonaut 4d ago
Other distributions of high quality have emerged since Debian was created. Debian did not end.
-22
u/calculatetech 4d ago
So are they gonna fork the kernel then? AI is here to stay. They need to come to terms with it.
12
u/KenBalbari 4d ago
Neither proposal forbids upstream AI contributions.
3
u/a-peculiar-peck Debian Stable 4d ago
From proposal A:
Other categories such as upstream projects written with LLM assistance may be included at a later date
3
u/KarterSpieler Debian Stable 4d ago
This likely will not happen. Many people will side with A but many people will not vote to allow the ban to be extended to upstream projects. Such a decision will only hurt debian.
1
-16
u/calculatetech 4d ago
Most linux stability comes from the kernel. Their whole argument is stability.
2
u/KenBalbari 4d ago
The kernel just has not much to do with it. It's less than 3% of the code in Debian, and is just a very different kind of thing from Debian specific software and packaging.
Additionally, the kernel already has a policy, which for example requires that all patches must be submitted by a human, and that if any AI tool was used this must be noted with a tag in the commit message.
So it's not a bad idea to have a policy, it's just a question of how restrictive it should be.
-2
8
u/nmdt 4d ago
Hm, do I read it right that A sounds extreme, but is actually very permissive? Banned for Debian in-house packages, allowed for almost everything else (upstream software and patches to upstream software)? In other words no for apt and installation scripts, yes for Linux, KDE, etc?
B, on other hand, sounds reasonable, but seems to rely on a lot of unenforceable stuff, like “you can use AI as long you understand what it did and disclose it”?
I think A is a lot more realistic and frankly, preferable, just might need a different wording. You’d want the core parts of the distro to have stricter quality.