开源非免费｜商业用途慎用 AGPLv3 开源软件

创作时间:

作者:

@小白创作中心

开源非免费｜商业用途慎用 AGPLv3 开源软件

引用

来源

https://juejin.cn/post/7453674221702725647

AGPLv3许可证是开源软件领域最具约束力的许可证之一，尤其在商业应用中可能带来意想不到的法律风险。本文通过多个实际案例和详细条款解释，深入探讨了AGPLv3许可证的传染性及其在SaaS等云服务场景下的应用，为企业和个人开发者提供了重要的合规参考。

前言

开源并非免费，开源软件即源代码是公开发布的，可供自由查看、修改、使用。你可以在软件发布网站如 GitHub 上找到源代码。作为个人开发者，你可能从来没有考虑过软件许可中的法律风险（或许你认为不需要考虑）。但作为一家商业公司或小型商业作坊，使用某些许可证的开源软件直接或间接获取商业利益可能面临法律风险，例如本文着重讨论 Copyleft 类的许可 GPL 系列。旨在提醒商业公司在对互联网用户提供服务时，应慎用 GPL 类许可证的开源软件，尤其是 AGPL v3 许可证。

软件许可侵权判决案例

2019 年 11 月，北京市中级人民法院对一起侵权计算机软件著作权纠纷案作出二审终判决，判令被告停止侵权行为，并赔偿原告 71 万元。

2021 年 4 月，深圳市中级人民法院就一起涉及 GPL 许可证的计算机软件著作权侵权案作出一审判决，认定被告因违反 GPLv3 许可证而构成著作权侵权，酌情确定赔偿数额为 50 万元。

2022 年 9 月，南京市中级人民法院审理一起 GPL 许可代码侵权案，判处被告赔偿原告经济损失 300 万元，被告上诉至最高人民法院，仍抗辩失败。

简介

由北京大学牵头的木兰宽松许可证第二版通过了 OSI 认证
软件许可证是创建和提供应用程序、底层源代码或相关产品的实体与其最终用户之间的合同。许可证是一种文本文件，旨在保护软件开发人员的知识产权，并限制因使用许可证而可能对他们提出的任何索赔。软件许可证还为软件的分发和使用提供了具有法律约束力的定义。最终用户的权利，如安装、保证和责任，也经常在软件许可证中详细说明，包括对开发人员知识产权的保护。
相比于 MIT、Apache v2 和 BSD-3， GPL 系列许可证具有强约束，是最容易产生法律风险的开源许可证。
GPLv2，即 GNU 通用公共许可证第二版（GNU General Public License version 2），是由自由软件基金会（Free Software Foundation, FSF）发布的一个广泛使用的自由软件许可证。GPLv2 具有传染性，任何基于 GPLv2 许可证的软件，如果被修改后重新分发，也必须以 GPLv2 许可证发布，公开源代码。
对商业公司来说，源代码是公司资产与核心竞争力，公开源代码与商业公司理念相违背。因此，某些公司采取了一种绕行方式。简单来说，遵守 GPLv2 的传染性以及强制开源的约束，但另外通过技术手段如“访问控制”机制，限制用户自由运行修改后的软件，显然该行为与 GPLv2 许可证的开源理念相违背。另外，GPLv2 强传染性难以兼容其他许可证，也不包含专利豁免条件。
GPLv3 针对 GPLv2 作了以下重要改进，专利授权：GPLv3 包括了专利授权条款，防止专利诉讼对开源软件的影响，保护开源软件的开发者免受专利侵权索赔的困扰；传染性：GPLv3 对传染性做了更加详细的探讨，区分静态链接和动态链接，如果程序与库紧密集成，那么整个程序需要以 GPLv3 发布，否则不必遵守 GPLv3。在法律案件中，动态链接是传染性判决焦点。
无论是 GPLv2 还是 GPLv3，在谈论约束条款时，条款出发点是具体的软件产品。“分发”倾向于通过拷贝或网络下载实体软件程序到本地，例如操作系统、客户端软件、单机游戏。在判定传染性时，使用 C/C++ 类编程语言的静态链接和动态链接论述。然而，随着云时代的到来，SaaS、前后端分离、微服务等软件开发概念在 GPL 许可的解释上更加复杂。软件服务提供商不需要向用户“分发”程序，那也意味着使用了 GPL 许可的软件提供商业服务不必遵守强制公开源代码的约束。又一次地，期望的开源理念被打破，尤其是一些云服务提供厂商，基于开源软件的力量构建商业体系，对源代码进行修改和优化并对外提供商业服务，但却不公开源代码，这严重损害了开源组织和维护公司的利益。
基于此现实情况，在 GPLv3 的基础上，AGPLv3 着重强调了即使作为 SaaS 不分发软件，凡是使用了 AGPLv3 衍生软件提供服务，均需遵守 AGPLv3 许可，强制公开源代码。

基于 AGPLv3 的开源软件

2021 年 4 月 20 日 Grafana Labs 宣布将其核心开源项目 Grafana、Grafana Loki 和 Grafana Tempo 的许可证从 Apache License 2.0 变更为 AGPLv3。

2021 年 5 月 11 日 S3 对象存储开源组件 MinIO 许可证由 Apache License 2.0 转变为 AGPLv3。

Elastic 近些年也做了一系列的许可证变更，并在 2024 年 9 月增加 AGPLv3 许可证，官方称许可证变更是为了降低市场混乱的风险。

AGPLv3 传染性

对许可证进行解释是一项非常复杂的工程，本文简单探讨 AGPLv3 许可证传染性触发条件。

个人开发者或中小型软件科技公司，系统集成是主要的工作模式，使用开源组件或开源工具进行软件开发，例如使用编程语言 Java JDK，服务端开发框架 SpringBoot、数据库 MySQL 开发电商交易平台。假如该软件产品使用了对象存储 MinIO（AGPLv3），项目是否必须以 AGPLv3 许可发布，并提供源代码？

该问题是有争议的，但多数意见认为软件需遵守 AGPLv3。如果该电商交易平台向用户提供服务，那么必须向用户申明许可证，并公开源代码。因此谨慎使用 AGPLv3 许可证的 MinIO 作为对象存储。

Minio 官网中的信息增加了模糊性：

如果 MinIO 源代码包含在同一个可执行文件中，那么它们肯定被组合在一个程序中。如果模块被设计为在共享地址空间中链接在一起运行，那么这几乎肯定意味着将它们组合成一个程序。

相比之下，管道、套接字、RESTful API 和命令行参数通常是两个独立程序之间使用的通信机制。因此，当它们用于通信时，模块通常是独立的程序。但如果通信的语义足够紧密，交换复杂的内部数据结构，那么这也可以成为将两个部分合并为一个更大程序的基础。

仅仅将 MinIO 软件聚合到您的发行版中并不构成衍生作品。

互联网上类似问题认为需要遵守 AGPLv3 许可的获得了高赞。

Reddit 上关于 Minio 许可证的提问：

Minio 用户在 Github issues 中提问时，被贡献者提醒违反了 AGPL 许可。

个人见解

如果运营商业软件，无论是 SaaS 还是软件分发，都需要考虑 AGPL 许可证的法律风险，需要向用户申明许可证并公开源代码。如果是企业内部软件，那么无需过多担心法律风险，无论是使用还是修改而衍生的软件产品，其面向的用户是企业内部用户，即使需要履行 AGPLv3 许可，也只面对企业内部员工，而不是将源代码公开到互联网，也就不存在商业敏感信息问题。

Google 公司禁止内部使用 AGPL v3 软件，以避免可能引发不必要的法律纠纷。项目负责人或架构师在技术选型时尽量采用 MIT、Apache v2 许可证的开源软件。任何企业都有必要知晓 AGPL v3 及其他 GPL 许可证中的法律风险。

作为开源作者，尽量选择被 OSI 接纳的软件许可证如 MIT、Apache v2、GPLv3 或 AGPLv3，而不是自定义许可证或选择非 OSI 认证许可证，这些许可证的法律认可度较低，难以保障作者知识产权。