The GCC project has published a policy governing the use of large language models in developing the GNU Compiler Collection. It is a rule set that stops well short of a ban while drawing a firm line at what actually enters the repository, and it is arguably more instructive for its narrowness than for its strictness.
The policy was the subject of discussion at the 2026 GNU Tools Cauldron, where longtime contributor Jeff Law and developer Kyrill Tkachov described the tools as useful in bounded, auxiliary roles under human review — according to a paywalled summary of the session published by LWN.net. The full policy text, however, is public at gcc.gnu.org/ai-policy.html, and its mechanics are straightforward.
Its core provisions: material produced by an LLM must not be committed to the GCC repository; contributors are expected to disclose AI assistance when submitting patches; and the human author remains responsible for everything they submit. In other words, the compiler's codebase stays human-authored and human-certified, even as contributors may use these tools upstream of the commit. What the policy governs is one boundary — what enters the repository and who certifies it — rather than attempting to police contributors' workflow or their thinking. That scoping is a large part of what makes it enforceable.
Why GCC drew the line there
The posture is best described as restrictively permissive: explicit and conditional, rather than silent or a blanket prohibition. Blanket bans push usage underground, where it cannot be governed at all. Silence invites inconsistent practice and, eventually, a provenance problem. GCC chose a third path, and the choice looks sound.
The reasoning behind it is structural — and this is our own analysis, not anything attributed to the Cauldron speakers. The Free Software Foundation requires copyright assignment for many contributions to GCC. That means the project is not merely accepting code; it is asserting ownership over it — and asserting ownership over material whose copyright status is legally unsettled. Machine-generated text has an ambiguous provenance in most jurisdictions, and an organization that certifies authorship it cannot substantiate is taking on a risk that compounds with every commit. On that reading, ambiguity is the greater risk: a project willing to stand behind every line is rationally motivated to know where each line came from.
It is also worth naming, again on our own account, a tension the policy surfaces but does not resolve. Practitioners like Law and Tkachov are demonstrably finding value in these tools; the policy concedes the space for that value while withholding it from the artifact. The tools help at the edges — drafting, exploring, explaining — but the record of the project itself remains human. That distinction may look unstable over time as output quality improves, but it is a defensible place to stand while the legal ground settles.
A template HK teams can adapt
For Hong Kong IT organisations drafting their own AI-usage rules, the GCC approach offers a compact template with three moves worth borrowing. First, scope the restriction to the artifact of record rather than the workflow — decide what enters your systems of record, not what people may think with. Second, require disclosure at the point of handoff, where a reviewer can act on it. Third, pin accountability to a named human, so responsibility does not evaporate into the tool. The result is a policy that teams can actually enforce, and one that survives contact with practitioners who are not going to stop experimenting. That the template was written by practitioners to solve a provenance problem they actually faced, rather than by compliance function drafting in the abstract, may be its most instructive feature for local teams facing the same pressure.
GCC's full policy text is public and worth reading in the original at gcc.gnu.org/ai-policy.html. The LWN.net report on the Cauldron session, published this month, is behind a paywall.
```
GCC 項目近日發布了一套政策，規管大型語言模型（LLM）在開發 GNU Compiler Collection 過程中的使用。這套規則並非全面禁止，而是在哪些內容可以進入 repository 這一點上劃下明確界線；與其說它的啟示來自嚴格程度，不如說來自其限制範圍之精準。
該政策是 2026 年 GNU Tools Cauldron 討論的焦點之一。根據 LWN.net 對該場會議的付費報道，資深 contributor Jeff Law 及開發者 Kyrill Tkachov 均表示，這類工具在有界、輔助性的角色中相當有用，但必須有人類審核。政策全文則公開於 gcc.gnu.org/ai-policy.html，內容簡單明確。
核心條款如下：由 LLM 產生的材料不得 commit 至 GCC repository；contributor 在提交 patch 時應披露 AI 協助；以及提交者本人須為其所提交的一切負責。換言之，編譯器的 codebase 始終由人類撰寫並由人類簽核認證，即使 contributor 可以在 commit 之前的環節使用這些工具。政策所規管的只有一個邊界——甚麼可以進入 repository、由誰簽核——而沒有試圖監管 contributor 的工作流程或思維方式。正是這一份界定範圍的精準，令政策具備可執行性。
為何 GCC 劃在這條界線
這一方針的姿態可稱為「限制性的允許」：明確列出條件，而非保持沉默或一刀切禁止。全面禁令只會令使用轉入地下，最終變得無法治理；沉默則會引致不一致的實踐，並最終演變成來源（provenance）問題。GCC 選擇了第三條路，而這個選擇看來是明智的。
其背後的理據是結構性的——以下屬本報分析，並非 Cauldron 講者的觀點。Free Software Foundation 要求 GCC 的多項貢獻進行 copyright assignment（版權轉讓）。這意味著項目不僅是接收代碼，更是對其宣示擁有權——而它所宣示擁有權的材料，其版權狀態在法律上尚未明確。機器生成的文本在多數司法管轄區的來源歸屬本就含糊，一個為自己無法證實作者身份的材料簽核認證的機構，每次 commit 都在累積風險。從這個角度看，含糊反而是更大的風險：一個願意為每一行代碼負責的項目，理應有充分動機去了解每一行的來源。
同樣是本報自身的觀察，這套政策也浮現出一個它並未解決的張力。Law 與 Tkachov 等從業者明顯在這些工具中找到價值；政策承認了這份價值存在的空間，卻拒絕讓它進入最終產出（artifact）。這些工具在邊緣環節發揮作用——起草、探索、解釋——但項目本身的記錄仍屬人類。隨著輸出品質提升，這條界線日後可能顯得不穩定，但在法律基礎尚未明朗之際，這是一個站得住腳的位置。
香港團隊可以借鑒的範本
對於正自行草擬 AI 使用規則的香港 IT 組織而言，GCC 的做法提供了一個精簡範本，當中有三個值得借鑒的步驟。第一，將限制範圍限定於具記錄價值的產出（artifact），而非工作流程——規管甚麼可以進入你們的系統記錄，而非規管人可以如何思考。第二，在交接環節要求披露，讓 reviewer 得以即時跟進。第三，將問責制度繫於具名的人類身上，令責任不會消散於工具之中。如此一來，團隊才能真正執行政策，而政策亦能在面對不會停止實驗的從業者時仍然有效。這個範本由實踐者為解決他們真實面對的來源問題而撰寫，而非由合規部門憑空起草——對本地團隊而言，這可能是它最值得借鑒之處。
GCC 的政策全文已公開，值得直接閱讀原文：gcc.gnu.org/ai-policy.html。LWN.net 本月發表的 Cauldron 會議報道則為付費內容。