Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLM Usage in Debian: Three Proposals

debian.org

Post reply on HN
Print view View original

111–120 of 228 posts

Re: LLM Usage in Debian: Three Proposals

#111

Post by vouaobrasil »

1saadcodes wrote: post #19

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

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.

Re: LLM Usage in Debian: Three Proposals

#112

Post by vouaobrasil »

sigmoid10 wrote: post #68
clcaev wrote: post #27

Earlier quoted context omitted.

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 contribu…

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…

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

Re: LLM Usage in Debian: Three Proposals

#113

Post by JodieBenitez »

JuettnerDistrib wrote: post #106

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?

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

Re: LLM Usage in Debian: Three Proposals

#114

Post by trollbridge »

sigmoid10 wrote: post #68
clcaev wrote: post #27

Earlier quoted context omitted.

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 contribu…

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…

All the proposals allowed LLMs in upstream packages.

Re: LLM Usage in Debian: Three Proposals

#115

Post by trollbridge »

Alien1Being wrote: post #107

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.

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

Re: LLM Usage in Debian: Three Proposals

#116

Post by e12e »

hkalbasi wrote: post #13

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

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?

Re: LLM Usage in Debian: Three Proposals

#117

Post by mmooss »

alightsoul wrote: post #16

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.

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

Re: LLM Usage in Debian: Three Proposals

#118

Post by mmooss »

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.

Re: LLM Usage in Debian: Three Proposals

#119

Post by josu »

e12e wrote: post #116
hkalbasi wrote: post #13

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

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?

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

Re: LLM Usage in Debian: Three Proposals

#120

Post by cuu508 »

goodmythical wrote: post #74
sigmoid10 wrote: post #68

Earlier quoted context omitted.

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…

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%…

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.
Post reply on HN