同一个公司、同一份贡献者协议,却诞生了两条完全相反的政策:OpenJDK 管理委员会通过了临时政策,明确禁止生成式 AI 产出的代码贡献;而 GraalVM 的 Coding Assistants 政策则允许使用 AI 辅助工具提交代码。这对任何参与或维护开源项目的人来说,都是一个值得仔细拆解的信号。
OpenJDK 为什么选择禁止
OpenJDK 是 Java 生态的基石,代码质量和知识产权的纯净度直接关系到数百万开发者。管理委员会批准的临时政策核心逻辑是:生成式 AI 工具的训练数据来源不透明,无法保证产出代码不包含受版权保护的片段。一旦这类代码进入 OpenJDK,后续的知识产权纠纷可能波及整个 Java 生态。
这不是对 AI 工具本身的否定,而是对「可追溯性」的严格要求——OpenJDK 需要每一行贡献都有明确的人类作者和清晰的授权链路。在训练数据合规性得到法律确认之前,禁止是最稳妥的选择。
GraalVM 为什么选择允许
GraalVM 的 Coding Assistants 政策走了另一条路:允许使用 AI 辅助工具,但要求贡献者对提交内容承担完全责任。政策的关键前提是——贡献者本人必须审查、理解并验证 AI 生成的每一行代码,确保不引入未授权的第三方内容。
GraalVM 定位是高性能运行时和多语言引擎,社区节奏更快,贡献者群体更偏向工程实践。允许 AI 辅助可以降低入门门槛、加速迭代,前提是把合规责任压在贡献者身上而非项目方。
同一份 OCA,两种解读
两个项目都要求签署 Oracle Contributor Agreement(OCA),OCA 的核心条款是贡献者保证自己拥有所提交内容的知识产权并授权给 Oracle。分歧在于:当代码由 AI 生成时,贡献者能否真正做出这一保证?
OpenJDK 的回答是「目前不能」——因为贡献者无法确认 AI 产出是否混入了他人版权代码,所以 OCA 的保证在 AI 场景下不可靠。GraalVM 的回答是「可以,前提是你做了充分审查」——只要贡献者逐行验证并承担责任,OCA 的保证依然成立。
两种解读都有法律逻辑支撑,但风险敞口不同:禁止政策把风险挡在门外,允许政策把风险转移给贡献者。
给开源维护者的实操建议
如果你的项目也在考虑如何对待 AI 生成贡献,以下是一个可以直接改造使用的贡献政策配置和 git 提交检查脚本。
项目贡献政策声明模板
在项目根目录放置 CONTRIBUTING_AI_POLICY.md,明确立场:
## AI 辅助贡献政策
本项目对使用生成式 AI 工具(如 ChatGPT、Copilot、Claude 等)的贡献采取以下立场:
- **允许使用** AI 工具辅助编写代码,但贡献者必须逐行审查所有 AI 产出。
- **禁止提交** 贡献者无法完全理解或无法解释的 AI 生成代码。
- **要求声明**:在 Pull Request 描述中注明使用了哪些 AI 工具及使用范围。
- **知识产权保证**:贡献者确认 AI 产出不包含未授权的第三方受版权保护代码。
违反以上条款的贡献将被拒绝,重复违反者将被限制提交权限。
Git 提交钩子:提醒贡献者声明 AI 使用
以下脚本在每次 commit 时检查提交信息是否包含 AI 使用声明标记,适用于团队内部流程管控:
#!/usr/bin/env bash
# .git/hooks/commit-msg
# 安装:cp commit-msg .git/hooks/commit-msg && chmod +x .git/hooks/commit-msg
COMMIT_MSG_FILE="$1"
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")
# 定义 AI 使用声明标记(贡献者在 commit message 中加上此标记即视为已声明)
AI_TAG="[ai-assist]"
# 检查是否涉及代码文件变更
CODE_CHANGED=false
for FILE in $(git diff --cached --name-only --diff-filter=ACMR); do
if echo "$FILE" | grep -qE '\.(java|py|js|ts|go|rs|c|cpp|rb|kt|scala)$'; then
CODE_CHANGED=true
break
fi
fi
if [ "$CODE_CHANGED" = true ]; then
if echo "$COMMIT_MSG" | grep -q "$AI_TAG"; then
# 已声明 AI 使用,通过
echo "✓ AI 辅助声明已包含,提交继续。"
else
# 未声明,提示但不强制阻断(可根据项目需要改为 exit 1 强制阻断)
echo "⚠ 提示:本次提交涉及代码变更但未声明 AI 工具使用。"
echo " 如使用了 AI 辅助,请在提交信息中添加 $AI_TAG 标记。"
echo " 示例:feat: add cache layer $AI_TAG (used Copilot for boilerplate)"
echo " 如未使用 AI 工具,可忽略此提示。"
fi
fi
exit 0
安装方式:将脚本保存为 .git/hooks/commit-msg 并赋予执行权限。如果项目需要强制阻断未声明的 AI 提交,将最后的 exit 0 改为条件性 exit 1。
PR 模板中增加 AI 声明字段
# .github/PULL_REQUEST_TEMPLATE.yml(GitHub PR 模板示例)
body:
- type: checkboxes
id: ai-declaration
attributes:
label: AI 工具使用声明
description: 请如实声明本次 PR 中 AI 辅助工具的使用情况
options:
- label: 本次 PR 未使用任何生成式 AI 工具
- label: 本次 PR 使用了 AI 工具辅助,我已逐行审查所有 AI 产出并确认不含未授权第三方代码
required: false
- type: textarea
id: ai-details
attributes:
label: AI 工具使用详情(如选了上一项则填写)
description: 列出使用的 AI 工具名称及辅助范围
placeholder: "例:使用 Copilot 辅助编写 JSON 解析部分,核心逻辑由人工编写"
选择哪条路:决策清单
在制定自己项目的 AI 贡献政策时,可以参考以下清单做判断:
- 项目定位:基础设施级项目(如语言实现、标准库)倾向禁止,应用级项目倾向允许——前者对 IP 纯净度要求更高。
- 社区规模:大型社区审核成本高,禁止政策降低审核负担;小社区信任链更短,允许政策更灵活。
- 法律环境:训练数据版权诉讼仍在进行中,如果你的项目背后有企业法律团队,先咨询他们。
- 风险承受力:禁止政策风险近零但牺牲效率,允许政策效率更高但 IP 风险由贡献者承担。
- 可逆性:OpenJDK 明确标注了「临时政策」,意味着随着法律明朗化可能调整——你也可以先保守再放开,反过来则更难。
Oracle 两个项目的分歧不是矛盾,而是同一法律不确定性下的两种合理应对。关键是:你的项目要明确选一条路,写进贡献指南,让所有贡献者知道规则。