同属 Oracle，OpenJDK 与 GraalVM 对 AI 代码贡献恰恰相反

两个由 Oracle 支持、彼此相关的项目，针对使用生成式 AI 创建的开源贡献发布了相反的政策： OpenJDK " 管理委员会批准了一项 临时政策 "，禁止此类贡献；而 GraalVM " 的 Coding Assistants 政策 "则允许这类贡献。两个项目都要求贡献者签署同一份 Oracle Contributor Agreement（OCA） "，用于处理知识产权相关事项。 2026 年 4 月初，OpenJDK 发布了其广泛禁止生成式 AI 内容的政策： 贡献不得包含由大语言模型、扩散模型或类似深度学习系统部分或全部生成的内容。这里所说的内容包括但不限于 OpenJDK Git 仓库、GitHub pull request、电子邮件、wiki 页面和 JBS issue 中的源代码、文本和图片。 该政策给出了三个理由。第一是评审负担：大量看似合理但实际错误或难以维护的代码会消耗有限的评审时间。第二是安全性与安全保障：JDK 支撑着关键任务系统，因此必须保持很高的门槛。第三是知识产权：OCA 要求贡献者拥有其授予 Oracle 的知识产权，且不得附带限制，但个人是否拥有 AI 生成输出的知识产权，目前仍有相关诉讼尚未尘埃落定。 该政策为私人使用留出了空间。贡献者仍然可以使用生成式 AI 来理解、调试和评审 OpenJDK 代码，也可以用于研究，他们只是不能贡献由 AI 生成的内容。 政策 FAQ " 明确指出，即使只是修改了 100 行 AI 生成代码中的 10 行，也不能提交，因为这份贡献仍然包含 AI 生成内容。该政策也允许使用“编辑器或 IDE 中的拼写检查、语法检查、自动补全和重构功能”等工具，前提是“它们不是基于大语言模型或类似深度学习系统”。 OpenJDK 贡献者很快必须在 Skara " 这个自动化 pull request 评审系统中勾选一个复选框，以确认其贡献符合生成式 AI 政策。OpenJDK 承认，人类生成内容和 AI 生成内容通常很难被区分，但仍建议评审者留意 AI 生成内容的典型痕迹。 2026 年 4 月中旬，GraalVM 这个不受 OpenJDK 管理委员会管辖的 Oracle Labs 项目，明确了其 AI 辅助贡献政策和贡献者指南 "，允许生成式 AI 内容： GraalVM 贡献者在准备贡献时，可以使用 AI 编码助手和类似工具。……就本文档而言，“编码助手”包括有助于起草、转换、解释、评审或总结代码、测试、文档或提交文本的 AI 工具。本政策适用于使用此类工具准备的贡献和项目互动，包括提交给项目的 pull request 和 issue。 该项目还在 2026 年 6 月 3 日为 AI 编码助手新增了一份“ 文档术语和风格指南 "”。 GraalVM 政策参考了 Linux 内核的 AI CodingAssistants 政策 "，但也对其进行了调整。例如，Linux 政策规定，“贡献应包含 Assisted-by 标签”。相比之下，GraalVM 的要求相对宽松。它表示，贡献者可以选择是否注明具体使用了哪个模型或工具；但如果披露 AI 辅助过程有助于评审者理解这项变更是如何完成的，项目仍鼓励贡献者说明。 贡献者责任是 GraalVM 贡献者责任规则的核心：提交贡献的人类贡献者要对整个贡献负责，包括其中任何由 AI 辅助完成的部分。他们必须评审并理解该贡献，验证其正确性，并在不把问题推给工具的情况下回答评审者的问题：“如果贡献者无法解释、辩护或维护某项 AI 辅助变更，该贡献可能会被拒绝。” 维护者的评审规则也不会因为 AI 辅助而改变。GraalVM 明确表示，使用 AI 辅助并不意味着某项变更就是正确的，也不意味着它已经达到可评审状态，更不意味着它可以跳过正常审查。维护者在评审时，仍可以追问变更来源、设计意图、许可、测试情况，以及贡献者是否真正理解这项改动。 两个项目都要求贡献者签署同一份 OCA，并授予 Oracle 不受限制的知识产权。但 OpenJDK 将 AI 生成内容所带来的不明确知识产权风险作为全面禁止的理由，而 GraalVM 则认为贡献者责任足以成为允许这类贡献的依据。 Oracle 正在为 OpenJDK 制定一项完整的 AI 贡献政策，并将在“适当时候”提出。目前，尚无关于 GraalVM AI 贡献政策演进的公开公告。 原文连接： https://www.infoq.com/news/2026/06/oracle-genai-policies/ "