一、核心基础认知：开源≠无版权、免费≠随便用
所有开源代码受著作权法保护，作者保留版权；开源只是作者授予有限使用许可，不是放弃版权。
不存在 “开源就可以闭源售卖、抹去作者信息、二次分发不公开代码”，不同开源协议约束天差地别。
区分两个概念：
使用权：绝大多数开源协议允许免费商用、修改；
分发义务：一旦对外交付程序（售卖、打包交付客户、公网下载），部分协议强制要求公开修改后的源码。
二、主流开源协议分级与版权约束（最关键）
1. 强传染型（Copyleft，高风险，极易踩坑）
（1）GPLv1/v2/v3（Linux、GCC、FFmpeg）
核心传染规则：
只要程序静态 / 动态链接 GPL 代码，整体软件全部强制采用 GPL 协议开源；
对外分发（售卖、给客户、上传下载）时，必须完整提供全部源代码（自研代码 + 修改的开源代码）；
禁止修改、删除原代码版权声明、作者署名；
GPLv3 新增：禁止硬件锁死（Tivoization），不能用 GPL 代码做加密不可修改的硬件固件。
风险场景：商用闭源软件内嵌 FFmpeg、直接链接 GPL 库，未开源全部自研代码，构成侵权。
（2）LGPL（弱 GPL，Qt 默认协议）
动态链接（独立 so/dll）：自研代码无需开源，仅需提供 LGPL 库修改源码、标注版权；
静态链接：整个程序触发 GPL 传染，必须完整开源；
分发时必须保留原协议文本、版权信息，说明对库的修改点。
2. 宽松型（Permissive，商用友好，低约束）
MIT、Apache 2.0、BSD（2 条款 / 3 条款），企业商用首选
通用宽松规则：
允许修改、闭源、商用、售卖、二次分发，无需公开自研代码；
强制义务仅 3 条：
保留原始代码中的版权声明、作者署名；
附带原始开源协议文本；
不得用作者商标 / 名称做商业宣传（BSD3/Apache 特有）。
协议细微差异（容易忽略）
Apache 2.0：额外包含专利授权，贡献代码者自动授予使用者相关专利许可；同时明确修改文件必须标注修改记录；
BSD 3-clause：禁止借用原作者名称做产品背书；BSD 2-clause 无此限制；
MIT：最简协议，无专利、无商标约束，仅保留版权声明即可。
3. 特殊限制性协议（慎用，商用限制多）
AGPLv3（网络传染，SaaS 最大坑）
GPL 仅分发触发开源，AGPL 只要通过网络对外提供服务（SaaS 网站、接口平台），就必须公开全部源码；
哪怕不打包交付客户，只是线上给用户使用，也要开源自研代码；
常见项目：MongoDB 旧版、Nextcloud、很多开源后台管理系统。
商业友好限制协议：Mozilla MPL2.0
文件级传染：仅修改的 MPL 源码文件需要开源，自研独立文件不受约束；介于宽松协议和 GPL 中间。
三、使用开源代码全场景版权合规要点
场景 1：仅内部使用，不分发、不上线对外服务
内部办公、内网系统、测试项目，不对外交付 / 访问：几乎无强制开源义务；
底线：代码内部留存原始版权注释，不得删除作者信息。
场景 2：商用闭源软件（客户端、桌面程序、嵌入式固件）
严禁静态链接 GPL 库；LGPL 库尽量动态链接；
使用 AGPL 项目：如果软件联网对外提供功能，必须整体开源；
MIT/Apache/BSD 库可放心闭源售卖，但程序文档、关于页面、源码头部必须标注开源组件清单、版权、协议文本；
嵌入式设备（路由器、智能硬件）使用 GPL：客户索要源码时必须提供。
场景 3：SaaS 线上服务（网站、API 平台、云系统）
最大雷区：AGPL
只要引入 AGPL 组件，所有线上服务代码必须开源；
GPL 无网络传染，单纯后端链接 GPL 库做 SaaS，无需开源自研代码（仅分发打包才触发）；
Apache/MIT 无任何线上开源要求。
场景 4：二次分发开源代码（修改后上传 Github、打包给客户）
强 Copyleft（GPL/AGPL/LGPL 静态链接）：完整开源所有关联代码；
宽松协议：仅需保留原版权，可搭配私有闭源代码；
所有场景：分发包中必须附带对应协议文件（LICENSE）。
场景 5：修改开源代码后自用 / 分发
任何协议都禁止删除、涂改原始版权注释、作者名字；
Apache 2.0、MPL 要求：修改的文件头部增加修改记录（修改人、时间、改动内容）；
GPL/AGPL 修改后的源码必须完整对外提供（分发 / 线上服务场景）。
四、高频侵权红线（绝对不能做）
抹去版权信息：删除代码头部 @copyright、作者、LICENSE 注释；
混淆协议传染规则：闭源商用软件静态链接 GPL/AGPL 库；SaaS 使用 AGPL 但不公开源码；
专利风险（Apache 2.0 反向坑）：修改 Apache 项目后，起诉原项目贡献者专利侵权，协议自动终止授权；
商用宣传冒用作者名义：使用 BSD3/Apache 组件，对外宣称 “原作者认证、联合开发”；
不提供协议文本：软件安装包、文档中不附带开源组件对应的 LICENSE 文件；
拆分代码规避传染：通过进程间调用、RPC 拆分程序，试图规避 GPL/AGPL 传染，司法判例中已认定无效。
五、企业落地合规实操规范（可直接执行）
1. 引入前：开源组件准入审查
建立组件白名单：优先 MIT/Apache 2.0/BSD；限制 GPL/LGPL；禁止商用 SaaS 直接引入 AGPL；
明确区分依赖类型：静态链接 / 动态链接 / 仅 API 调用 / 前端纯静态资源；
排查组件嵌套依赖：很多 MIT 项目内部依赖 GPL 子库，会间接触发传染。
2. 开发阶段：代码标注规范
所有引入的开源文件保留原始头部版权注释，禁止清理；
新建第三方依赖清单（OPEN_SOURCE_LICENSE.md），记录：组件名称、版本、仓库地址、协议类型、修改记录；
Apache 协议修改文件，头部添加修改日志。
3. 发布上线阶段：对外合规披露
客户端 / 桌面软件：「关于我们」页面展示开源组件清单与完整协议文本；
Web/SaaS 系统：后台、登录页底部增加开源许可说明链接；
交付客户的安装包、固件：附带 LICENSE 文件夹，存放所有开源协议文件；
若使用 GPL/LGPL 组件，提前准备好完整源码包，客户索要时 7 日内提供。
4. 风险兜底方案
高风险组件（GPL、AGPL）采用独立微服务 / 独立进程部署，仅通过 HTTP/RPC 通信，降低传染范围；
若无法规避 AGPL，两种选择：①整体项目开源；②替换为 MIT/Apache 同类组件；
定期开源依赖扫描（工具：FOSSA、BlackDuck、license-checker），自动识别协议冲突、隐藏 GPL 依赖。
六、补充特殊版权问题
开源代码中的第三方素材：代码内附带图片、字体、图标、音视频，这些素材可能有独立版权（CC、付费字体），不能随代码商用；
商标与版权分离：开源协议只约束著作权，项目名称、Logo、品牌商标仍归原作者，未经许可不能用作自有产品商标；
衍生作品界定：基于开源代码二次开发、封装、插件、扩展，法律上均属于衍生作品，受原开源协议约束；
国内法律依据：《著作权法》《计算机软件保护条例》，开源许可属于著作权许可合同，具备法律效力，违规可被起诉要求停止使用、赔偿损失。