4. 开源合规组织与角色设计

开源合规不是某一个部门的“独角戏”。一个中等规模的企业，若仅由法务在发布前做一次许可证扫描，往往会遇到三类典型问题：研发已经引入 GPL 组件却未告知、安全团队发现的漏洞无法定位到具体产品版本、采购签下的供应商合同里缺少开源义务转移条款。要解决这些问题，必须把合规职责拆解到具体角色，并用明确的协作机制把角色串起来。

一、五类角色的职责边界

合规委员会是决策与仲裁层，通常由法务负责人、研发负责人、安全负责人、采购负责人及一名高管组成，每季度或每月固定开会。它不处理单个组件的许可证判断，而是负责三件事：批准开源合规政策与例外、裁决跨部门争议（例如某产品必须使用 AGPL 组件但无法开源，是否放行）、审议重大风险事件。委员会需要一个明确的“例外审批单”入口，否则所有争议都会堆积到个人身上。

法务是规则解释与风险判断层。核心职责包括：维护许可证白名单/灰名单/黑名单，判断许可证兼容性（如 GPL-2.0-only 与 Apache-2.0 的冲突），审核对外分发时的义务履行方式，起草和审核供应商合同中的开源条款。法务不负责扫描代码，但必须定义“什么算分发”“什么算修改”这些判断标准。

研发是引入与履行的执行层。研发工程师在引入新组件时提交开源使用申请，填写组件名、版本、许可证、引入方式（直接依赖/间接依赖）、是否修改。研发还负责保留版权声明、提供 Corresponding Source、在构建产物中嵌入许可证文本。研发最容易犯的错误是“只写代码不看许可证”，因此需要在 CI 流程中设置卡点。

安全是漏洞与供应链风险层。安全团队维护 SBOM（软件物料清单），将组件版本与 CVE 数据库比对，输出漏洞等级和修复建议。安全与合规的交集在于：一个组件可能许可证合规但存在高危漏洞，也可能漏洞可控但许可证是强传染性的。两者需要共享同一份组件清单，避免各扫各的。

采购是外部引入的合同控制层。采购在签订软件采购、外包开发、云服务合同时，需要嵌入开源条款：要求供应商提供 SBOM、声明其产品中包含的开源组件及许可证、承诺不引入黑名单许可证、约定漏洞披露与修复时限。采购不判断许可证兼容性，但必须把法务给出的条款模板落到合同里。

二、协作机制：从“串行审批”到“并行卡点”

很多企业的合规流程是串行的：研发提交申请 → 法务审批 → 安全扫描 → 采购签合同。这种模式在组件数量少时可行，但当一个产品有 800 个依赖时，串行审批会成为瓶颈。更实际的做法是把合规动作嵌入研发流程，形成并行卡点。

具体机制可以设计为：研发在代码仓库提交依赖变更时，CI 自动调用 SCA（软件成分分析）工具生成组件清单；清单同时推送给法务（许可证判断）和安全（漏洞判断）；法务和安全在 1～2 个工作日内返回“通过/有条件通过/拒绝”；采购只在涉及外部供应商时介入。合规委员会只处理被标记为“例外”的条目。

为了让这套机制可运转，需要一份共享的“组件台账”。台账字段建议包括：组件名称、版本、许可证、引入项目、引入方式、是否修改、SBOM 来源、漏洞状态、审批状态、例外编号。这份台账由安全团队维护，法务和研发只读并更新各自字段。台账不是形式主义，它是后续审计、客户尽调、并购尽职调查时的核心证据。

三、关键接口与判断标准

角色之间最容易扯皮的地方，是“谁来判断许可证兼容性”和“谁来决定漏洞是否阻断发布”。建议用以下规则固化：

• 许可证兼容性由法务判断，但研发必须提供“是否修改、是否对外分发、是否动态链接”三个事实。缺少事实，法务只能退回申请。
• 漏洞阻断由安全判断，但阻断阈值由合规委员会批准。例如：CVSS ≥ 9.0 且存在公开利用代码，阻断发布；CVSS 7.0～8.9，允许带修复计划发布。
• 供应商条款由采购执行，但条款模板由法务提供。采购无权自行删减“供应商须提供 SBOM”这一条。
• 例外审批由合规委员会裁决，例外单必须包含：组件名、许可证、使用场景、风险描述、补偿措施、有效期。有效期建议不超过 6 个月，到期自动复审。

四、一个可运行的协作示例

假设某研发团队要在产品中引入 library-x 2.3.1，许可证为 LGPL-2.1，且团队修改了其中两个源文件。流程如下：

1. 研发在依赖变更 PR 中填写申请：组件名 library-x、版本 2.3.1、许可证 LGPL-2.1、引入方式为动态链接、已修改 2 个文件。
2. CI 触发 SCA 扫描，生成组件清单并写入共享台账，状态标记为“待法务/安全判断”。
3. 法务判断：LGPL-2.1 允许动态链接且不要求主程序开源，但修改部分必须以 LGPL 提供源码。结论为“有条件通过”，条件为：在发布包中提供修改后的 library-x 源码及许可证文本。
4. 安全判断：该版本存在 CVE-2024-XXXX，CVSS 6.5，无公开利用代码。结论为“通过，建议下个版本升级至 2.4.0”。
5. 研发按法务条件补充源码包，并在发布说明中记录。台账状态更新为“已批准”，漏洞字段保留“建议升级”。
6. 若该组件为外部供应商提供，采购同步要求供应商提供 SBOM 并确认其许可证声明与台账一致。

五、落地时的常见阻力与应对

实际推行中，最大的阻力往往来自研发：认为合规流程拖慢迭代。应对方式不是取消卡点，而是把卡点做“薄”：SCA 扫描自动化、许可证白名单内的组件自动放行、只有灰名单和黑名单才触发人工判断。另一个阻力来自采购：供应商不愿提供 SBOM。此时可以把 SBOM 作为付款条件之一，或在合同中约定“未提供 SBOM 的组件视为未授权使用”。合规委员会需要为这些条款提供背书，否则采购单独面对供应商时缺乏谈判筹码。

最后需要强调的是，组织设计不是画一张组织架构图就结束。真正决定合规体系能否运转的，是每个角色是否有明确的输入、输出和时限，以及当角色之间出现分歧时，是否有预设的升级路径。合规委员会的价值，正在于它是这条升级路径的终点，而不是起点。