1. 课程导入与合规地图

开源早已不是“要不要用”的问题，而是“怎么用才安全、怎么发布才合规”的问题。现代企业研发中，一个普通后端服务可能直接或间接依赖数百个开源组件，前端工程动辄上千个 npm 包，容器镜像里还叠加了基础镜像、系统库和运行时。开源带来的效率提升是真实的，但风险也是真实的：许可证冲突、版权归属不清、专利与商标争议、安全漏洞、出口管制、供应链投毒，任何一项都可能在产品发布、融资尽调、客户审计或并购交割时集中爆发。

本课程的核心目标，是帮助研发、法务、安全、产品与开源办公室（OSPO）建立一张可落地的“合规地图”：从引入、修改、分发到对外开源，每个阶段有哪些动作、由谁负责、产出什么证据、在什么条件下可以放行。合规不是发布前的一次性检查，而是贯穿需求、编码、构建、测试、发布、运维的持续过程。

一、先建立全生命周期视角

很多团队把开源合规等同于“扫一遍许可证”，这远远不够。更合理的做法是按软件生命周期划分阶段，并明确每个阶段的输入、动作、输出与判断标准。下图给出了一张贯穿研发全流程的开源合规地图，它把“使用侧”和“发布侧”两条主线放在同一张图上，便于团队对照定位自己当前所处的环节。

二、四个关键判断点

地图画出来之后，真正决定合规成败的是四个判断点。第一，许可证识别。不能只看组件首页写的“MIT”，要确认实际代码文件头、LICENSE 文件、包元数据是否一致。有些项目采用多许可证，有些核心模块与周边工具许可不同，还有些项目从 GPL 切换到 Apache 但历史版本仍受 GPL 约束。第二，使用方式判断。同样是 GPL 组件，内部自用、SaaS 提供服务、随产品分发二进制，三种场景的义务完全不同。第三，修改与衍生判断。修改了 GPL 代码并通过网络提供服务，是否触发 AGPL 的源码提供义务，需要结合具体许可证版本和部署方式分析。第四，出站许可选择。企业对外开源时，如果代码中混入了 GPL 或 AGPL 组件，出站许可就不能随意选择 MIT 或 Apache-2.0，否则会形成许可冲突。

三、从“事后救火”到“事前拦截”

很多企业的开源合规是“发布前突击”：法务拿扫描报告逐条看，研发临时替换组件，发布窗口被迫推迟。更成熟的做法是把合规动作嵌入研发流程。例如在包管理器中配置私有代理仓库，只允许白名单许可证的组件被拉取；在 CI 流水线中集成 SBOM 生成与许可证扫描，对高风险许可证自动告警；在代码评审模板中增加“是否引入新开源组件”的检查项；在发布清单中固定“LICENSE/NOTICE 文件是否随包提供”的确认项。

下面给出一个可直接参考的引入阶段检查表示例，字段和判断标准可根据企业实际策略调整。表中“允许”指可直接引入，“需审批”指经 OSPO 或法务评估后引入，“禁止”指不得引入或必须替换。

四、合规地图怎么用

这张地图不是挂在墙上的装饰，而是团队协作的共同语言。研发看到“引入”阶段，就知道选型时要查许可证；测试看到“集成”阶段，就知道构建产物要生成 SBOM；产品看到“分发”阶段，就知道交付包里必须带 LICENSE 和 NOTICE；法务看到“对外开源”阶段，就知道要先确权再选许可证。每个角色只需要关注与自己相关的节点，但所有人都知道上下游在做什么、证据在哪里、风险从哪里来。

接下来的章节会沿着这张地图逐段展开：如何识别许可证、如何生成和解读 SBOM、如何处理许可证冲突、如何履行声明与源码义务、如何建立对外开源的审批与发布流程、如何应对审计与尽调。本章的任务是先把全局框架建立起来，知道风险在哪里、动作在哪里、证据在哪里。只要这张地图清晰，后续每个环节的具体操作就有了明确的落点。