Debian 关于使用 LLM 的决议草案：提案 A-D 解析

概述

Debian 将于 2026 年 7 月 25 日进行决议投票，针对项目应如何对待涉及大语言模型 (LLM) 或其他生成式 AI 工具的贡献，提出四项竞争性提案。这些提案的范围涵盖了从全面禁止到带有条件的许可框架，社区正在对这些提案进行辩论，以做出最终决定。

提案 A：直接禁止

提案 A 寻求明确禁止任何使用 LLM 或其他生成式 AI 工具编写的 Debian 贡献。其范围涵盖 Debian 源码包、官方项目软件、网络资源、文档、翻译和官方通信，但不包括使用 LLM 的上游项目和 AI 相关软件。其理由提到了四个方面的担忧：LLM 输出的版权状态不明、质量和准确性问题、给社区审查人员带来的压力，以及 LLM 训练数据抓取和资源消耗带来的伦理危害。为了消除疑虑，该提案在《社会契约》(Social Contract) 中增加了一项条款，规定 Debian 不允许通过 LLM 直接创建贡献。执行难度被认为是巨大的，但将依赖于社区的诚信。

提案 B：有条件允许

提案 B 允许 AI 辅助的贡献（由 LLM 部分或全部生成），前提是必须满足六个条件：(1) 工具法律兼容性，确保 AI 的条款不与 Debian 的分发、修改或使用发生冲突；(2) 许可与归属，要求验证输出中的任何第三方版权材料都可以在相关的开源许可下使用；(3) 问责制，提交者对技术价值、安全性、许可合规性和实用性承担全部责任；(4) 披露，要求对 AI 生成或 AI 辅助的大部分工作进行显著标记（例如通过 Git trailer）；(5) 对批量或自动更改进行事先讨论，类似于大规模错误提交 (mass-bug) 流程，并由人类监督；(6) 保密与隐私，禁止使用可能泄露非公开或敏感项目信息的云端 AI。

提案 C：不鼓励并要求披露

提案 C 不实施直接禁止，但要求所有贡献者在 Debian 工作中避免使用 LLM，要求决策者从实际出发不鼓励使用 LLM，并要求更广泛的自由软件社区远离该技术。它在《行为准则》(Code of Conduct) 中补充了八项要求：(1) 给人类的信息必须完全由人类起草，不得有 LLM 辅助；(2) 任何在 Debian 工作中使用 LLM 的行为都必须披露；(3) 个别项目和维护者可以完全禁止 LLM 贡献，且此类禁令必须得到尊重；(4) 违规行为将被视为违反《行为准则》，并受到迅速且比例适度的纪律处分；(5) 无法在没有辅助的情况下用英语写作的贡献者可以用母语写作，欢迎但不需要人类编写的英语摘要；(6) 该提案承认，鉴于上游的使用情况，目前实施全面禁令是不切实际的。

提案 D：接受针对 Debian 特定工作的 AI 贡献

提案 D 承认 AI 辅助实践已在投入使用，并选择将责任归于贡献者而非禁止它们。这些指南仅适用于专门为 Debian 项目（网站、应用程序、资源、软件包）编写的代码和工作。贡献者必须确保工作符合 DFSG，对提交的工作承担全部责任，必须理解并能够为其辩护，必须亲自应用任何 Signed-off-by 标签和 GPG 签名，并且必须确保上传到生产基础设施的任何内容都是由他们明确提交的。由生成式 AI 智能体或工具辅助的工作应在适当位置（提交信息、变更日志等）标记，并注明可能在无意识的情况下使用了像自动补全这样的轻量级工具，贡献者应评估规则适用的时机。最后，当传输的数据对项目敏感或非公开时，不得使用云端 AI。

Hacker News 上的社区讨论

评论者强调了几个争论点和需要澄清的点：

• @simonw 指出，该页面展示的是三个独立的提案 (A, B, C) 以供辩论和投票，而非最终决定。
• @hkalbasi 纠正了“LLM 仅仅产生训练数据的‘语法上可能的组合’”这一说法，指出强化学习使 LLM 能够超越其训练数据。
• @Meneth 观察到 Gentoo 在两年前就禁止了 LLM，并且看起来运行良好。
• @rixed 怀疑即将发布的 Trixie 版本中，有多少比例已经违反了提案 A 中提出的禁令。
• @zzo38computer 建议将提案 A 的元素（仅限于实际涉及 LLM 输出或盲目信任的贡献）与提案 C 用于其他情况相结合，并对提案 C 中“辅助”的定义提出了质疑。
• @russfink 询问使用 Claude Code 来查找错误并建议修复，同时由人类编辑和测试源码，是否算作辅助。
• @mike_hock 表示希望社区选择提案 C。
• @dismalaf 质疑使用 Gemini 作为 Google 搜索的无广告前端是否会被视为被禁止的“使用”或“辅助”。
• @mmooss 对贡献者如何验证 LLM 输出不包含预先存在的版权材料表示担忧，指出了实际操作的困难和潜在的责任问题。
• @nilespotter 将提案 D 描述为“使用 LLM 但不告诉任何人”。
• @sublinear 认为真正的问题在于缺乏解释变更的讨论，而不是 LLM 本身，适当的审查可以减轻风险。
• @JuettnerDistrib 觉得讽刺的是，在 OSS 促成了他们的发展之后，OSS 项目却在考虑禁止 LLM。
• @TZubiri 批评这些提案没有区分使用 LLM 输出与使用 LLM 进行对话或分析的辅助。
• @Kon5ole 预测随着 LLM 的进步，严格的“禁止 LLM”政策将变得难以为继，尽管他承认了关于能源消耗的伦理问题。
• @logicallee 总结了权衡：LLM 可以快速生成和测试代码，但可能会忽略源自维护者经验的非成文规范。

结论

Debian 项目面临着在严格禁止、有条件的许可框架、带有披露要求的强力不鼓励，或带有指南的接受方式之间的选择。每项提案都反映了对版权风险、质量保证、社区影响和伦理考量的不同权重。正如 Hacker News 评论中所见，正在进行的讨论揭示了在执行力度、“辅助”的含义，以及鉴于上游广泛使用 LLM 的情况下禁令的实用性方面存在深刻的不确定性。

摘要： Debian 正在考虑四项提案 (A-D) 来规范贡献中大语言模型的使用，范围从全面禁止到带有披露和问责要求的有条件允许。