GitHub 开源许可证合规正式可用：企业可集中管控依赖许可证

企业现在可以通过基于规则集的复杂检查来大规模管理其依赖项的许可证，从而执行集中化策略。开源许可证合规现已面向 GitHub Enterprise Cloud 客户正式可用，包括数据驻留型 GHEC，适用于已启用 GitHub Code Security 的仓库。

开源许可证合规扩展了依赖项审查操作的能力，引入了企业级许可证策略。该策略通过使用新的“合并前要求许可证合规结果”条件（类似于现有的代码扫描条件）的规则集来定位目标仓库，从而被激活。当开发者打开添加或修改依赖项的拉取请求时，许可证检查会自动确保每个新增或变更的依赖项具有可接受的许可证。该功能会在拉取请求上标注关于每个不合规依赖项的消息。这些标注必须通过移除或替换依赖项、修改许可证策略或创建包例外来处理。

开源许可证合规引入了一个新的预定义企业角色：Enterprise Open-Source License Manager。将该角色分配给应审查和批准关闭请求的个人或团队。策略管理员会收到有关待处理请求的电子邮件通知，并可从企业控制台审查这些请求。

自 6 月公开发布预览版以来，我们做了多项改进：许可证信息现在可用于 GitHub Enterprise Cloud 数据驻留客户。这不仅启用了许可证合规功能，还使依赖关系图和软件物料清单（SBOM）导出中填充许可证数据。许可证策略变更现在会发出审计日志事件，以便与外部记录系统集成。新增了用于下载、更新和替换企业许可证策略的 API 端点。还有一个新的 API 端点，用于检查包是否符合策略。这使编码代理能够避免推荐或引入违反组织许可证使用策略的包。

有关详细设置说明，请参阅“关于开源许可证合规”。有关 API 端点的信息，请参阅依赖关系图的 REST API 端点。加入 GitHub 社区中的讨论。

GitHub 宣布开源许可证合规功能正式可用，面向已启用 GitHub Code Security 的 GitHub Enterprise Cloud 客户（含数据驻留型）。企业可通过规则集在合并前强制执行统一的许可证策略，新增企业级角色管理例外审批，并开放相关 API，使编码代理也能规避违反许可证策略的依赖包。

• GitHub 宣布开源许可证合规功能正式可用，面向已启用 GitHub Code Security 的 GitHub Enterprise Cloud 客户（含数据驻留型）。企业可通过规则集在合并前强制执行统一的许可证策略，新增企业级角色管理例外审批，并开放相关 API，使编码代理也能规避违反许可证策略的依赖包。
• 原贴提到：Enterprises can now manage their dependencies’ licenses at scale with so
• 来源：github.blog

这是什么信号

GitHub 把开源许可证合规从公开预览推进到正式可用，并且只面向已启用 GitHub Code Security 的 GitHub Enterprise Cloud 客户（包含数据驻留型）。这意味着“许可证合规”不再是第三方扫描工具或法务团队的事后审计动作，而是被嵌入到合并前的 Pull Request 流程里：新增或修改依赖项时，规则集自动校验许可证是否落在企业统一策略内，不合规则在 PR 上直接标注，必须移除、替换该依赖、修改策略或走包例外流程。

更值得注意的是三处配套设计：一是新增预定义企业角色 Enterprise Open-Source License Manager，让“审批例外”有了明确的责任人而不是模糊的团队共识；二是策略变更写入审计日志，并开放下载、更新、替换策略和校验包合规性的 API；三是官方明确点出这套 API 能让编码代理避免推荐或引入违反许可证策略的包。换句话说，合规检查正在从“人审依赖”扩展到“AI 生成代码时就要守规矩”。

为什么重要

依赖许可证风险的特点是低频、高破坏性：平时没人看，一旦在并购尽调、客户安全问卷、开源诉讼或合规审计中被翻出来，返工成本极高，甚至要重构或替换整条技术栈。把校验点前移到 PR，等于把这类风险从“事后取证”改成“事前拦截”。

对企业云客户而言，许可证数据同时被补进依赖关系图和 SBOM 导出，这让许可证信息第一次和 SBOM 这类供应链合规产物处在同一条数据链路上——安全团队、法务团队和平台工程不必再各自维护一份依赖清单。规则集驱动的集中策略，也把“哪个团队能用什么许可证”从口头约定变成可执行、可审计、可版本化的配置。

对 AI 编码工具链来说，一个可查询的“包是否合规”接口意义更大：模型推荐依赖时最常见的失败模式就是给出一堆流行但许可证不可用的包。合规校验成为代理可调用的工具后，“AI 写的代码”才可能在依赖层面被企业的法务边界约束住。

对谁有价值

• 平台工程 / DevEx 团队：用规则集一次性把许可证策略铺到目标仓库，不必逐个仓库配置。
• 法务与开源合规（OSPO）团队：获得企业级角色、邮件通知和企业控制台审批队列，例外申请有了可追溯的流程。
• 安全与供应链团队：许可证数据进入依赖关系图与 SBOM 导出，审计材料更完整。
• 构建 AI 编码代理的团队：可调用合规校验接口，在推荐或引入包之前先过滤。
• 受强合规约束的行业客户：数据驻留型 GHEC 同样支持，减少了“合规功能不能用”的地域阻碍。

可以怎么行动

1. 先盘点当前依赖的许可证分布（依赖关系图与 SBOM 导出此时已有许可证数据可用），明确哪些是真正需要禁止的，而不是一刀切禁用所有 copyleft。
2. 编写企业许可证策略与例外流程，先在小范围仓库用规则集以观察模式验证，再逐步扩大范围并开启“合并前要求许可证合规结果”。
3. 指定 Enterprise Open-Source License Manager 角色人选，并把邮件通知接入现有值班或工单系统，避免审批积压。
4. 把策略变更的审计日志事件对接进外部记录系统，让合规状态可被定期复核。
5. 若已在使用编码代理，把包合规性校验接口接进代理的工具链，从生成阶段就阻断不合规依赖。

风险与限制

这套能力有明确的边界：它只面向 GitHub Enterprise Cloud 客户，且仓库需启用 GitHub Code Security，自建或非企业版用户无法直接使用。规则集是“强制”手段，策略一旦过于激进，会以全体开发者的合并阻塞为代价，因此策略粒度、例外通道和责任人必须同步到位，否则容易出现大量包例外、审批拥堵甚至团队绕过流程。

此外，自动化检查只能判定“许可证是否命中策略”，不能替代对许可证兼容性、专利条款、修改义务的实质法律判断；真正复杂的场景仍需人工评审。合规数据被补入 SBOM 与依赖关系图是好事，但前提是依赖关系本身被正确解析——私有包、非标准分发方式仍可能存在盲区。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub 开源许可证合规正式可用：企业可集中管控依赖许可证》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖