甲骨文禁止向OpenJDK提交AI生成代码

IT时代网8月10日消息，甲骨文（Oracle）已通知OpenJDK开发者，项目组不再接受AI生成的代码。

公司给出的表述相当直接：OpenJDK社区贡献内容不得包含由大语言模型、扩散模型或深度学习系统生成的内容。这里的“内容”范围铺得很开，代码只是其中一项，文本、Pull Request、电子邮件沟通、维基页面和Bug报告统统算在内。

为什么要把口子收得这么紧，甲骨文列了三条理由：知识产权风险、网络安全风险，以及代码审查的工作量。

第一条是绕不过去的坎。生成式模型的训练语料来源复杂，产出的代码片段与既有开源代码之间是否构成实质性相似、许可证如何继承，目前既没有统一的司法结论，也缺乏可靠的技术手段去逐行溯源。对一个被全球企业当作基础设施的Java运行时项目来说，任何一处权属不清的代码都可能在多年后变成麻烦。

第二条和第三条其实是一体两面。模型生成的代码看上去规整、注释齐全，逻辑上却可能藏着难以察觉的缺陷；审查者需要花更多精力去分辨“写得像模像样”和“确实正确”之间的差别。当提交量上来之后，维护者的时间被大量消耗在甄别环节，社区的整体效率反而下降。

新规并没有把AI工具从开发者的桌面上赶走。甲骨文明确说明，开发者仍然可以私下使用AI工具审查代码、调试问题，或者做OpenJDK项目相关的研究，只是一切AI生成的内容不得提交至仓库。分界线画在“输出物”而不是“工作方式”上。

把视线放宽一点，这样的规定并非孤例。此前已有开源项目出于版权归属不清的顾虑，对AI生成内容设过类似门槛，理由大同小异——项目方无法为自己不掌握来源的代码承担法律责任。

另一个绕不开的现实是执行难度。除非贡献者主动声明，维护者很难从代码本身判断它出自人手还是模型。这类规则更多起到的是责任划分的作用：一旦日后出现权属纠纷，项目方至少能证明自己已经尽到告知义务。真正的约束力，最终还是落在社区的自觉与信任上。

注：本文中包含AI辅助创作的内容。