I will tell my children this is what popped the bubble in the end. W Debian
The mass-extinction causing orphan-crushing torment nexus (MECOCToN) is a tool, just like other tools we use. And it’s clearly a useful one.
There are other questions around MECOCToN (like if we should be complicit in killing billions of people, and making more than 50% of genera go extinct, via its CO2e releases and water use), but “is it useful” is no longer one of those questions.
The Debian project has been and will continue to be about the technology.
Sure, the people who use it is important and often a very motivating part of the project, but in the end that’s a side benefit, not the point of the project.
In the Debian community we do open source because it results in better technology, not because of ethical reasons.
And so we make decisions primarily based on technical merit. Not fear of causing a mass extinction.
/s
Geiger’s proposal cites four main concerns: copyright, technical quality, impact on Debian’s volunteer community, and broader ethical issues related to generative AI.
I do not envy their position. Either way they are going to get irate comments.
I lean more towards Nussbaum’s position. Allow it only when the submitting person can explain the changes. That would at least put completely vibe-coded submissions out of Debian.
That being said, I would ban fully automated submissions from bots and agents. A human still needs to have a part in it, in my opinion.
Yeah, I agree. In practice it’s difficult to tell whether or not someone used AI to help them code something (especially if they didn’t just tell the LLM to do everything lmao), so it makes more sense to check whether they actually understand the code they’re trying to commit. That’ll keep out the slop while still letting people use coding LLM agents as a static analysis tool for finding bugs or something.
I think I’d be okey with semi automated submissions if they are managed by the maintainer themselves. There were a couple of security incident of long existing vulnerabilities recently. I think its fine if maintainers have a bot running making security audits to find and fix them before somebody else can use them. Of course if some human going over potential PRs.
the most basic rule of thumb that should ALWAYS be held to is that a human has to take responsibility for the actions of a tool, computers cannot be held accountable.
A computer can never be held accountable, therefore computers must never make a management decision.
Rules about submissions and determining if a pr helps a project is a management decision. AI or automated tools can reject a PR if it fails to meet a human made rule (like failing to compile or breaking code standards) but accepting a pr to merge? That should be a human.
“Written” by AI agents, no less.
Debian doesn’t seem like an organization that would allow AI contributions. I hope I’m right.
same. I came to Debian looking for stability. would be a shame for them to shit on that trust.
It’s a no-brainer guys. Ban that shit.
Eh, if the kernel (Linus himself) hasn’t banned it, maybe it isn’t a no brainer.
Nope, its still a no-brainer. Linus is just being a moron.
Linus clearly meant that the tech is useful, and based on his history he probably meant for debugging more than anything else. And he’s absolutely right, there have been lots of vulnerabilities found by the thing. He didn’t say generated code is great, or that no human review is needed, or how we can adapt to incorporate gen ai in our workflows, etc. He only said it’s a useful tool, and that he doesn’t care about the ethics behind it (which is dumb, but we shouldn’t be surprised, especially if people are trying to push him into a direction, he’ll lash out and pick whatever is pragmatic in his view).
The ethics are a major concern and if you dismiss that, you are a moron. AI wasnt born out of good will, it was born out of a desire for profit. Until it’s energy efficient and the models are built ethically, it’s a no-brainer to deny its use. Once them concerns are addressed then we can start the conversation about the pros and cons of dealing with slop.
Well… I’m quite on the fence about AI, after being against it for a while.
Your point stands. Current AI use is terrible: both the ecological disaster and mass theft they present are not small issues.
Yet these aren’t a fault of the tech itself. They’re the fault of the companies doing said theft, and the governments either silently or openly ebracing said theft. And economic bubble fueling the theft and the unprecedented rate of datacenters popping up.
I like to compare AI to photography. Both are/were revolutionary. Both killed jobs. Both raised copyright issues. Yet photography today is an integral part of life. And I’m afraid LLM chatbots will be as well in ad few as 15 years.
There’s no stopping technological progress, even when it’s actively blocked - let alone when governments feed billions into it and take a blind eye to all its issues.
So the case isn’t as clear cut. You can admit defeat now, or you can wait a bit. You can be the sole hermit not using it in a world which does. Which is a personal choice for everyone. The only thing to ask is: is it the right one for an open source project?
Rejecting “known unethical” tools does seem like a sensible approach though. Either make your own, use a known-good one or do things the old fashioned way. No leaded gas in our vicinity allowed.
Photography isnt dangerous, it’s a form of art, capturing something that is real and tangible.
AI is fabricating something that isnt real, using works that were real. It’s dangerous, it’s not art. The only people who put time into is productions are the ones it stole from.
While I get what you are trying to say, it’s a terrible comparison. AI is already causing a lot of harm to humanity and will continue to do so. We should reject it for as long as we can, hopefully forever. If it does stay, it should be heavily, heavily regulated.
I’m completely with you there
What does this mean when the kernel allows AI contributions?
This would not conflict with linux kernel policy, nor with other upstream use of AI. The article makes it clear:
Importantly, the ban would not apply to upstream projects that use AI, software related to artificial intelligence, or patches and security fixes from upstream sources. In other words, Debian could still package third-party software developed with AI assistance, but Debian contributors would be prohibited from using such tools for direct project work
Debian is its own project with their own maintainers and policy.
I would assume they would concider the kernel an upstream project and therefore exempt from the policy.
