1. 课程导入与风险全景
开源软件已经成为现代软件供应链的基础设施。一个看似普通的业务系统，往往在编译期、运行期、构建期和部署期同时引入数百甚至上千个开源组件。问题在于，“开源”并不等于“无约束”。绝大多数开源项目都附带许可证，许可证规定了使用者必须履行的义务；一旦这些义务没有被满足，企业就可能从“合法使用者”变成“违规使用者”。本课程讨论的，正是这种违规发生之后，如何识别、评估、处置并闭环。
一、什么是“开源软件违规使用”
开源软件违规使用，通常指企业在引入、修改、分发或对外提供服务的过程中，未遵守所使用开源组件许可证条款的行为。它不一定表现为“盗版”，更多时候表现为“义务未履行”。例如：
- 使用了 GPL 类强著佐权（Copyleft）组件，却将整个衍生作品以闭源方式分发；
- 使用了 MIT、Apache-2.0 等宽松许可证组件，但未保留版权声明和许可证文本；
- 将 AGPL 组件用于网络服务，却未向用户提供对应源代码；
- 在商业产品中嵌入了带有额外限制条款的组件，未做合规审查；
- 使用了来源不明、许可证缺失或声明冲突的组件，无法证明其可被合法使用。
这些行为的共同点是：组件本身可能来自公开仓库，但使用方式与许可证要求不匹配。违规的判定依据不是“是否付费”，而是“是否履行了许可证规定的义务”。
二、典型场景：违规通常从哪里发生
从工程实践看，违规使用很少是单一环节造成的，它往往沿着软件供应链逐层累积。下面这张图展示了从组件引入到对外分发的主要路径，以及每条路径上最容易出现的违规触发点。
三、风险类型：从许可证到供应链
开源违规风险并不只有“许可证不合规”一种。实际处置中，通常需要同时关注以下几类风险：
| 风险类型 | 典型表现 | 处置关注点 |
|---|---|---|
| 许可证合规风险 | GPL/AGPL 义务未履行、宽松许可证声明丢失 | 义务识别、源码提供、声明保留 |
| 知识产权风险 | 组件来源不明、版权归属不清、专利条款缺失 | 来源追溯、权利链验证 |
| 供应链安全风险 | 组件被篡改、依赖投毒、版本劫持 | 完整性校验、SBOM 比对 |
| 商业条款冲突 | 开源组件与商业授权、客户合同条款冲突 | 合同审查、替代方案评估 |
| 声誉与客户信任风险 | 被客户审计发现、公开质疑、媒体曝光 | 沟通策略、整改证明 |
这些风险之间会相互放大。例如，一个来源不明的 GPL 组件，既带来许可证合规风险，也可能带来知识产权和供应链安全风险。因此，处置时不能只看单一维度，而应建立“组件—许可证—义务—风险—动作”的关联视图。
四、处置目标：不是“消灭开源”，而是“可控使用”
本课程的处置目标可以概括为四句话：
- 看得见：知道产品里用了哪些开源组件、什么版本、从哪来。
- 说得清：能说明每个组件的许可证、义务和当前履行状态。
- 控得住：对高风险组件有替代、隔离、开源或授权等处置手段。
- 证得了：有记录、有证据、有流程，能应对客户审计或法律质询。
这四项目标对应的是从“被动救火”转向“主动治理”。处置动作可能包括：替换组件、调整链接方式、补充许可证声明、开放相应源码、获取商业授权、与客户沟通说明等。选择哪种动作，取决于许可证类型、分发方式、修改程度和业务影响。
五、课程路线图：从识别到闭环
后续章节将按照“识别—评估—处置—验证—固化”的主线展开。具体包括：开源许可证基础与义务判断、组件清单与 SBOM 构建、静态与动态链接的合规差异、GPL/AGPL 场景处置、宽松许可证声明修复、商业授权与替代方案、客户审计应对、内部流程与工具链建设等。每一章都会围绕真实可操作的对象、参数和判断依据展开，而不是停留在概念层面。
本章建立了风险全景和处置目标。接下来，我们将从最基础也最关键的一步开始：如何识别一个开源组件到底附带什么许可证，以及它要求你做什么。