Debian就AI使用征求开发者意见：允许还是禁止？

# Debian 就是否清除机器人、驯化机器人或放任机器人展开开发者投票 来源：https://www.theregister.com/ai-and-ml/2026/08/26/debian-polls-its-developers-on-whether-to-burn-the-bots-tame-the-bots-or-let-em-loose/5292270 ### 最受欢迎内容 Debian 项目正就 AI 使用问题征询开发者意见：是使用它、施加限制，还是彻底禁止。 Debian 本年度的第二次投票——**通用解决方案：LLM 在 Debian 中的使用**（https://www.debian.org/vote/2026/vote_002）——正在进行中。更值得注意的是，它*仍在*进行中：Debian 项目负责人 Sruthi Chandran（https://www.debian.org/vote/2026/platforms/srud）已将投票截止日期延长了一周（https://lists.debian.org/debian-vote/2026/08/msg00053.html）。（她于今年 3 月在 2026 年的首次项目投票中当选（https://www.debian.org/vote/2026/vote_001）。） Debian 是一个庞大而复杂的项目：版本 13 的发布公告（https://www.debian.org/News/2025/20250809）显示其拥有 69,830 个软件包，总共占用 403 GB 磁盘空间，包含 1,463,291,186 行代码。因此，这场投票同样规模庞大且复杂，恰如其分。 投票内容超过 5,000 字，包含八项不同的提案，这些提案既按数字*也*按字母编号。每项提案获得了六至十七名开发者的附议。具体内容如下： 1. 通过《社会契约》禁止 LLM 向 Debian 贡献代码。 2. 在特定条件下允许 AI 辅助贡献。 3. 尽可能拒绝 LLM，更新行为准则。 4. 接受 AI 对 Debian 特定工作的贡献。 5. 负责任地使用生成式 AI。 6. 对生成式 AI 采取谨慎态度。 7. Debian 由人类创造。 8. 避免使用 LLM：气候破坏是不可逾越的红线。 投票说明还指出： “提案 A 需要 3:1 的绝对多数票，其他提案只需简单多数票。” 除此之外，每个提案下的具体内容也存在很大差异。有的结构严谨，有的包含解释及其适用/不适用范围的列表，有的则提供了摘要等等。只有正式的 Debian 开发者才有资格投票，但我们希望他们不会被这长篇大论吓倒，并花时间弄清楚这些相当微妙的差异中，哪一个最能代表他们的观点。 **提案 A** 是最长的提案之一。其最接近摘要的部分是“前言”，内容如下： “本提案旨在明确禁止任何使用或借助大语言模型（LLMs）或其他生成式 AI 工具编写的对 Debian 的贡献。” **提案 B** 将允许基于 LLM 的贡献，但前提是满足六项要求。这些要求涵盖“法律兼容性”、“许可与署名”、“责任”、“披露”、“对批量或自动化更改的事先讨论”以及“保密性和隐私”。 **提案 C** 呼吁全面禁止，其摘要简单明了：“尽可能拒绝 LLM（生成式‘AI’）。”该提案得到了“Debian 元老 Ian Jackson”（https://www.theregister.com/on-prem/2016/07/16/debian-s/chairman/chair/g/1117587）的支持，他编写了 dpkg 并运营着 Chiark（https://www.theregister.com/software/2022/07/25/upgrading-probably-the-worlds-oldest-running-linux-install/410480）。 **提案 D** 试图采取务实的折中方案，表示“承认这些实践已被使用并将持续存在。与其禁止其使用（这似乎适得其反且难以执行），项目选择将责任赋予贡献者，并因此制定以下指导方针。”随后列出了一系列合理的限制——工作必须清晰描述、符合《Debian 自由软件指南》（https://wiki.debian.org/DebianFreeSoftwareGuidains）等。 **提案 E** 与 D 类似，最后指出“每项贡献的责任都在于提交它的贡献者，他们需对其技术质量、法律可接受性以及是否适合包含在 Debian 中负责。” **提案 F** 敦促谨慎行事，并“鼓励贡献者在实际可行的情况下避免使用生成式 AI”。 **提案 G** “旨在确保直接提交给 Debian 的贡献是由人类创建的”——换句话说，*代码*应手写，但在编写过程中允许以其他方式使用 LLM 工具。它最后指出“我们禁止将生成式 AI 的输出作为对 Debian 的直接贡献。” 最后，**提案 H** 仅关注众多伦理问题中的一个——但总体而言，这是最重要的一项，因为它影响所有人。“LLM 的使用加速了我们生态系统（地球）的破坏，这是不可逾越的红线。” 如果说提案 H 有弱点，那就是它没有区分本地 LLM 和基于云的 LLM，尽管有人认为训练过程的环境影响是主要方面，最终结果是本地的（相对资源高效）还是远程的（极其低效）影响并不大。 在我们看来，提案数量太多，且彼此重叠过多。我们怀疑这使得第一项提案获得 3:1 的绝对多数票的可能性极低。为了更容易做出决定，我们本希望看到立场整合得更少、更清晰、互斥。但话说回来，我们并非 Debian 贡献者，此事与我们无关。 投票还有几天才结束，但截至目前收到的选票数量（https://vote.debian.org/~secretary/gr_llm/）正在增加，我们撰写本文时收到了不到 350 张选票。 一些其他项目和发行版已经在此争议中选择了立场。早在 2024 年 4 月，Gentoo 就选择禁止（https://www.theregister.com/software/2024/04/16/gentoo-linux-bans-code-contributions-written-with-ai/432800）——不久后 NetBSD 也采取了同样措施（https://www.theregister.com/software/2024/05/18/gentoo-and-netbsd-ban-ai-code-but-debian-doesnt-yet/1434665）。正如我们在报道最新 OpenBSD 版本（https://www.theregister.com/software/2026/05/25/openbsd-79-arrives-a-diamond-in-the-rough-proud-of-every-sharp-edge/5244877）时所述，该项目表示由于 AI 代码无法获得版权（https://marc.info/?l=openbsd-tech&m=177425035627562&w=2），因此不能提交到 OpenBSD——但该项目接纳了来自 Tmux 项目的旧代码，而 Tmux 允许 LLM 辅助贡献，因此这个壁垒有些松动。其他类似项目可能也会效仿。 正如我们在 2025 年 9 月报道的，FreeBSD 不想要 AI 代码（https://www.theregister.com/software/2025/09/03/freebsd-project-isnt-ready-to-let-ai-commit-code-just-yet/533101），但它尚未更新其官方指导方针以明确立场。从一些社交媒体帖子来看，我们认为目前正进行一场激烈的辩论，可能包括类似 Debian 的投票——但信息并未公开。 *The Register* 曾联系 FreeBSD 项目领导层征求意见，但截至发稿时未收到回复。 一些发行版可能会禁止 LLM 代码，但这能在多大程度上改变现状是一个难题。Linux 内核本身现在已正式表明不是反 AI 项目（https://www.theregister.com/ai-and-ml/2026/07/15/linus-torvalds-tells-ai-haters-to-fork-off/5271894），而且，Red Hat 全力投入（https://www.theregister.com/software/2026/03/31/memo-red-hat-global-engineering-plans-to-lean-in-to-ai/52214320）——这家 IBM 子公司确实创建了大多数发行版中使用的大量代码。既然如此，可以说各个发行版的选择变得有些无关紧要了。®