Debian Decides: Contributors Can Use Generative AI 'Responsibly' (debian.org) 29
This week Debian voted on whether to ban AI-assisted contributions. The winning proposal? "Debian neither endorses nor prohibits the use of generative AI tools" in its projects, documentation, and packaging... Generative AI "is neither exempt from nor subject to special rules beyond the standards already expected of Debian contributors."
"The responsibility for every contribution rests with the contributor who submits it, who remains accountable for its technical quality, legal acceptability, and suitability for inclusion in Debian." "We recognize that such tools can substantially improve the productivity of contributors when used responsibly, allowing volunteers to spend more of their limited time on work that requires technical expertise, judgment, review, and collaboration.
The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance. The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit. Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian. Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian's established development practices.
We enourage our contributors to disclose whether a contribution was made with AI assitance, but do not require them to do so.
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... 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. Instead, Debian continues to rely on the judgment and responsibility of its individual contributors. Project members are expected to exercise appropriate care when using generative AI tools, to consider the provenance and licensing implications of material they contribute, and to avoid introducing content whose legal status they cannot reasonably justify. Existing Debian policies governing licensing, copyright, software freedom, and the acceptance of contributions continue to apply irrespective of the tools used to produce those contributions.
It also cautions contributors to keep keys, credentials, and embargoed security reports from leaking to third-party AI services.
But discussion continues on Debian's mailing list. "I regret the loss of contributors," wrote the author of the winning proposition (while acknowledging it would have happened with either option winning). "It is just too early to take a final decision on the matter. Let's revisit this in two years or so, and let this mess of a GR be a warning for our future selves."
Other comments from the mailing list:
"The responsibility for every contribution rests with the contributor who submits it, who remains accountable for its technical quality, legal acceptability, and suitability for inclusion in Debian." "We recognize that such tools can substantially improve the productivity of contributors when used responsibly, allowing volunteers to spend more of their limited time on work that requires technical expertise, judgment, review, and collaboration.
The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance. The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit. Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian. Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian's established development practices.
We enourage our contributors to disclose whether a contribution was made with AI assitance, but do not require them to do so.
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... 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. Instead, Debian continues to rely on the judgment and responsibility of its individual contributors. Project members are expected to exercise appropriate care when using generative AI tools, to consider the provenance and licensing implications of material they contribute, and to avoid introducing content whose legal status they cannot reasonably justify. Existing Debian policies governing licensing, copyright, software freedom, and the acceptance of contributions continue to apply irrespective of the tools used to produce those contributions.
It also cautions contributors to keep keys, credentials, and embargoed security reports from leaking to third-party AI services.
But discussion continues on Debian's mailing list. "I regret the loss of contributors," wrote the author of the winning proposition (while acknowledging it would have happened with either option winning). "It is just too early to take a final decision on the matter. Let's revisit this in two years or so, and let this mess of a GR be a warning for our future selves."
Other comments from the mailing list:
- "On a very personal note, I regret that the winning option does not acknowledge all the legitimate concerns around AI: environmental impact, copyright and licensing uncertainty, the health of Free Software communities, and the strain of aggressive scraping on the open web... [W]e have a lot of work ahead of us to act as a community and understand how we can continue to accommodate the very large minority that would have preferred to ban or discourage AI.
- "I also think that our next discussion should distinguish between locally running LLMs and cloud LLMs. The way things are going, locally running LLMs will be an alternative, and then you can much better control what was the training data and the Freeness of the thing."
Thanks to long-time Slashdot reader Robbat2 for sharing the news.
Re:Local models are an option NOW. (Score:5, Insightful)
The problem with that is that most people writing code do not have a good idea what is all required on a more abstract level. And hence using coding assistants they will overlook stuff they would not have coding directly. This is, incidentally, not a new situation. When I did my CS studies some 35 years ago, the 5GL project had just completely failed. The idea was to have the coder only write a spec in constraint logic and have the code synthesized by software. Turns out, writing a spec for code is much harder and more effort than writing code. I suspect LLM coding assistants are subject to the same problem, with hallucinations added on top.
Re: (Score:1)
Re: (Score:2)
I don't think this problem is new due to AI. You need to know what you want with AI (frontier models may help a bit more with that) and also without AI. The intern who can code needs guidance what to code just like the AI.
I see a bit of problem for the new generation. If you stop coding today and only guide AI you will still be able to produce good code. The intern will still be able to produce code, but never learn to understand it that much as you do. And the problem is, that the motivation to learn how t
Re: (Score:2)
I not only have an idea, I am teaching it. Other engineering disciplines demonstrate it as well. The key is to teach the low-level tech to a level so that students understand it. Yes, that takes time. But since I teach things like secure coding, some things cannot even be explained without it and we take students though some assembler and C, for example. And unlike coding education, we get no complaints since they see that this level of understanding is needed.
Classical coding could do this as well. For exa
Re:Local models are an option NOW. (Score:4, Informative)
Cool story bro.
This article is about Debian allowing the use of genAI for code incorporated into the Debian repos despite the international legal uncertainty, the environmental impacts, and the lack of quality that's largely being ignored solely because software in general has seen a collapse in quality since the early 2010s.
It isn't about your slopware habits.
I'm curious to know whether the people in charge of Debian have a back-up plan if Debian turns out to violate copyright in countries across the world or whether their solution will be to just shrug and say "Well countries that don't allow AI generated slop without compensation to the original copyright holders will just have to do without "open source" - which today is adulterated by shitty unreadable code from slopgobblers."
They should have used the GCC decision (Score:2)
The GCC folks have obviously a far better understanding of the problem than the Debian leadership.
Re: (Score:3)
The GCC folks have obviously a far better understanding of the problem than the Debian leadership.
"For the time being, the GNU Compiler Collection (GCC) policy is to decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content. "
Linus Torvals and Greg K-H are using AI in the Linux Kernel and introducing LLM generated code in the Kernel (mostly pathces) NOW.
I'd venture the guess that the Kernel is "Legally Significant" from Debian's point of view.
What is Debian to do if the adopt the same approach as GCC? Reject the Linux Kernel due to the pr
Re: (Score:2)
Re: (Score:2)
All previous versions of the Linux kernel are available. Nothing stops any distro project from freezing the version they include. In fact, this has been done many times before, since modern Linux is a "bloated piece of crap" (TM) for some people's purposes.
Tell us how that works for your favourite "non-AI" distro in 2040, when the last non-AI SLTS Kernel (6.12) has been going without any patches for 4 years.
Re: (Score:2)
All previous versions of the Linux kernel are available. Nothing stops any distro project from freezing the version they include. In fact, this has been done many times before, since modern Linux is a "bloated piece of crap" (TM) for some people's purposes.
Oh, wait, is even worse, because LTS and SLTS kernels will receive AI patches. You will have to fork the last Non-AI kernel, and develop all the patches yourself, without ever again looking at the Linux mainline code, as some of that may have AI patches in it... Also, if you want that kernel to suuport new hardware, you will have to write the changes yourself...
Good luck with that.
Re: (Score:2)
Re: (Score:2)
Indeed, a tty? who needs that? I just catch the keyboard interrupt and I write directly to B000:0000 memory address to display output.
https://www.phatcode.net/res/2... [phatcode.net]
Re: (Score:1)
"For the time being, the GNU Compiler Collection (GCC) policy is to decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content. "
How would they know?
Seriously, remove the excessive code comments or what have you, and how the bleep would they even know that you used an LLM to help generate your code?
It's like pompously declaring that you won't accept nails pounded by Craftsman hammers, because of a labor dispute or something.
Re: (Score:2)
This is not about knowing. This is about liability. If it turns out they have to rip out LLM generated code, they (a) are not liable for it being there, the contributor is and (b) the courts will give them time to do it. Obviously, whoever submitted LLM code could find themselves sued for massive amounts of money and hence this also serves as a clear warning.
That said, I think the kernel-team is pretty much doing the same thing, just less obviously so. They have very strong requirements on all contributed c
Re: (Score:3)
It was offered as a choice I think. Debian put it up to a vote.
And the FSF has good reason for the GCC decision - because the legal status of AI contributed code is uncertain. Is it a code laundering machine that can turn GPL code into legitimate "free" code? Or does code retain the license? Either situation is bad, especially the second where incompatible licensed code (e.g., GPLv2, BSD, etc) might get introduced which complicates the licensing.
Debian is far less reliant on code - the amount of original D
Re: (Score:2)
It is not just the license, it is the ownership. For GCC or the kernel, that could mean the thing suddenly belongs to somebody and is not free anymore. Just remember the SCO and Java lawsuits and how they put a black cloud over things for a long, long time.
We will see how that turns out. I agree that consequences for Debian will probably less catastrophic technologically and may mainly mean they have to rip out packages or patches. Since anything contributed to Debian needs to meet the DFSG and hence Debian
Re: (Score:2)
the amount of original Debian code is very small compared to the amount of code they ship
Debian is four things besides contributors: Governance/COC, license, code, and a network of repos. Debian's code is a tiny amount compared to the overall distribution, but code is not a trivial percentage of Debian.
I'd like to see them be resistant to AI contributions to the code that makes up Debian, I don't care as much if AI is used to do packaging. That's probably a place it could succeed, especially since Debian uses systemd and there will already be unit files which just need paths corrected in predic
Re: (Score:2)
You post would really have benefited from explaining what the GCC decision was.