[simonw]

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.

[clcaev]

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.

[gsliepen]

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

[rlpb]

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

[tomtomtom777]

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

[tingletech]

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.

[setopt]

n’th’ed?

[sigmoid10]

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.

[AlexeyBrin]

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

[throw101010]

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.

[__bjoernd]

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?

[goodmythical]

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"

[cuu508]

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.

[calvinmorrison]

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

[setopt]

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

[DaSHacka]

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

[mrtx01]

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

They should call it:

debAIn

[sigmoid10]

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

[trollbridge]

All the proposals allowed LLMs in upstream packages.

[vouaobrasil]

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

[DaSHacka]

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

You mean technology?

[vrighter]

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

[smellf]

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.

[simonw]

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.

[yjftsjthsd-h]

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)

[aspensmonster]

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

[simonw]

They're talking about the software that is unique to Debian, like their lintian tool. https://wiki.debian.org/Lintian

[bradfa]

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.

[mmwelt]

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

[dang]

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

[infl8ed]

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"

[MeteorMarc]

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

[dvhh]

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.

[lacoolj]

The title says "proposals"

Why would someone misinterpret this as a final decision?

[simonw]

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.

[derrida]

Eternal September of the Spotless Mind.

[Cider9986]

It seems the title wasn't always as clear.

[ckastner]

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

[fl0ki]

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

[hackeraccount]

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