作者：杜晓宽 宁敏 成如意 北京己任（上海）律师事务所
2021年4月，深圳市中级人民法院针对一起侵害某开源软件的计算机软件著作权纠纷案做出判决，认定被告构成著作权侵权，责令其立即停止提供涉案软件的下载、安装和运营服务，并赔偿原告经济损失及维权合理费用共计50万元。
本案为国内首个明确GPL 3.0协议性质的司法案例，法院明确开源软件维权无需经过所有贡献者的同意或授权，认定开源协议具有合同性质，开源代码使用者的违约行为会触发协议的“终止授权条款”，由于失去权利来源，使用者需要承担侵犯著作权的后果。本案为开源软件版权纠纷案件的处理提供了开创性的观点和思考空间。
GPL许可证概述
用户使用开源软件需遵循开源许可协议，即需要在协议的允许范围内对软件的源代码进行使用、修改和发行（包括以盈利为目的商业发行）。GPL许可证（GNU General Public License, 通用公共许可证）简称GPL，是众多开源许可证中最著名的一种，GPL许可证授权用户对软件进行复制、修改和分发的权利，且具有“强传染性”特征：GPL开源软件本身修改的衍生作品和其他仅适用部分GPL开源软件源代码的衍生作品都将受到“传染”，必须依据GPL协议进行开源。
开源软件的实质被概括为“软件权利人在前既公开其源代码之信息（可能为商业秘密），又明确其放弃软件中的修改权和许可使用权及其报酬权，并以此为对价换取在后改软件免费使用者或者修改者对后续开发之软件同样公开源代码信息（可能为商业秘密）和明确放弃软件之许可使用权及其报酬权、修改权的利益平衡模式”[1]。在后软件免费使用者或修改者在使用或修改开源软件时，如果没有预见到其后续需要依据协议进行开源，将可能面临被认定著作权侵权或商业秘密被迫披露的后果。
案情概述
原告济宁市罗盒网络科技有限公司独立开发“罗盒（VirtualApp）插件化框架虚拟引擎系统[简称：VirtualApp]V1.0”（以下称涉案软件），其在国际著名的软件托管平台GitHub上公开了涉案软件的源代码，并于2017年取得计算机软件著作权登记证书。VirtualApp从2016年7月8日的版本开始引入开源协议，起初为LGPL3.0协议，2016年8月12日更换为GPL3.0协议。2017年10月29日，原告在VirtualApp后续开源版本中删除“适用GPL3.0协议”的表述。2019年，原告发现名为“点心桌面”的软件，经过对比源代码，发现“点心桌面”与涉案软件构成实质性相似，故提起软件著作权侵权诉讼。
法院对案件争议焦点的认定
一、GPL3.0协议具有合同性质，系授权人与用户之间订立的著作权协议，适用合同法有关规定。
开源软件即开放源代码软件，开源软件的著作权人将其享有的著作财产权和部分人格权，通过开源许可协议的方式授予用户使用，以达到软件的自由开发、使用或传播的目的。开源许可证已经成为国际行业共同认可和遵守的开源许可协议的形式，GPL3.0协议是众多开源许可证中的一种。开源软件权利人在发布开源软件时可以选择使用某开源许可证，其他用户在复制、修改、再发布该开源软件时，需要遵守开源许可证中的内容。
法院认为GPL3.0协议具有合同性质，系授权人与用户之间订立的著作权协议。GPL3.0协议在内容上具有发生私法上效果的意思表示，授权人的授权行为与用户的使用行为均出于自愿，通过设立、变更、终止民事权利义务关系发生权利变动，属于民事法律行为；协议在形式上为电子文本，系书面合同，因此GPL3.0协议具有合同性质，属于《合同法》调整范围。协议中的“终止授权条款”[2]属于附解除条件的民事法律行为中所附解除条件，一旦用户违反了使用的前提条件，将导致GPL3.0协议在授权人与用户之间自动解除，用户基于协议获得的许可即时终止。
二、原告系涉案软件著作权人，开源软件维权无需经过所有贡献者的同意或授权，原告有权提起本案诉讼。
一是原告系Github网站上开源软件VirtualApp的著作权人。该网站由原告开发运营，原告的股东兼项目发起人在网站上传该软件的初始源代码，后续开源版本系在此基础上迭代演进而来，故法院依据《计算机软件保护条例》第九条[3]认定原告系著作权人。
二是原告提起本案诉讼不需要Github网站上显示的VirtualApp贡献者授权。某些用户将获取的源代码修改后“提交”，如果项目发起人认可并把修改部分 “合并”到源代码的 “主分支”中，形成新的源代码版本，那么这些用户就成为项目的贡献者。法院认为贡献者上传的代码是否“合并”，由项目人取舍和决定，故贡献者的提交行为不对原告享有著作权产生实质影响，且贡献者的“提交”行为可以视为同意将贡献内容许可给项目人和其他用户使用。另外，由于贡献者人数众多、互不相识且身居世界各地，数量也处于持续增加、变动中，将所有贡献者同意或授权作为开源项目维权的前提，将导致维权行为无法实现。因此原告提起本案诉讼无需贡献者同意或授权。
三是原告的诉讼行为符合GPL3.0协议关于争议解决方式的约定。法院根据协议第10条中有关限制授权人不得向用户索要授权费或者版税，不得主张任何专利权的规定，认为GPL3.0协议并未限制授权人对违反许可协议的用户主张著作权。因此，原告的诉讼行为并未违反GPL3.0协议关于争议解决方式的约定。
综上，原告有权提起本案诉讼。
三、被告使用了附带GPL3.0协议的开源代码，却不履行该协议规定的使用条件，其获得的授权已自动终止，故其实施的复制、修改、发布等行为，因失去权利来源而构成侵权。
一是原告将VirtualApp在后续开源版本中删除“适用GPL3.0协议”的行为不影响后续开源版本仍受协议约束。VirtualApp从2016年7月8日的版本开始引入开源协议，起初为LGPL3.0协议，2016年8月12日更换为GPL3.0协议。2017年10月29日，原告在VirtualApp后续开源版本中删除“适用GPL3.0协议”的表述。根据GPL3.0协议，只要后续版本中有使用先前开源版本中的源代码，并且先前版本使用了GPL3.0协议，则后续版本也必然受GPL3.0协议的约束（通常被称为具有“强传染性”特征）。因此，VirtualApp后续开源版本仍然受GPL3.0协议的约束。授权人与用户在行使权利、履行义务时均应遵循诚实信用原则，恪守协议的约定。
二是被诉“点心桌面”App(V6.5.8)应该开源。被诉“点心桌面”App(V6.5.8)中使用了原告采用GPL3.0协议发布的VirtualApp，根据GPL3.0协议的相关内容及“强传染性”特征，对在逻辑上与开源代码有关联性且整体发布的派生作品，只要其中有一部分是采用GPL3.0协议发布，那么整个派生作品都必须受到GPL3.0协议的约束。因此，被诉“点心桌面”App(V6.5.8)应当遵循GPL3.0协议向公众无偿开放源代码。
被告福建风灵公司使用了附带GPL3.0协议的开源代码，却拒绝公开“点心桌面”App(V6.5.8)的源代码，系拒不履行GPL3.0协议规定的使用条件。根据GPL3.0协议第8条自动终止授权的约定及《民法总则》第一百五十八条的规定，被告福建风灵公司通过该协议获得的授权已因解除条件的成就而自动终止。被告福建风灵公司对VirtualApp实施的复制、修改、发布等行为，因失去权利来源而构成著作权侵权。
四、被告应承担停止侵权和赔偿损失的法律责任。
被告福建风灵公司作为“点心桌面”App(V6.5.8)的开发、运营和发布者，依法应承担停止侵害VirtualApp著作权的行为。同时法院认为，开源软件大多都是免费的，但授权人付出的开发成本是必然存在的，按照侵权获利来承担赔偿责任更为公平合理，故依据相关事实，酌定赔偿数额50万元。
案件解读
开源软件虽然公开，但并不属于可以任意使用的公共产品。绝大部分开源软件都是有著作权且受著作权法保护的。为了开放、共享、交流协作，开源软件的著作权人通过开源许可协议将开源软件的复制权、修改权、发行权等部分权利让渡给了被许可人，被许可人在遵从开源协议的前提下，才可以行使这些权利。如果企业没有按照开源许可协议的规定使用开源软件，就存在很大的著作权侵权风险。
本案为国内首个明确GPL 3.0协议性质的司法裁判案例。法院认定开源协议具有合同性质，在这个版权纠纷案中被告因违反了GPL3.0协议导致GPL3.0协议自动解除，从而失去了GPL3.0协议下的源代码授权保护，进而构成侵权。即便本案在二审中仍存在改判的可能，一审判决也给我们提供了很多思考的空间。
本案首要涉及的问题是违约和侵权责任的竞合。开源协议的被许可人在违反协议设定的义务时构成合同违约，同时，根据具体情况还可能构成著作权侵权。《民法典》第一百八十六条[4]规定，在违约与侵权构成责任竞合时，当事人需要择一地主张权利。本案原告选择著作权侵权这一救济路径，法院通过被许可人违约导致所获授权终止，从而失去权利基础的思路，最终认定被告构成著作权侵权。
此种救济途径和判决思路具有一定的合理性，也有值得推敲之处，比如被告违反“终止授权条款”是因为拒绝将软件开源，如果其同意将软件开源，那么就不构成对GPL3.0协议的违反，进而也不会失去权利来源造成著作权侵权后果。假设被告重新选择遵守GPL3.0协议，那么就又重新获得了合法许可，那么侵权情况就随着被告重新遵守相关开源协议得到了及时制止，被告也并不用停止涉案软件的商业使用。从开源协议的共享精神出发，开源协议的存在就是为了保障人们自由的使用和修改软件，从而促进软件开发的不断创新，故促使开源软件的使用者遵守协议，符合开源协议的宗旨。
其次，本案如果从合同违约角度考察，如果原告选择合同违约的救济路径，要求被告继续履行开源协议要求，法院是否会支持原告的强制开源诉请？从本案中鉴定意见的部分，也可以看到被告开发的软件有与原告代码不同的部分，不排除这些不同部分的代码是被告自主构思、设计和开发的代码[5]。 假设这其中被告独立研发的代码，因被强制要求继续履行开源协议、进而公开相关代码，那么势必会将这些可能是被告享有软件著作权或者商业秘密的代码，进行公开。
这从另外一个角度提出了个警示：
1. 开源代码给代码开发提供了极大的便利，但要尤其注意，一旦加入开源协议就必须严格遵守相关协议条件，否则无论从侵权角度还是合同违约角度，势必会带来法律上的纠纷；
2. 利用开源软件开发软件产品时，要尤其注意对开源代码的使用、注意所遵循的开源协议的内容和要求，否则权利权属就会不稳定，不利于企业相关知识产权、商业秘密的保护。比如从商业秘密角度来看，软件源代码无疑是很多企业极其重视并作为企业商业秘密保护的资产，但若相关代码属于开源代码，或者需要遵循开源协议必须公开的代码，那么商业秘密权利基础就会受到极大挑战。
再次，适用强传染性开源协议的开源软件，是否一经使用，其派生作品必须开源？能否通过技术方案规避强传染性开源协议的适用？本案中，法院并未指定鉴定机构对原告VirtualApp的源代码与被告福建风灵公司被诉“点心桌面”软件的源代码进行比对，一审判决书中唯一提及的技术鉴定，是由原告单方委托进行的，且由于原告并未掌握被告被诉软件的源代码，技术鉴定方案是将原告源代码与被告被诉软件的安装包反编译得到的源代码进行比对。一审法院认定被告被诉软件代码应当开源的理由为：（1）被告确认使用了原告根据GPL3.0协议发布的原告软件代码，且（2）根据GPL3.0协议相关条款及“强传染性”特征，对在逻辑上与开源代码有关联性且整体发布的派生作品，应当遵循GPL3.0协议无偿开放代码。
在实践中，对很多使用开源软件进行技术开发的企业而言，将其开发成果作为开源软件公开，并不符合企业的商业利益。在使用开源软件之前，谨慎考虑确定开源软件的选择及使用方案，从技术层面考虑规避或隔离开源协议传染性，将成为使用开源软件必须进行的前置准备工作。否则一旦涉诉，尤其涉及强传染性开源协议的情况下，被诉方无法提供可靠有力的技术规避或隔离方案说明的，可能会被推定负有按开源协议约定公开其软件代码义务，违反该等义务则导致侵权他人著作权的不利后果。
事实上，实践中因使用者未遵守开源协议而产生的纠纷呈现不断增长的趋势，使用者享受到了知识共享的红利，却也面临巨大的法律风险，企业在使用开源软件时，如不进行合规风险分析，将很容易陷入不利局面。因此建议企业从严格做好开源软件的合规审查，例如谨慎选择开源软件和明确开源协议的版本、内容及相关条件，明确是否可能触发协议的“强传染性”，以及如何从技术层面合理避免被“传染”以及如何合规履行开源协议条款等。
注释：
1.参见张平、马骁：《开源软件按知识产权问题解析》，北京大学出版社2005年12月，第129页。
2.GPL3.0协议第8条为终止授权条款：授权人许可用户在遵守许可证规定的前提下行使某些权利，但用户必须承担相应的义务。若用户违反GPL3.0协议的使用条件进行复制、修改或传播受保护的作品，其通过GPL3.0协议获得的授权将会自动终止。
3.根据《计算机软件保护条例》第九条规定，软件著作权属于软件开发者，本条例另有规定的除外。如无相反证明，在软件上署名的自然人、法人或者其他组织为开发者。
4.因当事人一方的违约行为，损害对方人身权益、财产权益的，受损害方有权选择请求其承担违约责任或者侵权责任。
5.鉴定意见载明：送检的“VirtualApp”源代码与“点心桌面”软件安装包反编译得到的源代码共有421个可比代码文件中，其中有27个可比代码具有高度相似性，有78个可比代码具有一般相似性，有308个可比代码具有实质相似性，有8个可比代码不具有相似性。
京公网安备 11010502049464号