Debian Votes To Allow "Responsible Use Of Generative AI" : linux

[-] j3tt@lemmy.world 10 points 6 hours ago

This is good news; Debian is still the way to go for me:

Debian acknowledges that the legal status of material produced by generative AI systems remains the subject of ongoing discussion in many jurisdictions, including questions relating to copyright, authorship, licensing, and potential reproduction of training material. The Project does not seek to resolve these unsettled legal questions through this General Resolution, nor does it adopt a position on whether AI-generated output is, in whole or in part, copyrightable or derived from copyrighted works.

[-] tengkuizdihar@programming.dev 46 points 10 hours ago

Responsible use of llms can't be achieved. Can you verify that all of your training data are square with its creators? If not, how is that responsible?

[-] SapphironZA@sh.itjust.works 6 points 4 hours ago

It can if you control the training data, or if the data is public domain.

But I get your point. You can say all the Diamonds you use are conflict free, but out of the thousands you have, how do you know some have not slipped in.

At what point do you say you did a good enough job, and at what point is it too contaminated?

Like many things, it difficult to draw a line, so its up to communities to set a reasonable standard.

[-] OwOarchist@pawb.social 10 points 8 hours ago

Can you verify that it didn't reproduce any code that's proprietary or has more restrictive licenses than your own?

[-] DmMacniel@feddit.org 9 points 7 hours ago

That's the main issue for FOSS.

[-] anzo@programming.dev 5 points 7 hours ago

The complement/ reverse is true for companies that produce proprietary software (but they won't care, sure.)

[-] sbeak@sopuli.xyz 27 points 10 hours ago

In a nutshell, it looks like AI disclosures are encouraged, but not required, and AI usage is encouraged to be human reviewed, but not required. They have also stated they will not allow the use of online AI services for security reasons (but how this will be enforced I'm not sure, since they are relying on the judgement of contributors)

[-] dreamkeeper@literature.cafe -4 points 8 hours ago

No online services? So you can use AI to generate code, but only garbage local AIs (assuming you don't have a ton of RAM)?

This seems like the weakest possible decision they could've made.

It's open source software. I'm not saying security isn't a concern, but this is just stupid.

If you're not going to ban AI then you should at least take advantage of models that are more reliable and produce higher quality output.

[-] sbeak@sopuli.xyz 8 points 5 hours ago

It looks like their point is that they don't want Debian's codebase to be used to train corporate AI models, and almost all the proposals seem to agree on that at the very least. I feel like a required AI disclosure would have been better, but what do I know, I'm not a Debian contributor

[-] j3tt@lemmy.world 8 points 6 hours ago

You are not supposed to use online LLMs for undisclosed security stuff; there is no general ban of online services if you can take responsibility for the stuff it produces for the contributor. At least, this is how I read the general resolution.

This is one more reason, that using Debian as my main distro was a good choice.

[-] dreamkeeper@literature.cafe 1 points 2 hours ago

Ah my bad, that makes more sense.

[-] FiniteBanjo@feddit.online 13 points 11 hours ago

Yikes, rest in peace Deb users. I just hope it never happens to my distro.

[-] terabyterex@lemmy.world 32 points 10 hours ago

if your distro uses the linux kernel then its already happened.

[-] eleijeep@piefed.social 6 points 6 hours ago

This vote was not about upstream projects included in the Debian distro, it was about the Debian project itself.

[-] terabyterex@lemmy.world 1 points 34 minutes ago

i didnt say it was. the guy i was responding too wasnt talking abput debian but whatever distro he uses. implying it was free of any ai assisted code.

[-] queerlilhayseed@piefed.blahaj.zone 10 points 9 hours ago

I ain't shook up about it. There's not really a surefire way to detect tool-assisted code gen anyway, so IMO the acceptance criteria should be the same as it's always been, tool-assisted or otherwise. Which is ultimately the path they chose to take.

[-] FiniteBanjo@feddit.online 7 points 9 hours ago

Obvious slop should be immediate permanently banworthy, sloppers can just keep burning new accounts (as long as they have access to new IP addresses) while real developers deserving of praise and reputation thrive.

[-] eleijeep@piefed.social 10 points 6 hours ago

sloppers can just keep burning new accounts (as long as they have access to new IP addresses) while real developers deserving of praise and reputation thrive.

Becoming a Debian developer requires you to meet an existing Debian developer in person and have your public key signed by them. It's not possible to keep burning new accounts unless you go and meet a different Debian developer each time and there's a limited number of them in each region and they usually meet together, so more than one person will see your face.

[-] queerlilhayseed@piefed.blahaj.zone 5 points 8 hours ago

Yep. I'm not familiar with Debian's strategy specifically, but generally, I think any new contributor to a project should be subject to heightened scrutiny. My policy is that new contributors should start small and develop a rapport with the maintainers before submitting more ambitious (and for the maintainers, more costly to review) large and/or critical path PRs. It was a good policy before LLMs and I think it remains a pretty robust method of weeding out irresponsible devs without wasting a ton of maintainer time. There are simply more slop PRs to reject sight unseen these days, which is admittedly very annoying, but the process is much the same as it's always been.

I'll admit I don't maintain any projects anywhere near the popularity or volume of the Debian project, so I'm not really sure what the view is from their vantage point.

[-] FiniteBanjo@feddit.online 3 points 8 hours ago* (last edited 8 hours ago)

I still think that's not good enough, that treating them fairly is a stupid waste of time and resources and unfair to everyone else.

Just make the rule "any slop" and give the idiots a checkbox so they can ban themselves for reasons which will never be revealed to them (sloppers don't read documents, it'll take them a while to figure out). Also start banning people when evidence surfaces of them admitting to slopping.

I don't like this concept that a slopper can potentially produce decent code, the data shows this simply isn't true: sloppers produce vast amounts more and worse bugs and vulnerabilities. It's better for the health of the project to ban it in every scenario.

[-] queerlilhayseed@piefed.blahaj.zone 0 points 8 hours ago

How is treating one contributor fairly unfair to another contributor? If you want to add a "check this box to get your PR dumpster'd" checkbox I guess go nuts, but I'm unconvinced that's a good long-term solution. I find it easier to ask "Do I know this contributor, or did they follow the new contributor guidelines and submit a small, single-issue PR?", and if the answer is "no" then the PR gets ignored or, if I'm feeling gregarious and have the time, rejected with change requests. It's a pretty easy rubric.

Humans have been perfectly capable of generating huge volumes of trash code, and code that looks good at first glance but has tricky bugs or vulnerabilities, since long before LLMs were a thing. The only real change now is the pace at which shitty code can be ripped out. IMO the solution is just: don't accept more code than you can review and test. If that means rejecting 10x or 100x more LoC than you did five years ago, then... ok. It is more busy work, and it is annoying. But I don't think trusting contributors to self-declare LLM use is an answer to the problem. There are better ways of rate-limiting eager beavers, regardless of what tools they use.

[-] cupcakezealot@piefed.blahaj.zone -1 points 5 hours ago

for fuck sakes; stop pretending the csam generating machine is useful.

[-] SapphironZA@sh.itjust.works 0 points 4 hours ago

Just because you could not find a use for it, does not mean millions of other people have not.

Just like any technology. you can use it responsibly or irresponsibly.

[-] cupcakezealot@piefed.blahaj.zone 3 points 2 hours ago

if people are finding use for a csam generating machine, i hope they get a visit from the fbi

[-] SapphironZA@sh.itjust.works 2 points 2 hours ago

I take it you think the only use for a microwave is to cook babies?

[+] Sina@beehaw.org -7 points 10 hours ago* (last edited 10 hours ago)

Sanity won imo. We can argue all day about what responsible Ai use is, but distro projects without allowing AI use at all and are serious about are dead in the water. What were they supposed to d do? Disconnect with upstream?

[-] fruitcantfly@programming.dev 17 points 8 hours ago

None of the proposals would have banned AI usage in upstream projects:

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

[-] FiniteBanjo@feddit.online 15 points 8 hours ago

There are more kernel forks every day, fuck the sloppers. From where I'm sitting the slop distros which allow or even rely on AI are sick with a cancer and doomed.

[-] jobbies@lemmy.zip 0 points 3 hours ago

Yep. There is a middle ground with generative AI and they've struck the right balance.

[-] esc@piefed.social 0 points 7 hours ago

Nooo, you see chosing utilitarian position is a sin.

Linux