Flathub封殺AI程式碼 QEMU諗住解禁 開源界AI大分裂浮面

Flathub並冇嘗試喺「可接受」同「唔可接受」嘅AI使用之間畫一條仔細嘅界線。佢選擇咗一刀切禁止，因為單係做分流（triage）本身，已經成為一個無法承受嘅成本。平台要保護嘅係審查員嘅注意力同心理健康，而唔係嘗試去修補一個仍然追唔上科技發展嘅法律體系。

QEMU轉軚：測試申報制呢條中間路線

QEMU喺2025年中曾經採納咗開源界最嚴格嘅AI政策之一。佢嘅正式程式碼來源規則列明，任何被認為包含或者衍生自AI生成內容嘅貢獻——包括ChatGPT、Claude、Copilot、Llama同類似工具嘅輸出——都會被拒絕 。當時列出嘅理由係，AI程式碼冇辦法滿足開發者原產地證書（DCO）嘅要求，因為根本冇一個人類作者可以做所需嘅證明 。

但到咗2026年5月底，呢個項目開始朝相反方向行。Red Hat嘅傑出工程師兼KVM維護者Paolo Bonzini，提議容許喺有限度、低風險嘅領域使用AI輔助嘅補丁——特別係嗰啲侵犯版權嘅後果容易還原、而且唔會擴散嘅地方。核心程式碼（Core code）就繼續係禁區，除非事先得到維護者同意 。

Bonzini嘅理據好務實。佢指出，接受AI輔助貢獻嘅項目，至今都未遇過嚴重嘅法律麻煩，而Red Hat自己嘅法律團隊亦評估過，對於特定類別嘅改動，風險係可以接受嘅 。新建議加入咗強制申報要求，要貢獻者明確標示AI生成嘅部分，而唔係收收埋埋 。

QEMU實際上係喺度賭一鋪，博一條以透明度為基礎嘅中間路線行得通——當一刀切禁令製造出嚟嘅摩擦，同佢帶嚟嘅法律保障唔成比例嗰陣，尤其係對於機械式嘅貢獻，好似測試用例、文件修正同小型補丁。

點解DCO係條斷層線

Flathub嘅強硬禁令，同QEMU嘅謹慎放寬，其實都圍繞住同一個未解決嘅法律問題：當AI生成嘅程式碼要面對開發者原產地證書（DCO）嗰陣，會發生咩事？

DCO要求貢獻者證明，佢哋親手建立咗呢個貢獻，或者有權根據項目嘅授權許可去提交。但根據現行法律，AI生成嘅程式碼冇可識別嘅人類作者。美國版權局喺2025年1月裁定，AI輸出只有喺人類貢獻咗足夠嘅表達元素嗰陣先可以受版權保護——而單靠提詞（prompting）係唔夠嘅 。喺「Thaler 對 Perlmutter」一案，華盛頓特區巡迴上訴法院喺2025年3月確認，「版權法要求所有合資格作品必須首先由人類創作」，而截至2026年3月，最高法院已經拒絕再審理相關挑戰 。

咁就製造咗一個兩難局面。一個提交AI生成程式碼嘅開發者，可能冇辦法誠實咁簽署DCO。Linux核心嘅回應——喺2026年4月正式制定咗史上第一份AI編碼助手政策——就要求只有人類先可以加「Signed-off-by」標籤，而且嗰個人類要為所有AI生成嘅程式碼行數負全責 。但QEMU最初嘅禁令就咁推理：鑑於授權許可嘅模糊性，宣稱AI程式碼符合DCO係「唔被認為可信」嘅 。

至今未有法院明確裁定AI生成嘅程式碼係咪可以享有版權、如果可以嘅話邊個持有呢啲權利、或者會附帶咩下游授權義務。各個項目都係自己做緊風險計算，因為法律體系仲未俾到一個清晰嘅答案佢哋。

版權之外嘅人力成本

法律爭論固然重要，但真正將Flathub推落懸崖嘅，係維護者爆煲。多個項目嘅維護者都報告緊同一種模式：AI生成嘅提交通常量大但膚淺——diff好大，但缺乏真正理解——產生出嚟嘅審查負擔，同佢嘅價值完全不成比例 。

GNOME Shell擴展都面對過類似嘅湧入潮。喺2025年底，審查員報告話某啲日子會收到超過15,000行AI生成嘅擴展程式碼，仲有AI生成嘅審查問題回覆 。Flathub維護者Piotrowski好直白咁總結咗爆煲點，話呢個政策係必要嘅，因為某啲提交者「根本唔識得好好地溝通」。

人力成本同法律成本係分唔開嘅。DCO問題咁重要，係因為維護者要為佢哋接受嘅程式碼面對實實在在嘅法律責任。爆煲問題咁重要，係因為維護者係義工，時間同心力都好有限。AI生成嘅提交，係同時向呢兩樣嘢施壓。

三個陣營，冇共識

RedMonk喺2026年2月發表嘅一份分析，調查咗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就選擇好窄咁打開道門，附加透明度要求，並且賭一鋪——對於低風險嘅貢獻，法律風險係可以管理嘅。以現有資訊嚟講，兩個舉動都係理性嘅。佢哋只係對同一個令人不安嘅問題，反映出唔同嘅答案：喺一個建立喺人類作者身份同義工勞動之上嘅社群入面，當程式碼到來嘅時候，冇附帶上述任何一樣嘢，你應該點做？