在开源软件生态中，「徽章软件」（Badgeware）是一种特殊的存在：软件名义上采用开源许可证发布，但实际上通过强制保留商标 Logo、推送不可移除的广告等方式，对用户的自由使用构成了隐性限制。长期以来，许多开发者面对这种「表面开源、实则限制」的灰色地带感到困惑。而 AGPLv3 第 7 条第 4 款正是为解决这一问题而设计的法律工具。本文将以 OnlyOffice 事件为核心案例，解析该条款的实际运作机制与工程实践意义。
自相矛盾许可证的历史困境
要理解 AGPLv3 §7¶4 的价值，需回溯开源许可证发展的历史问题。在 GPLv2 时代，业界普遍存在一种「伪装开源」的 licensing 套路：软件顶层目录确实包含一份 GPLv2 许可证文件，声称采用开源协议，然而同级目录下同时存在一份 LICENSE 文件，写明「本软件采用 GPLv2，但禁止商业修改与再分发」。这种自相矛盾的许可证让开发者陷入法律困境 —— 他们必须在最严格的解释下放弃自己的商业计划，或者另寻代码库。
GPLv2 本身已包含「不得对接收者行使本授权所赋予的权利施加进一步限制」的条款，但该条款仅能阻止下游分发者添加额外限制，无法约束原始作者或版权持有者作为初始授权者时自行添加的矛盾条款。开发者面对这种自相矛盾的许可证时，往往只能选择妥协或放弃。
AGPLv3 §7¶4 的创新解决方案
这一问题在 GPLv3 起草阶段（约 2006 年）得到了系统性的解决。AGPLv3（以及 GPLv3、LGPLv3）在第 7 条第 4 款中引入了革命性的条款：
如果您收到的程序或其任何部分包含声明受本许可证管辖的条款，并且该条款属于进一步限制，您可以删除该条款。
这意味着，当用户收到的许可证文本中包含「进一步限制」时，用户有权直接移除该限制，并纯粹依据 AGPLv3 的原始条款行使权利。copyleft 的设计初衷本就是赋权下游用户，而 §7¶4 将这一理念推向了新的高度。用户不再需要因为初始授权者的「小聪明」而被迫接受不合理的限制。
OnlyOffice 事件：徽章软件的典型案例
2026 年 4 月，拉脱维亚公司 Ascensio System SIA 发布的办公软件 OnlyOffice 成为了 AGPLv3 §7¶4 的最新实践案例。Ascensio 在其许可证中添加了所谓的「进一步限制」，要求分发者在程序中保留原始产品 Logo，并同时声明不授予用户任何商标权。这种做法在开源社区引发了广泛争议。
从技术角度看，AGPLv3 §7 (b) 条款允许授权方要求保留「合理的法律声明或作者署名」，但 Logo 和商标并不属于「合理法律声明」的范畴。Ascensio 试图利用 §7 (b) 的表层合法性来包装其徽章软件本质，实际上创造了一个自相矛盾的许可证：用户被禁止展示商标 Logo，同时又被禁止移除显示该 Logo 的代码。
根据 AGPLv3 §7¶4，Nextcloud 与 IONOS 合作推出的 Euro-Office 分支完全有权移除这一「进一步限制」。Ascensio 对此发表了措辞强烈的声明，指责 Euro-Office 侵犯许可证条款，但这一指控忽视了 AGPLv3 赋予用户的合法权利。
工程实践中的参数与监控要点
对于处理类似徽章软件场景的开源项目，建议采用以下工程化策略。首先，在引入第三方 AGPLv3 组件时，应全面审查其 LICENSE 文件，识别是否存在 §7 条款中的额外限制。特别关注要求保留 Logo、强制广告显示、限制商业使用等条款。其次，如果确认存在「进一步限制」，可依据 §7¶4 移除该条款，但需做好文档记录，以便在潜在法律纠纷中说明决策依据。第三，监控上游许可证动态，Ascensio 案例表明，许可证条款可能随版本更新而变化，持续审计是必要的合规实践。第四，对于商业产品中的 AGPLv3 组件，需严格遵守网络服务提供条款（§13），确保用户能够获取对应的源代码。
结语
AGPLv3 §7¶4 为开源社区提供了一件对抗徽章软件的利器。它不仅是法律层面的保障，更体现了 copyleft 许可证设计者对用户自由的深层关怀。OnlyOffice 事件警示我们：开源许可证的实践需要持续的警惕与专业审查。当面临自相矛盾的许可证条款时，用户完全可以依据 §7¶4 主张自己的合法权利，移除不应存在的限制，还原开源软件的本质自由。
资料来源：本文核心事实与案例细节来自 Software Freedom Conservancy 2026 年 4 月 16 日发布的分析文章《AGPLv3§7¶4 Empowers Users to Thwart Badgeware》。