Log in
Ian Jackson: Debian LLM GR - Summary of the options
Debian LLM GR - Summary of the options
Introduction
LLMs have finally made it to the ultimate stage of Debian’s governance processes, a General Resolution of all the project’s full governing members (DDs).
There are a lot of options on the ballot, and they all have a different structure and approach the question in a different way. It can be hard to see the wood for the trees. I have made a summary table to try to capture the main differences, both in effect, and sentiment.
A plea to the undecided voter
Suspending briefly my attempt to be neutral:
Before voting, I encourage you to read the passionate rationales in options H and A, or at least the summary in my option C.
Few of the LLM defences in the discussion threads, and none of the LLM-positive proposals, provide answers to any of these profound ethical concerns, many of which ought individually to be a deal-breaker. Instead, these crucial questions are simply dismissed or even ignored.
Some will tell you we should “keep politics out of software” but as we can see in the world around us, software is political - now more than ever. Debian’s mission is a highly political one: developing a fully-free operating system, and defending its freeness as we do, is far from neutral!
And of course many of LLMs’ harms affect Debian directly.
Table
| A | G | C | H | F | D | B | E | |
|---|---|---|---|---|---|---|---|---|
| LLM harms | Robustly discussed | Discussed | Robustly summarised | Robustly discussed; especially re climate | Summarised | Accepted as inevitable | Disregarded [1] | Ignored |
| Direct contributions of LLM-generated code | Forbidden | Forbidden | Strongly discouraged | Strongly discouraged | Discouraged | Permitted | Permitted | Permitted |
| Direct use of LLM output in communications (bugs, mailing lists, etc.) | Forbidden | Forbidden | Forbidden (with possible exceptions) | Strongly discouraged | Discouraged | Permitted | Permitted | Permitted |
| LLM use where LLM output does not end up in the code/message | Forbidden | No position, so permitted | Strongly discouraged | Strongly discouraged | Discouraged | Permitted | Permitted | Permitted |
| Disclosure of LLM use | LLM use forbidden | LLM use largely forbidden, no further disclosure requirement | Disclosure required | Disclosure encouraged | Disclosure encouraged | Disclosure required | Disclosure required | Undisclosed LLM use is OK |
| Use of LLMs by upstreams | Condemned | “Not recommended” | ||||||
| Positive statements about LLMs | “Here to stay” | Moderate | Strong |
Notes
Ordering
I have tried to present the options in semantic order, with most LLM-negative proposals to the left, and the most LLM-positive to the right.
I have not quoted the one-line titles for the options. These have generally been provided by the proponents of each option, and, unfortunately, some of them are IMO quite misleading.
Note that, unfortunately, the voting software likes to assign numbers to options but also to preferences. Be mindful of this possible confusion when casting your vote. For clarity I quote only the option letters.
Upstream LLM code contributions
Some of the proposals acknowledge the uncertain legal status of LLM output. But all of them implicitly or explicitly assume that LLM output is or can be DFSG free. So none of the proposals forbid upstream projects with LLM-generated contents.
None of the proposals would require us to go back to pre-LLM versions of the upstream projects we use, and attempt to fork and maintain them. I very much think there is room in the world for people to try to do that, but I don’t think the Debian project can be that effort.
Given that the conclusions are the same in each case, whether the matter is discussed does not seem to me to be a significant difference. I have therefore not included a column for it.
Ability of individual teams to set their own rules
My proposal has a specific paragraph (7) explicitly permitting teams to set a “no LLM” policy. The other proposals do not discuss this point specifically. During the discussion, it seemed that most participants agreed that even options which explicitly permit LLM use generally do not prevent a team from setting its own more restrictive LLM policy.
I have therefore not tabulated this aspect.
Exceptions and nuances
Few of the permissive texts are absolute or unconditional. To summarise I have necessarily left out some nuance.
So for example when an entry says “permitted”, that generally means “permitted with conditions which are believed by LLM users to be readily satisfiable” (for example, DFSG-compatibility - see above).
[1] Footnote re proposal B
Proposal B does mention that there are “concerns” about LLM use. But it fails to make an explicit statement about whether these concerns are justified.
It then proceeds exactly as if they are not justified. IMO “disregarded” is a relatively mild term for such a rhetorical technique.
Edited 2026-08-18 09:02 UTC to make the proposal letters in the table be links; 2026-08-26 09:11 UTC to fix typos.
comments
