4000-989-866 010-80885651 info@bcac.com.cn 周一至周五 9:00–18:00
代理记账经营许可 · 持证中介协同执业 微信客服
首页 / 知识产权 / 开源协议的合规风险:GPL、MIT、Apache 的差异
实务指南Insight

开源协议的合规风险:GPL、MIT、Apache 的差异

知识产权 作者:诚立集团 · 知识产权研究组 全文阅读

几乎所有的软件都用了开源代码。用开源不是问题,问题是不知道自己用了什么、承担了什么义务。

开源协议不是“免费使用”,而是一份附条件的许可合同。条件不履行,就是侵权。

一、四类主流协议

MIT / BSD(宽松型)

  • 义务:保留版权声明与许可声明;
  • 不要求开源衍生作品;
  • 可用于商业闭源产品,风险最低。

Apache 2.0(宽松型 + 专利条款)

  • 义务:保留版权与许可声明、NOTICE 文件;修改过的文件需注明;
  • 含专利授权条款:贡献者授予使用者专利许可,但使用者若发起专利诉讼,许可终止;
  • 可用于商业闭源产品,但需注意专利报复条款。

LGPL(弱传染型)

  • 义务:动态链接使用 LGPL 库的,可以闭源;但修改 LGPL 库本身的,修改部分需开源;
  • 需提供替换库的方式(如动态链接);
  • 静态链接 LGPL 库的,可能被要求开源整个程序(争议较大,实践中避免)。

GPL(强传染型)

  • 义务:分发基于 GPL 代码的衍生作品,整个作品必须以 GPL 开源;
  • “衍生作品”的边界是关键:链接、集成、代码混用,通常认定为衍生;
  • 内部使用不分发的,不需开源(但 SaaS 场景下的 AGPL 除外)。

二、传染性的边界

判断是否构成衍生作品,实务中看三点:

  • 结合方式:代码混用、静态链接、同一进程内调用,通常构成衍生;通过命令行调用、进程间通信(IPC)、网络接口调用,通常不构成。
  • 依赖程度:是否依赖 GPL 库的数据结构与函数签名,是否必须与 GPL 库一起编译。
  • 分发方式:只在内部使用不分发的,GPL 义务不触发(AGPL 除外,网络提供服务也算分发)。

这个边界在司法实践中并不完全清晰,企业应采取保守策略。

三、一个 GPL 引发召回的案例

某智能硬件企业的产品固件中集成了一段 GPL v2 协议下的开源代码(用于文件系统管理)。企业不知情,产品上市销售 8 万台。

被开源社区发现后,权利人(该开源项目的版权持有人)发出律师函,要求:

  • 公开整个固件的源代码(因构成衍生作品);
  • 或停止分发该产品。

企业无法接受公开固件(含自研的算法与控制逻辑),也无法在短期内替换该组件。

结果:

  • 与权利人和解,支付和解金 120 万元;
  • 召回已售产品中的 3.2 万台,通过 OTA 升级替换固件,成本约 260 万元;
  • 未召回部分提供开源承诺,公开了部分代码(经技术处理剥离自研算法,但仍暴露了架构设计);
  • 整体损失约 500 万元,另有 4 个月的上市延迟。

根因:研发团队引入开源组件时,没有做许可审查,也没有建立组件清单。

四、企业合规流程

  • 准入审查:引入任何开源组件前,登记名称、版本、协议、来源、用途。
  • 协议分类:把组件按协议分为“可闭源使用(MIT/BSD/Apache)”“需谨慎(LGPL)”“禁止用于闭源产品(GPL/AGPL)”。
  • 使用方式审查:确认是链接、调用还是代码混用,判断是否触发传染。
  • 义务履行:保留版权声明、提供 LICENSE 文件、公开修改部分(如适用)。
  • SBOM 管理:建立软件物料清单,记录每个组件的协议与版本,便于追溯。
  • 定期扫描:用工具扫描代码库,识别协议冲突与已知漏洞。

五、常见误区

  • “开源就是免费,随便用”——协议有条件,违反即侵权。
  • “我们没分发,只是在云上跑”——AGPL 下,网络提供服务也可能触发开源义务。
  • “改了就不是原来那个了”——修改后的版本仍受原协议约束。
  • “只要不声明就没人知道”——代码扫描工具已经非常成熟,被发现的概率很高。
  • “用 MIT 的最安全”——MIT 也要求保留版权声明,删掉声明同样违约。

六、操作清单

  • 建立开源组件登记制度,引入前审查协议;
  • 维护 SBOM(软件物料清单);
  • GPL/AGPL 组件禁止用于闭源产品,或隔离为独立进程;
  • LGPL 组件用动态链接,避免静态链接;
  • 保留所有版权声明与 LICENSE 文件;
  • 修改开源代码的,记录修改内容;
  • 对外分发时附开源声明与源码获取方式;
  • 定期用工具扫描代码库;
  • 收购/被收购时做开源合规尽调;
  • 建立开源合规责任人制度。

开源是别人给的“有条件礼物”。条件写在协议里,不看协议就用,等于闭着眼睛签字。

七、常见问题

以下问题取自客户咨询中出现频率最高的几处,答案与正文相应章节对应,可结合自身情形对照使用。

问:GPL、MIT、Apache 三种协议差在哪?

答:GPL 具有传染性,衍生作品需以 GPL 开源;MIT 最宽松,只需保留版权与许可声明;Apache 2.0 同样宽松,但包含专利授权与商标限制条款,修改文件需作说明。

问:商用时要重点检查什么?

答:建立开源组件清单,逐项核对许可证类型与义务;避免 GPL、AGPL 代码进入闭源产品;保留许可证与版权声明;关注 AGPL 的网络使用触发条款,SaaS 场景尤其容易踩线。

问:违反开源协议会有什么后果?

答:构成著作权侵权,可能被要求停止分发、公开源代码并赔偿损失;在并购或融资尽调中发现开源合规问题,会直接影响交易估值,甚至导致交易终止。

本文由诚立集团专业团队编写,仅供一般性参考,具体事项请结合企业实际情况咨询。 需要针对性建议?联系我们 →

这份流程落到你的企业,需要改哪几处?

说明行业、规模与当前节点,我们会指出可执行的先后次序、哪些环节能并行,以及大致的费用区间。

客服电话 4000-989-866 北京总部 010-80885651
在线咨询
诚立集团微信客服二维码