分为制度管理、开发准入、技术隔离、交付合规、审计举证、人员管控六大模块，覆盖个人 / 中小企业 / 大厂全场景，可直接落地执行。
一、先建立内部制度：从源头管住风险（治本）
1. 制定《开源软件使用管理规范》，分级管控协议
把开源协议分成三类，明确使用权限、审批流程：
- 低风险（白名单，可直接引入）
MIT、BSD-2、Apache 2.0、CC0
要求：保留版权、LICENSE、NOTICE 文件，修改做好记录。 - 中风险（灰名单，架构 + 法务审批）
LGPL、MPL 2.0
重点核查：是否静态链接、是否修改库源码、是否对外分发。 - 高风险（黑名单，商业闭源产品禁止直接引入）
GPLv2/v3、AGPLv3、SSPL、BSL、自定义限制协议- 闭源客户端、硬件固件、售卖软件：严禁静态链接；
- SaaS 云服务：严禁直接引入 AGPL；
- 确需使用必须走专项法务评估，做技术隔离。
2. 设立开源合规评审小组（OSRB）
成员：研发架构、法务、安全、产品
流程：新增开源组件必须提交申请表，写明：组件名称、版本、协议、使用方式（静态 / 动态链接 / 独立服务）、是否对外分发、是否修改源码，审批通过才能入库。
3. 区分两大使用场景，规则完全分开
- 内部自用（不分发、不上线 SaaS）：约束宽松，仅留存清单即可；
- 对外交付（APP、固件、安装包、云 SaaS、售卖软件）：严格执行全部协议义务，传染类协议强制隔离。
二、开发准入：引入前拦截 80% 侵权隐患
1. 严禁 3 种高危取码行为
- 直接复制 GitHub 无 LICENSE 仓库代码（无协议 = 著作权完全保留，商用即侵权）；
- 复制论坛、博客、Gist 片段不标注来源；
- 员工私自带公司闭源代码开源，或私自 fork 开源项目并入商业产品。
2. 引入前强制扫描全依赖树（含传递依赖）
自动化 SCA 工具嵌入 CI/CD 流水线，提交代码、打包构建时自动阻断高风险协议：
- 商用工具：Snyk、FOSSA、BlackDuck；
- 开源免费：OWASP Dependency-Check、LicenseFinder；
检测目标：直接依赖、深层子依赖，避免表层 MIT、底层 GPL 隐形传染。
3. 协议兼容校验，禁止冲突组合
核心兼容红线：
- GPL/AGPL 无法和闭源自有代码共存分发；
- Apache2.0 不能并入 MIT（专利条款冲突）；
- GPLv2 与 Apache2.0 互不兼容；
- 多协议混合分发，整体遵循最严格协议。
冲突处理方案：更换替代组件、拆分服务隔离、自研替代。
三、技术隔离：必须使用 GPL/AGPL 时，阻断 “传染”
若业务刚需高风险协议组件，用架构隔离避免自有代码被强制开源，分两级隔离方案：
1. 强隔离（适配 GPLv2/v3、AGPL，推荐）
将开源组件拆为独立进程 / 微服务，通过网络 HTTP/RPC/IPC 通信，禁止代码层链接：
- 自有业务代码与 GPL 代码分仓库、分服务部署；
- 二进制分离，不打包合并为单一程序；
- 硬件设备：GPL 程序独立固件，主系统通过接口调用。
2. 弱隔离（仅适配 LGPL）
- 仅动态链接（dll/so），不静态编译打包；
- 若修改 LGPL 库源码，单独开源修改部分，主程序保持闭源；
- 分发时提供目标文件，允许用户自行替换 LGPL 库。
3. 前端特殊避坑
前端打包分发 SPA 应用，若引入 GPL 组件，打包后整体视为衍生作品，优先替换为 MIT/Apache 组件。
四、编码与修改：严格履行协议义务（最容易踩坑）
1. 所有开源文件完整保留头部版权声明
禁止删除、遮挡、修改原作者版权、LICENSE 文本；
Apache2.0 项目额外保留 NOTICE 文件。
2. 修改代码必须留存变更记录
- Apache2.0 强制要求：改动文件添加修改日志（修改人、时间、变更内容）；
- GPL/LGPL：修改部分标注清晰，留存修改补丁。
3. 不擅自改写开源协议条款
不能自行删除专利、禁止商用、署名等限制，私自修改协议属于违约，授权直接失效。
4. BSD-3 条款额外约束
产品宣传、官网文案，不得使用原作者、机构名称做营销，避免不正当竞争纠纷。
五、产品发布 / 交付：对外分发完整合规流程
1. 生成 SBOM 软件物料清单（核心自证证据）
每版产品输出完整清单，包含：
组件名称、版本、仓库地址、开源协议、使用方式、是否修改、LICENSE 文件副本；
交付给客户、固件、APP 安装包时随包附带。
2. 履行源码提供义务
- GPL/LGPL 分发二进制包：向客户提供索取源码的渠道、存放地址；
- AGPL 云 SaaS：对外服务时，官网提供完整源码下载入口；
- 留存客户索取源码的沟通记录，作为合规证据。
3. 产品内置开源声明页面
APP、后台管理、硬件界面增加「开源许可说明」页面，展示全部组件版权与协议文本，满足司法举证要求。
六、定期审计 + 证据留存：应对诉讼、监管、IPO
1. 常态化三级审计
- 提交审计：CI 自动扫描，阻断高风险依赖；
- 版本上线审计：发版前人工复核 SBOM 清单；
- 季度全面审计：全仓库扫描，清理过期、违规组件，更新替代方案。
2. 完整证据链永久存档（诉讼关键）
- 开源组件审批单、扫描报告、协议文本；
- 代码修改记录、补丁文件；
- 产品开源声明、源码分发记录；
- 法务评审意见、隔离架构设计文档；
全部文件云端归档，至少保存 5 年。
3. 风险预案
提前储备高风险组件替代库，一旦合规冲突可快速替换，避免产品下架、停产损失。
七、专利、员工、跨境附加风险防控
1. 专利风险规避
- 商用产品优先 Apache2.0，自带专利豁免；
- MIT/BSD 无专利授权，采购第三方专利保险，避免专利诉讼；
- 禁止使用 Apache 代码后起诉原项目专利，否则丧失全部开源授权。
2. 员工行为管控
- 入职签署知识产权协议，禁止私自搬运开源 / 公司代码；
- 员工对外开源贡献前，法务审查代码脱敏，防止泄露自有业务代码；
- 定期开展开源合规培训，明确开发红线。
3. 出海跨境合规
- 欧美市场对 GPL 合规审查极严，硬件设备违规会被海关扣押；
- 开源代码涉及加密、AI、军工技术，同步核查出口管制；
- 不同国家著作权法对 “衍生作品” 认定不同，海外产品提前做当地法务评估。
八、极简落地自查清单（发版前逐项核对）
- 所有开源组件完成 SCA 扫描，无 GPL/AGPL 直接链接自有闭源代码；
- 无 LICENSE 的代码全部清理、替换；
- 所有源码文件完整保留原始版权与 LICENSE；
- 修改代码留存变更日志，Apache 项目保留 NOTICE；
- 生成完整 SBOM 物料清单，随产品交付；
- 高风险组件已做服务 / 进程隔离；
- 具备源码对外提供渠道，留存索取记录；
- 全套审批、扫描、评审文档归档留存。