Debian votes to allow “responsible use of generative AI”
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.
Posted Aug 29, 2026 14:03 UTC (Sat) by dskoll (subscriber, #1630) [Link] (3 responses)
I’m a bit sad it went that way, but I guess it was inevitable. Debian is too large a project to be able to meaningfully enforce a stronger stance against LLMs. So I think they realized it’s pointless to make rules that you can’t enforce.
Posted Aug 29, 2026 15:06 UTC (Sat) by MarcB (subscriber, #101804) [Link] (2 responses)
Posted Aug 29, 2026 20:08 UTC (Sat) by tachi (guest, #185877) [Link] (1 responses)
Also, (at least for me) the point was not to focus on enforcement, but rather signal to the wider world “Hey, we think this is not OK”.
Posted Aug 29, 2026 20:12 UTC (Sat) by bluca (subscriber, #118303) [Link]
Posted Aug 29, 2026 14:20 UTC (Sat) by bluca (subscriber, #118303) [Link] (4 responses)
The rest of the options cleared that line and then it was a (complicated) matter of which one was the “least unfavored” among all voters, so to speak.
A handy graph that someone else prepared makes the result a lot more digestible: https://people.debian.org/~lucas/gr-2026-002/results.png
Posted Aug 29, 2026 14:41 UTC (Sat) by mhvk (subscriber, #86585) [Link] (3 responses)
Personally, I hope that truly open locally run models, perhaps specialized to coding, become sufficiently good that one can do without the large, closed-source ones (which to me are very problematic for lots of reasons; it doesn’t help to come from a country that will be under water — the Greenland icesheet melting completely is nearly unavoidable by now, and 6 meters of sea level rise is more than one can build dykes for; why these data centers are not forced to rely on renewable energy is truly beyond me).
Posted Aug 29, 2026 14:45 UTC (Sat) by bluca (subscriber, #118303) [Link]
With this voting system, failing to beat “NOTA”, as mentioned, means the option is soundly rejected even before considering relative preferences
Posted Aug 29, 2026 15:20 UTC (Sat) by MarcB (subscriber, #101804) [Link]
In theory, they are. The problem is that the absurd investments into AI hardware have made it unaffordable. 64-128 GiB+ GPUs at home would be absolutely realistic without this cost explosion.
…the Greenland icesheet melting completely is nearly unavoidable by now…
Technically not, but I also believe we will not avoid it. But the reason for that is not AI. Its share of human energy consumption is somewhere around 0.2%, likely lower. And AI would be very amenable to using renewal energies - if any relevant government cared enough to enforce its usage.
Posted Aug 29, 2026 20:44 UTC (Sat) by emk (subscriber, #1128) [Link]
If you consider the Chinese open weight models “truly open”, we’re either at that point already, or tantalizingly close.
There are at least 4 small and mid-sized MIT-licensed models that match or beat Opus 4.5. The cheapest to run is Qwen3.8 27B, which mostly fits in 32GB of VRAM. (Which you can still buy for about US1,700 this week, though I don’t expect that to last.) It would still be happier with 48-64GB, which is starting to get trickier.
Going up in cost from there, you have Qwen3.8 Flash Next, DeepSeek V4 0731, and finally (for small businesseses) GLM 5.3 Flash, which is closer to Opus 4.8 on many tasks but is a better match for people who have a machine room with a server rack or two. Nothing you can afford to run locally will match Opus 5 or Fable 5.
Most of these models benefit from a knowledgeable developer being in the loop somewhere. Much like modern Linux, they still have occasional rough edges. But much like modern Linux, they’re perfectly reasonable in the hands of a normal developer, when used for normal use cases (where “normal use cases” involves things like “async Rust code” or “debugging Terraforn nonsense”).
Power costs start around 300W, which is far less than any 220V appliances you may have.
If RAM prices go down before someone builds SkyNet, it will be absolutely possible to run MIT-licensed coding models locally on a higher-end gaming rig or Mac Studio. Laptops may take a little longer to get 64GB of VRAM and enough compute to make it pleasant.
Posted Aug 29, 2026 14:44 UTC (Sat) by aimannajjar (subscriber, #184277) [Link]
It will be interesting to watch what happens next in terms of quality and review processes as well as young engineers skills. I genuinely think it’s good to have diversity in AI adoption so we can compare and contrast the net results across projects in the long term.
Posted Aug 29, 2026 15:13 UTC (Sat) by jpeisach (subscriber, #181966) [Link] (2 responses)
Posted Aug 29, 2026 15:28 UTC (Sat) by hlieberman (subscriber, #123867) [Link]
As long as you are being respectful and following the other requirements of the Code of Conduct, the only group with the ability to force a maintainer to accept a patch would be the Technical Committee. That’s a high bar, and generally the only things that go in front of them are issues around major packages or mass-filings, or when two maintainers heatedly disagree.
As a maintainer of a package, I am responsible for what goes into that package. Another maintainer can disagree with my decisions, but absent a ruling of the TC, they can’t override my decision*.
*: Technically, a developer could just ship an update with their change, but doing so over the objections of the maintainer would almost certainly end up getting you in a world of trouble.
Posted Aug 29, 2026 15:30 UTC (Sat) by cen (subscriber, #170575) [Link]
Posted Aug 29, 2026 15:40 UTC (Sat) by akselmo (subscriber, #174307) [Link] (5 responses)
Posted Aug 29, 2026 16:41 UTC (Sat) by dilinger (subscriber, #2867) [Link] (4 responses)
Posted Aug 29, 2026 16:54 UTC (Sat) by MarcB (subscriber, #101804) [Link] (3 responses)
Ironically, demanding disclosure of AI usage would only work without problems in an environment, where it is absolutely acceptable to use AI.
Posted Aug 29, 2026 17:07 UTC (Sat) by dilinger (subscriber, #2867) [Link] (1 responses)
Currently people can lie about whether they used AI, and there’s no consequence. Sure, there might be personal consequences - a specific maintainer, after discovering such an incident, might say, “never submit a PR to me again”. The person who lied, however, can just move onto another package/maintainer/project.
Otoh, codifying a “you must disclose” rule allows for more project-wide consequences.
Ironically, demanding disclosure of AI usage would only work without problems in an environment, where it is absolutely acceptable to use AI.
Sure, that was option 2. Well, except option 2 used the wording “should” instead of “must”, but oh well.
Option 3 did use the word “must”, but it was also a vote to reject as far as practical, so that’s not really an environment where it’s acceptable to use AI.
Posted Aug 29, 2026 18:13 UTC (Sat) by MarcB (subscriber, #101804) [Link]
That is precisely the problem. Those consequences might very well be quasi-witch-hunts/inquisitions with huge chilling effects on any potential contributor (even those not using AI). It could easily have created an atmosphere of pervasive distrust and people forming an “AI police” (maybe even outside the project; imagine comments in the bug tracker).
Having gone through some of the public discussions about this, I am absolutely certain this would have happened.
But don’t get me wrong: I would absolutely prefer a declaration of AI usage - given an appropriate environment.
Posted Aug 29, 2026 17:28 UTC (Sat) by oridb (subscriber, #85941) [Link]
As I keep saying, because people will steal anyways, we should legalize robbery.
Posted Aug 29, 2026 16:22 UTC (Sat) by hmh (subscriber, #3838) [Link] (1 responses)
If that starts to get even worse (in Debian), I expect something forbidding that outright to make it to the CoC or terms of service, this GR outcome would not contradict that.
Posted Aug 29, 2026 21:16 UTC (Sat) by aigarius (guest, #7329) [Link]
Posted Aug 29, 2026 16:35 UTC (Sat) by gray_-_wolf (subscriber, #131074) [Link] (4 responses)
So I get all of these except the last one. When Claude gives me back a block of code, how can I ensure it is legally compliant? Either Debian decided that LLM-generated patches cannot have legal issues or they do not allow non-trivial generated patches, but did not want to say it? Which is it?
Posted Aug 29, 2026 18:28 UTC (Sat) by clint (subscriber, #7076) [Link] (1 responses)
Posted Aug 29, 2026 22:51 UTC (Sat) by alx.manpages (subscriber, #145117) [Link]
Posted Aug 30, 2026 2:21 UTC (Sun) by banana (guest, #144773) [Link]
Posted Aug 30, 2026 4:22 UTC (Sun) by intelfx (subscriber, #130118) [Link]
So I get all of these except the last one. When Claude gives me back a block of code, how can I ensure it is legally compliant? Either Debian decided that LLM-generated patches cannot have legal issues or they do not allow non-trivial generated patches, but did not want to say it? Which is it?
I’d like to point out that the answer to your question is literally contained in the text of the winning proposal:
Posted Aug 29, 2026 19:06 UTC (Sat) by atai (subscriber, #10977) [Link] (2 responses)
For example, GNOME does not allow AI written code. The GNOME guideline still applies in Debian
Posted Aug 29, 2026 19:23 UTC (Sat) by salimma (subscriber, #34460) [Link]
Though I should note that while some individual GNOME projects have adopted no-LLM policies, the wider project itself has not
Posted Aug 29, 2026 19:25 UTC (Sat) by intelfx (subscriber, #130118) [Link]
This Debian decision does not override the choices of each project/package packaged in Debian, right?
For example, GNOME does not allow AI written code. The GNOME guideline still applies in Debian
The GNOME guideline applies to the GNOME upstream. There’s a distinction: GNOME does not have a power to “not allow” AI-written code, it only has a power to “not accept” it.
If GNOME does not allow AI written code (I didn’t look, so I’m just taking your statement at face value), that does not and cannot prohibit Debian Developers to e.g. apply AI-authored patches to GNOME code downstream.
Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds