开源合规通关秘籍(一)|深度解析互惠型许可证的合规之道

 

 

开源软件(oss)许可证是数字时代协作创新的法律基石,其核心在于通过明确的权利与义务框架,既保障开发者对知识成果的归属权,又为全球开发者提供自由使用、修改与分发的通行证。
现如今普遍使用的“互惠型/著作权型”(copyleft)许可证为GNU通用公共许可证,通常简称为GPL。它是由自由软件基金会(FSF)创建的开源协议,为了确保GNU软件的自由性、防止闭源,1989年发布了第一版GPL许可证。

 

1.互惠型许可证

互惠型许可证通常要求对任何修改后的源代码必须向他人开放,允许二次修改和再分发;同时强制规定衍生作品必须采用与原作相同的许可条款进行发布,其核心原则为衍生作品必须以相同许可证开源,即“使用开源代码后,你的改进也需回馈给开源社区”,这类许可证旨在通过技术共享和社区协作推动开源生态的发展。

互惠型许可证最常见的为GPL许可证、AGPL许可证、SSPL许可证等,与弱互惠型许可证的核心区别在于互惠型许可证约束整个程序,而弱互惠型许可证则允许开发者在原程序中添加库或插件时,保留修改代码的私有性。

1.1 典型互惠型许可证核心条款比较

以上三种互惠型许可证的特点、核心条款及相关案例如下表:

1.2 GPL-2.0——经典Copyleft许可的奠基者

主要条款

1.复制和分发未修改的程序版本
🔹保留原始版权声明
🔹附许可证原文
🔹保留软件免责声明
2.修改程序和分发修改程序
🔹修改后的程序版本必须以同样的许可条件进行分发
🔹所有修改版本必须做出标记,指明修改内容、修改日期和修改人身份
🔹如果修改后的程序是在运行时和用户交互式读取命令,且原程序在运行前显示或打印出所有版权声明、维保免责声明、修改标记和许可文本链接,那么修改后的程序也需要显示这些信息
🔹如果编写了隔离且独立的作品,该作品是单独分发的,或者仅与GPL软件放于同一分发介质(例如U盘、光盘等)上,则作品不用遵循GPL许可
🔹如果作品与GPL代码组合为一个新的“基于软件的作品”,或该作品并非独立而是必须与GPL代码组合才能执行时,那么作品需要遵循GPL许可
3.以目标码形式复制和分发经过修改或未修改的程序
🔹如果在网上分发GPL程序的可执行版本,则需在同一位置提供其完整对应源码
🔹如果通过物理介质分发,则需在同一介质或者DVD或USB存储卡等介质随附该程序分发
🔹也可附书面要约表示愿意提供完整对应源码的声明,其有效期应至少为3年
4.私下使用和修改代码

如果不打算将修改后的软件分发给其他人,则重新编写代码并闭源自行使用。

5.其他情况

如果与许可证要求相冲突,只能选择放弃发布该程序或基于该程序的作品,除非版权持有人授予附加许可。

适用项目

🔹确保软件及衍生品保持开源的项目
🔹不需要复杂专利保护或网络服务条款的项目
🔹需兼容旧项目或避免专利条款约束的项目
🔹常用于传统软件或嵌入式系统

优缺点

优点:广泛使用的copyleft许可证,简单直接,有大量法律实践供参考。
缺点:未明确提及专利条款,存在专利封锁风险,与其它许可证兼容性较差(如Apache-2.0)。

相关案例

案例一2

华为公司自行研发的“OpenHarmony”开源项目存在开发者针对软件独立性的特别说明。“OpenHarmony”中包含一个名为“third_party_mtd_utils”的开源软件,该软件适用GPLv2,“OpenHarmony”的开发者对该开源软件进行了如下说明:“third_party_mtd_utils用于编译生成jffs2文件系统镜像的打包工具,该工具用于打包jffs2格式的rootfs和userfs镜像,代码不会编译打包到kernel_liteos_a内核中,故kernel_liteos_a内核不受GPL影响”。

案例要点:GPL组件作为打包工具、语言、容器、载体等不会被其传染。
 
案例二3

原告不乱买公司发现被告闪亮公司网站设计、布局及源代码均与其网站相同。闪亮公司提出抗辩称不乱买公司网站使用了GPL-2.0下的开源代码,不乱买公司无权对其网站整个软件著作权等相关版权主张权利。原告明确主张虽在前端代码中使用了开源代码,但其后端程序并非前端程序的衍生品或修订版本,故GPL许可协议对于后端程序并无约束力。最终法院认定被告闪亮公司行为侵犯了闪亮公司的著作权,并判令其立即停止侵权行为,公开致歉,并赔偿经济损失。

案例要点:私有代码若独立于GPL下的代码(如该案例中的前端代码与后端代码),则这部分不会被传染,开发者仍享有独立著作权。
 
案例三4

未来公司声称其享有“未来网上投标文件制作工具软件”的计算机软件著作权,并指控云蜻蜓公司的“南京工程版投标工具”未经许可使用了其软件的源代码,尤其是主程序部分,违反了GPL-2.0协议的开源要求。

法院经审理认为,未来公司软件的主程序部分包含了基于GPL-2.0协议的第三方开源代码,但未遵守开源协议的要求进行公开,因此不享有对该部分的著作权保护。然而,预览程序部分未受GPL协议的影响,法院认定云蜻蜓公司在该部分构成侵权,最终判决云蜻蜓公司停止侵权并赔偿原告经济损失。

案例要点:使用GPL-2.0协议的开源软件时,必须严格遵守协议的开源要求,否则将失去对该软件部分的著作权保护。
 
案例四5

网经公司基于GPL-2.0许可下的OpenWRT项目开发了OfficeTen软件,亿邦和启奥公司通过非法手段获取并修改了该软件代码。网经公司称OfficeTen底层系统和上层软件建立了隔离层,且被告的软件相似率高达90%,法院认定被告构成著作权侵权。尽管原告未完全遵守GPL-2.0协议公开源代码,但法院仍认为网经公司拥有对OfficeTen的著作权,支持了网经的部分赔偿请求。

案例要点:软件开发者是否违反GPL-2.0和是否享有著作权要分开审理;被告以不合规的方式获取并使用了源码会构成著作权侵权。

1.3 GPL-3.0——强化自由与专利保护

▌主要条款

GPL-3.0和GPL-2.0在兼容性、专利、开放性和硬件限制方面存在一些重要区别。主要新增五项关键条款:

🔹明确允许与Apache-2.0等许可证的代码结合,解决了GPL-2.0与其他许可证的兼容障碍
🔹对数字版权管理(DRM)进行限制。明确禁止以DRM名义剥夺用户对GPL软件的权利
🔹明确专利授权,要求贡献者自动授予所有用户专利使用权
🔹明确通过ASP/SaaS方式提供网络服务不属于“分发”行为,无需公开源代码
🔹新增了应对“TiVo化”问题的硬件限制条款,禁止通过硬件锁定限制软件修改

▌适用项目

🔹现代软件项目,尤其是涉及专利或硬件的项目
🔹需要与Apache-2.0兼容的项目
🔹适合强调用户自由和反DRM的项目

优缺点

优点:明确了专利保护,反Tivoization,兼容性更广。
缺点:相比GPL-2.0,条款更复杂,与GPL-2.0不完全兼容,且仍然无法完全覆盖网络服务(SaaS)场景。

相关案例

案例一6

数字天堂公司开发了HBuilder开发工具软件,其中包含三个插件。柚子移动公司开发的APICloud软件被指控抄袭了上述插件的源代码,柚子公司认为HBuilder使用了GPL-3.0,因此这三个插件属于衍生作品,柚子公司可以免费使用其代码,不构成著作权侵权。一审法院判决,这三个插件属于独立的计算机软件作品,不受GPL开源协议的影响,柚子公司构成著作权侵权,二审法院将一审的多个侵权行为合并为一个侵权行为,判决柚子公司侵犯了原告的复制权、修改权。

案例要点:国内首个涉及GPL的著作权纠纷案,默认了开源协议的法律效力。

1.4 AGPL-3.0—网络时代的强互惠约束

▌主要条款

AGPL-3.0在GPL-3.0的基础上增加了一项附加要求,即使你不分发软件,但如果你在服务器端运行该软件(如Web服务、SaaS),也必须向用户开放源代码。

适用项目

🔹网络服务软件,如Web应用、云服务
🔹希望确保所有用户都能获得源代码的项目

优缺点

优点:继承GPL-3.0的优势,填补GPL漏洞,强制云服务公开修改后的源码。
缺点:商业友好性低,被批评“过度约束”。

相关案例

案例一7

特朗普媒体和技术集团推出社交平台“TruthSocial”被指直接使用了基于AGPL-3.0协议的开源项目Mastodon的源代码,然而TruthSocial在测试阶段未向用户分发源代码,也未在网站中明确标注原始代码来源,违反了AGPL-3.0的条款,最终Truth Social团队遵守许可条款公开了其源代码8

案例要点:使用AGPL-3.0代码时,需严格履行许可义务,必须醒目地且合适地附带版权声明和免责声明、许可证文本,同时需要附带源码。

2.互惠型许可证该如何规避风险

2.1 使用互惠型许可组件的代码

若该项目一定要使用互惠型许可证的组件代码,在复制代码文件时需保留文件中的版权声明和免责声明、本许可证(如图1),且该项目需要以相同的许可证进行开源(如图2-3)。

图1

 

图2

 

图3

2.1 修改互惠型许可组件的代码

若使用并修改了互惠型许可证的组件代码,除需保留文件中的版权声明和免责声明、本许可证,且该项目需要以互惠型许可证进行开源以外,还需要在头文件中附加修改说明

如:

#文件名:example.py

#修改日期:2024年9月5日

#修改人:张三

#修改说明:xxxxx

2.3 规避互惠型许可传染性

如果引用互惠型许可证的开源软件与自研部分分别属于独立软件,则自研软件并不会被协议所传染,但迄今为止国内对于传染性边界的界定等核心问题仍存在显著分歧。具体场景是否触及传染要求请咨询专业人士,典型场景的传染性说明将在后续文章详细探讨,敬请期待!

 

软安源兮SCA是一款开源软件成分分析工具,通过多种检测技术,利用自主可控的分析引擎和强大的基因库,提供开源软件资产识别(SBOM)、安全风险检测、许可合规分析、漏洞监控告警及开源软件安全管理等功能,帮助企业缓解开源软件安全、合规和运维风险,助力构建软件供应链安全保障体系。

image.png
 

参考文献

  1. TiVo化:GPL-2.0允许设备制造商(如TiVo公司)在硬件中使用GPL授权的软件(如Linux),但同时通过技术手段(签名验证或硬件锁)进行限制,修改后的软件就不能直接在原有硬件上运行。GPL-3.0新增反TiVo条款:若硬件产品包含GPL-3.0的开源软件,厂商必须提供安装信息,包括解锁硬件限制所需的认证密钥、方法流程等,确保用户能运行修改后的代码

  2. OpenHarmony许可声明https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E5%8F%8A%E8%AE%B8%E5%8F%AF%E8%AF%81%E8%AF%B4%E6%98%8E.md

  3. 不乱买诉闪亮时尚案:(2019)最高法知民终663号

  4. 未来公司诉云蜻蜓案:(2021)最高法知民终406号

  5. OpenWRT衍生软件开发纠纷案https://mp.weixin.qq.com/s/nfNNx3NBlHsxMmmbIzLsIQ

  6. 数字天堂诉柚子科技案:(2018)京民终471号

  7. 软件自由保护协会发文指控特朗普违规https://sfconservancy.org/blog/2021/oct/21/trump-group-agplv3/

  8. Truth Social源码地址:https://github.com/milesmcc/truthsocial

END

 
 

 

● AI+SAST|破解传统代码审计痛点,DeepSeek助力开发效率提升
● 软件供应链安全的"身份证":SBOM之SPDX
● 深交所审核指南发布!“通关秘籍”助力企业解密上市合规
● DeepSeek有没有“抄袭”?软安MST为你揭秘
 
关于软安科技

 

软安科技专注于软件质量和安全检测领域,面向客户场景一站式解决软件生态质量和安全问题。

 

核心团队来自国内外一线厂商,经过三年努力自主开发完成软件成分分析工具、源代码静态测试分析工具、模糊测试工具,打造了与业务场景相结合的行业解决方案,并在汽车、半导体、通信等领域赢得了头部客户的认可。

 

公司在成都、武汉、上海、北京、深圳设有办公机构,可以为客户提供及时专业的售前和售后服务。

 

 

创建时间:2025-04-11 11:18