AI 编程工具已经不只是“看几行代码给补全”了。Copilot 在 IDE 里联想，Codex 类工具能重构项目，企业内部 agent 还会轮询仓库、索引依赖、生成补丁。问题是：很多商业源码许可证诞生时，并没有认真描述“AI 可以拿这些代码做什么”。
ACL v1.0 的发布，正是冲着这个空白来的。它试图回答一个新问题：在 AI 时代，代码“可见、可用、可修改”和“可训练、可索引、可代理执行”之间，边界到底在哪里。
老许可证没写 AI，不等于 AI 行为天然被允许
BUSL 和 Elastic License 2.0 这类许可证，主要关注的是传统软件商业化场景：你能不能把它作为托管服务卖，能不能修改后再分发，能不能绕开原厂商业模式。
但今天的代码消费方式变了：
- IDE 插件可能把上下文片段发送给远端模型；
- 企业 AI agent 可能批量读取仓库、issue、CI 日志；
- RAG 系统可能把源码嵌入向量库；
- 模型训练或微调可能把代码变成参数的一部分；
- 自动化工具可能基于仓库内容生成可执行补丁。
这些动作不完全等同于“复制”“分发”或“提供 SaaS”。如果许可证没有写，企业法务、开源办公室和工程团队就会进入灰区：工具可以接入吗？索引算不算派生使用？把代码发给第三方模型供应商是否合规？
ACL v1.0 的意义不在于它让所有争议立刻消失，而在于它把 AI 行为从默认沉默变成可讨论、可审计、可授权的许可证条款对象。
“开源商业许可证”的核心张力
“开源”在开发者语境里常常意味着可读、可 fork、可修补。但商业许可证通常还要保护厂商的核心营收边界。AI 把这两者的张力放大了。
一个现实例子：某个基础设施项目允许你阅读源码、提交补丁、内部部署，但不希望竞争对手把整个仓库喂给模型，训练出一个能自动生成兼容实现的助手。传统许可证可能禁止直接复制产品，却未必明确禁止这种 AI 派生能力建设。
因此，ACL 这类许可证通常会被企业用来定义几类边界：
- 交互式辅助：开发者在 IDE 中使用 AI 阅读当前文件或生成小补丁；
- 仓库级索引：AI 系统持续扫描整个代码库，用于问答、搜索或自动修复；
- 模型训练/微调：把源码用于训练权重、适配模型或构建专用编码模型；
- 商业替代服务：用 AI 生成、复制或重建一个与原项目竞争的服务。
不同团队对这些边界的接受度不同。关键是不要让工程默认行为跑在许可证和采购条款前面。
可以这样实践：给仓库加一层 AI 使用策略
如果你维护的是企业内部项目，或者正在采用带有 AI 条款的新许可证，可以先不要等所有工具都“自动理解许可证”。更务实的做法是：在仓库里增加机器可读的 AI 使用策略，让 CI、agent 和开发者都有一个明确入口。
下面是一个可改造的示例。假设团队允许本地 IDE 辅助，但禁止把完整仓库用于第三方模型训练。
# .ai-policy.yml
license_profile: ACL-1.0-compatible
repository: example/service-api
allowed:
- local_code_completion
- pull_request_review
- test_generation
restricted:
- third_party_model_training
- whole_repository_embedding_without_approval
- competitive_service_generation
approval:
owner: legal-engineering@example.com
required_for:
- external_ai_vendor_upload
- repository_wide_indexing
- fine_tuning
retention:
max_prompt_retention_days: 30
allow_vendor_training: false
再配一个简单的 CI 检查，至少能防止仓库缺少策略文件时被 AI 自动化流程接管：
#!/usr/bin/env bash
set -euo pipefail
POLICY_FILE=".ai-policy.yml"
if [[ ! -f "$POLICY_FILE" ]]; then
echo "Missing $POLICY_FILE. Add an AI usage policy before enabling agents."
exit 1
fi
if grep -q "allow_vendor_training: true" "$POLICY_FILE"; then
echo "Vendor training is enabled. Legal approval is required."
exit 1
fi
echo "AI policy check passed."
你可以把它放进 scripts/check-ai-policy.sh，然后在 GitHub Actions 里执行：
name: AI Policy Check
on:
pull_request:
push:
branches: [main]
jobs:
ai-policy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check AI usage policy
run: bash scripts/check-ai-policy.sh
这不是 ACL v1.0 的官方要求，而是一种可以落地的工程做法：把许可证意图转成仓库治理规则，减少“工具默认打开、风险事后发现”的情况。
工程团队该怎么评估 ACL v1.0
看待 ACL v1.0，不要只问“它是不是开源”。更有用的问题是：它是否准确表达了你想允许和禁止的 AI 行为。
可以按这份清单评估：
- 开发体验：是否允许日常补全、重构、测试生成？限制会不会让贡献者难以工作？
- 数据边界：源码能否发送给第三方模型？供应商是否保留 prompt 或用作训练？
- 索引边界：内部 RAG、代码搜索、agent 扫描是否需要额外批准？
- 竞争边界：许可证是否明确限制用 AI 生成替代性商业服务？
- 执行成本：团队是否有能力审计 AI 工具、CI、插件和供应商设置？
许可证不是魔法盾。它需要配合供应商合同、开发者培训、仓库配置和自动化检查。ACL v1.0 的价值在于提醒我们：AI 已经改变了源码的使用方式，许可证也必须从“人读代码”的时代，更新到“机器持续理解代码”的时代。