GitHub许可证检查GA：为例外设定复审条件
依赖更新没有安全警告，不等于许可证审查已经完成。许可证检查通过，也不代表产品的所有分发方式都经过评估。GitHub于2026年10月16日宣布开源许可证合规检查正式可用。
先核对资格与目标仓库
公告适用于GitHub Enterprise Cloud，包括数据驻留环境，且仓库须启用GitHub Code Security。不能理解为所有Free或Team仓库自动可用。企业策略通过含有Require license compliance results before merging的ruleset指定仓库。应分别核对账户资格、目标仓库和实际生效的合并条件。 Active模式阻止合并，Evaluate模式仅标注。但若另有必须解决评论的保护规则，标注仍可能影响合并。
检查对象是发生变化的依赖
PR新增或修改依赖时，系统将新增或变更的包与策略比较，并在PR标注不合规项。可通过删除、替换、修改策略或创建包例外处理。这并不证明过去所有交付物都完成审查。记录被检查的包版本与策略。以下流程属于本文的运维建议。
例外需要负责人和复审触发点
Enterprise Open-Source License Manager角色可指定关闭请求的审核人。团队还可记录包、版本、PR、用途、理由、负责人和复审条件。例如，仅获演示用途批准的包在进入客户交付物前重新评估。这是建议的团队流程，并非GitHub自动使例外到期的功能。
在代理选择包之前检查
公告还提供包合规检查API和策略变更审计事件。安装前检查有望减少后期替换成本。将包、策略、时间及结果关联到变更，而不只是记录API有响应。请求失败或许可证未知应转交审查，不应默认为许可。
可先做两个小型测试PR，分别使用允许的依赖和刻意不合规的依赖，检查标注、合并阻止以及例外批准后的记录。使用不改动客户代码的测试仓库。推广前明确负责人和回退办法。这是建议的验证方法，并非已执行测试的报告。
实用问题是谁负责例外，以及什么变化会触发复审。公告链接了社区讨论，本文没有估算参与规模或采用率。内容不替代对具体许可证的法律判断。下一次依赖PR中，把理由和复审条件一起保存。
来源与核查范围
GitHub Docs · Open source license compliance
2026年10月17日核对官方公告。请同时检查最新文档与自己的账户设置。