开源合规管理是什么
开源合规检查引入的开源组件许可（MIT、Apache-2.0、GPL 等）与随之而来的义务：保留版权与许可声明、满足传染性条款、规避公司禁用的许可类型。做法是用工具生成依赖清单（SBOM），并在流水线设置门禁，让引入行为在合并前就被审查。
怎么落地
先建许可分级策略：宽松型（MIT、Apache-2.0、BSD）通常可商用，只需保留声明；传染型（GPL、AGPL）需评估分发与网络服务场景带来的义务；未知许可与明文禁止项直接暂缓引入。SBOM 要随发布更新，而不是审计前临时生成，否则依赖变化后清单早已失真。
基本信息
| 检查项 | 许可证类型、版权声明、传染性义务、已知漏洞 |
|---|---|
| 工具 | 依赖清单生成、许可扫描、SBOM 实践 |
| 门禁 | 高风险或未知许可阻止合并与发布 |
| 记录 | 扫描结果与例外审批留档，供审计追溯 |
典型使用场景
- 新增依赖评审：引入前扫描许可与漏洞情况
- 版本发布前：生成 SBOM 并归档本次依赖构成
- 对外交付或私有化部署：确认分发场景下的义务
- 并购或投资尽调：梳理代码库中的开源构成
- 收到合规质询函：快速定位涉事组件与引入时间
- 漏洞应急：按 SBOM 反查受影响的产品与版本
许可应对示例
许可应对示例
MIT / Apache-2.0 / BSD：保留版权与许可声明即可
Apache-2.0 注意：附带专利授权条款，修改文件需标注
GPL / AGPL：评估分发与网络服务义务，必要时隔离或替换
未知或许可冲突：暂停引入，先由法务确认 # 不猜
# 流水线门禁：高危漏洞或许可命中禁用清单 → 阻断合并许可类型与关注点
| 类型 | 常见许可 | 主要关注点 |
|---|---|---|
| 宽松型 | MIT、BSD、Apache-2.0 | 保留声明；Apache-2.0 含专利条款 |
| 弱传染 | LGPL | 动态链接场景义务较松，仍需评估 |
| 强传染 | GPL、AGPL | 分发或网络服务可能触发开源义务 |
| 不明 | 无声明或自拟条款 | 默认按高风险处理，先确认再引入 |
合规检查要与依赖升级流程绑定：只做一次扫描的清单会在下一次依赖升级后失效，自动化的持续扫描比人工审查更可靠。