「OnlyOffice添加的限制条款与AGPLv3不兼容，且接收者可以移除这些限制。」——自由软件基金会Krzysztof Siewicz的这句话，把一场持续数月的开源协议争议推向了高潮。

事件核心：谁在违反开源精神？

OnlyOffice CEO Lev Bannov近期指控Euro-Office分支违反AGPLv3协议。戏剧性的是，FSF的裁定反而指向了指控方本身。

AGPLv3（GNU Affero通用公共许可证第三版）是开源软件领域最严格的协议之一。它要求：只要软件在网络服务器上运行，就必须向所有用户提供完整源代码。

OnlyOffice的做法是：在标准AGPLv3基础上附加额外条款。FSF的结论是——这些附加条款构成了事实上的限制，与AGPLv3的兼容性格格不入。

关键细节：为什么"附加条款"是红线

Siewicz的文章揭示了一个技术细节：AGPLv3本身允许添加补充条款，但有严格边界。OnlyOffice的条款越界了——它们限制了用户的权利，而非扩展。

更关键的是，FSF明确表示「接收者可以移除这些限制」。这意味着任何拿到OnlyOffice代码的开发者，都有权剥离这些附加条款，回归纯净AGPLv3。

这对Euro-Office分支是重大利好。他们不必再为"是否违规"辩护，反而获得了法理上的主动权。

商业逻辑：开源公司的两难困局

OnlyOffice的困境极具代表性。作为开源办公套件的商业公司，它需要平衡两条线：

对社区：必须保持开源姿态，获取开发者信任和代码贡献。

对股东：需要构建商业壁垒，防止云厂商"白嫖"代码后直接竞争。

附加条款是典型的防御手段——既想蹭AGPLv3的开源光环，又想偷偷收紧控制。FSF的裁定戳破了这种策略的合法性。

行业影响：开源协议的"解释权"之争

这件事的深层意义在于：谁掌握开源协议的解释权？

FSF作为GPL系列协议的制定者，其立场具有准司法效力。但现实中，大量开源项目都在玩"协议+附加条款"的游戏。MongoDB的SSPL、Elastic的ELv2都是类似思路的变体——既然GPL管不住云厂商，就自己造新协议。

OnlyOffice的教训是：在AGPLv3的框架内搞小动作，风险极高。FSF的裁定会被法院参考，也可能影响开发者的技术选型决策。

对科技从业者而言，这个案例提供了清晰的行动指南：评估开源项目时，不仅要看它挂什么协议，更要查有没有隐藏条款——以及这些条款是否被权威机构认可。协议合规不是法务部门的专属议题，它直接影响技术栈的长期稳定性。