alt.hn

7/25/2026 at 7:44:39 PM

LLM Usage in Debian: Three Proposals

 https://www.debian.org/vote/2026/vote_002

by zdw

7/25/2026 at 11:35:22 PM

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.

by simonw

7/25/2026 at 11:45:13 PM

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.

by clcaev

7/26/2026 at 10:56:53 AM

> Notable are the endorsements, which are balanced over all three options, perhaps indicating only 1/3 are supportive of a more permissive position.

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).

by gsliepen

7/26/2026 at 10:03:04 AM

> Notable are the endorsements, which are balanced over all three options...

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.

by rlpb

7/26/2026 at 11:29:32 AM

A bit of topic, but does the word "seconded" still work when five are required? Isn't there a more generic term?

by tomtomtom777

7/26/2026 at 6:12:11 PM

Depends on your rules of order. Under Robert's you can have multiple seconds but seconds aren't recorded. In model UN there are multiple seconds. Second'ing a motion is not generally an endorsement per se, it's just saying you support a vote on the matter.

by tingletech

7/26/2026 at 2:22:26 PM

n’th’ed?

by setopt

7/26/2026 at 1:59:46 AM

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.

by sigmoid10

7/26/2026 at 2:32:24 AM

> 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.

by AlexeyBrin

7/26/2026 at 2:47:58 AM

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.

by throw101010

7/26/2026 at 2:53:18 AM

[flagged]

by pixl97

7/26/2026 at 7:32:35 AM

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?

by __bjoernd

7/26/2026 at 2:13:14 AM

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"

by goodmythical

7/26/2026 at 6:43:25 AM

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.

by cuu508

7/26/2026 at 2:43:23 PM

Or maybe we stop hard forks and just automate rebasing unless there's significant deviation

by calvinmorrison

7/26/2026 at 6:21:57 PM

> 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.

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.

by setopt

7/27/2026 at 3:36:34 AM

It's already been quite interesting to witness the birth of the 'Digital Amish' throughout the past few years.

by DaSHacka

7/26/2026 at 11:15:46 AM

"maintainer said no AI pulls, so we forked it"

They should call it:

debAIn

by mrtx01

7/26/2026 at 9:52:13 AM

>given that there are in fact many humans who will outright refuse machine driven cars

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.

by sigmoid10

7/26/2026 at 5:57:15 AM

All the proposals allowed LLMs in upstream packages.

by trollbridge

7/26/2026 at 5:24:36 AM

> 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.

by vouaobrasil

7/27/2026 at 3:37:19 AM

> There's something seriously wrong if we just keep creating these new arms race scenarios. It's sickening.

You mean technology?

by DaSHacka

7/26/2026 at 10:19:27 AM

you can neither check nor enforce any conditions. So the right answer is A

by vrighter

7/26/2026 at 7:27:29 AM

[dead]

by nullsanity

7/25/2026 at 11:58:08 PM

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.

by smellf

7/26/2026 at 12:02:16 AM

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.

by simonw

7/26/2026 at 12:27:01 AM

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)

by yjftsjthsd-h

7/26/2026 at 12:42:25 AM

Isn't basically every package in Debian an upstream project?

by aspensmonster

7/26/2026 at 12:03:55 AM

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.

by bradfa

7/26/2026 at 2:29:35 AM

There is also proposal D right at the bottom, which is "Accept AI contributions for Debian specific work".

by mmwelt

7/26/2026 at 12:59:09 AM

Thanks, we've put the three proposals bit in the title above.

by dang

7/26/2026 at 12:26:45 AM

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"

by infl8ed

7/26/2026 at 2:17:11 PM

Wait, can we have a vote to not link HN contributions to dynamic pages!

by MeteorMarc

7/26/2026 at 12:49:03 PM

while my heart lean heavily toward A, this would serverly limit Debian contribution and would rely on contributor honesty. It might be dismissed as an attempt to gatekeep contribution. But the issue of the human cost on the receiving end of the contribution and how sophisticated attack vector it could potentially be give me some concerns about long term quality.

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.

by dvhh

7/26/2026 at 1:39:00 AM

The title says "proposals"

Why would someone misinterpret this as a final decision?

by lacoolj

7/26/2026 at 3:59:46 AM

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.

by simonw

7/26/2026 at 2:00:36 AM

Eternal September of the Spotless Mind.

by derrida

7/26/2026 at 2:03:51 AM

It seems the title wasn't always as clear.

by Cider9986

7/26/2026 at 8:36:04 AM

Note that we are still in the discussion period, and more proposals can and will be added. Some might even be withdrawn.

by ckastner

7/26/2026 at 11:49:09 AM

Mr President, a 4th proposal has hit the General Resolution.

by fl0ki

7/27/2026 at 2:34:45 PM

Disappointing there's not a Proposal E "require use of LLM's by contributors"

by hackeraccount

7/25/2026 at 11:23:06 PM

> 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.

by hkalbasi

7/25/2026 at 11:35:07 PM

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.

by aabhay

7/26/2026 at 8:53:13 AM

"Combinations of the training data" is also hiding a pretty common and serious misconception about modern generative AI: this seems to come from a mental model that LLMs and image generators are merely producing a collage of sorts, especially that this is some way linked to specific parts of the training data as opposed to a generalized result of building up an understanding of how to produce a sentence, piece of code, or plausible image.

by rcxdude

7/26/2026 at 11:28:53 AM

That is how they feel when using them for code. It feels like they generate templates filled in with the details of a specific case.

by inigyou

7/26/2026 at 7:17:01 AM

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".

by LiamPowell

7/26/2026 at 3:29:56 PM

That argument is mostly used against the misconception of AI-stans that LLMs are compilers, English is a programming language, and that prompting is a programing. There are many reasons for why that is false, and LLMs being stochastic is one of the more obvious reasons.

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.

by runarberg

7/26/2026 at 4:47:57 PM

The "gotcha" here, if you want to call it that, is that the picking the next token based on probabilities (either in training or in the sampler) is not an argument that LLMs are inherently flawed, especially when one reduces a LLM to "it just picks a token based on a probability" as you could apply that same description to a human.

by LiamPowell

7/26/2026 at 4:58:46 PM

Like I said, usually this is used to debunk false claims about LLMs being compilers. I personally think there are better arguments to be made to debunk that, but the probabilistic nature of LLMs is an obvious one, so it is not unsurprising that it is also popular.

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.

by runarberg

7/26/2026 at 6:08:19 AM

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?

by e12e

7/26/2026 at 3:17:48 PM

So do humans more or less? The only counterpoints I've heard are religious or unmeasured quantum brain something.

by bob001

7/26/2026 at 4:32:07 PM

I think there are quite fundamental differences to the LLM model equivalent to an adult human mind and current LLMs (even accepting an LLM can model a human brain, which I don't think is a given - but I also don't think it's impossible).

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.

by e12e

7/26/2026 at 5:00:19 PM

>The details matter (training set, full context).

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.

by bob001

7/26/2026 at 10:16:06 PM

> I'm merely noting that your argument that "training+input=>output is the problem" applies to humans.

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.

by e12e

7/26/2026 at 8:51:21 PM

No. Humans actually understand things and can reason from one fact to another. We do not just spit out the next most likely thing without any intelligence the way an LLM does.

by bigstrat2003

7/26/2026 at 4:48:53 PM

It’s not sampling anything though. At each inference step the fundamental output of the process can be interpreted as a probability for each possible token how likely it is. Sampling would imply otherwise but the probabilities are the output.

by semiquaver

7/26/2026 at 6:33:09 AM

The combination of the most probable tokens doesn't necessarily have to be in the training set, thus creating something completely novel.

by josu

7/26/2026 at 4:33:13 PM

If you shuffle a deck of cards, you likely have a novel sequence of cards. I'm not sure how that is relevant?

by e12e

7/26/2026 at 9:38:13 PM

I was responding to this "merely produces syntactically likely combinations of the training data".

by josu

7/26/2026 at 9:01:27 AM

That is called a hallucination.

by DiabloD3

7/26/2026 at 9:46:11 AM

Yes, like the Jacobian counterexample.

by josu

7/26/2026 at 11:29:33 AM

That LLM was attached to a Python and MATLAB evaluator. It generated plausible things to feed into a real computer.

by inigyou

7/26/2026 at 5:10:52 PM

Weird take as a lot of things humans invent and test are done in similar ways.

by pixl97

7/26/2026 at 9:12:48 AM

Only if it's incorrect.

by Gander5739

7/26/2026 at 1:24:35 AM

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.

by runarberg

7/26/2026 at 1:37:06 AM

I think OP might be referring to synthetic data, which is now used to provide more data for training?

by atherton94027

7/26/2026 at 2:26:32 AM

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.

by runarberg

7/26/2026 at 1:40:01 AM

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.

by tulio_ribeiro

7/26/2026 at 2:14:01 AM

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.

by runarberg

7/26/2026 at 2:00:04 PM

that's not how the terminology is typical used, even if it makes literal sense

by xdavidliu

7/26/2026 at 9:29:06 AM

I would like to offer this comment from three days ago as counterpoint:

https://news.ycombinator.com/item?id=49013694

by probably_wrong

7/26/2026 at 10:38:53 AM

Common sense testing only tells about the presence of common sense, that's it. It is clear from recent events that LLMs do definitely possess some sort of intelligence even though it might have been polarized to certain domains.

by lifthrasiir

7/26/2026 at 1:29:19 PM

What does that prove? That AIs are not RLd for counting letters in texts? Do you doubt that they could excel at it with only synthetic data?

by scotty79

7/25/2026 at 11:58:22 PM

Gentoo chose to ban LLMs two years ago. They seem to be doing well.

by Meneth

7/26/2026 at 12:22:39 AM

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)

by orsorna

7/26/2026 at 3:29:30 AM

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.

by isatty

7/26/2026 at 3:51:07 AM

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.

by hparadiz

7/26/2026 at 12:36:07 AM

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’

by UqWBcuFx6NV4r

7/26/2026 at 2:11:53 AM

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.

by preg_match

7/26/2026 at 3:47:50 AM

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.

by hparadiz

7/26/2026 at 10:03:44 AM

Their policy doesn't cover upstream, it's only for the Gentoo project specifically. It's clearly infeasible for them (or Debian) to try to control what their upstreams do, especially with the kernel accepting LLM contributions now.

by CamouflagedKiwi

7/26/2026 at 1:18:14 AM

You would not even know about it if they were not doing well

by ekianjo

7/25/2026 at 10:40:03 PM 

  > Documentation and translations added by Debian contributors
I wonder what fraction of Trixie already violates this requirement of the first proposal...

by rixed

7/25/2026 at 10:43:43 PM

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.

by russfink

7/26/2026 at 1:21:19 AM

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.)

by zzo38computer

7/27/2026 at 12:26:55 PM

Skimming over the proposals, only option 1 even mentions copyright and licensing issues, which have been traditionally a big deal for open source software

by ghtbircshotbe

7/25/2026 at 11:06:05 PM

i think the line is: expressing that you reputationally certify its correct and its worth the time

by carterschonwald

7/25/2026 at 11:13:51 PM

I certainly hope they'll choose C.

by mike_hock

7/26/2026 at 9:26:22 AM

A is good, it's grounded. C is just based

by pixlmint

7/26/2026 at 2:14:06 PM

The unhinged Background paragraph is disqualifying.

by baggy_trough

7/25/2026 at 10:30:34 PM

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.

by TZubiri

7/25/2026 at 11:42:52 PM

I’m curious what makes you believe that this distinction is precise or meaningful. What exactly is the difference?

by aabhay

7/26/2026 at 2:16:30 AM

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.

by preg_match

7/26/2026 at 3:04:00 AM

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.

by pixl97

7/26/2026 at 10:19:28 AM

Debian is conservative so it makes sense that they have proposals for not using LLM's. They'll need another year or so but I am convinced it'll soon be obvious that any "no LLM" policy is untenable.

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.

by Kon5ole

7/26/2026 at 11:05:33 AM

We'll see how much people like it once the cheap subscriptions end and the actual cost of LLMs (+ profit margin) is asked of them. Although I'm suspecting that eventually, machines that are good enough to run reasonably useful models will become cheap enought that most developers will have those, but that might be some years from now.

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.

by gsliepen

7/25/2026 at 10:56:32 PM

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?

by dismalaf

7/25/2026 at 11:27:51 PM

Even if they wanted to forbid that, how would they even detect it?

by Narishma

7/26/2026 at 3:28:35 AM

Some people want to uphold the rule even if they can't be caught.

by yjftsjthsd-h

7/26/2026 at 2:50:07 PM

Some people find a duty to ignore senseless rules.

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.

by lanstin

7/26/2026 at 5:27:34 PM

It's strange we're complaining about too much investment. The reason we avoid deflation is because it hinders investment, but perhaps it's time for a bit less money creation and have a period of deflation, even if it makes the "growth" figures look bad.

Politically difficult of course.

by onraglanroad

7/27/2026 at 12:47:07 PM

It ruined my nice quiet job of delivering networks services during the dot com bust; it ruined the ordinary practice of staying employed and moving during the financial crisis; it didn’t hurt as much but wasted a lot of time and energy during the crypto excitement, and seems to causing people to somehow think that increasing our (based on 2026 chips) compute capacity by an order of magnitude or so makes sense (which economically represents real pessimism - we spend a few trillion on this years technology is saying we don’t think that the rate of growth of tech power will continue to increase in the out years).

by lanstin

7/25/2026 at 11:30:38 PM

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.

by RodgerTheGreat

7/26/2026 at 2:14:17 PM

Whatever the decision is today, it's going to become utterly moot within a decade or so.

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.

by simondotau

7/26/2026 at 8:54:31 PM

> Think about how far we've come over the past three years.

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.

by bigstrat2003

7/26/2026 at 11:24:35 PM

You are saying that LLMs have not meaningfully improved since 2023? If you want me to take that claim seriously, you will need to do more than merely assert it. I am not a mind-reader.

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.

by simondotau

7/26/2026 at 1:35:53 AM

Be interesting to see what happens when it becomes a serious hacker target.

by skeledrew

7/26/2026 at 3:17:21 PM

A lot of people pointing out that Proposal A is untenable/ at philosophical odds with the widespread upstream LLM usage, etc. etc.

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.

by lucideer

7/26/2026 at 3:42:15 PM

The wording of "written with ai tools" implies generation, as do all the concerns about copyright etc. it would be beyond insane to attempt to ban asking a chat bot or an agent questions to navigate or understand a codebase, not in the least because that is completely unenforceable

by vikramkr

7/26/2026 at 6:03:49 PM

> not in the least because that is completely unenforceable

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.

by lucideer

7/27/2026 at 5:53:58 AM

IMO firm wording against non generative uses of AI or lightweight uses like tab complete will go beyond just influencing good faith actors to reduce llm usage - it'll just influence them to not contribute instead. If you make it clear you don't even want llms used for debugging, if you're a good faith actor that makes use of even the most minimal extent of these very common and basic tools, you'd rather just not deal with the hassle. Either you don't deal with debian at all or you don't try and upstream your changes. The latter is probably the desired outcome to limit slop contributions, but when you have the Linus Torvalds making clear that llms are a tool and that he thinks banning their use is absurd when it comes to the kernel itself, youre gonna cut down on a lot more than slop.

by vikramkr

7/27/2026 at 7:21:07 AM

> when you have the Linus Torvalds making clear that llms are a tool and that he thinks banning their use is absurd when it comes to the kernel itself, youre gonna cut down on a lot more than slop

What you're saying here is that you think one person should dictate the philosophical position of every downstream project.

by lucideer

7/26/2026 at 10:35:49 AM

This is a very difficult problem. LLM's don't learn from reasoning about trade-offs and from their personal experience, so systems made with AI assistance stop obeying the unwritten rules of why things are the way they are, that comes from the maintainers' decades of experience.

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.

by logicallee

7/26/2026 at 3:32:32 AM

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.

by sublinear

7/25/2026 at 11:48:39 PM

looks like the best proposal is the just the least bad

by accountrequired

7/25/2026 at 11:50:42 PM

What do you think is the best proposal?

by sanxiyn

7/26/2026 at 12:38:18 AM

It doesn’t really matter for their central point.

by UqWBcuFx6NV4r

7/26/2026 at 9:34:55 AM

That is how policy tends to work

by broodbucket

7/26/2026 at 4:48:05 AM

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?

by JuettnerDistrib

7/26/2026 at 2:26:02 PM

> Shouldn't OSS be the first to benefit?

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.

by wolrah

7/26/2026 at 5:54:43 AM

> 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.

by JodieBenitez

7/26/2026 at 4:53:07 AM

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.

by Alien1Being

7/26/2026 at 5:58:17 AM

Indeed it is, and it doesn't count as a "contribution" at all; the actual work is in fixing the CVE.

by trollbridge

7/26/2026 at 6:44:54 AM

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".

by murderfs

7/26/2026 at 7:41:51 AM

It’s still not an LLM contribution in a meaningful sense. The contribution is the fix, no matter how trivial it is.

by trollbridge

7/26/2026 at 6:21:55 AM

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.

by mmooss

7/26/2026 at 1:00:56 PM

> 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"?

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.

by doginasuit

7/26/2026 at 9:01:15 AM

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

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)

by rcxdude

7/26/2026 at 9:57:47 AM

Copyright law varies across jurisdictions, and it's not obvious how training for AIs would align with https://en.wikipedia.org/wiki/Fair_dealing (and it appears a recent push to re-examine copyright law in Australia ended due to AI companies getting involved).

by aragilar

7/26/2026 at 11:44:22 AM

Exactly. This is like proposing to solve memory safety by asking programmers to simply not make any mistakes. Simply specify that "the contributor should verify" that the code has no use after free, no out of bounds access, no undefined behavior, etc., for which they "assume full responsibility".

by ptx

7/26/2026 at 12:17:42 PM

At the same time, how can a human know if they accidentally rewrote exactly some code they read in the past from a codebase with an incompatible license?

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?

by Orphis

7/26/2026 at 8:28:24 PM

This argument is almost algorithmic: Take the concern about <TECH>, substitute 'human'. Also, another popular response: don't address questions, instead try to put the person asking on the defensive.

The main point is the implicit argument that humans and machines are equivalent.

by mmooss

7/27/2026 at 7:08:46 PM

Sure. But in the end, it's just a tool that is used to assign blame when there are issues, and humans are more comfortable when another human is to blame rather than a machine as it means they are still in control (or have the illusion of).

by Orphis

7/26/2026 at 3:57:33 AM

"Look at this. Look at what they make you give." - The Professor from The Bourne Identity (2002)

by ares623

7/25/2026 at 11:35:53 PM

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

by 1saadcodes

7/26/2026 at 5:21:45 AM

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.

by vouaobrasil

7/26/2026 at 7:59:55 AM

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.

by lifthrasiir

7/26/2026 at 8:41:36 AM

Is the stake high? Doesn’t seem to be the case to me

by dgellow

7/26/2026 at 9:02:30 AM

It is a project-wide concern, so the stake is obviously high.

by lifthrasiir

7/26/2026 at 11:14:52 AM

That feels pretty easy to revert the decision later on if that doesn’t work for some reasons

by dgellow

7/26/2026 at 6:16:58 PM

I disagree. We should adopt caution - so that the burden of proof is on those doing the inventing.

by vouaobrasil

7/26/2026 at 2:12:19 AM

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.

by tulio_ribeiro

7/26/2026 at 8:40:06 AM

The idea that Debian will become irrelevant if it doesn’t accept llm output is so obviously wrong. What would that even mean? Debian has never been a bleeding edge distribution, it’s pretty much the whole appeal, that and the strict rules for packaged software. Even if true, less people using Debian is pretty much irrelevant, it’s not a company trying to grow at all cost.

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.

by dgellow

7/26/2026 at 8:57:35 PM

> 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.

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.

by bigstrat2003

7/26/2026 at 10:04:09 AM

[dead]

by messen

7/26/2026 at 3:44:16 PM

[dead]

by doadfda

7/26/2026 at 3:56:44 AM

[dead]

by horseandcart

7/26/2026 at 9:04:32 PM

[dead]

by snootypoot

7/26/2026 at 2:38:46 PM

tl;dr right problem, wrong solution.

by andrewjneumann

7/26/2026 at 2:34:46 AM

Proposal D, currently enacted: Use LLMs but don't tell anyone

by nilespotter

7/26/2026 at 7:26:04 AM

Poor Debian. AI is killing it right now.

by shevy-java

7/26/2026 at 12:21:25 AM

Proposals like these are arrogant and obnoxious. You aren’t going to tell me what tools I can use.

by baggy_trough

7/26/2026 at 12:38:33 PM

Were you going to contribute to Debian otherwise?

by ahartmetz

7/26/2026 at 8:42:13 AM

Then don’t contribute? It’s crazy how some of you feel offended that projects you’re not engaged with might decide to not use LLMs

by dgellow

7/26/2026 at 4:55:12 AM

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.

by bigstrat2003

7/26/2026 at 2:21:08 PM

I simply don't accept that this type of project rule has any validity. It's like telling me what editor I can use, or that I can't use Google to search for programming tips, or that I can only use an electric car to drive to the office.

by baggy_trough

7/26/2026 at 3:07:17 PM

Debian has, like all software projects, always had rules about how you created the code you contributed. No software project is going to accept your contributed code which you wrote at work using company time and resources; that’s a copyright violation. There has never been a situation in which simply your contributed code can be analyzed and accepted in a vacuum. Bits do have color: <https://ansuz.sooke.bc.ca/entry/23#:~:text=historical>

by teddyh

7/26/2026 at 6:44:11 PM

They are unenforceable and the motivation looks to be political in nature. I will simply ignore them, but it does reduce the credibility of Debian if the more AI-hostile variants of these pass.

by baggy_trough

7/26/2026 at 8:59:11 PM

Well, you're wrong. Whether or not you are actually writing the code is well within their right to regulate. Using an LLM is no different than if you hired a guy to write code for you and contributed it under your name; they would probably explicitly ban that too if there were significant numbers of people doing it.

by bigstrat2003

7/26/2026 at 9:14:55 PM

It is quite different indeed. There are many ways to use an LLM. Blunderbuss approaches like this are wrongheaded and ignorant.

by baggy_trough

7/26/2026 at 1:31:12 AM

Proposal A

Using LLM encourages data theft or unethical acts.

by lilerjee

7/26/2026 at 3:05:39 AM

How can they even tell code was written by AI instead of a human?

by phyzix5761

7/26/2026 at 3:25:34 AM

> 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.

by yjftsjthsd-h

7/26/2026 at 3:15:45 PM

Yeah, good luck with that.

by phyzix5761

7/26/2026 at 3:14:02 AM

emdashes

by bdangubic

7/26/2026 at 3:16:16 PM

Code uses emdashes?

by phyzix5761

7/26/2026 at 8:41:16 PM

sorry I was just joking :)

by bdangubic

7/26/2026 at 3:53:16 AM

My coding TUIs all have rules to never use emdashes.

by hparadiz

7/26/2026 at 9:00:17 PM

For one thing, LLMs write terrible code. So unless a human does a lot of editing, they'll be able to tell because the code is slop.

by bigstrat2003

7/25/2026 at 11:33:30 PM

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.

by alightsoul

7/25/2026 at 11:41:30 PM

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.

by aabhay

7/25/2026 at 11:43:26 PM

That is Proposal C, not Proposal A. (Although I do think Proposal A as written also does not forbid translation usage to communicate.)

by sanxiyn

7/25/2026 at 11:40:25 PM

I don't believe Proposal A forbids this usage.

by sanxiyn

7/25/2026 at 11:46:24 PM

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.

by alightsoul

7/25/2026 at 11:49:35 PM

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.

by sanxiyn

7/25/2026 at 11:53:05 PM

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

by alightsoul

7/26/2026 at 6:12:17 AM

This is a somewhat common talking point for supporting LLMs. What did non-English speakers do before LLMs?

by mmooss

7/26/2026 at 8:12:49 AM

They learned English or gave up.

by lifthrasiir

7/26/2026 at 8:49:12 AM

Or got help from someone else who was better at English.

by tmtvl

7/26/2026 at 7:41:35 PM

What about translation software that existed before LLMs?

by mmooss

7/25/2026 at 11:57:20 PM

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

by Barrin92

7/26/2026 at 12:00:46 AM

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.

by alightsoul

7/26/2026 at 12:33:04 AM

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.

by Barrin92

7/26/2026 at 12:58:59 AM

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

by alightsoul

7/25/2026 at 10:26:39 PM

Good so Debian will die soon or later.

by mt42or

7/25/2026 at 10:31:30 PM

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?

by ahofmann

7/26/2026 at 12:40:40 AM

Anyone that has an opinion about this, already knows that, yes. Drop the condescension.

by UqWBcuFx6NV4r

7/26/2026 at 8:46:54 AM

My question was genuine. I have no idea why someone wants Debian to die, so I asked.

by ahofmann

7/25/2026 at 10:29:22 PM

By Lindy effect, debian has a life expectancy of 25 more years

by TZubiri

7/26/2026 at 1:04:57 AM

Just like BSD is dying. Netcraft confirms it.

by steelframe

7/25/2026 at 11:15:54 PM

The fact that some react to these like they were taken away some possession is genuinely interesting

by numpad0

7/26/2026 at 3:49:01 AM

This is ridiculos, think about that, will Debian project survive without a Linux kernel written with the help of LLM tools?

by fisheuler

7/25/2026 at 11:40:08 PM

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.

by prologic

7/26/2026 at 2:05:17 AM

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.

by mappu

7/26/2026 at 2:58:51 AM

An LLM is a tool.

A nuclear bomb is a tool.

And programmers are the biggest tools of them all.

/ba dum tis

by pixl97

7/26/2026 at 2:33:03 AM

You wouldn't program a computer with a nuclear bomb!!!

by potsandpans

7/25/2026 at 11:42:05 PM

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.

by sanxiyn

7/26/2026 at 1:38:32 AM

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.

by prologic

7/26/2026 at 9:06:52 AM

Or does it?

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"?

by b112

7/26/2026 at 2:43:41 PM

My partner went to a carpentry school in Seattle 7 years ago where I learned about sawstops and I remember thinking the same. A pretty amazing technology exists that saves lives and limbs, and it is weird that we allow table saw without this technology.

Interestingly there was a discussion here about exactly that a couple of years ago: https://news.ycombinator.com/item?id=39977058

by runarberg

7/26/2026 at 2:21:12 AM

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.

by runarberg

7/26/2026 at 2:25:11 AM

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!

by prologic

7/26/2026 at 2:34:45 AM

WTF. Food safety is just a reasonable thing for a mature civilization to do. It has nothing to do with banning technological advancement.

by sanxiyn

7/26/2026 at 2:55:12 AM

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.

by prologic

7/26/2026 at 8:56:12 AM

At least in the US, no, not many, and the fish itself is very import restricted to keep the toxic parts from reaching the market. Hmmm.

by eichin

7/26/2026 at 3:00:49 AM

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.

by pixl97

7/26/2026 at 4:56:41 AM

Yes, people make mistakes. But they make far fewer than LLMs.

by bigstrat2003

7/26/2026 at 12:27:17 AM

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.

by UqWBcuFx6NV4r

7/26/2026 at 8:56:35 AM

Ironically, any SoTA LLM would be able to make a better analogy than you. Sometimes the average human is the slop generator

by greyw

7/26/2026 at 1:43:49 AM

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.

by tulio_ribeiro

7/26/2026 at 1:47:00 AM

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".

by prologic

7/25/2026 at 11:56:58 PM

> 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?

by dataflow

7/26/2026 at 1:44:27 AM

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.

by prologic

7/26/2026 at 4:46:34 AM

> 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?

by dataflow

7/26/2026 at 12:32:19 AM

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.

by UqWBcuFx6NV4r

7/26/2026 at 8:11:06 AM

Yeah, I agree, it's really stupid. It's like discussing whether contributors are allowed to use google search, stackoverflow, an encyclopedia, etc.

by jagadaga

7/26/2026 at 4:54:42 AM

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.

by gorgoiler