OpenJDK 发布生成式 AI 临时政策:零容忍,LLM 生成代码一律不准进社区贡献
2026 年 8 月 3 日,The Register 报道,Oracle 名下的 OpenJDK 项目在官方站点 openjdk.org/legal/ai 悄悄上线了一份《生成式 AI 临时政策》(Interim Policy on Generative AI)。政策的核心句很短、也几乎没有回旋空间:"OpenJDK 社区的贡献中,不得包含任何由大语言模型、扩散模型或类似深度学习系统生成的内容,无论是全部还是部分。" 这一条覆盖范围包含 OpenJDK 的 Git 仓库、GitHub pull request、邮件列表、wiki 页面和 JBS 工单,所有这些渠道提交的代码、文本、图片都按同一把尺子量。
政策到底放开了什么
临时政策只留出一条窄通道:贡献者可以私下用生成式 AI 工具来帮助理解、调试、评审 OpenJDK 现有的代码与文档,也可以拿它做与项目相关的研究,前提是 AI 生成的内容不能落到贡献物里。openjdk.org/legal/ai 的 FAQ 进一步把这条线画死:如果你用生成式 AI 工具写出 100 行代码,然后亲手改掉其中 10 行,这份贡献仍然不合规,因为整段贡献里依然包含 AI 生成的部分。编辑器里那些传统的非 LLM 功能——拼写检查、语法检查、自动补全、重构——仍然允许,但前提是它们底层不是 LLM 或类似的深度学习模型。这份政策明确定位为"临时",Oracle 作为 OpenJDK 社区的企业发起方,将向 OpenJDK 治理委员会提出完整版政策,在那之前先用这份临时稿顶着。
为什么 OpenJDK 比同行走得更远
政策明确给出三条理由。第一,版权与 IP 来源:Oracle Contributor Agreement 要求贡献者拥有或能合法授予每一份贡献的知识产权,而 AI 生成内容在多数司法管辖区的版权归属仍未定论,让来源模糊的代码永久沉淀到被广泛分发的 JDK 里,会留下结构性法律风险。第二,审核者带宽:AI 生成补丁看起来"像那么回事"、却藏着细微缺陷,会大量吞噬本就稀缺的志愿者审核时间。第三,基础设施风险:JDK 是大量企业与政府关键系统的底层,基础性、安全敏感的代码库选择零容忍,是一种站得住脚的保守姿态。横向对比,GCC 指导委员会 7 月底给出的政策拒绝"具有法律意义"的 LLM 内容、按 GNU 规则设了约 15 行的阈值,留了 LLM 测试用例的裁量空间;OpenJDK 这版没有任何"行数容忍"或"测试用例例外",是迄今为止主流开源项目里最严的一份。Rust 项目在 8 月 5 日发布的生成式 AI 贡献指南则相对宽松,允许分析与评审类使用,只限制纯 AI 生成的"创造"。同一周,三家顶级项目各画了一条互不重叠的红线。
Oracle 自身的反差,与行业坐标
The Register 把这件事从政策脚注变成头条,靠的是 Oracle 内部的反差。联合创始人 Larry Ellison 公开发言中已经说"AI 在替 Oracle 写代码";联席 CEO Mike Sicilia 也把更精简的工程团队归功于 AI 工具。Oracle 今年的 AI 数据中心投入大约 700 亿美元,这笔赌注大到 S&P 把 Oracle 的信用评级下调到 BBB-,距垃圾级仅一档,理由之一就是这笔投资回报前景不确定。所以,同一家一边对投资人讲"AI 在替我们写产品代码"的公司,另一边却在告诉 OpenJDK 的贡献者"社区维护的 Java 核心不接受一行 AI 生成的代码,哪怕你亲手改过也行不通"。刻薄地读,这像"AI 代码对我们够好,对你不够好";善意地读,这是法律风险管理——Oracle 在 IP 诉讼史上是个凶悍的玩家(它跟 Google 那场围绕 Java API 的多年版权官司就是教科书级案例),一家有这种诉讼历史的公司,有充分动机避免在一个被广泛 fork 的社区代码库里制造"AI 出身"的模糊地带,也不愿意立"人手大幅改写过就算 OK"这种内部都解释不清的标准。
同一周,Anthropic 把 Claude Code 的 auto-mode 设为 Pro、Max、Team 用户的默认,把手动审批提示换成自动权限分类器,影响数百万开发者日常编程会话。Anthropic 自己受控研究给出的数字是:人类评审员只能在大约 13.6% 的情况下抓到预设的危险命令,而 auto-mode 分类器能抓到 89%——也就是说,在这种场景下,自动化守门员比人类扫 diff 更可信。把 OpenJDK 和 Anthropic 这两条新闻并排摆,真正值得记下来的结论不是"AI 代码糟糕"或"AI 代码没问题":对 AI 写或 AI 协助写的代码的信任,完全是语境相关的。在公司内部产品工程里,有权限分类器、会话日志、CI 在背后兜着,AI 协助的提速是可以接受的默认选项;在社区评审、底层基础设施、每份外部补丁 IP 来源都不清晰、志愿者评审员又没法规模化扩编的环境里,同样的 AI 协助被当成独立的法律和质量负债。底层模型的能力没变,变的是谁为这段代码负责、谁可能因为它被告、谁要永远维护它。
对贡献者的实操含义
要往 OpenJDK 上游提 patch,现在的实操红线很清楚。披露,不要伪装:哪怕只是用 LLM 起草过一段,哪怕后来你又重写了,政策都把这笔贡献判出局。别想着"把 AI 输出洗干净直到看起来像人写的"——OpenJDK 的措辞("全部或部分")就是为了堵这条路写的。非 LLM 工具仍然能用,但先确认一下 IDE 的自动补全引擎是不是 LLM 驱动的——很多现代 IDE 已经悄悄把 LLM 自动补全做成默认了。AI 拿来做研究、做理解,可以——分析一段堆栈、读懂一个子系统、探索一个 API——只要别让 AI 输出落到提交内容里就行。政策明确定位为"临时",在 OpenJDK 和 Oracle 推进完整版治理委员会政策的过程中,这条线还会动。
对更大的 AI × 开源生态,OpenJDK 这条线把"AI 安全的贡献基线"抬高了一截。三大项目在一周里画了三条互不重叠的线,这种碎片化本身就是真正的信号:业界还没在"贡献里有多少 AI 算太多"上达成共识。每个项目都在按自己的风险偏好、诉讼历史、审核能力划线,在至少一家主要基金会发布一份能引用、可对照的共享标准之前,这种碎片化不会收敛。
资料来源
- OpenJDK — Interim Policy on Generative AI:
https://openjdk.org/legal/ai - The Register, August 3, 2026:
https://www.theregister.com/2026/08/03/as-larry-ellison-bets-the-farm-oracle-says-it-loves-ai-written-code-just-not-in-openjdk/ - explainx.ai 中文/英文分析(8/8):
https://www.explainx.ai/blog/openjdk-bans-ai-generated-code-oracle-policy-august-2026 - Solidot 中文版(转载):
https://www.solidot.org/story?sid=85041