Comment by simonw
3 days ago
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.
> 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).
> 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.
A bit of topic, but does the word "seconded" still work when five are required? Isn't there a more generic term?
2 replies →
I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs. Like, if you have two forks of Debian and one uses LLMs to fix exploitable bugs and the other one doesn't, the level of security they can offer will be worlds apart. And noone in their right mind would want to use the less secure one. Similar to how noone would want to drive a car that was 100% hand built by humans when we know that machines do a much better job at precision tasks. LLMs are just another tool in the end.
> I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs.
You can use an LLM to scan your human written code for exploits and patch the relevant ones yourself without any LLM code generation. An LLM is a tool, you can chose how you use it.
4 replies →
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"
6 replies →
All the proposals allowed LLMs in upstream packages.
> And noone in their right mind would want to use the less secure one.
I mean, this is a perfect description of the prisoner's dilemma. Ins't it a shame that we keep playing that game? There's something seriously wrong if we just keep creating these new arms race scenarios. It's sickening.
1 reply →
you can neither check nor enforce any conditions. So the right answer is A
[dead]
I wonder how they can reconcile the stricter proposals with the LLM usage in kernel development. That seems totally untenable. I mean it all seems untenable, but with the kernel especially.
Also, what about when you inevitably get a situation where a critical vulnerability is discovered, and the only patch available is LLM generated? Do they have to wait to patch until some person who hasn't seen the LLM-generated patch does a clean room implementation?
I understand the objections to LLMs, but rejecting LLM-generated code really doesn't seem realistic.
Kernel development is excluded from this, because it's covered by "Upstream projects using LLMs for development".
On security, I worry that proposal A's "forbid any contributions to Debian written with the use or assistance of large language models", as written, excludes contributions where the LLM assisted in discovering the vulnerability. That's clearly a bad policy, and they should update their wording to clarify that.
I read the question more as, if AI is working out for the kernel, why not a distro? (This is a question with valid answers, like the kernel having more devs paid to handle things while maintaining quality, but it's a fair question)
Isn't basically every package in Debian an upstream project?
1 reply →
The proposals which say no LLM generated code mean just for Debian, if upstream allows it then they will still accept it. It’s just contributions to Debian itself which would prohibit or discourage LLM contributions.
There is also proposal D right at the bottom, which is "Accept AI contributions for Debian specific work".
Thanks, we've put the three proposals bit in the title above.
There actually seem to be 4 separate proposals right now, maybe another was just added?
Proposal D is "Accept AI contributions for Debian specific work"
Wait, can we have a vote to not link HN contributions to dynamic pages!
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.
The title says "proposals"
Why would someone misinterpret this as a final decision?
I misinterpreted it as a final decision when I first skimmed the page. The title of the linked document is "Resolution: LLM usage in Debian" and it's not obvious that it's several competing proposals until you explore the page in more detail.
The Hacker News submission title was updated to include "Three Proposals" after I posted my comment.
Eternal September of the Spotless Mind.
It seems the title wasn't always as clear.
Note that we are still in the discussion period, and more proposals can and will be added. Some might even be withdrawn.
Mr President, a 4th proposal has hit the General Resolution.
Disappointing there's not a Proposal E "require use of LLM's by contributors"