編按：本文綜合整理自 The Register 原始報導、InfoQ 對 OpenJDK 與 GraalVM 政策矛盾的整理、TechZine EU 報導、Hacker News 討論串，並加入 Siami 編輯部觀點與分析。
Oracle 對 OpenJDK 下了 AI 禁令
2026 年 8 月初，Oracle 在 OpenJDK 社群張貼一份標記為「legal」的政策聲明，明確禁止任何 AI 生成內容（包含大型語言模型、擴散模型等深度學習系統的輸出）進入 OpenJDK 貢獻。聲明中清楚列出禁令範圍：
「OpenJDK Community 的貢獻內容，不得包含全部或部分由大型語言模型、擴散模型或類似深度學習系統所產生的內容。此處所稱『內容』包括但不限於 OpenJDK Git 儲存庫中的原始碼、文字、影像，以及 GitHub pull requests、電子郵件、wiki 頁面、Java Bug System 議題。」
政策同步允許兩件事：私人使用 LLM 來「理解、除錯、審查 OpenJDK 程式碼」以及進行相關研究——但這些工具的輸出不能進入正式貢獻。同時明確點出：即使 AI 生成 100 行程式碼、人類只編輯其中 10 行，這份貢獻仍然不被接受，因為它本質上「部分由 AI 生成」。
政策也保留例外給純粹的工具類輔助：「拼字檢查、文法檢查、IDE 內的自動完成、refactoring 功能」——只要這些工具不是基於 LLM。
Oracle 給出的理由有三層：
- 審查工作量暴增：AI 能快速產生大量「看起來合理」的程式碼，但事後可能被發現是錯誤、有資安風險、或難以維護
- 安全考量：OpenJDK 是全球許多組織關鍵系統的 Java 實作基礎，「看起來對但其實錯」會把這些關鍵系統置於風險中
- 智財不明：貢獻者依 Oracle Contributor Agreement（OCA）必須保證擁有內容的智財，但 AI 生成內容的法律定位目前仍不明確
內部與外部完全相反的態度
這份禁令的時機極為尷尬：就在 Oracle 內部全力擁抱 AI 寫程式碼的同時。
Oracle 共同創辦人暨技術長 Larry Ellison 在 Oracle AI World 2025 上公開宣稱：
「Oracle 正在寫的程式碼，Oracle 並沒有在寫。我們的 AI 模型在寫。我們只是告訴模型我們想要程式做什麼，AI 就會產生出實際執行的一步步流程。我們不寫程序，我們宣告意圖，但模型寫出了那個一步步的程序——也就是我們一般所說的電腦程式。」
共同執行長 Mike Sicilia 也在今年稍早公開表示：「AI 工具和它們的編碼能力如果我們不採用就會是威脅，但我們已經非常迅速地採用了。Oracle 內部使用 AI 編碼工具，讓更小的工程團隊能更快地為客戶交付更完整的方案。」
更諷刺的是，Oracle 也在今年 6 月公開解釋裁員 21,000 人的原因時提到 AI：「AI 技術在我們營運中的部署，已經導致——並可能繼續導致——我們員工數的縮減。」
換言之，Oracle 內部把 AI 視為「提升效率、減少員工、加速開發」的戰略核心；對 OpenJDK 社群卻以「AI 程式碼不可信」為由禁用同一技術。The Register 直接點出矛盾：「如果 AI 程式碼適合 Oracle 自己的產品，卻不適合 OpenJDK 貢獻，那 Oracle 顯然有一套讓內部 AI 程式碼變得安全可靠的祕密武器——只是 Oracle 還沒公開分享過。」
同一公司、同一 OCA、兩個專案的政策大轉彎
更戲劇化的轉折發生在 Oracle 旗下另一個專案：GraalVM。InfoQ 2026 年 6 月報導指出，GraalVM 的 Coding Assistants 政策明確允許 AI 程式碼貢獻——只要貢獻者承擔最終責任。
兩個政策並列對照如下：
| 專案 | AI 程式碼政策 | 智財風險處理 |
|---|---|---|
| OpenJDK | 全面禁止（含文件、bug report、AI 改過的程式碼） | 「智財風險不明所以禁」 |
| GraalVM | 允許，需貢獻者負責 | 「貢獻者負責即可」 |
兩個專案都要求貢獻者簽署同一份 Oracle Contributor Agreement（OCA），授予 Oracle 不受限制的智財權。換言之，Oracle 在法律上拿到的是同一種權利，但對「AI 生成內容」的態度卻完全相反——OpenJDK 認為「AI 內容的智財定位不明，所以禁」；GraalVM 認為「只要貢獻者負責，AI 內容可以進」。
這也是為什麼 The Register 在文末帶有諷刺意味地補一句：「Oracle 顯然有一套讓內部 AI 程式碼變得安全可靠的祕密武器。」讀者會問：如果 Oracle 真的掌握這套方法，為什麼不公開讓 OpenJDK 社群也用，反而選擇最嚴厲的全面禁用？
為什麼這件事重要
這不只是 Java 社群的事，而是 AI 時代「企業政策 vs 開源社群信任」的試金石。
第一，這是大型企業第一次對 AI 程式碼進駐開源專案做出「明確、嚴格、可執行」的禁令。Linux kernel、Python PEPs、Chromium 等大型開源專案目前都採取「揭露式」（contributor 必須揭露 AI 使用）而非「禁止式」。Oracle OpenJDK 走的是比 Linux 更嚴的路線——連「揭露後允許」都不准，這對未來其他企業處理自家開源專案是個標竿性決策。
第二，AI 程式碼的法律風險正在從「學術討論」變成「企業決策」。Oracle 在政策中明寫「智財風險不明所以禁」，這是第一次有大型企業把 AI 程式碼的智財不確定性，轉化為「正式商業政策決策」而非「律師內部備忘錄」。對其他企業法務團隊而言，Oracle 的禁令是個明確的 reference point：「連 Oracle 都不敢冒這個險，我們也該禁」。
第三，這場矛盾會重塑「AI 寫程式碼」這件事的市場敘事。Oracle 內部宣稱 AI 寫程式又快又省人力（並已因此裁員 21,000 人），同時對外要求 OpenJDK 社群放棄 AI 程式碼——這個雙重標準若被主流媒體放大，會讓企業客戶重新審視「我們用 AI 寫的程式碼，到底能不能賣給客戶？」這個根本問題。
對台灣與華文開發者社群的具體意涵：
- 企業內部 AI 工具使用 vs 對外程式碼貢獻，將成為台灣科技公司法務必須正式回答的政策題
- OpenJDK 社群貢獻者（包含許多台灣 Java 開發者）現在必須重新檢視自己的 PR 流程
- GraalVM 政策若維持開放，可能成為 Java 生態系中「AI 友善」的替代聚集地
數據解讀與質疑
質疑一：政策是「臨時」的——Oracle 明確說這是「interim policy」（臨時政策），正式版本還在草擬中。但臨時政策通常會設一個 sunset date（屆滿日），Oracle 沒有提供。這代表 Oracle 可能無限期沿用這個禁令，直到他們決定何時推出正式版。
質疑二：「Plausible-looking but incorrect」是通用說詞，不是 Oracle 內部獨有的問題。這正是所有 AI 程式碼生成工具的共同特徵，無論是 GitHub Copilot、Cursor、還是 Oracle 內部用的 AI 工具。Oracle 對外說這是 OpenJDK 不能接受的風險，對內卻說 AI 程式碼已經能讓「更小的團隊交付更完整的方案」——同一個問題，兩個答案。
質疑三：政策執行依賴 Skara 工具的 checkbox。InfoQ 報導指出，OpenJDK 的自動化 PR 審查系統 Skara 會加上 checkbox，要求貢獻者確認「我的貢獻符合 generative AI 政策」。但 OpenJDK 自己也承認：「一般來說，可靠地區分人類生成與 AI 生成內容是不可能的。」換言之，這個 checkbox 機制完全依賴貢獻者的誠實。如果有人偷偷用 AI 生成再手動修 10 行，根本查不出來。
質疑四：法律風險是真實的，但已被業界多數公司接受。Google、Microsoft、Meta 的內部 AI 程式碼政策雖然細節不同，但都允許 AI 程式碼進入產品——他們的做法是「強化 IP 揭露 + 模型輸出過濾 + 法律團隊逐案審查」。Oracle 選擇最嚴厲的「完全禁止」，可能反映 Oracle 法務部門對 AI 程式碼智財風險比其他公司更保守，這與 Oracle 本身的企業文化（封閉原始碼、嚴格控制授權）一致。
編按：Siami 將持續追蹤 Oracle 是否在「due course」提出 OpenJDK 正式版 AI 政策，以及 GraalVM 政策是否維持開放。AI 程式碼與開源社群的界線，將在 2026 下半年成為所有大型開源專案治理委員會必須面對的議題。
網友熱門留言 (4)