AGPLv3许可证维权指南：开源项目被闭源SaaS侵权怎么办

一个开源开发者的真实困境

近日，一位开源开发者在 Reddit 上分享了他遭遇的许可证纠纷。他花费近一年时间，借助 AI 工具并参考了 frame.io 等平台，开发了一个名为 ViTransfer 的开源项目——一个视频审阅（review）平台，目标是为市面上的商业审阅工具提供开源替代方案。

frame.io 是视频协作审阅领域的头部商业产品，2021年被Adobe以12.75亿美元收购并整合进Creative Cloud生态。视频审阅平台的核心功能包括：带时间码的逐帧标注、多版本比较、审批工作流管理以及团队协作评论。这一细分市场长期被 frame.io、Wipster、Vimeo Review 等商业产品垄断，月费从每用户15美元到50美元不等，对独立创作者和小型工作室构成不小的经济负担。ViTransfer 项目正是试图填补这一生态空缺——提供一个自托管的、免费的开源替代方案。

项目采用 AGPLv3 许可证开源发布。后来，有人对该项目进行了 fork，经过大量修改后，将其包装成一款 SaaS 产品对外提供服务。开发者本人对 fork 行为并无异议——毕竟 fork 是公开的，且托管在 GitHub 上，完全符合开源精神。

真正的问题出在下游：这家 SaaS 服务商在其官网上声称自己是软件的"构建者"并主张版权，却对项目衍生自 AGPLv3 授权的开源代码只字不提。潜在客户看到的是官网，而非 GitHub 页面，因此几乎无从得知他们所使用的软件其实是开源的。

AGPLv3 许可证的核心要求

要理解这场纠纷，必须先厘清 AGPLv3（GNU Affero General Public License v3）的核心条款。它是 GPLv3 的强化版本，专门针对"网络服务"这一场景设计。

AGPLv3 的诞生有着深刻的历史背景。2007年，随着 Google、Facebook 等公司大规模使用开源软件构建网络服务却无需回馈代码，自由软件社区意识到传统 GPL 的"分发触发"机制已无法应对云计算时代的挑战。FSF（自由软件基金会）因此在 GPLv3 发布的同年推出了 AGPLv3，其核心创新就是将"通过网络交互"等同于"分发"，从而要求 SaaS 服务商也必须公开修改后的源代码。这一设计使得 AGPLv3 成为目前对 SaaS 场景约束力最强的开源许可证。

网络分发条款：堵住SaaS漏洞

传统 GPL 有一个著名的"漏洞"：如果软件只是作为网络服务运行、而不实际分发给用户，那么服务商就无需公开源码。SaaS 模式恰好钻了这个空子。

AGPLv3 正是为堵住这个漏洞而生。其第 13 条明确规定：如果你通过网络让用户远程与经过修改的程序交互，就必须向这些用户提供获取对应源代码的途径。这意味着，那家 SaaS 服务商即便不"分发"软件，也有义务向其服务的用户公开修改后的源码。

署名与许可证保留义务

保留原始版权声明，不得删除或隐藏；
衍生作品必须以相同的 AGPLv3 许可证发布（copyleft 传染性）；
必须明确告知使用者其软件的许可证状态。

这里的"copyleft 传染性"是一个关键概念。Copyleft（著佐权）是一种利用版权法来保障软件自由的法律策略，由 Richard Stallman 在1980年代提出。其"传染性"指的是：任何包含 copyleft 代码的衍生作品，都必须以相同的 copyleft 许可证发布，形成一种"病毒式"的自由传播链条。在实践中，这意味着如果你 fork 了一个 AGPLv3 项目并添加了新功能，你的新功能代码也必须以 AGPLv3 发布——你不能将衍生作品"闭源化"。这与 MIT、Apache 等宽松许可证形成鲜明对比，后者允许将开源代码整合进闭源商业产品中而无需公开修改。

因此，这家服务商声称"拥有版权"这一表述本身就存在问题——他们只对自己新增的部分享有版权，而项目"核心"仍受原作者的著作权与 AGPLv3 约束。在官网上完全不提及开源来源和许可证，构成了对 AGPLv3 条款的违反。

开发者的诉求：不是钱，是署名

你可能没注意到，这位开发者的诉求相当克制。他明确表示：

"我不是想要钱，也不想让他们停止运营。我做这个开源项目，是为了让人们有一个开源的审阅平台替代方案。我只想要一点署名，让用户知道他们用的软件是开源的。"

这种态度代表了相当一部分开源作者的心声——开源不等于放弃权利。许可证是开源协作的契约基础，署名和许可证透明既是法律义务，也是对社区信任的维护。当下游商业化产品刻意隐藏开源来源时，损害的不仅是原作者的声誉，更是整个开源生态的健康。

开源许可证违规的维权路径

开发者目前已经向对方发送了邮件，但尚未收到回应。对于类似情况，社区通常建议以下逐级升级的处理方式：

1. 发送正式书面通知

第一步（也是已经做的）是发送清晰、专业的书面通知，具体指出：

项目的原始 GitHub 地址与版权归属；
AGPLv3 的具体条款要求（署名、许可证声明、源码提供）；
期望对方采取的补救措施（如在官网标注开源来源）。

保留所有沟通记录，这在后续可能的法律行动中至关重要。

2. GitHub DMCA 与平台申诉

如果对方 fork 仍托管在 GitHub 上却违反许可证，可以考虑通过 GitHub 的许可证违规或 DMCA 流程申诉。

需要注意的是，DMCA（数字千年版权法）是美国1998年通过的版权保护法律，其"通知与移除"（Notice and Takedown）机制被 GitHub 等平台广泛采用。然而，开源许可证违规与传统版权侵权有本质区别：许可证违规本质上是"有条件授权下的违约"——对方确实获得了使用代码的许可，只是没有遵守许可条件。部分法院将其视为合同纠纷而非版权侵权，这意味着 DMCA 流程可能不完全适用。在实践中，GitHub 会根据具体情况评估许可证合规投诉，但处理时间和结果往往不如纯版权侵权案件那样明确。AGPLv3 违规属于合同/著作权纠纷，DMCA 更适用于纯粹的版权侵权场景，二者需区分对待。

3. 寻求专业法律援助

对于个人开发者，独立起诉成本高昂。可以联系 Software Freedom Conservancy（软件自由保护协会） 或 Free Software Foundation（自由软件基金会） 等组织。这些机构长期致力于 GPL 家族许可证的合规执行，能提供咨询甚至代为交涉。

Software Freedom Conservancy（SFC）成立于2006年，是一个专门为开源项目提供法律和行政服务的非营利组织。它最著名的工作之一是代表开源项目执行 GPL 合规，包括对违规企业提起诉讼。SFC 曾在针对 VMware 违反 Linux 内核 GPL 许可证的案件中提供关键支持，也主导了多起针对消费电子产品制造商的 GPL 执法行动。对于个人开发者而言，SFC 提供的免费法律咨询和代理交涉服务极大降低了维权门槛——个人开发者无需承担动辄数万美元的律师费用即可推动许可证合规。

4. 借助舆论与社区力量

在合法合规的前提下，公开事实、借助开源社区的关注，往往能促使违规方主动整改。许多 SaaS 公司在意品牌声誉，公开的许可证违规讨论足以形成压力。

给开源作者的实用启示

这起案例并非孤例，它折射出开源商业化时代反复出现的张力：

第一，选对许可证至关重要。 这位开发者选择 AGPLv3 而非 MIT，恰恰是明智之举——如果当初用的是宽松的 MIT 许可证，对方连署名都可以合法省略。AGPLv3 的强 copyleft 特性为这类维权提供了法律武器。

第二，许可证的价值在于被执行。 许可证条款写在文件里只是第一步，真正的保护来自于作者愿意在违规发生时站出来维护。

第三，AI 辅助开发不改变著作权归属。 尽管作者提到大量使用 AI 辅助编码，但这并不影响他对项目整体的著作权主张——由人主导创作、组织和发布的软件，其著作权依然归属开发者本人。

关于 AI 辅助开发的著作权问题，这是当前知识产权法领域的热点议题。美国版权局在2023年发布的指导意见中明确：纯由 AI 生成、无人类创造性干预的内容不享有版权保护；但如果人类对 AI 输出进行了实质性的选择、编排和创造性修改，则最终作品仍可获得版权。在软件开发领域，使用 GitHub Copilot 或 ChatGPT 辅助编码的开发者，只要在架构设计、功能规划、代码审查和整合方面做出了实质性的创造性贡献，其对项目整体的著作权主张通常不受影响。这也是为什么 ViTransfer 开发者虽然大量使用 AI 工具，但其著作权地位依然稳固。

开源的本质是自由与协作，而非无偿被掠夺。这位开发者的经历提醒我们：一个健康的开源生态，既需要慷慨的分享者，也需要坚守契约底线的维护者。