开源许可证合规是什么
引入开源组件前要核对许可证类型与附带义务。宽松型（MIT、Apache-2.0、BSD）基本只要求保留版权与许可声明；弱传染型（LGPL、MPL）要求对修改过的那些文件按同许可开放；强传染型（GPL）要求衍生作品整体按 GPL 分发；AGPL 进一步把义务扩展到通过网络提供服务的情形——即使不发布二进制，只要用户通过网络使用也可能触发开源义务。分发场景与 SaaS 场景需要分别评估。
基本信息
| 宽松型 | MIT、Apache-2.0、BSD：保留版权与许可声明，可闭源分发 |
|---|---|
| 弱传染 | LGPL、MPL：通常限于被修改的文件或库层面 |
| 强传染 | GPL：分发衍生作品时需按 GPL 授权并给源码 |
| 网络触发 | AGPL：以网络服务形式提供也会触发开源义务 |
| 落地方式 | 依赖清单 + 许可证扫描进流水线，按版本留档 |
典型使用场景
- 技术选型评审：确认候选组件的许可证是否匹配产品的分发方式
- 流水线门禁：构建时自动生成依赖清单并阻断高危许可证
- 发布前检查：产品交付时随附许可证与版权声明文件
- SaaS 上线评审：识别 AGPL 与带商用限制的许可证
- 并购与客户审计：需要提供完整的第三方组件清单与 SBOM
- 存量治理：扫描历史项目，找出长期未处理的许可证风险
类型与义务
| 类型 | 代表许可证 | 主要义务 | 常见风险 |
|---|---|---|---|
| 宽松 | MIT、Apache-2.0、BSD | 保留版权与许可声明；Apache-2.0 另含专利授权条款 | 漏附声明文件，形式合规问题 |
| 弱传染 | LGPL、MPL | 修改过的文件需按同许可开源 | 静态链接或改动后未开放对应文件 |
| 强传染 | GPL | 衍生作品需按 GPL 分发并提供源码 | 闭源产品误用，需整体开源或替换 |
| 网络传染 | AGPL | 提供网络服务也可能触发开源义务 | SaaS 场景未评估，事后被迫替换 |
| 非标准限制 | 带商用限制、禁止商用条款 | 需逐条阅读许可条款 | 条款非 OSI 标准，容易被忽略 |
合规检查清单
合规检查清单
# 1 依赖清单：直接依赖与传递依赖都要覆盖，按版本记录
# 2 许可证识别：优先读组件仓库的 LICENSE 文件，不只看元数据字段
# 3 义务匹配：按产品分发方式判断（二进制分发 / 网络服务 / 内部使用）
# 4 门禁策略：高危许可证在流水线阻断，例外需书面审批
# 5 交付物：随发布附带第三方声明文件；客户审计时提供 SBOM
# 6 存量复查：升级或新增依赖时重新扫描，避免义务状态变化未被发现同样的组件在不同使用方式下结论可能不同：LGPL 库动态链接与修改源码的后果差别很大，判断前先确认链接方式和是否改动过源码。
许可证合规属于法律问题：扫描工具只能给出线索，涉及 AGPL、双许可与商用限制时应当交由法务确认，不要凭经验下结论。