时间线提案 提案A 提议者 提案A 副提议者 提案A 提案B 提议者 提案B 副提议者 提案B 提案C 提议者 提案C 副提议者 提案C 时间线讨论期间：2026-07-24 提案A 提议者 Matthias Geiger [ werdahias@debian.org ] [ 提案文本 ] 提案A 副提议者 Johannes Schauer Marin Rodrigues [ josch@debian.org ] [ 邮件 ] Antoine Le Gonidec [ vv221@debian.org ] [ 邮件 ] Simon Richter [ sjr@debian.org ] [ 邮件 ] David Bremner [ bremner@debian.org ] [ 邮件 ] Pierre-Elliott Bécue [ peb@debian.org ] [ 邮件 ] Ian Jackson [ iwj@debian.org ] [ 邮件 ] Amin Bandali [ bandali@debian.org ] [ 邮件 ] Thorsten Glaser [ tg@debian.org ] [ 邮件 ] 提案A 选择1 前言 本提案旨在明确禁止任何使用大语言模型(LLMs)或其他生成性AI工具撰写的对Debian的贡献。本GR的范围是（非详尽）：Debian源包 官方Debian项目软件，如lintian Debian网络资源 Debian贡献者添加的文档和翻译 Debian的官方通信 它不包括： 使用LLMs进行开发的上游项目 AI相关软件 上游补丁/安全修复等。 理由 Debian因其稳定性而享有很好的声誉。这种稳定性对Debian在自由软件生态系统中的地位至关重要。我们相信，大规模使用LLM源于“快速行动，打破事物”的态度，这种态度在该行业的许多地方很常见，但与Debian的本质背道而驰，并且不适合Debian贡献者。在实际操作中，LLM的使用引发以下担忧： 1. 版权 LLM的输出在法律地位上非常不明确：可能根据自身的优点获得版权，也可能不然；可能受到训练数据中的所有许可证和版权的影响，也可能不然。Debian政策和DFSG要求对许可和版权有绝对清晰性[1][2]。常规由人类编写的贡献，若其版权或许可证状态不明确，则不允许在Debian中存在；LLM输出不应对此有特殊例外。 2. 质量 LLM的输出存在许多众所周知的准确性问题[3][4][5]。LLM永远无法“知道”其输出是否正确，因为它只是生成训练数据的语法上可能的组合。在一些环境中，这已足够。然而在Debian中并不如此。例如，在打包中，每个Debian源包都是唯一的。由于打包语法和最佳实践随时间而变化，由LLM生成的包将会包含跨越归档年代的内容混合，可能包含无效的watch文件、超出上下文的覆盖、虚构的版权，且通常不适合上传。一位具有打包专业知识的经验丰富的Debian贡献者可能会发现一些有限的用处，但新贡献者却无法及不知如何修复这些问题。这些相同的质量和准确性问题显然适用于上述提案范围中的所有领域。如果Debian是一个封闭的组织，仅由从未离开的领域专家组成，这可能不是问题；然而， 3. 社区 Debian是一个不仅仅由代码构成的项目：它是一个基于对自由软件和解决技术问题的共同兴趣建立的社区。Debian通过多种手段有意地发展这个社区，并始终鼓励新贡献者加入。允许LLM贡献会破坏这一点。新贡献者提交LLM输出以供审查，会给审查者带来不必要的压力，这可能导致疲惫。此外，依赖LLM的新贡献者并没有真正学习和理解Debian打包或流程的细节，因此他们无法替代前任的疲惫的DD。 4. 伦理 LLM公司通过爬取整个互联网以获取训练数据，完全无视许可证、版权，甚至已建立的约定，如robots.txt，直接打击自由软件社区[6]。这对Debian的公共网络资源产生了重大负面影响，实际上是对许多用户依赖的站点进行大规模和持续的拒绝服务攻击。因此，我们的基础设施部分无法访问，必须启用基于JS的检查。许多其他项目也受到类似影响。此外，LLM训练消耗了惊人的资源[7]，我们被迫实施的用户验证系统作为保护措施也浪费了资源。这对互联网作为公共资源的公然无视，浪费了系统管理员的时间，尽管个别LLM会话并不会直接使用大量资源或对公共网络进行拒绝服务，但它们能够被使用的事实直接是LLM公司这些不道德行为的结果。Debian有一项社会合同。[8] 我们的优先事项是我们的用户和自由软件。Debian是稳定的。[9] 用户和组织选择Debian是因为它可靠且安全。Debian不是用来生成...