开源合规通关秘籍（一）｜深度解析互惠型许可证的合规之-CSDN博客

本文链接：https://blog.csdn.net/weixin_60602539/article/details/146975952

开源软件（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。