Debian launches competing General Resolutions on LLM usage in Debian code
secabeen
11 points
1 comment
July 24, 2026
Related Discussions
Found 5 related stories in 991.8ms across 14,736 title embeddings via pgvector HNSW
- Debian decides not to decide on AI-generated contributions jwilk · 306 pts · March 10, 2026 · 57% similar
- Linus Torvalds on LLM usage in kernel development asciimoo · 43 pts · July 16, 2026 · 53% similar
- Debian must ship reproducible packages robalni · 348 pts · May 10, 2026 · 52% similar
- Protecting our FLOSS commons from LLMs acmnrs · 11 pts · July 23, 2026 · 51% similar
- Debian Bookworm v12.15 Released saikatsg · 13 pts · July 14, 2026 · 50% similar
Discussion Highlights (1 comments)
patrakov
Even though I am not a Debian project member, let me express my dissatisfaction with Proposal A. The proposed addition to the Social Contract (i.e., the LLM contribution ban), by itself, is well-worded and acceptable, but the rationale quoted to justify it is not OK. 1. The copyright argument, even if true, is inconsistent with the permission to package third-party LLM-assisted software into Debian. 2. It is no longer the case that LLMs merely produce syntactically likely combinations of the training data. The best practice is to give LLMs access to a knowledge base (i.e., implement RAG) and instruct them to use that knowledge base. 3. The failure of the new packager to understand the best practices should be attributed to the lack of proper mentorship, not to their use of LLMs. A phrase "you can do better than this LLM" is expected to work better than a formal LLM ban. 4. I am not qualified to comment on LLM ethics and the load caused by collecting datasets for their training, so I will refrain from accepting or dismissing this piece of the rationale.