GitHub 把许可证检查装进合并门禁，还给了 coding agent 专属 API

GitHub 在 10 月 16 日的 Changelog 里宣布：企业级开源许可证合规检查正式 GA。第一眼看，这像是给大公司法务部门准备的又一个合规小工具。但读到 changelog 的最后一行，味道就变了——GitHub 专门新增了一个 API 端点，让 coding agent 在推荐或引入第三方包之前，先查一下这个包符不符合组织的许可证政策。

这是 GitHub 第一次把「AI 编程」写进合规基础设施的设计目标里。许可证合规，从此有了 agent 原生形态。

这个功能到底是做什么的

先讲机制。它面向 GitHub Enterprise Cloud 客户（需要开启 GitHub Code Security），核心是一个企业级的许可证政策：管理员定义好哪些许可证可用、哪些禁用，然后通过 ruleset（规则集）把政策应用到一批仓库上。规则集里新增了一个条件：Require license compliance results before merging（合并前必须通过许可证合规检查），用法和已有的代码扫描条件类似。

之后，每当有人提 PR 新增或修改了依赖，检查会自动跑一遍：每个新增/变更的依赖，其许可证必须在政策允许范围内。不合规的依赖会被逐条标注在 PR 上，作者必须三选一：删掉或替换这个依赖、修改许可证政策、或者为这个包创建例外。想绕过去？合并不了。

配套的还有组织层面的设计：新增预置企业角色 Enterprise Open-Source License Manager（企业开源许可证管理员），专门负责审批例外申请；政策变更会写入审计日志；license 数据还会回填到依赖图谱和 SBOM（软件物料清单）导出里。自 6 月公开预览以来，数据驻留版 GHEC 客户也能用上了。

为什么现在？因为 AI 把许可证风险放大了十倍

许可证问题不是新问题。npm install 一个包，里面可能混着 MIT、Apache、GPL、SSPL 各种许可证；GPL 的传染性条款和某些云厂商许可证的限制， historically 是靠法务 review 和工程师自觉来防的。但 AI 编程改变了风险的量级：

第一，依赖引入的速度变了。以前一个人一天加两三个依赖，现在 agent 一下午能给你装二十个。每个依赖都是一次许可证风险敞口，人工 review 根本跟不上这个速度。

第二，依赖引入的「知情度」变了。人自己加依赖时，至少会看一眼 README 和 license；agent 加依赖时，它可能只是「觉得这个包能解决问题」。很多 vibe coding 场景下，开发者甚至不知道 agent 引入了哪些传递依赖——风险在完全无感的情况下累积。

第三，代码的「作者」变了。传统合规流程假设「写代码的人」和「担责任的人」是同一个；agent 生成的代码，责任链条是断的。出了许可证纠纷，你很难说「是 AI 干的」来免责。

GitHub 的 changelog 把这层意思点得很透：新 API 的存在，就是为了让 coding agent「避免推荐或引入违反组织许可证政策的包」。翻译一下：GitHub 承认 agent 已经是依赖引入的主要入口之一了，合规检查必须前移到 agent 做决策的那一刻，而不是等 PR 提上来再由人来拦。

从「人审」到「策略即代码」：合规范式的转移

这个 GA 真正值得记录的，不是某个具体功能，而是一次范式转移。过去十年，开源合规的答案是「流程+人」：dependency review、法务审批、定期审计。现在的答案是「策略即代码」：政策写成规则，规则挂进合并门禁，机器自动执行，人只处理例外。

这个转移和 AI 编程是同一枚硬币的两面：AI 让代码生产变成了机器速度，合规就必须也变成机器速度。用人工流程去管机器产出的代码，就像用人工收费站去管高速公路——堵是注定的。GitHub 的做法是把收费站修成 ETC：ruleset 就是 ETC 门架，政策就是费率表，例外审批是人工窗口。

可以预见，下一步就是各家 agent 工具原生集成这个 API：Cursor、Copilot、Codex 在引入依赖前自动查政策，不合规的包直接换方案。这会是 2027 年 coding agent 的标配能力，就像今天的自动补全一样理所当然。

例外机制：合规系统里的人性化阀门

任何自动化的合规系统，最考验设计的都是例外通道。GitHub 这次给了完整的答案：不合规的依赖可以走「创建例外」流程，由新设立的 Enterprise Open-Source License Manager 角色审批，审批人会收到邮件通知，直接在企业控制台处理。

这个设计里有两处值得细品。第一，例外是「申请制」而不是「自助制」。开发者不能自己点一下就放行，必须有人审批。这防止了合规门禁沦为摆设——如果人人都能一键豁免，ETC 门架就形同虚设。第二，审批权被收拢到一个专职角色，而不是散落在各个仓库管理员手里。许可证判断是专业活（GPL 的 classpath 例外、LGPL 的动态链接条款，不是每个 TL 都分得清），集中到懂行的人手里，既保证了质量，也让责任可追溯。

但硬币的另一面是：例外通道很容易变成橡皮图章。如果审批人每天要处理几十个例外申请，「快速通过」会成为默认动作，合规就退化成「多点一次鼠标」。GitHub 给的解法是审计日志——每次政策变更、每次例外审批都有记录，可供外部系统对接。这意味着例外不是法外之地，而是「留痕的特批」。对企业来说，真正的考验不是装上这个功能，而是能不能坚持让例外审批保持严肃性。

对中小团队有个启发：即使没有企业版，也可以借鉴这个「门禁+例外」的结构。比如在仓库的 CONTRIBUTING 里写明：引入 GPL 系列依赖需要技术负责人书面同意；CI 里跑许可证扫描，不合规就 block PR，例外走 issue 审批。工具是 GitHub 的，方法论是通用的。

给独立开发者和中小团队的四条建议

这个功能今天是企业版专属，但风险可不分企业还是个人。几条马上能用的建议：

第一，知道你常用的许可证意味着什么。MIT/Apache-2.0 最宽松；GPL 系列有传染性，用在闭源产品里要非常小心；SSPL、Elastic License 这类「源码可用」许可证根本不是 OSI 认证的开源许可证，商用限制很多。让 agent 加依赖前，先立好自己项目的许可证红线。

第二，给仓库打开免费的依赖检查。公开仓库可以直接用 GitHub 自带的 dependency review action，每次 PR 自动列出新增依赖的许可证。这是最便宜的「ETC 门架」，今天就能装上。

第三，在 agent 的指令里写明许可证约束。比如在 CLAUDE.md 或项目 instructions 里加一句：「引入第三方依赖时优先选择 MIT/Apache-2.0 许可证的包，避免 GPL 系列」。把合规前移到 agent 做决策的那一刻——这正是 GitHub 这次 GA 背后的核心思想，你现在就可以手动实现。

第四，定期跑一次许可证盘点。agent 已经往你的项目里加过多少依赖了？花半小时跑一遍 license-checker 之类的工具，看看有没有惊喜。很多 vibe coding 项目的 package.json 里，都躺着几个作者自己都没听说过的包。

AI 让写代码变成了「说话」，但许可证从来不是「说说而已」的东西。当机器开始替你做引入依赖的决定，合规就必须从「事后审查」变成「事前策略」。GitHub 这次 GA，只是把这句话写成了产品——而聪明的开发者，应该比产品先行一步。毕竟，等法务找上门的时候，解释「是 AI 让我装的」可没什么用。