Flathub 封殺 AI 程式碼，QEMU 卻考慮解禁——從兩個極端看開源界的 AI 裂痕

Flathub 並未試圖在可接受與不可接受的 AI 使用之間劃出細膩的界線。它選擇了全面禁止，因為光是「審查分類」本身，就已經成了一種難以為繼的成本。該平台是在保護審查者的注意力與心理健康，而非試圖去修補一個仍然追不上科技發展的法律制度。

QEMU 急轉彎：測試一條以揭露為前提的中間路線

QEMU 在 2025 年中，曾制定了開源界最嚴格的 AI 政策之一。其正式的程式碼溯源規則指出，任何被認為包含或衍生自 AI 生成內容的貢獻——包含 ChatGPT、Claude、Copilot、Llama 等工具——都會被直接拒絕 。背後的根本理由是：AI 程式碼無法滿足「開發者原創證明」（Developer's Certificate of Origin，DCO）的要求，因為沒有人類作者能夠做出證明中所需的聲明 。

但到了 2026 年 5 月底，該專案卻開始往相反的方向移動。Red Hat 的傑出工程師與 KVM 維護者 Paolo Bonzini 提議，允許在有限且低風險的領域中使用 AI 輔助修補程式——具體來說，是指那些「著作權侵權的後果至少容易恢復，且不太可能擴散」的範圍。核心程式碼則在沒有維護者事先同意的情況下仍是禁區 。

Bonzini 的理由非常務實。他指出，目前接受 AI 輔助貢獻的專案還沒遇到過嚴重的法律麻煩，而 Red Hat 自家的法務團隊也已評估，對於特定類型的變更，其風險在可接受範圍內 。這項提議增加了一項強制揭露的要求，請貢獻者明確標示出 AI 生成的部分，而不是隱瞞 。

QEMU 實質上是在賭，一條奠基於透明度的中間路線是行得通的——特別是對於測試用例、文件修正和小型修補程式這類機械性的貢獻，一刀切的禁令反而增加了無謂的痛苦，卻沒帶來相稱的法律保護。

DCO：那道無法繞開的斷層線

無論是 Flathub 的強硬禁令，還是 QEMU 的小心放寬，都圍繞著同一個尚未解決的法律問題：當 AI 生成的程式碼碰上「開發者原創證明」（DCO）時，會發生什麼事？

DCO 要求貢獻者保證，他們親手創造了這個貢獻，或者有權在該專案的授權條款下提交它。但在現行法律下，AI 生成的程式碼並沒有一個可識別的人類作者。美國著作權局在 2025 年 1 月裁定，AI 生成內容只有在人類貢獻了「充分的表達性元素」時才能取得著作權——而光是下指令（提示工程），即使再複雜，也還不夠 。在「Thaler v. Perlmutter」一案中，華盛頓特區巡迴上訴法院在 2025 年 3 月確認，「著作權法要求所有合格的作品，首先都必須是由人類創作的」，而截至 2026 年 3 月，美國最高法院已拒絕審理相關的挑戰 。

這就創造了一個尷尬的兩難困境。一個提交 AI 生成程式碼的開發者，可能根本無法誠實地簽署 DCO。Linux 核心的回應方式——在 2026 年 4 月，透過第一份 AI 編碼輔助政策的正式化——是要求只有人類才能添加「Signed-off-by」標籤，且該人類必須對所有 AI 生成的程式碼承擔全部法律責任 。但 QEMU 當初的禁令正是基於一個推論：鑑於授權的模糊性，主張 AI 程式碼符合 DCO 是「不被認為可信的」。

至今仍沒有任何法院，針對「AI 生成程式碼能否取得著作權」、「如果可以，誰擁有權利」、「以及隨之而來的是什麼下游授權義務」做出決定性的裁決。各個專案正在進行各自的風險計算，因為法律制度還沒有給出一個明確的答案。

超越版權的人性成本

法律的辯論固然重要，但真正將 Flathub 推向臨界點的，是維護者的過勞。多個專案的維護者都回報了相同的模式：AI 生成的提交通常數量龐大卻深度淺薄——大量的異動（diffs）背後卻缺乏真正的理解——所產生的審查負擔與其實際價值完全不成比例 。

GNOME Shell 擴充套件也面臨了類似的洪水。在 2025 年底，審查者回報，有些日子一天會收到超過一萬五千行的 AI 生成擴充套件程式碼，甚至在提出審查問題時，還會收到 AI 生成的回覆 。Flathub 維護者 Piotrowski 直白地總結了這個引爆點，他表示這項政策的必要，就是因為某些提交者「根本不知道如何好好溝通」。

人性的成本與法律的成本是無法分割的。DCO 的問題之所以重要，是因為維護者對於他們接受的程式碼，真的會面臨法律責任。而過勞問題之所以重要，則是因為維護者是一群時間與善意都非常稀少的義工。AI 生成的提交，一次性地加重了這兩種壓力。

三大陣營，沒有共識

一份 2026 年 2 月的 RedMonk 分析調查了 32 個開源組織，發現沒有任何共識正在浮現 。專案大致上分為三個陣營：

• 全面禁令：Flathub、Gentoo（於 2024 年理事會一致投票通過）、NetBSD（稱 AI 代碼「被推定為受汙染」），以及 GNOME 的 EGO 審查系統，全都明確禁止 AI 生成的貢獻 。
• 有條件接受並揭露：QEMU 的提議讓它加入了 Apache、Fedora、Linux 基金會與 EFF（電子前哨基金會）的行列，這些組織全都允許使用 AI，但強制要求標示並由維護者最終裁量 。
• 容許，但由人類承擔全責：Linux 核心與 Red Hat 允許使用 AI，前提是人類開發者承擔全部責任、簽署 DCO，並標記所使用的工具——但「Signed-off-by」這個簽署動作，仍僅限人類專屬 。

這些陣營不只在政策上意見不合，他們的根本歧見在於：AI 程式碼到底是一個可以被管理的「工具」，還是一個需要被排除在外的「威脅」？而管理它的成本，究竟是該由維護者來扛，還是該由一個還沒準備好的法律體系來買單？

接下來會發生什麼事？

Flathub 和 QEMU 並非離群值，它們是光譜上的資料點。隨著 AI 編碼工具持續進步，以及生成式提交的數量不斷增加，這道裂痕只會持續擴大。有些觀察家指出，在一兩年內，偵測 AI 生成的程式碼在功能上將會變得不可能，這意味著無論禁令的初衷為何，最終都將難以執行 。

EFF 也已做出結論，認為全面禁止在實務上是無法執行的，因為 LLM 的使用已變得無所不在 。但實務上的難以執行，並不能解決最初迫使 Flathub 作出此決定的「過勞」問題。

在法院判決或立法為 AI 生成程式碼的作者身分與歸責建立明確規則之前，每一個開源專案基本上都是在為自己挑選一種賭注。Flathub 選擇了立刻保護它的審查者，代價是對 AI 工具關上大門。QEMU 則選擇謹慎地開一道小門，搭配透明化要求，並賭在低風險貢獻上，法律風險是可控的。這兩種做法，在現有的資訊基礎上都是理性的。它們只是對同一個令人不安的問題，給出了不同的答案：在一個建立在人類作者身分和志願勞動上的社群裡，當程式碼既不是人類寫的，也不是志願付出時，你該怎麼辦？