GitHub 在 2026 年 10 月 16 日宣布，开源许可证合规能力正式可用。企业可以制定统一的依赖许可证政策，再通过分支规则集检查 Pull Request 中的依赖变化，将不符合政策的依赖留在合并之前处理。
对开发团队，这项功能的价值不是自动回答所有法律问题，而是把政策执行、例外审批与代码审查连接起来。它依赖哪些数据、什么时候会阻断合并、谁能批准例外，都需要在启用前明确，否则一个合规开关也可能变成难以解释的发布障碍。
先分清三件事：有依赖、能识别、符合政策
依赖没有已知漏洞，并不意味着它符合企业的许可证使用政策。反过来，某个许可证不在企业允许列表中，也不能据此断言它本身违法或不可使用。
GitHub 此次能力处理的是后一类工程判断：依赖图识别出的许可证，是否符合企业当前配置的政策。许可证对应的具体义务、软件怎样分发或部署，以及企业是否接受某种使用方式，仍需合适的法律与合规人员判断。
适用范围也不是所有仓库。官方公告与文档要求使用 GitHub Enterprise Cloud，包括支持数据驻留的 GHEC；要强制执行政策的仓库需要 GitHub Code Security 授权，并启用 dependency graph。
因此，不能把它描述成所有免费仓库默认获得的许可证合规扫描，也不能将仓库首页显示许可证、导出 SBOM 与合并时强制执行政策混为一谈。
中央政策如何变成合并条件
企业先定义允许使用的许可证。管理员可以从内置列表选择，也可以手工输入 SPDX 许可证标识。配置指南还支持以 SPDX 表达式列表导入已有政策，便于迁移现有约束。
接着，通过分支规则集选择目标仓库和分支，并启用 Require license compliance results before merging 条件。政策的存在与政策被强制执行是两个步骤，只创建允许列表，不代表所有 PR 都已经受到合并限制。
当 PR 修改包清单时，GitHub 比较基准分支与 PR 分支的依赖变化，对检测到的直接和传递依赖进行许可证评估，并把不符合政策的结果标注在 PR 中。
这条路径可以拆成几个不同的责任：
| 环节 | 提供什么 | 需要确认什么 |
|---|---|---|
| 依赖图 | 直接、传递依赖及检测到的许可证数据 | 目标项目的依赖是否能被识别 |
| 企业许可证政策 | 允许列表及相关例外 | 基线是否经过组织确认 |
| 分支规则集 | 目标范围、评估模式与合并条件 | 哪些仓库和分支真正被覆盖 |
| PR 注释与审批 | 开发者反馈及例外处理入口 | 谁处理请求，按什么依据批准 |
| 审计记录 | 政策变更历史 | 是否需要接入企业记录系统 |
这个模型适合将各仓库零散的检查配置收拢成共同基线。官方公告也明确说明，它扩展了 dependency review action 的能力，但并不是说已有 action 或其他依赖管理措施都应立即删除。
看得到的依赖，才进入这次判断
传递依赖会影响许可证检查结果。例如，开发者只新增一个直接依赖，它又引入其他包，其中某个包的许可证不符合政策，PR 仍可能出现相关提示。只检查最外层包的 README，无法解释整条依赖链。
但覆盖范围来自依赖图，而不是对最终交付物中所有代码的完整法律鉴定。运行时额外下载的文件、未被依赖图识别的组件、直接复制进仓库的第三方代码，不能仅凭这项 PR 检查就认定已经覆盖。
正式可用公告还提到，数据驻留 GHEC 的许可证信息现在可以填充到依赖图和 SBOM 导出中。这有助于后续清单管理，但清单的完整性仍需要按实际项目核验。
试点时，可以准备一组已知依赖变更，检查锁定版本、传递依赖和许可证字段在 PR 中怎样显示。对于缺失、无法识别或存在多种许可选择的数据，应建立人工处理规则，不能直接把“没有看到违规提示”解释成没有义务。
这里还要区分增量检查与存量清理。官方描述的 PR 执行流程针对依赖变化；已经合并的历史依赖，应另行纳入清单和审查计划。启用新规则，不等于历史软件供应链已全部完成复核。
Evaluate 不阻断，为什么 PR 仍可能被卡住
规则集提供 Evaluate 与 Active 等状态。按官方概念文档，Evaluate 会执行检查并注释 PR，但不会因该规则集自身阻止合并；Active 才会将不符合政策的依赖作为合并阻断项。
不过，同一文档明确提醒：如果分支保护要求在合并前解决评论，许可证检查产生的注释也会受这项保护约束。即使许可证规则集处于 Evaluate，团队仍可能需要处理这些注释才能合并。
所以，“观察模式一定对开发流程零影响”是不准确的。试点前应同时检查现有分支保护，而不是只看新规则集的状态。
GitHub 配置指南建议用仓库自定义属性分批推进。例如设置单选属性 open_source_license_compliance，取值为 inactive、evaluate 和 active，再分别建立观察与强制规则集，按属性定位仓库。
属性只是控制推广范围的一种方式，不是产品内固定的必填名称。谁能修改属性、规则集是否覆盖正确分支，以及其他合并条件怎样交互，也需要一并测试。
例外审批不能悄悄变成全局放行
出现提示后，开发者可以移除或替换依赖，也可以在确有需要时申请例外。检测结果不会自动替开发者发起例外请求，开发者需要补充信息并主动提交。
企业可以将 Enterprise Open-Source License Manager 角色分配给负责审查的人员或团队。审批者可以拒绝请求，也可以选择按包、许可证或包模式添加例外，并确定是在仓库范围还是企业范围生效。
这些选项的影响明显不同。某个业务仓库获准使用一个包，不应在没有额外依据时扩大成整个企业都允许某类许可证；一个包模式也可能覆盖未来新增的包。
本文建议采用与审批理由相符的最小范围，并记录包、版本、业务用途、审查依据、责任人和复核时间。这是治理建议，不是说产品会自动替团队设置全部记录和到期机制。
批准后，相关告警可以关闭，PR 在没有其他必需检查失败时解除阻断。这个结果表达的是“当前变更符合有效政策或已获例外”，并不等于 GitHub 为具体使用方式作出法律保证。
同样，内置许可证列表中的风险分类只是信息提示。官方配置指南明确要求向组织法律团队确认政策，而不是直接把产品分类当成法律意见。
API 可以前移检查，不能替代合并时校验
此次从预览走向正式可用，还增加了政策下载、更新、替换等 API，以及检查包是否符合政策的 API。公告举出的用途之一，是让编码 Agent 在推荐或引入依赖前，先查询企业政策。
这对开发体验有帮助：在选择库时获得反馈，通常比 PR 等待合并时才得知限制更容易调整。平台团队也可以利用政策管理 API 备份配置，或将相关流程连接到已有系统。
但 API 查询得到的是某个时间点、某组输入与当时政策下的结果。随后如果包版本、依赖解析结果、仓库有效政策或例外发生变化，早先的检查不能直接替代最终 PR 判断。即便推荐的直接依赖可用，传递依赖也仍要在完整依赖变化中评估。
给 Agent 集成时，宜先使用只读的包合规检查，而不是让它为了消除提示自动扩大允许列表。检查失败时，也不应默认改政策或批准例外。修改政策与选择依赖是不同权限，应分开授权。
本文没有为现有博客开启许可证策略、修改规则集或调用任何政策写入 API。具体端点和权限应以实际使用时的官方 REST 文档为准。
用一个小范围试点验证完整流程
与其首先追求覆盖所有仓库，不如先验证一条可以解释的处理流程。选择一个依赖清单清晰的仓库，确认授权和依赖图可用，准备一组正常变更与预期违反基线的变更。
测试应包含传递依赖，而不只是直接依赖。再分别验证 Evaluate、Active 与现有评论解决要求的交互，看看开发者是否能理解提示，审批者能否收到并处理请求。
例外审批也值得单独演练：只对当前仓库放行某个包之后，其他仓库不应被意外放开。仓库设置中的有效许可证政策页面可以帮助核对企业基线和仓库例外共同形成的结果。
最后检查审计与记录。官方说明，政策变化会产生带 license_compliance_policy 前缀、分类为 Policy Management 的审计事件；是否将这些记录接入外部系统，以及怎样定期复核广泛例外，需要企业自行安排。
当检测、反馈、审批与审计都能解释清楚，再扩大强制范围，通常比只确认一个开关已打开更有价值。
结语
GitHub 这次正式发布的许可证合规能力，把依赖政策放到了开发者日常处理的 PR 流程中，也提供了企业基线、分批推广和例外审批的连接点。
它能减少不符合政策的依赖在缺少讨论时进入代码库，但前提是依赖数据可靠、规则范围正确、例外有人负责。自动检查负责发现与执行，具体使用义务和业务风险仍需要组织作出判断。把这两者分清，才能既让开发反馈更早，也避免把工具结果误当成最终结论。
参考来源
- GitHub Changelog：Open source license compliance generally available，2026 年 10 月 16 日发布，本文近期选题、正式可用范围与更新内容的主要来源。
- GitHub Docs：About open source license compliance，授权前提、依赖图评估、Evaluate 模式及分支保护交互。
- GitHub Docs：Configuring open source license policies，政策配置、分批推广、例外范围、角色和审计事件。本文根据 2026 年 10 月 18 日查阅资料整理，不构成法律意见。