Don't misinterpret this link as representing a final decision. It's actually three separate proposals which will be debated and then voted on.
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.
Of the 3 proposals, the 2nd/B seems to be more of an “informed consent” model while the other two are seeking a comprehensive exclusion. I hope earnest dialogue and driving to a broad consensus among significant contributors is forthcoming.
Notable are the endorsements, which are balanced over all three options, perhaps indicating only 1/3 are supportive of a more permissive position. If this represents core contributors, this could be worrisome: a clear majority favoring a exclusion, but yet a sizable portion of contributors who don’t want a ban. Losing 1/3 of core contributors would be a significant loss to the project.
I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs. Like, if you have two forks of Debian and one uses LLMs to fix exploitable bugs and the other one doesn't, the level of security they can offer will be worlds apart. And noone in their right mind would want to use the less secure one. Similar to how noone would want to drive a car that was 100% hand built by humans when we know that machines do a much better job at precision tasks. LLMs are just another tool in the end.
> I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs.
You can use an LLM to scan your human written code for exploits and patch the relevant ones yourself without any LLM code generation. An LLM is a tool, you can chose how you use it.
That's quite naive. We're looking at 50 years of legacy software running Unix/Linux environments. If the attacker with an LLM finds one in minutes it might take you hours to even comprehend the finding. Guess what the attacker with the LLM will do in that time?
Don't ask me how they would know you've used a LLM to "assist" you to find the exploit... I don't even know how they would definitely know if you used a LLM for the code to fix it either.
There are a few of these "maintainer said no AI pulls, so we forked it" in the wild already and I am really interested to see how it all pans out.
Like, okay, sure, maintainer says AI bug monitoring is cumbersome. One fork stops reading the AI bug monitoring, the other leans in. Isn't the latter more likely to find/fix critical/performance/security issues?
>Similar to how noone would want to drive a car that was 100% hand built by humans
Though, of course, this highlights that the market will fragment itself given that there are in fact many humans who will outright refuse machine driven cars despite mounting evidence that they are vastly safer and more efficient in a growing number of situations.
We'll likely see both "individual who won't use AI assisted software gets hacked" and "individual who won't get in a robo-taxi kills jay-walker in broad daylight"
I think the viability of the fork primarily depends on whether it has enough people motivated to maintain it long term. A turtle can win a distracted hare.
> And noone in their right mind would want to use the less secure one.
I mean, this is a perfect description of the prisoner's dilemma. Ins't it a shame that we keep playing that game? There's something seriously wrong if we just keep creating these new arms race scenarios. It's sickening.
I wonder how they can reconcile the stricter proposals with the LLM usage in kernel development. That seems totally untenable. I mean it all seems untenable, but with the kernel especially.
Also, what about when you inevitably get a situation where a critical vulnerability is discovered, and the only patch available is LLM generated? Do they have to wait to patch until some person who hasn't seen the LLM-generated patch does a clean room implementation?
I understand the objections to LLMs, but rejecting LLM-generated code really doesn't seem realistic.
Kernel development is excluded from this, because it's covered by "Upstream projects using LLMs for development".
On security, I worry that proposal A's "forbid any contributions to Debian written with the use or assistance of large language models", as written, excludes contributions where the LLM assisted in discovering the vulnerability. That's clearly a bad policy, and they should update their wording to clarify that.
I read the question more as, if AI is working out for the kernel, why not a distro? (This is a question with valid answers, like the kernel having more devs paid to handle things while maintaining quality, but it's a fair question)
The proposals which say no LLM generated code mean just for Debian, if upstream allows it then they will still accept it. It’s just contributions to Debian itself which would prohibit or discourage LLM contributions.
I misinterpreted it as a final decision when I first skimmed the page. The title of the linked document is "Resolution: LLM usage in Debian" and it's not obvious that it's several competing proposals until you explore the page in more detail.
The Hacker News submission title was updated to include "Three Proposals" after I posted my comment.
> A LLM (...) merely produces syntactically likely combinations of the training data
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.
The natural next argument that I see a lot is "well it's still all probabilistic", which is technically true. However, don't the atoms that make up the cells that make up a human move around and interact based on probabilities?
Saying a LLM is all just based on probabilities is pretty meaningless, even if it is true, since everything else is just based on probabilities too. What matters is the massive amount of machinery that generates those probabilities. Anything from rolling a dice to an accurate model of an entire human, or even a model of the entire universe, is all "just probabilities".
I think the questionable term is not “syntactically likely” but “merely”. Syntactical likeness is a vast solution space that encompasses the work of a terrible developer and a genius developer. In fact this solution space is a gap wide enough to encompass all coding knowledge and expertise.
Doesn't the LLM still output the next most probable token (modulus heat/desired variation) according to its model? Training shifts the probability - but doesn't change the fact that the output is a sampling based on input and the model?
I assume RL stands for reinforcement learning, which just means that the weights are adjusted by evaluating some loss function. If the loss function uses the training data (i.e. supervised learning) then the original assumption still holds. So I fail to see how this is a misconception.
Supervised learning and reinforcement learning are mathematically distinct. Supervised pre-training as you said maximizes the likelihood of a token sequence. RL optimizes a policy against an external reward signal or execution environment. For example, RL evaluates code against runtime execution/unit tests/proof checkers (e.g lean). Models learn new strategies and are able to produce novel code if trained in an RL environment.
I don‘t understand what you mean. Supervised learning is reinforcement learning, while not all reinforcement learning is supervised learning (e.g unsupervised learning is also reinforcement learning; i.e. reinforcement learning with unlabelled data).
Like you said, you can have reinforcement learning which doesn’t use training data. But that is not what my parent said. What they said is: since RL is used heavily in the training. And since reinforcement learning is a broad category which includes supervised learning, nothing in their logic disproves the strawman they created from an AI skeptic.
That would makes sense. This is how AlphaGo became better then the training data, and was the basis for Alpha Zero which used no human data and became even better.
However the loss function (or the success criteria more broadly) for the game of go is extremely simple. We do not know whether such a success criteria even exists for a generic task like coding, and it is a mistake to assume that the AI labs have found one.
Funny because out of all the distros, Gentoo benefits from LLM usage, at least as a power user. I have fixed many-an-issues just having LLMs write patches in a way that portage automatically builds them, or rapidly put together ebuilds. I respect upstream decision though and don't share my changes (and realistically who would want them)
This tracks with what I do too (also a gentoo power user). My personal overlay is much healthier thanks to LLMs, but I don’t use it for writing code for personal use. It’s just not fun.
6 months ago I would not have considered Gentoo for my work laptop but LLMs have unlocked my ability to do so. Wrestling with Linux is no longer constantly Googling with no end in sight. My work setup right now is _perfect_. I can't emphasis enough. I even built a gui for the VPN where non existed before.
Yes for gentoo and their users it makes sense. Debian is much, much larger and is used pretty extensively in enterprises.
The biggest question, I think, is: does a complete LLM ban interfere with, or slow down, security patches? I think it could, as LLMs are used a lot for vulnerability discovery.
I've been running Gentoo for 20 years. What you consider "Gentoo" is simply the package manager and "ebuilds"; instructions to build upstream packages. Right now I'm using LLMs to make my own ebuilds and maintain them. The packages I am compiling are basically vanilla upstream Linux packages. It is laughable to suggest Gentoo doesn't use AI made code because upstream already has it.
I might su combining Proposal A (but only for contributions (to Debian) that actually involve the output of LLMs/generative-AI or that blindly trust their results) with Proposal C (for everything else).
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.)
What comprises “assistance?” Getting Claude Code to find bugs, suggest a fix, but a human actually editing the source files and testing the result - is that assistance? Perhaps this policy is as it says: a guiding principle that the community is expected to follow.
> 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.
Curious what the "use" or "assistance" of LLM models means. I mostly use Gemini as a front-end to search Google without getting ads or SEO garbage, would that be forbidden?
Asking for good-faith compliance, and failing that, simply waiting for slop enthusiasts to publicly brag about using LLMs to break the rules. All evidence suggests that it is impossible for slop enthusiasts to resist outing themselves for any significant span of time.
I think when we're talking about mature software, LLMs aren't the problem. It's the lack of discussion justifying the change. LLMs don't necessarily lower code quality. They put a spotlight on people "just going through the motions".
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.
Interesting that this makes no distinction from using LLM output and using LLM assistance. An overly strict policy is better than no policy, but I wonder if using llm for conversation and analysis, but not code/config generation, was discussed.
The difference is LLMs are extremely good at analyzing code under the careful hand of an engineer. This is how most vulnerabilities are found now.
Prohibiting that might mean that security falls off.
And, if the concern is code quality, then everything before the code writing shouldn’t matter. A good engineer using an LLM for analysis and then writing a patch by-hand might create a better patch.
A rather mean counter troll to this is rather than submitting any bugs/security flaws to Debian, just immediately zero day them and say it's because of their LLM policy, since the bugs were found by an LLM.
I'm guessing after a few dozen serious risks that are found some people might think twice.
I find it ironic that so many OSS projects are or are considering banning LLM usage. After all, without OSS, LLMs would never have been this good at coding.
Shouldn't OSS be the first to benefit? Or should OSS be a bedrock of carefully curated code untouched by AI slop?
Yes, it should. And not just for code. Think better, more accurate documentation, quick start guides for both developers and users, reduce yak shaving effort, etc.
> should OSS be a bedrock of carefully curated code untouched by AI slop?
Slop is slop. There's plenty of human slop in OSS.
The whole anti-LLM crusade feels like developers trying to gatekeep their own relevance. They know the tool can automate parts if not all of what gave them status, so instead of adapting, they want to declare its use illegitimate and keep themselves as mandatory middlemen. Which is already ironic enough. If Proposal A passes and is somehow enforceable, every distro that embraces AI while Debian moralizes about it will lap them within a few years. You do not stop technological displacement by banning the tools everyone else is using. You just volunteer to be displaced first.
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.
I suspect the debate shouldn't be LLMs or no LLMs, but rather what level of human accountability is required.
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
Some of the reasons to ban LLMs are beyond what they do to code. I.e. environmental degradation, scraping without authorization, reduce human interaction etc. So I think banning them still makes sense.
All of which have been challenged though. As the stake is high, any such reason (for or against LLMs, to be fair) has to be backed with Wikipedia-level evidences at the very least.
No, but they are going to tell you what's acceptable if you want to contribute to their project, and kick you out if they find you broke the rules. Projects have always had their rules you had to follow if you wanted to participate.
This is nonsense, the vast majority of critical CVEs are trivial to fix once you spot them. It's very rare that you have something like spectre where the solution is non-obvious: most of them are shit like "delete a `free`" or "put the `goto fail` in braces".
> Other projects exploring similar decisions have elicited a common reply: "How will you enforce a ban on LLM contributions?" While enforcement could be a challenge, this is a statement of intent by the Debian community, and we trust this community to adhere to it in good faith.
Proposal A is the end of debian for non-english speakers. For those who don't speak english which is most of the world, using an LLM has become vital, because technical information is not available in their language or is extremely basic. Arch Linux is far more lenient with this.
Un what? There’s several friendly clauses among these proposals including
> 8. Any contributor who feels they cannot write in English without assistance, may write in their native language, and expect readers to use translation tools of their choice. In that case a human-written English summary would be very welcome but is not required. In any case we promise not to shame anyone for any linguistic mistakes.
I would say it leaves communication between individuals in a gray area. And discourages translation work because it has to be done manually. I would say, LLM-translated text on documentation is better than having an LLM translate it again and again on the fly every time someone asks how to do something, because the LLM-translated text can be corrected for everyone to see, whereas conversations with LLMs stay private by default.
For now, I find the quality of LLM translation highly inadequate, I can do much better, and LLMs agree my translation is much better. So I think "no LLM for official documentation" could be a right call, for now. It should be re-evaluated as LLM translation advances.
I believe the bigger risk is not low translation quality but choosing instead to use an LLM in a private by default conversation because the LLM rule discourages translation which causes the no information in native language problem which forces the use of LLMs, and thus the LLM output can contain wrong commands which have bricked some computers on reddit
this doesn't prevent you from reading documentation in whatever language you like. If you're saying this is the end of someone communicating with you through an LLM despite not speaking the language, that should never happen and I've never been in any technical organization where that was considered appropriate, if you want to work in international software projects you need to have at least a functional grasp of English
most documentation is not translated to spanish, for example. working on international projects is the exception, not the rule. Spanish speakers just use LLMs because searching on google in spanish yields no results, because the info they need is in english so google doesn't show it to spanish speakers or by searching it in spanish. Spanish speakers have their search result language set to spanish by default based on IP location and most never change it to english, where the results are far more detailed, and then they almost never search in english.
and they still can do this. Again nobody, by definition, can stop you from consuming documentation using machine translation, what you cannot do per these guidelines is contribute translations or documentation using an LLM or pretend you speak a language to contribute, and that is eminently reasonable.
You will continue to be able to translate the English documentation into Spanish but they will understandably not publish machine translation as authoritative technical documentation.
It doesn't elminate the problems of AI translation, it just shifts it into users in global south countries and makes fixing them harder because there is no transparency in private by default AI chats to know which parts of the translation are wrong
This set of proposals, are (sorry) just stupid. It's like saying to someone, you are not allowed to saw wood using an electric saw, you must do it by hand. What are we doing here?! LLM(s) are just a tool. Use it as such. You should own the work anyway.
It's more like: food processing tool A is known to be defective. We ask employees of this restaurant and supply chains to avoid food processing tool A. This seems eminently reasonable. The question is whether the tool is in fact defective.
That's just it though. The tool(s) aren't necessarily defective. Just because you can chop off your own hand with an chainsaw or do a botch job of sawing a plank of wood because you weren't watching what you were doing with the electric saw, does not by itself make the tools (Chainsaw, Electric Saw) defective.
The tool makes the food taste bad in ... say ... 20% of the cases, and in 5% of the cases it contaminates the food with salmonella.
Yes you can have the chefs taste the food before serving, and test it for salmonella. But it would be completely reasonable for a regulator to ban such a tool, and even more reasonable for restaurants to have a strict policy against using this tool.
You may as well ban every technological advancement in society then. There are risks to everything we do, build and support. Ban 'em all! Let's go back to the dark ages where everything is safe!
Let's just put this argument to bed shall we? Let's consider another case. Leatherman pocket knives. It has a ~20% chance of cutting you, a 5% change of killing you if it pieces the wrong place in your body. I'm speaking from experience, where I sliced my thumb open (by accident of course!), but it was quite bad that I severed a nerve.
Needless to say, I don't feel compelled to take a moral or ethical stance on the use of such tools -- in this case; pocket knives and their inherent dangers.
Every time no matter how sophisticated or the no. of safeguards you put in place, can still inherently pose risks.
I'm not even arguing about food safety. Just think about the many restaurants that prepare and cook up the Japanese pufferfish. That's not even a tool problem right there, that's a skill and trianing problem. That shit™ will can can kill you if not done right.
Sure, kind of, if the supposed defect is only one of the reasons, and if ‘food processing tool A’ was a hot-button topic that many people have deeply philosophical and ideological opinions about. Oh, and for good measure, if the proposed ban is for ‘food processors’ in general, and a material amount of pushback is coming from a bunch of greybeard industrial cooks that used one particular food processor a couple of years ago, weren’t all that impressed, and have been railing against food processors ever since.
Linus Torvalds said last week that LLMs were just a tool. Lorenzo Stoakes had the impeccable rebuttal that "it's a tool in the same way a nuclear bomb is just a tool" - of course it's useful but there is clearly more to it than that.
I'm happy for Debian to at least consider the other aspects of social impact, ethics, copyright, and maintainability.
Yes, they are. But that’s exactly what Proposal B (the only one without moral panic) says: allow its use, but place the responsibility on whoever uploads it. If you upload broken or unlicensed code, that’s on you. Proposal B is the most pragmatic and realistic option.
Yes. this I agree with. It's teh same thing many corporations like the one I work for are doing as well. Expecting and mandating that even if you use these so-called "AI" tools. that you are a) responsible and b) accountable for the "work".
> This set of proposals, are (sorry) just stupid. It's like saying to someone, you are not allowed to saw wood using an electric saw, you must do it by hand.
Stupid? Since when has there been a lack of clarity in copyright status with electric vs. hand saws?
This has nothing to do with copyright status or copyrighted works. If it did, Debian wouldn't even be a thing. You can't be a puritan about this; How much of Debian can one say, hand on heart, is truly not inspired, or influenced by other people's work, copyrighted or not.
Probably since we all started getting our legal advice from you and every other “I think that it’s illegal so it’s illegal” developer-turned-fake-lawyer on the Internet.
Oh, wait, that never happened.
Debian Airport is debating whether to allow aircraft to land on autopilot. On the one hand it’s nice that autopilot gives more people the chance to fly, and it lets experienced pilots fly more often. On the other hand, Debian Airport has, to date, been run by a carefully curated club of “stick and rudder” pilots. It’s a club where the air safety is backed up by nothing more than the name and reputation of the pilot coming in to land.
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.
Don't misinterpret this link as representing a final decision. It's actually three separate proposals which will be debated and then voted on.
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.
Of the 3 proposals, the 2nd/B seems to be more of an “informed consent” model while the other two are seeking a comprehensive exclusion. I hope earnest dialogue and driving to a broad consensus among significant contributors is forthcoming.
Notable are the endorsements, which are balanced over all three options, perhaps indicating only 1/3 are supportive of a more permissive position. If this represents core contributors, this could be worrisome: a clear majority favoring a exclusion, but yet a sizable portion of contributors who don’t want a ban. Losing 1/3 of core contributors would be a significant loss to the project.
I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs. Like, if you have two forks of Debian and one uses LLMs to fix exploitable bugs and the other one doesn't, the level of security they can offer will be worlds apart. And noone in their right mind would want to use the less secure one. Similar to how noone would want to drive a car that was 100% hand built by humans when we know that machines do a much better job at precision tasks. LLMs are just another tool in the end.
> I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs.
You can use an LLM to scan your human written code for exploits and patch the relevant ones yourself without any LLM code generation. An LLM is a tool, you can chose how you use it.
That's quite naive. We're looking at 50 years of legacy software running Unix/Linux environments. If the attacker with an LLM finds one in minutes it might take you hours to even comprehend the finding. Guess what the attacker with the LLM will do in that time?
The proposal A doesn't limit it to "use" only:
> with the use or assistance
Don't ask me how they would know you've used a LLM to "assist" you to find the exploit... I don't even know how they would definitely know if you used a LLM for the code to fix it either.
There are a few of these "maintainer said no AI pulls, so we forked it" in the wild already and I am really interested to see how it all pans out.
Like, okay, sure, maintainer says AI bug monitoring is cumbersome. One fork stops reading the AI bug monitoring, the other leans in. Isn't the latter more likely to find/fix critical/performance/security issues?
>Similar to how noone would want to drive a car that was 100% hand built by humans
Though, of course, this highlights that the market will fragment itself given that there are in fact many humans who will outright refuse machine driven cars despite mounting evidence that they are vastly safer and more efficient in a growing number of situations.
We'll likely see both "individual who won't use AI assisted software gets hacked" and "individual who won't get in a robo-taxi kills jay-walker in broad daylight"
I think the viability of the fork primarily depends on whether it has enough people motivated to maintain it long term. A turtle can win a distracted hare.
All the proposals allowed LLMs in upstream packages.
> And noone in their right mind would want to use the less secure one.
I mean, this is a perfect description of the prisoner's dilemma. Ins't it a shame that we keep playing that game? There's something seriously wrong if we just keep creating these new arms race scenarios. It's sickening.
I wonder how they can reconcile the stricter proposals with the LLM usage in kernel development. That seems totally untenable. I mean it all seems untenable, but with the kernel especially.
Also, what about when you inevitably get a situation where a critical vulnerability is discovered, and the only patch available is LLM generated? Do they have to wait to patch until some person who hasn't seen the LLM-generated patch does a clean room implementation?
I understand the objections to LLMs, but rejecting LLM-generated code really doesn't seem realistic.
Kernel development is excluded from this, because it's covered by "Upstream projects using LLMs for development".
On security, I worry that proposal A's "forbid any contributions to Debian written with the use or assistance of large language models", as written, excludes contributions where the LLM assisted in discovering the vulnerability. That's clearly a bad policy, and they should update their wording to clarify that.
I read the question more as, if AI is working out for the kernel, why not a distro? (This is a question with valid answers, like the kernel having more devs paid to handle things while maintaining quality, but it's a fair question)
Isn't basically every package in Debian an upstream project?
They're talking about the software that is unique to Debian, like their lintian tool. https://wiki.debian.org/Lintian
The proposals which say no LLM generated code mean just for Debian, if upstream allows it then they will still accept it. It’s just contributions to Debian itself which would prohibit or discourage LLM contributions.
There is also proposal D right at the bottom, which is "Accept AI contributions for Debian specific work".
Thanks, we've put the three proposals bit in the title above.
There actually seem to be 4 separate proposals right now, maybe another was just added?
Proposal D is "Accept AI contributions for Debian specific work"
The title says "proposals"
Why would someone misinterpret this as a final decision?
I misinterpreted it as a final decision when I first skimmed the page. The title of the linked document is "Resolution: LLM usage in Debian" and it's not obvious that it's several competing proposals until you explore the page in more detail.
The Hacker News submission title was updated to include "Three Proposals" after I posted my comment.
It seems the title wasn't always as clear.
Eternal September of the Spotless Mind.
> A LLM (...) merely produces syntactically likely combinations of the training data
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.
The natural next argument that I see a lot is "well it's still all probabilistic", which is technically true. However, don't the atoms that make up the cells that make up a human move around and interact based on probabilities?
Saying a LLM is all just based on probabilities is pretty meaningless, even if it is true, since everything else is just based on probabilities too. What matters is the massive amount of machinery that generates those probabilities. Anything from rolling a dice to an accurate model of an entire human, or even a model of the entire universe, is all "just probabilities".
I think the questionable term is not “syntactically likely” but “merely”. Syntactical likeness is a vast solution space that encompasses the work of a terrible developer and a genius developer. In fact this solution space is a gap wide enough to encompass all coding knowledge and expertise.
Doesn't the LLM still output the next most probable token (modulus heat/desired variation) according to its model? Training shifts the probability - but doesn't change the fact that the output is a sampling based on input and the model?
The combination of the most probable tokens doesn't necessarily have to be in the training set, thus creating something completely novel.
I assume RL stands for reinforcement learning, which just means that the weights are adjusted by evaluating some loss function. If the loss function uses the training data (i.e. supervised learning) then the original assumption still holds. So I fail to see how this is a misconception.
Supervised learning and reinforcement learning are mathematically distinct. Supervised pre-training as you said maximizes the likelihood of a token sequence. RL optimizes a policy against an external reward signal or execution environment. For example, RL evaluates code against runtime execution/unit tests/proof checkers (e.g lean). Models learn new strategies and are able to produce novel code if trained in an RL environment.
I don‘t understand what you mean. Supervised learning is reinforcement learning, while not all reinforcement learning is supervised learning (e.g unsupervised learning is also reinforcement learning; i.e. reinforcement learning with unlabelled data).
Like you said, you can have reinforcement learning which doesn’t use training data. But that is not what my parent said. What they said is: since RL is used heavily in the training. And since reinforcement learning is a broad category which includes supervised learning, nothing in their logic disproves the strawman they created from an AI skeptic.
I think OP might be referring to synthetic data, which is now used to provide more data for training?
That would makes sense. This is how AlphaGo became better then the training data, and was the basis for Alpha Zero which used no human data and became even better.
However the loss function (or the success criteria more broadly) for the game of go is extremely simple. We do not know whether such a success criteria even exists for a generic task like coding, and it is a mistake to assume that the AI labs have found one.
Gentoo chose to ban LLMs two years ago. They seem to be doing well.
Funny because out of all the distros, Gentoo benefits from LLM usage, at least as a power user. I have fixed many-an-issues just having LLMs write patches in a way that portage automatically builds them, or rapidly put together ebuilds. I respect upstream decision though and don't share my changes (and realistically who would want them)
This tracks with what I do too (also a gentoo power user). My personal overlay is much healthier thanks to LLMs, but I don’t use it for writing code for personal use. It’s just not fun.
6 months ago I would not have considered Gentoo for my work laptop but LLMs have unlocked my ability to do so. Wrestling with Linux is no longer constantly Googling with no end in sight. My work setup right now is _perfect_. I can't emphasis enough. I even built a gui for the VPN where non existed before.
Gentoo is doing as well as it’s always done. It’s clearly a very niche distribution. I say this as someone that used Gentoo for years.
They are free to keep pretending that they aren’t receiving covert AI contributions, because I’d bet the farm that they are.
Debian has a little more ‘general interest’
Yes for gentoo and their users it makes sense. Debian is much, much larger and is used pretty extensively in enterprises.
The biggest question, I think, is: does a complete LLM ban interfere with, or slow down, security patches? I think it could, as LLMs are used a lot for vulnerability discovery.
I've been running Gentoo for 20 years. What you consider "Gentoo" is simply the package manager and "ebuilds"; instructions to build upstream packages. Right now I'm using LLMs to make my own ebuilds and maintain them. The packages I am compiling are basically vanilla upstream Linux packages. It is laughable to suggest Gentoo doesn't use AI made code because upstream already has it.
You would not even know about it if they were not doing well
I might su combining Proposal A (but only for contributions (to Debian) that actually involve the output of LLMs/generative-AI or that blindly trust their results) with Proposal C (for everything else).
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.)
What comprises “assistance?” Getting Claude Code to find bugs, suggest a fix, but a human actually editing the source files and testing the result - is that assistance? Perhaps this policy is as it says: a guiding principle that the community is expected to follow.
Poor Debian. AI is killing it right now.
Be interesting to see what happens when it becomes a serious hacker target.
I certainly hope they'll choose C.
From Proposal A:
> 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.
i think the line is: expressing that you reputationally certify its correct and its worth the time
Curious what the "use" or "assistance" of LLM models means. I mostly use Gemini as a front-end to search Google without getting ads or SEO garbage, would that be forbidden?
Even if they wanted to forbid that, how would they even detect it?
Some people want to uphold the rule even if they can't be caught.
Asking for good-faith compliance, and failing that, simply waiting for slop enthusiasts to publicly brag about using LLMs to break the rules. All evidence suggests that it is impossible for slop enthusiasts to resist outing themselves for any significant span of time.
I think when we're talking about mature software, LLMs aren't the problem. It's the lack of discussion justifying the change. LLMs don't necessarily lower code quality. They put a spotlight on people "just going through the motions".
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.
Interesting that this makes no distinction from using LLM output and using LLM assistance. An overly strict policy is better than no policy, but I wonder if using llm for conversation and analysis, but not code/config generation, was discussed.
I’m curious what makes you believe that this distinction is precise or meaningful. What exactly is the difference?
The difference is LLMs are extremely good at analyzing code under the careful hand of an engineer. This is how most vulnerabilities are found now.
Prohibiting that might mean that security falls off.
And, if the concern is code quality, then everything before the code writing shouldn’t matter. A good engineer using an LLM for analysis and then writing a patch by-hand might create a better patch.
A rather mean counter troll to this is rather than submitting any bugs/security flaws to Debian, just immediately zero day them and say it's because of their LLM policy, since the bugs were found by an LLM.
I'm guessing after a few dozen serious risks that are found some people might think twice.
looks like the best proposal is the just the least bad
What do you think is the best proposal?
It doesn’t really matter for their central point.
Proposal D, currently enacted: Use LLMs but don't tell anyone
Proposal A
Using LLM encourages data theft or unethical acts.
I find it ironic that so many OSS projects are or are considering banning LLM usage. After all, without OSS, LLMs would never have been this good at coding.
Shouldn't OSS be the first to benefit? Or should OSS be a bedrock of carefully curated code untouched by AI slop?
> Shouldn't OSS be the first to benefit?
Yes, it should. And not just for code. Think better, more accurate documentation, quick start guides for both developers and users, reduce yak shaving effort, etc.
> should OSS be a bedrock of carefully curated code untouched by AI slop?
Slop is slop. There's plenty of human slop in OSS.
"Look at this. Look at what they make you give." - The Professor from The Bourne Identity (2002)
The whole anti-LLM crusade feels like developers trying to gatekeep their own relevance. They know the tool can automate parts if not all of what gave them status, so instead of adapting, they want to declare its use illegitimate and keep themselves as mandatory middlemen. Which is already ironic enough. If Proposal A passes and is somehow enforceable, every distro that embraces AI while Debian moralizes about it will lap them within a few years. You do not stop technological displacement by banning the tools everyone else is using. You just volunteer to be displaced first.
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.
I suspect the debate shouldn't be LLMs or no LLMs, but rather what level of human accountability is required.
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
Some of the reasons to ban LLMs are beyond what they do to code. I.e. environmental degradation, scraping without authorization, reduce human interaction etc. So I think banning them still makes sense.
All of which have been challenged though. As the stake is high, any such reason (for or against LLMs, to be fair) has to be backed with Wikipedia-level evidences at the very least.
Proposals like these are arrogant and obnoxious. You aren’t going to tell me what tools I can use.
No, but they are going to tell you what's acceptable if you want to contribute to their project, and kick you out if they find you broke the rules. Projects have always had their rules you had to follow if you wanted to participate.
Debian should completely avoid 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.
Indeed it is, and it doesn't count as a "contribution" at all; the actual work is in fixing the CVE.
This is nonsense, the vast majority of critical CVEs are trivial to fix once you spot them. It's very rare that you have something like spectre where the solution is non-obvious: most of them are shit like "delete a `free`" or "put the `goto fail` in braces".
It’s still not an LLM contribution in a meaningful sense. The contribution is the fix, no matter how trivial it is.
How can they even tell code was written by AI instead of a human?
> Other projects exploring similar decisions have elicited a common reply: "How will you enforce a ban on LLM contributions?" While enforcement could be a challenge, this is a statement of intent by the Debian community, and we trust this community to adhere to it in good faith.
emdashes
My coding TUIs all have rules to never use emdashes.
Proposal A is the end of debian for non-english speakers. For those who don't speak english which is most of the world, using an LLM has become vital, because technical information is not available in their language or is extremely basic. Arch Linux is far more lenient with this.
Un what? There’s several friendly clauses among these proposals including
> 8. Any contributor who feels they cannot write in English without assistance, may write in their native language, and expect readers to use translation tools of their choice. In that case a human-written English summary would be very welcome but is not required. In any case we promise not to shame anyone for any linguistic mistakes.
That is Proposal C, not Proposal A. (Although I do think Proposal A as written also does not forbid translation usage to communicate.)
I don't believe Proposal A forbids this usage.
I would say it leaves communication between individuals in a gray area. And discourages translation work because it has to be done manually. I would say, LLM-translated text on documentation is better than having an LLM translate it again and again on the fly every time someone asks how to do something, because the LLM-translated text can be corrected for everyone to see, whereas conversations with LLMs stay private by default.
For now, I find the quality of LLM translation highly inadequate, I can do much better, and LLMs agree my translation is much better. So I think "no LLM for official documentation" could be a right call, for now. It should be re-evaluated as LLM translation advances.
I believe the bigger risk is not low translation quality but choosing instead to use an LLM in a private by default conversation because the LLM rule discourages translation which causes the no information in native language problem which forces the use of LLMs, and thus the LLM output can contain wrong commands which have bricked some computers on reddit
This is a somewhat common talking point for supporting LLMs. What did non-English speakers do before LLMs?
this doesn't prevent you from reading documentation in whatever language you like. If you're saying this is the end of someone communicating with you through an LLM despite not speaking the language, that should never happen and I've never been in any technical organization where that was considered appropriate, if you want to work in international software projects you need to have at least a functional grasp of English
most documentation is not translated to spanish, for example. working on international projects is the exception, not the rule. Spanish speakers just use LLMs because searching on google in spanish yields no results, because the info they need is in english so google doesn't show it to spanish speakers or by searching it in spanish. Spanish speakers have their search result language set to spanish by default based on IP location and most never change it to english, where the results are far more detailed, and then they almost never search in english.
and they still can do this. Again nobody, by definition, can stop you from consuming documentation using machine translation, what you cannot do per these guidelines is contribute translations or documentation using an LLM or pretend you speak a language to contribute, and that is eminently reasonable.
You will continue to be able to translate the English documentation into Spanish but they will understandably not publish machine translation as authoritative technical documentation.
It doesn't elminate the problems of AI translation, it just shifts it into users in global south countries and makes fixing them harder because there is no transparency in private by default AI chats to know which parts of the translation are wrong
Good so Debian will die soon or later.
Are you aware, that a very big chunk of Linux distributions like Ubuntu are build in top of Debian?
Why do you want Debian to die?
Anyone that has an opinion about this, already knows that, yes. Drop the condescension.
By Lindy effect, debian has a life expectancy of 25 more years
Just like BSD is dying. Netcraft confirms it.
The fact that some react to these like they were taken away some possession is genuinely interesting
This is ridiculos, think about that, will Debian project survive without a Linux kernel written with the help of LLM tools?
This set of proposals, are (sorry) just stupid. It's like saying to someone, you are not allowed to saw wood using an electric saw, you must do it by hand. What are we doing here?! LLM(s) are just a tool. Use it as such. You should own the work anyway.
Yeah, I agree, it's really stupid. It's like discussing whether contributors are allowed to use google search, stackoverflow, encyclopedia, etc.
It's more like: food processing tool A is known to be defective. We ask employees of this restaurant and supply chains to avoid food processing tool A. This seems eminently reasonable. The question is whether the tool is in fact defective.
That's just it though. The tool(s) aren't necessarily defective. Just because you can chop off your own hand with an chainsaw or do a botch job of sawing a plank of wood because you weren't watching what you were doing with the electric saw, does not by itself make the tools (Chainsaw, Electric Saw) defective.
The tool makes the food taste bad in ... say ... 20% of the cases, and in 5% of the cases it contaminates the food with salmonella.
Yes you can have the chefs taste the food before serving, and test it for salmonella. But it would be completely reasonable for a regulator to ban such a tool, and even more reasonable for restaurants to have a strict policy against using this tool.
You may as well ban every technological advancement in society then. There are risks to everything we do, build and support. Ban 'em all! Let's go back to the dark ages where everything is safe!
WTF. Food safety is just a reasonable thing for a mature civilization to do. It has nothing to do with banning technological advancement.
Let's just put this argument to bed shall we? Let's consider another case. Leatherman pocket knives. It has a ~20% chance of cutting you, a 5% change of killing you if it pieces the wrong place in your body. I'm speaking from experience, where I sliced my thumb open (by accident of course!), but it was quite bad that I severed a nerve.
Needless to say, I don't feel compelled to take a moral or ethical stance on the use of such tools -- in this case; pocket knives and their inherent dangers.
Every time no matter how sophisticated or the no. of safeguards you put in place, can still inherently pose risks.
I'm not even arguing about food safety. Just think about the many restaurants that prepare and cook up the Japanese pufferfish. That's not even a tool problem right there, that's a skill and trianing problem. That shit™ will can can kill you if not done right.
Why don't you come back to talking about software rather than using terrible analogies.
LLMs write bad code / so do people, a lot of really bad code.
LLMs write security bugs / so do people, so many god damned security bugs.
Yes, people make mistakes. But they make far fewer than LLMs.
Sure, kind of, if the supposed defect is only one of the reasons, and if ‘food processing tool A’ was a hot-button topic that many people have deeply philosophical and ideological opinions about. Oh, and for good measure, if the proposed ban is for ‘food processors’ in general, and a material amount of pushback is coming from a bunch of greybeard industrial cooks that used one particular food processor a couple of years ago, weren’t all that impressed, and have been railing against food processors ever since.
Linus Torvalds said last week that LLMs were just a tool. Lorenzo Stoakes had the impeccable rebuttal that "it's a tool in the same way a nuclear bomb is just a tool" - of course it's useful but there is clearly more to it than that.
I'm happy for Debian to at least consider the other aspects of social impact, ethics, copyright, and maintainability.
An LLM is a tool.
A nuclear bomb is a tool.
And programmers are the biggest tools of them all.
/ba dum tis
You wouldn't program a computer with a nuclear bomb!!!
Yes, they are. But that’s exactly what Proposal B (the only one without moral panic) says: allow its use, but place the responsibility on whoever uploads it. If you upload broken or unlicensed code, that’s on you. Proposal B is the most pragmatic and realistic option.
Yes. this I agree with. It's teh same thing many corporations like the one I work for are doing as well. Expecting and mandating that even if you use these so-called "AI" tools. that you are a) responsible and b) accountable for the "work".
> This set of proposals, are (sorry) just stupid. It's like saying to someone, you are not allowed to saw wood using an electric saw, you must do it by hand.
Stupid? Since when has there been a lack of clarity in copyright status with electric vs. hand saws?
This has nothing to do with copyright status or copyrighted works. If it did, Debian wouldn't even be a thing. You can't be a puritan about this; How much of Debian can one say, hand on heart, is truly not inspired, or influenced by other people's work, copyrighted or not.
> This has nothing to do with copyright status or copyrighted works.
It's literally the first rationale of choice 1 of proposal A. How does this have "nothing to do" with it?
Probably since we all started getting our legal advice from you and every other “I think that it’s illegal so it’s illegal” developer-turned-fake-lawyer on the Internet. Oh, wait, that never happened.
Debian Airport is debating whether to allow aircraft to land on autopilot. On the one hand it’s nice that autopilot gives more people the chance to fly, and it lets experienced pilots fly more often. On the other hand, Debian Airport has, to date, been run by a carefully curated club of “stick and rudder” pilots. It’s a club where the air safety is backed up by nothing more than the name and reputation of the pilot coming in to land.
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.