編按：本文綜合整理自 The Register（2026-08-03）、OpenJDK 官方 Interim Policy（2026-04-09）、InfoQ（2026-06-12），並加入 Siami 編輯部觀點與分析。
Java 開發者社群最近迎來一項令人玩味的政策：Oracle 在 2026 年 4 月 9 日悄悄於 OpenJDK 官網發布了一份「Interim Policy on Generative AI」過渡政策，禁止任何 AI 生成內容——不只源碼，連 Pull Request 描述、郵件、Wiki、Java Bug System 報告都一併封殺。時隔四個月，The Register 8 月 3 日的深度報導揭開了這份禁令背後的矛盾：Oracle 自己內部正大量使用 AI 寫程式碼。
OpenJDK 禁令的具體內容
OpenJDK 官方公告寫得相當直白：
“Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems. Content, in this context, includes but is not limited to source code, text, and images in OpenJDK Git repositories, GitHub pull requests, e-mail messages, wiki pages, and Java Bug System issues.”
Oracle 給出的理由有四個面向：
- 審查工作量暴增：AI 能快速產出大量看似合理的程式碼，但後續常被發現不正確、不安全或難以維護。
- 安全疑慮：“Plausible-looking but incorrect code would put these critical properties at risk.” Java 支撐全球大量 mission-critical 系統。
- 智慧財產權不確定性：Oracle Contributor Agreement（OCA）要求貢獻者保證擁有 IP 權利，但 AI 生成內容的法律定位目前仍模糊。
- 責任歸屬：難以可靠區分人為內容與 AI 內容。
值得注意的是，政策允許開發者私下用 AI 來「理解、除錯、審查」OpenJDK 代碼——只是不能把 AI 產出的內容交出去。傳統的拼字檢查、文法檢查、自動補完、重構工具，只要不是基於大型語言模型，也不受限制。
為什麼這件事重要
表面上看，這是一份企業內部對開源專案治理的過渡政策，跟外界沒太大關係。但拉遠來看，這件事觸及了 2026 年 AI 產業最深的三條張力線：
第一，企業對 AI 內容的「分級監管」邏輯成形。Oracle 不是全面禁止 AI，而是劃了一條界：凡是會進入公開 commit history、留下 IP 痕跡、可能被引用為「Oracle 認可」的內容，全部禁；凡是不會留下痕跡的內部使用，全部放行。這跟金融業對 AI 的「影子使用」容忍、醫療業對 AI 診斷的嚴格管制，是同一個邏輯——只是發生在開源基礎設施層。
第二，開源治理正面臨「AI 內容洪流」的現實壓力。OpenJDK 治理委員會（GB）通過這份政策的速度——從 4 月初發布、到 6 月 InfoQ 詳細報導——顯示這不是單一公司的奇想，而是整個 Java 生態面對 AI 投稿暴增的集體反應。其他大型開源專案（GCC、Linux Kernel）也先後發布了不同程度的 AI 投稿指引，OpenJDK 只是其中最嚴格的一份。
第三，Oracle 內部與外部的「雙重標準」正在侵蝕開源信任。當一家公司同時是「AI 寫程式碼的最大受益者」與「AI 投稿的最大守門人」，社群會開始懷疑：這些規則是為了保護 Java 品質，還是為了保護 Oracle 在訴訟戰場上的籌碼？
Oracle 內部：Larry Ellison 自己說「AI 正在寫我們的程式碼」
The Register 報導中最具張力的一段，是直接引用 Larry Ellison 在 Oracle AI World 2025 大會上的演講：
“The code that Oracle is writing, Oracle isn’t writing. Our AI models are writing. We just tell the model what we want the program to do, and then the AI comes up with a step-by-step process to actually do it. We don’t write the procedure. We declare our intent, but the model writes the step-by-step procedure; that thing we commonly think of as a computer program.”
Oracle 共同 CEO Mike Sicilia 也在今年稍早補刀：
“AI tools and their coding capabilities would be a threat if we weren’t adopting them, but we are and very rapidly. The use of AI coding tools inside Oracle is enabling smaller engineering teams to deliver more complete solutions to our customers more quickly.”
更直接的數字：Oracle 在 2026 年 6 月 22 日提交的 10-K 年報中，把裁員 21,000 人（從 162,000 降到 141,000 人，約 13%）直接歸因於 AI——這是第一家在 SEC 公開文件上白紙黑字寫「AI 取代工作」的大型科技公司。
Oracle 自己也承認，內部產品（包括所謂「agent embedded in applications」）已經使用 AI 來推理、做商業決策、代表使用者行動。
數據解讀：Oracle 雙重標準的三大張力
1. 同一份 OCA，兩個相反的政策
InfoQ 6 月的深入分析指出，Oracle 同時擁有兩個 Java 相關開源專案，採用了完全相反的 AI 投稿政策：
| 專案 | AI 生成內容政策 | 治理委員會 |
|---|---|---|
| OpenJDK | 全禁（連部分修改也不行） | OpenJDK Governing Board |
| GraalVM（Oracle Labs） | 開放（由貢獻者負責） | Oracle Labs 自行管理 |
兩個專案都用同一份 Oracle Contributor Agreement（OCA），授權 Oracle 無限的 IP 權利。OpenJDK 認為 AI 內容的 IP 風險構成禁止理由；GraalVM 認為貢獻者責任已足夠構成許可理由。同一間公司、同樣的法律協議、相反的規則——這在開源史上相當罕見。
2. 財務壓力下的「AI 大躍進」
The Register 同篇報導揭露了一個關鍵的時序背景：
- Oracle 預告 2027 財年將投資 $70 billion 建設資料中心（比 2026 財年的 $55.7 billion 高出 26%）。
- 2026 財年自由現金流為 負 $23.7 billion（capex 暴增 162%）。
- S&P 在 2026 年 7 月 9 日把 Oracle 信評從 BBB 降到 BBB-，離垃圾級只差一級。理由：AI 投資的「uncertain path to profitability」以及 OpenAI 集中度風險。
- 10 年期 Oracle 公司債殖利率約 6.5%，明顯高於 BBB 指數平均，已逼近 BB 垃圾級水位。
換句話說：Oracle 正同時用「OpenJDK 全面禁止 AI 投稿」+「內部 100% 用 AI 寫程式碼」+「舉債 $70 billion 蓋 AI 資料中心」三條路線，全力衝刺 AI。這三條路線如果有任何一條被證明是錯的，後果都不輕。
3. 社群質疑：守門還是設卡？
Hacker News 討論串中（219 則留言），最尖銳的批評來自資深用戶 jerf：
“Oracle, the law firm with a tech business attached, probably wants to retain the option to sue other people for AI-washing their proprietary code, and that doesn’t work if they’re also publicly accepting AI contributions to their code with no apparent concern for the provenance of it.”
這個觀點的潛台詞是：Oracle 長年以智慧財產權訴訟聞名（與 Google 的 Android API 訴訟就是經典案例）。如果 OpenJDK 接納 AI 投稿，未來 Oracle 想告別人「AI 洗程式碼」的時候，就很難保持 IP 純度立場。
OpenJDK 郵件論壇上，開發者 Pavel Rappo 也提出了灰色地帶問題：
“I write the Pull Request description in Japanese myself. I then use a generative AI tool to translate it into English. Does this violate the policy?”
翻譯是用 LLM 做的，但內容原創性是貢獻者自己的。這類邊界案例在未來幾個月會大量湧現，OpenJDK 必須在「過渡政策」結束前給出明確指引。
影片：Larry Ellison 在 Oracle AI World 2025 的原話
這段 14 分鐘的影片包含 Ellison 那段「Oracle isn’t writing the code, our AI models are writing」的關鍵引言。Siami 建議讀者直接聽原音，體會 Oracle 內部對 AI 寫程式碼的真實態度：
延伸閱讀與原始來源
以下素材是本文的延伸研究基礎，可供讀者自行查證：
- OpenJDK 官方政策原文：openjdk.org/legal/ai（2026-04-09 發布，Oracle 官方版本）
- The Register 原報導：Lindsay Clark, 2026-08-03
- InfoQ 深入分析（OpenJDK vs GraalVM）：Karsten Silz, 2026-06-12
- Oracle 10-K 年報裁員聲明：The Next Web, 2026-06-23
- S&P 信評調降聲明：S&P Global Ratings, 2026-07-09
- Hacker News 原始討論串：492 則留言, delduca 投稿
- X 社群評論：Ayaan (@twtayaan) 整理 OpenJDK vs GraalVM 矛盾
- OpenJDK 郵件論壇質疑：[email protected] 4 月討論串
Siami 編按：這件事接下來會怎麼走
Oracle 在公告中寫明，「過渡政策」會由 Governing Board 在「in due course」（適當時機）審議一份完整政策。這個時間點目前不明，但從 4 月發布、6 月媒體大量報導、8 月社群反彈的節奏看，Oracle 內部勢必承受壓力。
最值得追蹤的兩個訊號：
- OpenJDK Governing Board 是否會在 2026 年內提出正式版本？ 如果正式版沿用相同禁令措辭，代表 Oracle 打算長期維持雙軌制；如果鬆綁到「允許人類修改後的 AI 內容」，代表社群壓力已奏效。
- GraalVM 政策是否被反向調整？ 如果 GraalVM 也轉向禁止，等於 Oracle 統一立場、放棄雙重標準辯護；如果維持開放，Oracle 必須對外說明為什麼同一份 OCA 卻有兩種解讀。
對 Java 開發者來說，最實際的影響是：未來 12 個月，OpenJDK 投稿者必須嚴格自我審查——任何被懷疑是 AI 生成（無論原作者是誰）的內容都可能被退回。對小型貢獻者與非英語母語者（如 Pavel Rappo 的翻譯情境），這個門檻會實質性地降低參與意願。
The Register 在文末留下一個未答的問題：「Why AI-generated code is suitable for Oracle’s products but not for OpenJDK contributions is therefore puzzling… Presumably Oracle has found some cast-iron method of making its internal AI-generated code safe and secure. It has yet to share the secret with us, but we have asked.」
這個問題到目前為止，Oracle 還沒有公開回答。
網友熱門留言 (5)