法律总有滞后性。目前，我国著作权法中尚无有关“开源协议”或“著佐权”的专门规定，但实践中已经涌现多起与GPL许可证协议相关的案例。纠纷总是先于法律规制出现，但同时，万变不离其宗。法院仍然可以适用现有法律，解决新型的争议，这也是法律作为上层建筑的意义。换言之，虽然“开源协议”有关纠纷是全新的，表面上超越现有知识产权或合同法规制，但对于风险预判及纠纷解决，实际上依然有迹可循、有法可依。

在本文中，我们将介绍多个国内典型案例，盘一盘国内著佐权那些事儿。

总结而言，目前有关“开源”争议的案件主要涉及两类。一类是“使用型”争议，即软件作者起诉被告企业，主张被告对开源协议的使用不符合协议约定，例如，涉及GPL许可证的罗盒诉玩友案、罗盒诉风灵和腾讯案。另一类是侵权型案件，原告诉被告使用开源软件侵权，而被告主张“开源软件”可随便使用，不侵权。例如，涉及GPL许可证的不乱买公司诉闪亮公司案、数字天堂公司诉柚子公司案、长沙米拓诉和谐网络科技案，以及有关PHP许可证的天创科技诉阿凡提案。

根据上述有限的开源争议案件，我们将开源争议所易涉及的问题分五个维度进行简要讨论，即：开源纠纷适格主体、开源协议性质、开源协议的效力及范围、合理使用抗辩、法律责任。在本文中，我们主要着重讨论前两个问题，其余三个问题，我们将在下几期文章中继续讨论。

第一，提交绝大部分代码量的项目管理者（通常是源代码的初始开发者）有权单独提起诉讼，无需经过其他代码贡献者（后续其他用户）的授权。

在罗盒诉玩友案和罗盒诉风灵和腾讯案中，被告主张，由于案涉软件实际由众多贡献者不断更新迭代，原告罗盒公司并非案涉开源软件著作权人，因此，原告并非适格原告，无权提起有关诉讼。

法院认为，原告罗盒公司是案涉开源软件的项目管理者，提供了绝大部分代码，有权单独起诉，理由有三。其一，其提交的代码量占案涉软件代码量的绝大部分，且根据托管平台Github的要求，任何人对该源代码作出的修改、补充，如需并入原开发项目，则必须经项目管理者同意。因此，项目管理者对最终版本的形成起到决定性作用。其二，被告虽称案涉软件为合作作品，根据《著作权法实施条例》第九条[1]，提起诉讼需征得其他合作作者同意，但法院认为，合作作品在客观上要求合作作者贡献独创性表达。在该案中，被告并未举证证明合作作者的独创性表达要素，因此未证明作品是否合作作品。其三，从诉讼可行性看，由于代码贡献者散布于全球各地、数量众多且动态增加，若开源项目的起诉维权需经全体贡献者一致同意或授权，实则导致维权行为无从提起。

由上可见，法院在判定开源协议的维权者时，主要是从“可行性”的角度出发，同时辅以“实质性贡献”的考量标准，即维权者应提供了开源协议的“绝大部分的代码”，且对最终版本具有决定性作用。

但在司法实践中，“绝大部分代码”是个主观判断标准，不具有完全确定性。何谓“绝大部分”，其百分比到底是多少？是完全以代码数量定还是实质以起到的作用定？并无定论，且无从定论。因此，该判断标准，根据案件不同、事实不同，必然有不同结果。例如，如果开发者并未贡献“绝大部分代码”，但是贡献了特别重要的功能性代码，是否也能够具有维权者身份呢？这个问题，目前国内尚无判例予以分析。事实上，这部分也将是具体争议产生后双方“必争之地”。

第二，开源软件的后续开发者是否可以单独提起诉讼，我国司法实践中尚无相关判例。

通常而言，开源协议的原始创作人将贡献绝大部分代码，但这并不排除后续开发者对原始代码做出具有划时代意义的独创性实质修改。著名的安卓系统可以被用作思路参考。安卓软件最初由安德鲁鲁宾开发，后续由谷歌收购后继续发扬光大，使其一举成为最受欢迎的手机操作系统。开发者和使产品具有关键功能的后续开发者不是同一主体，是现实存在的常见问题。法律作为商业秩序的维护者，必然需要考虑这一问题。

目前学理中考虑的一个思路是，如后续用户修改代码后，修改的部分因具有独创性表达而构成新的演绎作品，则后续开发者可成为演绎作品的著作权人，可以单独提起诉讼；否则，原开发者仍然是著作权人，后续开发者则仅能在著作权人授权下提起诉讼。

上述思路主要从演绎作品的构成出发：根据《著作权法》第十三条[2]，演绎作品是改编、翻译、注释、整理已有作品而产生的作品，其著作权由改编、翻译、注释、整理人享有。因此，如后续用户通过自己的修改使得新的作品具有独创性，区别于其他作品，尤其是修改前的软件作品，则后续用户实质上已经成为新的著作权人，当然有权单独提起诉讼，要求保护自己享有的著作权。

值得注意的是，开源协议具有一定的特殊性，在形成作品的过程中也有一些特殊情况。例如，后续用户在实施复制、修改、发布行为的过程中，如未遵守开源协议，是否影响“演绎作品”著作权的行使？即，“侵权演绎作品”是否仍受著作权法保护？目前我国司法实践对此问题结论并不统一[3]，多数法院认为“侵权演绎作品”享有著作权[4]，即，将著作权的所有权问题和违约相分离。例如，在2011年北京市海淀区人民法院一审、北京一中院终审的一起案件中[5]，法院认为，被告对违反GPL协议的“侵权演绎作品”仍然享有著作权，被告享有诉权。北京市高级人民法院于1996年12月9日发布的《关于审理著作权民事纠纷案件适用法律若干问题的解答》（京高法发[1996]460号）第5条中，法院也认为，“侵权演绎作品”的著作权人（侵权人）有权就下游侵权行为单独提起诉讼。

如后续开发行为未构成演绎作品，则后续使用者不享有作品的著作权，仅能作为非专有使用权人，经著作权人授权，享有诉权。我们尚未检索到非专有使用权人直接提起诉讼的案例。但我们注意到，最高院在福州大德文化传播有限公司与宁乡县皇家贵族音乐会所著作权权属、侵权纠纷案(（2018）最高法民再417号)中曾经指出：著作权专有使用权许可的情形下，被许可人可以作为原告提起诉讼；如为非专有使用权许可，则经著作权人明确授权，被许可人亦可以自己的名义提起诉讼。我们认为最高院的上述分析与我们的上述分析吻合。

在罗盒诉玩友案和罗盒诉风灵和腾讯案中，我国法院首次明确了GPL V3开源协议具有许可协议的性质。

首先，GPL V3具有合同性质。从内容上看，开源协议有关条款产生私法上意思表示的效果，因此，GPL V3协议是一种民事法律行为。具体而言，开源软件的发布可以视为发出“要约”，而用户使用则应视为“承诺”。据此，在用户使用开源软件时合同成立。换言之，法院认为，用户对开源协议的承诺是以行为作出意思表示。

其次，GPL V3是作者与用户之间的格式化著作权协议，是为特定开源软件开发事项而预先拟定的，可以后续重复使用。通常来讲，对于被许可人，开源协议规定的义务主要包括：1）标明著作权信息及必要的修改信息（如修改人、修改时间及修改内容等）；2）发布时附该开源协议；3）提供完整的源代码；4）发布无担保声明；5）未经许可不得使用开源软件的商标或著作权人的名称[6]。

再次，GPL V3协议是附条件自动解除的合同。GPL V3协议规定了使用条件，一旦用户违反了该等条件及有关义务，则许可协议在授权人与用户之间自动解除。合同解除后，用户基于GPL协议获得的许可也即时终止。因此，用户实施的复制、修改、发布等行为，因失去权利来源而构成侵权。罗盒诉玩友案中，法院认为，玩友公司未向用户提供被诉侵权软件源代码下载，违反GPL V3协议规定，因此，玩友公司对争议软件源代码的复制、发布行为构成侵权。

我们认为，我国法院将开源协议定义为许可协议，有效解决了GPL协议相关案件中违约/侵权的关系。一方面，上述认定合乎逻辑，同时符合合同法、著作权法的相关理论；另一方面，上述认定与境外类案中法院对开源软件许可证性质的认定统一，例如，2008年美国联邦巡回上诉法院审理的Jacobsen诉Katzer上诉案[7]，以及德国法院Welte诉D-Link案[8]，有利于跨境争议中的司法统一。

但值得注意的，由于开源协议是一类特殊协议，其不仅仅交叉许可问题，还交叉复杂所有权，进而产生其他法律问题。法院的上述归类仅能解决开源协议中的一部分问题，实践中，可能与其他前沿问题产生矛盾冲突，需要通过司法实践，由法院进一步明确，最终上升至立法规范。

例如，许可协议定性并不能解释开源协议的许可源头是如何产生的。开源协议的所有权其实是“集体”产生的，而所谓的“许可”并不来自于软件初始创作人，而来自全体代码贡献者。又如自动解除权，是否在任何使用者违反任何条款情况下均产生自动解除权，是一个具有巨大争议的问题。在我国合同法和民法典体系下，即使约定解除权，解除合同也需达到实质性违约的程度。《九民纪要》明确规定，轻微瑕疵履约不导致合同解除的后果。这类问题在开源协议中如何进一步加以解决，我们拭目以待。

感谢大家阅读本篇有关开源协议适格主体及性质的介绍。下一期中，我们将继续探讨开源协议的效力范围，即哪些作品需要持续遵守开源协议，而什么情况下可以选择闭源等等。欢迎大家持续关注。