一句话看懂：2026 年 4 月，Oracle 支持的两个关键开源项目 OpenJDK 和 GraalVM 针对 AI 生成代码贡献发布了截然相反的政策：前者全面禁止，后者明确允许。这种分歧不仅反映了大厂内部对 AI 知识产权的不同判断，也为开源社区如何应对 AI 生成内容提供了两个可参考的样本。
事件核心：发生了什么
2026 年 4 月初，OpenJDK 管理委员会批准了一项临时政策，明确禁止贡献包含由大语言模型、扩散模型或类似系统生成的内容——包括源代码、文本和图片。该政策适用于 Git 仓库、GitHub pull request、邮件、wiki 和 JBS issue，仅豁免了拼写检查、语法检查等传统 IDE 功能。贡献者仍需在 Skara 评审系统中确认合规。同一月中旬，Oracle Labs 旗下的 GraalVM 则发布了允许 AI 辅助的贡献政策，明确贡献者可使用编码助手工具起草、解释或评审代码，但要求人类贡献者对全部内容负责，且维护者评审标准不变。两个项目均要求贡献者签署相同的 Oracle Contributor Agreement（OCA）。
为什么重要
两个同属 Oracle、同样由 OCA 管理的项目，对 AI 贡献的态度却完全相反，这直接暴露了 AI 时代开源治理的两大核心矛盾。第一是知识产权不确定性：OpenJDK 认为个人是否拥有 AI 生成输出的知识产权仍无定论，因此选择全面禁止；GraalVM 则认为贡献者责任机制已能覆盖风险。第二是评审效率与创新速度的取舍：OpenJDK 担心大量看似合理但错误的 AI 代码耗尽评审精力，GraalVM 则更看重降低贡献门槛。作为 Java 生态与 GraalVM 高性能运行时的基础设施，这两个项目的政策走向将直接影响下游框架、工具链和企业级应用的代码来源合规性。
对用户/开发者/创作者的影响
对使用 OpenJDK 的 Java 开发者而言，如需为 JDK 本身提交补丁，必须完全排除 AI 工具辅助生成内容，即使只修改了 100 行 AI 生成代码中的 10 行也不合规。但个人使用 AI 调试、理解代码仍被允许。对 GraalVM 的贡献者来说，政策更宽松，但必须能解释和维护由 AI 辅助完成的变更，否则维护者有权拒绝。对更广泛的开源项目维护者而言，这两个案例提供了两种可复用的政策模板：一种强调风险隔离，一种信任人工审核。企业采购需评估自身代码库是否涉及 OpenJDK 贡献合规。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
第一，Oracle 已公开表示正在为 OpenJDK 制定完整 AI 贡献政策，目前仅为临时过渡方案，后续是否放开或细化值得跟踪。第二，GraalVM 在 2026 年 6 月新增了 AI 编码助手文档术语指南，其政策执行细节仍在完善中。第三，两个项目的分歧可能引发 Java 社区其他子项目（如 Jakarta EE）以及 Linux 基金会旗下项目的效仿或调整，尤其是围绕 OCA 的条款解释是否统一。
来源：InfoQ CN
