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.
That's not the case. First, you can't really extrapolate from endorsers to all of the Debian Developers. Second, endorsers might not have looked at the other proposals at all, and the fact that they only endorsed one option doesn't mean they don't support the others. And you can also endorse an option if you believe it is a valid, useful proposal to add to the GR, even if you don't agree with it personally.
But most importantly, when Debian votes, you don't vote for a single option, instead you rank the choices, and apart from the given options, another option "further discussion" is always added to the list of choices. It's likely that many who rank the most permissive option first will rank the lesser permissive option second, above "further discussion", or they could even give options the same rank (if they really don't think one is better than the other).
I don't think this is notable. The process requires five seconders, so you're just seeing the set of people who seconded asynchronously before there were obviously enough that others didn't bother. The culture is to avoid unnecessary noise and leave it for the vote.
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.
> 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.
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"
There are also forks that go in the other direction, i.e. forking to avoid AI contributions upstream: https://drewdevault.com/blog/Forking-vim/
And promises to do so if it becomes necessary: https://human-emacs.org/
Will indeed be interesting to see how it all pans out.
They should call it:
debAIn
Are there though? I feel a lot of this hate is concentrated on Tesla and most of that is probably just a projection of hate on Elon. These may be the most vocal people online, but I doubt they even drive that much. Everyone who's had to drive a lot for work knows that any kind of assist on the road is extremely valuable.
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.
You mean technology?
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.
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.
B being the more pragmatic, despite the (valid) code licensing concerns. but could leave some very openly LLM driven project room to contribute package.
C as a middle ground would not satisfy any party and would only push back the resolution of the status quo.
Proposal D is "Accept AI contributions for Debian specific work"
Why would someone misinterpret this as a final decision?
The Hacker News submission title was updated to include "Three Proposals" after I posted my comment.
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.
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".
But there are more probabilistic elements about LLMs. Inference is by default deterministic for any given input and weights, however it is made stochastic algorithmically, when the model chooses the second or third likeliest outcome with some probability. Training is stochastic, the adjustment of the weights is probabilistic, etc. etc.
You seem to make the fact that our brains are also probabilistic as some sort of a gotcha. However that has never been in dispute. Neurons fire with certain probability, this has been known since the advent of neuroscience. However this is why computers are preferred for certain tasks over human brains. When you run a program you can be certain it behaves in a certain way given a particular input and parameters.
I don‘t think I have ever seen anybody make a claim that LLMs are a bad (or otherwise limited) technology because of the probabilistic nature of it. Plenty of excellent algorithms (including other machine learning algorithms) are probabilistic and work excellently for what they are meant to do. Problems arise when the algorithm is used for something more, and that is the case against LLMs. It is a next token prediction algorithm that people are using to write software. If they treat it as a compiler it will be lacking, and LLMs being non-deterministic is one of many reasons for why LLMs are bad compilers (or more accurately; are in fact not compilers).
And for that matter, neither are humans compilers. If you find an AI-hater who says “humans are good compilers” then I will agree with you that that person is wrong.
The details matter (training set, full context). I doubt our current LLMs knows what smelling cut grass on a wet morning feels like, or how the stomach flutters on a first kiss - even if they have "read" tens to hundreds of attempts at describing such things.
You're essentially suggesting we play Turing's Guessing Game; if your LLM can guess my response to any prompt - then it can be said to have modeled how I would reply to those prompts. Expand the prompts far enough, and you could reasonably argue the LLM models me.
But you said:
>Training shifts the probability - but doesn't change the fact that the output is a sampling based on input and the model?
So which is it?
>You're essentially suggesting we play Turing's Guessing Game; if your LLM can guess my response to any prompt - then it can be said to have modeled how I would reply to those prompts. Expand the prompts far enough, and you could reasonably argue the LLM models me.
I'm merely noting that your argument that "training+input=>output is the problem" applies to humans. There's other arguments for and against LLMs however I'm simply pointing out that your argument isn't a good one.
I'm not sure I ever said that it was a problem.
I also never meant to say that sampling across the model (formed by training) based on input couldn't produce novel token sequences.
As for human vs LLM - my argument would be that while trained on a large corpus, the models are poor in experience and "sensory input" - their training so different from growing up - that even if we could model humans as LLMs - the gap between current LLMs and "human" LLMs remain a wide one.
More to the point - I believe the current generation of LLMs are way too sensitive to input (prompt, system prompt, context/RAG) - precisely because they're still too narrowly trained, and also aligned to weigh input heavily.
What we have today are models that work well with language (generate, transform, translate) - not so great on complex tasks - because they're still generating next probable token.
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.
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.
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’
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.
> 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.
Debian is run by volunteers, and I think Debian Developers would not like it if they would have to pay to work on it, thus there will be some aversion to (at least frontier) LLMs.
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 do, and that's why I am pretty damn certain the future of programming doesn't involve LLMs. We still haven't really improved them, even with three years of pouring resources into doing so. The models of today are still as stupid and unreliable as the models of three years ago. Given we haven't made significant progress on that in three years, I don't expect we will get significant progress in the future either.
My current working theory for the seemingly irreconcilable differences between programmers' experiences with LLMs is grounded in their ability and willingness to explain what they want in sufficient detail. AI is not a mind-reader.
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.
You've completely missed my point. It's ALL completely unenforceable. That doesn't mean the directive is useless - it's a guideline for contributors towards a general project direction that will materially limit & reduce overt LLM usage by anyone acting in good faith (the vast majority). The enforcement doesn't need to be strict, but anything less than strict wording won't be effective in influencing people's behaviour.
What you're saying here is that you think one person should dictate the philosophical position of every downstream project.
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.
If Debian wants to make the LLM thing good, sue the providers for a billion or two for copyright violation, and join a class action to do some ASCAP style thing routing their money back to copyright holders. Separately, lobby to regulate data center build outs to include the solar and battery they need, and not be built in water stressed areas or near people who object. And understand the trillions thing is quite likely a dotcom style over investment and will vaporize in the next few years when all these pools of capital are either regulated or more likely off to ruin some other sector with too much money.
Politically difficult of course.
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.
I'm guessing after a few dozen serious risks that are found some people might think twice.
Shouldn't OSS be the first to benefit? Or should OSS be a bedrock of carefully curated code untouched by AI slop?
OSS projects have in many cases been the first to be hurt by LLMs.
As you note, LLMs are heavily trained on OSS code. This makes them very good at "license-washing" copyleft code in to a decidedly-not-cleanroom reimplementation which is different enough at first glance that it would be hard to stop without a legal battle most OSS projects could not even dream of.
Plenty of ink has also been spilled on how LLMs have led to a significant increase in administrative workload for OSS maintainers by allowing users to produce a high volume of both bug reports and pull requests that are likely to be of varying quality or adherence to project standards but unlike a new human contributor will never develop in to a better community member. It's infinite newbies forever, a computer-generated Eternal September.
On top of all that, as noted in the Debian proposal the companies training these LLMs have proven themselves to have no shame or concern for the resources of others in the process of gathering data, inefficiently crawling every single URL they can find and nowadays even using their own models to generate new potential URLs that have never existed, in ways specifically designed to make filtering, rate limiting, or blocking the traffic altogether as hard as possible while performing what are often some of the most resource-expensive requests. These tactics have imposed substantial real costs on basically everyone who hosts their own infrastructure as well as community hosting projects, without even getting in to the hardware-related cost increases every single one of us have experienced.
LLMs have gone to a lot of OSS projects, stolen their code, beat up their maintainers, and emptied their wallets. Now the LLM people are coming by wanting big projects to work with them, "for their security" like a protection racket.
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.
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.
I use an LLM to write code, but 90% of that usage is code review which raises suggestions or fixes which I go and implement myself. Occasionally I also have the LLM complete a single function that I know it will do correctly because the requirements are all present and unambiguous. Because the content of the function is all based on the unique context of my codebase, it has about the same chance of reproducing someone else's code that I have, nearly zero.
Under those circumstances, I'd be comfortable taking the responsibility that the code is free of legal issues. The LLM assisted review also would make me more confident of the quality of the code and capable of explaining it and justifying it.
This is vastly different from a scenario where a developer has an agent coordinate and write most of the content. There are many different ways to use LLMs and it seems like these policies need to take them into consideration. Developer responsibility for the legality/quality of the code should be no different than non-assisted code, but they could also give examples of safe and beneficial LLM use.
They're right that this has not been fully tested in court (though neither have some other open source licenses). There's a pretty clear direction that the wind is blowing in, though (you can see in most related cases that the judges focus on issues surrounding the core idea of using copyrighted data for training, and mostly don't give credit to the idea that all of a model's output is a derivative work of all of the input). I don't believe any LLM vendors try to claim copyright on the output of the models.
>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.
This is a common objection/worry. It seems relatively clear that even if most of the output of an LLM is not subject to existing copyright, some of it could well be (especially if, e.g. you feed an LLM a codebase and ask it to just output it again verbatim or with different variable and function names). What exactly the risks are if you are if this happens while you are using the LLM in good faith is pretty unclear (the vendors pretty much just say "It's at your own risk").
(This case felt a little surprising to me, BTW: https://petapixel.com/2026/07/22/dog-photographer-loses-copy... . But copyright case law is weird, arbitrary, and somewhat capricious about what aspects of a work are and aren't protected by copyright. With code this can also potentially be weird because in principle the functional parts are not protected, only the human expression components are. Untangling this can be time consuming, expensive, and ugly)
Accidental copies happen all the time in code, music and art. Not all of it is necessarily super original, but that's beside the point and it happens.
So while we think we can hold AI tools to higher standards than humans, they are still modeled after human thinking and will make the same mistakes. Is this really the right thing to do and is it entirely practical?
The main point is the implicit argument that humans and machines are equivalent.
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.
The whole „embrace genAI or be left behind“ is toxic nonsense repeated without actually engaging with reasons people have to reject the technology. Even in the case where the full-AI future becomes true, it takes pretty much no time to catch up and get up to speed with LLM tooling.
That's an absurd and entirely uncharitable interpretation. What it actually is, is developers recognize that LLMs suck at programming and don't want people using a tool which has proven to be so crappy.
Using LLM encourages data theft or unethical acts.
> 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.
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.
Why do you want Debian to die?
I'm happy for Debian to at least consider the other aspects of social impact, ethics, copyright, and maintainability.
A nuclear bomb is a tool.
And programmers are the biggest tools of them all.
/ba dum tis
https://youtu.be/gOReKxH5NlA?t=154
I agree "not by itself" was said, mostly your comment just made me think of this newer tech for table saws. And, made me think "when is a design inadequacy a defect"?
Interestingly there was a discussion here about exactly that a couple of years ago: https://news.ycombinator.com/item?id=39977058
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.
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.
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.
Stupid? Since when has there been a lack of clarity in copyright status with electric vs. hand saws?
It's literally the first rationale of choice 1 of proposal A. How does this have "nothing to do" with it?
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.
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.