摘要： OpenJDK 在官方法律頁面發布臨時政策，禁止社群貢獻包含由大型語言模型、擴散模型或同類深度學習系統部分或全部生成的內容，範圍涵蓋儲存庫、PR、email、wiki 與 JBS 中的程式碼、文字與圖像。貢獻者私下用生成式 AI 讀懂、除錯或審查程式碼並未受限，過渡期由 Skara 在 GitHub PR 加入合規勾選框，完整政策仍由 Oracle 起草。審查負擔、安全與未決的 IP 權利是主要理由；同一週 Rust 則採取較窄的逐情境規範。
OpenJDK 是 Java 平台最主要的開源實作，它的官方法律頁面上如今掛著一份「生成式 AI 臨時政策」。在正式版本拍板以前，社群送出的貢獻一律不得夾帶由大型語言模型、擴散模型或同類深度學習系統「部分或全部生成」的內容。率先披露此事的是 The Register，時間點在 8 月 3 日。而且被管的不只是程式碼：Git 儲存庫、GitHub pull request、電子郵件、wiki 頁面與 JBS 問題單當中的程式碼、文字、圖像，通通在管制範圍內。
這份臨時政策劃出的禁區
界線被畫得相當明確：生成出來的東西不能成為貢獻，工具本身則照用無妨。貢獻者若只在自己私下用生成式 AI 讀懂、除錯、審查 OpenJDK 程式碼，或進行與專案相關的研究，並沒有任何限制——官方甚至引述其他社群的經驗指出，面對規模龐大的既有程式庫，這類 AI 最有價值的地方正是分析既有程式碼，而非創造新的程式碼。完整的政策正由 Oracle 起草，日後會送交 OpenJDK 管理委員會。在過渡階段，負責處理 PR 的 Skara 工具鏈會在每一個 GitHub pull request 上加掛勾選框，貢獻者必須藉此聲明自己遵守政策。
風險清單：審查負擔、安全、IP
政策頁面把風險講得很直白。排第一的是審查負擔：生成式 AI 能輕而易舉產出大量「看起來合理」的程式碼與測試，這些東西就算正確，往往也不好維護，會把人類審查者原本就有限的時間吃光。第二是安全：JDK 是全球企業與政府關鍵系統的底層支撐，「看起來合理但實際上錯誤的程式碼」直接動搖這個前提。第三是智慧財產權：Oracle 貢獻者協議（OCA）要求貢獻者對提交內容握有完整權利，並能無限制地授權給 Oracle；生成式 AI 的訓練素材是受版權保護的內容，其輸出可能構成侵權，而使用者在 AI 生成內容上到底有沒有權利，本身還是訴訟中的未決問題。
常見問題集中最殺酷的一題是這樣：用 AI 生成 100 行程式碼、自己動手改掉 10 行，這樣能貢獻嗎？不行——你的貢獻依然「部分」含有 AI 生成內容。
自家全力擁抱 AI 寫碼，對開源卻劃紅線
對照組來自 Oracle 自家高層。Larry Ellison 在 Oracle AI World 2025 上說過：「Oracle 正在寫的程式碼，不是 Oracle 在寫的。」The Register 的標題把張力挑得更明：Ellison 押上全部身家押注 AI，Oracle 說它愛 AI 寫的程式碼——只是別放進 OpenJDK。這算不上單純的虛偽：內部程式碼的風險由自己吸收，開源貢獻要的則是一條乾淨的權利鏈，每一個 commit 背後都有簽過的法律文件。同一家公司，兩套風險帳本。
Rust 走上另一條路
同一週的 8 月 5 日，Rust 專案在 Inside Rust 部落格宣布：有五個團隊採納了一部政策，用來約束 rust-lang/rust 儲存庫的 LLM 使用方式，撰稿人是 Jynn Nelson。適用範圍明確得多——會受影響的是審核 PR 的人、用 LLM 寫 PR 的人、靠 LLM 發現問題後開 issue 的人，以及在留言裡直接引用 LLM 輸出的人；官方強調，這不代表 Rust 對 LLM 的整體立場。一邊全面禁止生成內容，一邊逐情境管理使用方式，兩大專案各自站在光譜的一端。
開源貢獻者該讀出什麼
三件事。第一，讓 agent 代你開 PR 之前，先把目標專案的政策查清楚——審查者的信任是開源最稀缺的資源，踩一次紅線就很難要回來。第二，合規要求正被寫進工具鏈：勾選框、審查流程、甚至偵測機制都會陸續登場，揭露不再是禮節，而是程序的一部分。第三，IP 判決還沒出爐之前，任何「AI 產出歸誰」的答案都可能翻盤——專案選擇先保護自己，是理性，不是保守。