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 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 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.)
> 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.
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.
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.
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 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.
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".
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.
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.
> 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.
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.
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
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.
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 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
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.
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.
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.
Why would someone misinterpret this as a final decision?
Proposal D is "Accept AI contributions for Debian specific work"
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.)
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.
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’
Using LLM encourages data theft or unethical acts.
Stupid? Since when has there been a lack of clarity in copyright status with electric vs. hand saws?
> 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.
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
Why do you want Debian to die?