两个由 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 贡献政策演进的公开公告。
原文连接：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。