Oracle 禁止将 AI 生成的代码提交至 OpenJDK 贡献

Oracle 禁止将 AI 生成的代码提交至 OpenJDK

Oracle 已禁止向 OpenJDK 项目提交 AI 生成的代码，理由是出于对安全、可靠性和知识产权（IP）风险的担忧。尽管开发人员仍可私下使用大型语言模型（LLMs）进行调试和代码审查，但任何提交至代码仓库、拉取请求或其他项目渠道的内容必须由人类编写。

这一政策与 Oracle 内部的运作形成鲜明对比。联合创始人拉里·埃里森最近表示，AI 模型如今正在编写 Oracle 的内部代码，联合首席执行官迈克·西西利亚则将 AI 工具归功于提升了小型工程团队的工作效率。这种差异表明，Oracle 在软件开发中对 AI 的采纳采取了“对你如此，对我却不然”的双重标准。

知识产权与法律风险

这项禁令的主要驱动力是降低法律和版权责任风险。由于目前 AI 生成的内容在版权认定方面存在挑战，Oracle 无法确保代码的来源，也无法维持其对 Java 生态系统所要求的严格许可控制。

行业观察者和社区成员指出了几个关键的法律动因：

• 版权可保护性： 当前普遍的法律观点认为，AI 生成的代码可能不具备版权保护资格，这意味着无法正式归属 Oracle 或项目，可能使其进入公共领域。
• 诉讼策略： 通过拒绝接受 AI 生成的贡献，Oracle 避免树立先例，从而防止削弱其未来对其他实体因“AI 包装”专有代码而提起诉讼的能力。
• 赔偿保障： 尽管企业内部使用 AI 通常附带供应商提供的赔偿保障，但外部社区贡献缺乏此类保护，使项目面临第三方知识产权主张的风险。

审查者负担与代码质量

除了法律问题，Oracle 还指出“人类审查者本已有限的时间”是关键因素。生成式 AI 的兴起导致贡献数量增加，这些贡献常表现为“粗糙代码”——看似正确，但缺乏深层架构考量或包含细微缺陷。

关键的技术担忧包括：

• 验证开销： 审查者必须花费更多时间验证 AI 生成的代码是否引入回归问题或安全漏洞。
• 维护责任： 在像 Java 这样成熟的软件产品中，代码被视为一种责任。向支撑全球绝大多数企业业务的项目引入不稳定性，其风险远超 AI 贡献可能带来的速度提升。
• 检测难题： Oracle 自己的常见问题解答（FAQ）也承认，可靠地区分 AI 生成与人工编写的代码几乎不可能，因此该政策在很大程度上依赖贡献者的诚信。

与其他生态系统的对比

OpenJDK 的政策并非孤立事件。其他主要语言项目也在采取类似措施以维护代码完整性：

• Rust： 最近发布了关于 AI 生成代码的指南，以确保质量和来源可追溯性。
• .NET/Microsoft： 相比之下，微软在 .NET 和 Copilot 驱动的开发中更积极地整合 AI，代表了对 AI 融入开发工作流的不同哲学立场。

社区观点

社区对这一禁令的反应褒贬不一，主要聚焦于 Oracle 内部使用 AI 与外部限制之间的讽刺性对比。

"Oracle，一家附带科技业务的律师事务所，可能希望保留对他人因‘AI 包装’其专有代码而提起诉讼的权利，但如果他们自己公开接受 AI 贡献且对来源毫无顾虑，这种策略就无法成立。"

其他贡献者认为，这正是一个成熟项目在走出‘快速行动、破坏性创新’时代后自然演进的结果，此时稳定性和法律确定性成为最高优先级。