What do you think it’ll happen and what do you want to happen?
BALLOT OPTIONS
Choice 1: Ban LLM contributions from Debian via Social Contract
Preamble -------- This proposal aims to expressly forbid any contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools. The scope of this GR is (non-exhaustive): - Debian source packages - Official Debian project software, such as lintian - Debian web resources - Documentation and translations added by Debian contributors - Official communication from Debian It does not include: - Upstream projects using LLMs for development - AI-related software - Upstream patches/security fixes etc. Rationale --------- Debian has a well-earned reputation for stability. This stability is crucial to Debian's position in the free software ecosystem. It is our belief that widespread LLM usage comes from the "move fast, and break things" attitude that, while common in many parts of this industry, is contrary to what makes Debian Debian, and is inappropriate for Debian contributors. In practical terms, LLM usage raises the following concerns: 1. Copyright ------------- LLM output has very unclear legal status: it may be possible to copyright on its own merits, or not; it may be affected by all of the licenses and copyrights in the training data, or not. Debian Policy and the DFSG require absolute clarity for licensing and copyright[1][2]. Software and other contributions written conventionally by humans with unclear copyright or license status are not allowed in Debian; LLM output should not have a special exception to this. 2. Quality ---------- LLM output has many well-known problems with accuracy.[3][4][5] A LLM can never "know" if its output is correct since it merely produces syntactically likely combinations of the training data. In some environments this is good enough. In Debian, it is not. For instance, in packaging, each Debian source package is unique. Since packaging syntax and best practices have changed over time, a LLM-produced package will have a mixture of contents spanning the age of the archive, with watch files that do not work, overrides out of context, imaginary copyright, and will generally be unfit for upload. A seasoned Debian contributor with packaging expertise may find some limited usefulness here, but a new contributor cannot, and would not know how to fix it. These same quality and accuracy concerns apply clearly to all of the areas listed in the scope of this proposal above. If Debian were a closed organization comprising only domain experts who never leave, this might not be an issue; however, 3. Community ------------- Debian is a project that is more than just code: it is a community built on shared interests in free software and solving technical problems. Debian intentionally grows this community through many means, and new contributors are always encouraged to join. Allowing LLM contributions breaks this. New contributors submitting LLM output for review places an unnecessary strain on the reviewer, which can lead to burnout. Furthermore, LLM-dependent new contributors do not actually learn and understand the details of Debian packaging or processes, so they cannot come to replace a former burned out DD.The correct link:
https://www.debian.org/vote/2026/vote_002
I thought debian was better than ubuntu, hopefully I was right. I only have it installed as a back-up/look more into later distro, so it is very easily deleted if they wander down the nuclear wasteland path.
What is this, a Monty Python skit? How the fuck are they gonna come with a consensus with all these choices?
There’s really just choices 1 & 2. The rest are just elaboration. And what the fuck is even ‘none of the above’?
Really, there’s just ‘yes’ and ‘no’. If it’s a ‘yes’, there would certainly be condition, which can come later. If it’s a ‘no’, who give a shit why; it’s a vote, not a fucking book club. They can definitely put the reason in the comment, but do they really need to put the reasons as the choice?
I would say it’s okay with more than yes/no. You could say yes, but only if code review by human. The difference is that if you can only say yes or no, you would have to say yes, but then don’t know if the details of the final rules of AI in the project would actually be a dealbreaker for you. However, these options are a little too much.
First time?
Long time Debian user. First time really paying attention to their governance process.
Long time Debian user and governance appreciator. Welcome. If you want some schizophrenia inducing reading material you should go back and check the long and well documented history of Debian voting.
especially the adoption of systemd that was decided by only 4 people back around 2014
Where did you pull that number from? https://vote.debian.org/~secretary/gr_initsystems/results.txt
The smallest difference between a systemd option and a “not-only-systemd option” I see is
Option 2 defeats Option 4 by ( 211 - 177) = 34 votes.
And bear in mind that condorcet selects the most agreeable option, not just the majority option.
And it makes sense: the most likely contender at the time was upstart, which didn’t stand the test of time AFAIK (I don’t think the systemd hater crowd still uses that)
So it ended up the right decision. Would they have decided differently if other good init systems had existed already? Maybe, but they didn’t.
Debian: the worst Linux distribution, except for all the other ones.
Those are some wildly feels-based choices.
They appear deliberately vague and misleading
