特稿 | 赵启杉：一案管窥中国法院对开源软件侵权纠纷审理的重大突破

2021年9月29日，广州知识产权法院就罗盒网络科技有限公司诉玩友网络科技有限公司等侵害开源软件著作权纠纷一案作出一审判决，判决侵权行为成立，被告须立即停止通过互联网平台提供含有被侵权开源代码的相关软件，并赔偿原告经济损失及维权合理开支共计50万元。该案判决和2021年4月深圳中院就罗盒网络科技有限公司诉风灵科技有限公司侵害开源软件著作权纠纷案的判决一样都承认了GPL3.0开源许可协议的合同性质并认定违反开源许可协议的行为构成侵权行为，但本案的判决书更为全面、详细地阐述了法院对GPL3.0开源许可协议性质及其若干条款的理解，深入剖析了诸如开源软件的著作权归属与行使、开源软件侵权行为的认定以及开源软件侵权行为的法律后果等在开源软件法律纠纷中可能涉及的若干核心法律问题，对把握开源软件法律纠纷案件的审理思路甚至理解开源软件合规治理的关键点都有重要的指导意义。

本案原告济宁市罗盒网络科技有限公司（以下简称罗盒公司）成立于2017年8月8日，其股东之一罗迪(Lody)在2015年开发了“罗盒”（Virtual App）插件化框架虚拟引擎系统（简称：Virtual App V1.0）并于2016年7月7日在Github网站上传了Virtual App的初始源代码共计31097行，次日附加了LGPL3.0协议。2016年9月10日，罗迪将LGPL3.0协议变更为GPL3.0协议，随后声明任何人如需将该软件用于商业用途，需要与作者授权的负责人联系购买。2017年10月29日，罗迪删除了Github网站上的Virtual App所附带的GPL3.0协议。2017年11月8日罗盒公司就Virtual App V1.0取得计算机软件著作权登记证书。2017年12月30日，罗迪在Github上发布声明：“VirtualApp对外开放的源代码将于2017年12月31日停止更新，VirtualApp商业版代码将持续更新”。

本案被告广州市玩友网络科技有限公司（以下简称玩友公司）成立于2016年9月7日，并就名为“微信视频美颜版”、“微信视频美颜相机版App”、“微信视频美颜相机”、“微信视频美颜相机版”的四款软件取得相关著作权登记证书。玩友公司通过“华为应用市场”、“应用宝”等平台在提供下载，用户可以有30分钟免费使用时间，之后需支付会员费才可继续使用。本案其他三位被告深圳冠准航科技有限公司、深圳奥斯坦科技有限公司和祥运实业（深圳）有限公司为玩友公司的合作伙伴，代玩友公司收取会员费，提取相应服务费后结算给玩友公司。

2019年3月罗盒公司在广州知识产权法院起诉四位被告，并提供司法鉴定报告，主张被告玩友公司提供下载的四款软件与原告拥有著作权的Vritual App软件（2017年12月30日版）构成实质性相似，被告玩友公司的行为已经构成软件著作权侵权，请求法院判令被告立即停止被控侵权软件的下载、安装和运营服务，赔偿原告经济损失1500万，赔偿原告维权合理费用15万并承担本案诉讼费；其他三位被告应承担连带责任。

被告玩友公司在答辩中提出五点反驳理由：（1）罗盒公司并非涉案计算机软件的著作权人，因为其诉称拥有著作权的软件的源代码为在GitHub上开源项目Virtual App- Master版本的开源代码，而参与编写该开源代码的有32人，项目人asLody（即罗迪）仅为著作权人之一，asLody（即罗迪）未经其他著作权人的同意将该开源软件的全部著作权转让给罗盒公司，侵犯了其他著作权人的权利，该单方转让著作权的行为应被认为无效；（2）Virtual App项目开始适用LGPL许可协议，后改为GPL3.0协议，而根据GPL3.0协议第4条、7条和第10条的规定，Virtual App的项目人不得附加限制商业使用条款；（3）开源代码免费公开发布后，其著作权已经“权利用尽”，项目人不得撤销或者反转开源授权许可；（4）Virtual App项目仅可实现沙盒分身基础功能，玩友公司在沙盒分身功能基础上自主研发创新，开发出了微信视频美颜App，其主要功能为微信视频美颜而非沙盒分身功能；（5）玩友公司在收到起诉状后就下架了被诉侵权软件并对软件版本做了相应的更新迭代。

本案另外三位被告主张自己与被告玩友公司的合作关系仅为代收用户付款，在合作之初已经对被控侵权软件的著作权登记证书进行了形式审查，没有能力对其进行实质性判断，不是本案的共同侵权人，不应承担连带责任。

本案2019年3月4日立案，2020年11月3日庭审。一审广州知识产权法院在查明本案相关事实后，将本案的争议焦点总结为三方面问题：（1）罗盒公司是否有权提起本案诉讼；（2）被诉侵权行为是否侵害罗盒公司的复制权、发行权和信息网络传播权；（3）若侵权成立，四位被告应分别承担怎样的法律责任。这三方面争议焦点分别对应了开源软件的著作权归属问题、侵权行为判定问题和侵权救济问题，对这个问题法院结合开源软件的开发方式、开源协议的法律性质和国外相关判例情况等进行了深入分析。

（一）开源软件的著作权归属问题

在本案中，被告提出的第一个抗辩理由涉及原告的诉讼主体资格问题，也涉及如何确定开源软件的著作权归属问题。在开源社区中通常是由项目发起人首先公开发布自己编写的源代码，成为该开源项目的项目管理者；而其他感兴趣的开发者可能根据自己的兴趣对初始的开源代码进行修改或增补，而如果其修改增补被项目管理者接纳合并到原有开源代码中，则这些“二次开发者”就成为该项目的贡献者。具体到本案中，法院查明，GitHub官网上的开源项目管理者可以在该网站上传其独立编写的软件项目初始源代码并选择适用的某一种开源许可授权协议，从而创建主分支master；而其他用户可以自由浏览并获取该项目源代码，即获得非排他性、全球性的许可，可以基于主分支创建自己的分支并自行进行代码的修改维护。其他分支可以向主分支提起“创建拉取请求”，即申请将分支中的修改合并到主分支中，项目管理者决定是否同意其他用户的“创建拉取请求”，而一旦该分支被合并到主分支中，该用户就成为了主分支的贡献者。

本案中，被告主张Virtual App软件为项目管理者和相关贡献者共同创作的、不可分割使用的合作作品，由各方共同享有著作权；而原告则主张合作作品需要创作双方有合作创作的合意和合作创作的行为，在本案中其他贡献者是在各自独立的分支空间中修改代码，其修改代码时并未与项目管理者达成修改合意，修改内容是否被主分支接纳也完全由项目管理者单方决定，故Virtual App不构成合作作品。另外，原告还举证证明在Virtual App软件中，经与被控侵权软件进行对比后被认定构成相似的421个代码文件有358个是由项目管理者asLody（即罗迪）独立完成的，而其他63个代码中也有大量独创性的代码是项目管理者创作完成的，其他贡献者只是在其基础上作出了少量、不具有独创性的代码修改。鉴于2017年12月30日版的Virtual App软件中90%的代码都是asLody（即罗迪）完成的，故罗盒公司是该软件的唯一著作权人。

对于本案所涉开源软件的著作权归属问题，法院的观点是：（1）罗盒公司股东罗迪作为项目管理人于2016年7月7日将Virtual App初始版本源代码（507个文件，共31097行）在GitHub官网上进行开源发布，该初始版本占本案Virtual App V1.0开源软件代码的绝大部分，是其核心基础，而其他贡献者提交的代码是在此基础上的升级优化，且由项目管理人决定是否将该修改diamagnetic并入主分支，因此其他贡献者提交的代码并未对涉案软件著作权产生实质影响。（2）在中国法下，合作作品的认定需要满足四个要素：作者为两个或两个以上、主观上有共同创作的合意、客观上有共同创作的行为以及合作作者贡献了独创性的表达。但是在本案中被告玩友公司并未举证证明贡献者提交的代码是否属于有独创性表达的创作，从而无法认定本案涉案软件属于合作作品；（3）涉案软件使用LGPL3.0或GPL3.0开源协议，其他贡献者在申请将其代码合并入主分支时即默认同意使用相关开源协议，也就意味着同意将其修改增补的代码贡献给项目管理者和其他用户在授权许可协议范围内自由使用；（4）罗盒公司在本案中已经就涉案软件提交了著作权登记证书，从2017年8月开始对Virtual App项目进行公司化运作开发运营，被告玩友公司否认罗盒公司的著作权人身份，但并未就此提供证据。故法院认定本案原告拥有涉案软件的著作权。

另外，法院认为开源软件项目的贡献者往往人数众多，互不相识且散布于世界各地，而且只要相关项目保持开源，则贡献者还会呈动态变化。因此即使认定涉案软件属于合作作品，也无法查清所有的权利人，不能要求项目管理者在获得其他所有贡献者的授权后才能提起诉讼，故本案原告罗盒公司有权单独提起本案诉讼。

（二）开源许可协议的性质及开源软件侵权行为的认定问题

关于本案中如何判断被告玩友公司是否侵害了原告罗盒公司的复制权、发行权和信息网络传播权的问题，法院认为涉及三方面法律问题：第一，怎么理解GPL3.0协议的法律性质和效力；第二，罗盒公司是否有权在GPL3.0协议中加入商业使用限制保留条款；第三，玩友公司是否违反了GPL3.0协议的规定。

1.GPL3.0开源许可协议的性质及违反GPL3.0开源许可协议的法律后果

本案中，被告玩友公司主张“开源免费公开发布一旦完成，其‘权利已用尽’”，这种观点显然误解了开源许可的真实性质，故法院首先对开源许可协议的性质进行了澄清。首先，法院列举了2008年美国联邦巡回上诉法院审理的Jacobsen 诉Katzer上诉案和德国法兰克福地区法院审理的Welte诉D-Link案件，说明了美国法院和德国法院都认同了开源许可协议的合同性质，且均认为违反相关开源许可协议规定的使用行为构成侵权行为；其次，法院认为在中国法下，GPL3.0协议的内容具备合同特征，属于广义的合同范畴，其格式化的条款明确规定了使用相关开源代码的方式，授权内容符合中国著作权法的规定，合法有效，而使用者的使用行为自动获得来自初始授权人的授权，无须另外签订书面合同。第三，法院认为GPL3.0协议属于附解除条件的著作权合同，许可条款是著作权许可的条件，而如果使用者违反条款规定，则许可的前提条件已不复存在，其所获得的许可授权也自将自动终止，相关使用行为也将构成侵权行为。

2.是否可以在GPL3.0开源许可协议中附加商业使用限制

本案中，原告罗盒公司在声明Virtual App 开源版适用GPL3.0协议的同时也声明任何人要将该软件用于商业用途，均须与项目管理人指定的联系人联系，另外原告还于2017年10月29日删除了GPL3.0协议声明并自2017年12月31日起停止更新涉案软件的开源版本，转为开发不开源的商业版本。被告指责原告的上述行为已经违反了GPL3.0协议的相关规定，且无权阻止自己对开源代码进行商用。

对此，法院首先认为根据GPL3.0协议的约定和性质，只要某个软件版本加入了GPL3.0协议，就无法删除该协议，意味着相关开源版本的源代码将永久保持开源。权利人只能在后续其他更新的版本中变更或删除GPL3.0协议，但不影响此前已经发布的开源版继续适用GPL3.0协议。本案中，罗盒公司起诉主张侵权的是2017年12月30日的版本，并承认与2017年10月29日删除GPL3.0协议之前的版本差别不大。因此，法院认为原告据以主张权利的软件仍为适用GPL3.0协议的开源软件。

其次，法院认为罗盒公司无权在GPL3.0协议中加入商业使用限制保留条款，原因是：第一，开源软件不等于不能有商业开发，GPL3.0协议序言就强调所谓自由软件（free software）强调的是自由，而非价格免费，GPL3.0协议的核心要义在于确保后续使用者能够获得和享有发布自由软件副本的自由；第二，GPL3.0协议第7条规定了六种可以添加的补充附加条款，其中不包括商业使用限制保留条款；而不属于第7条规定的条款都被视为第10条规定的不可以对GPL3.0协议所授权的权利行使附加的“进一步限制”。因此被告玩友公司无需遵守罗盒公司在GPL3.0协议中附加的商业使用限制保留条款，而罗盒公司主张的玩友公司违反商业使用限制保留条款从而构成侵权的诉讼请求缺乏依据，法院不予支持。

3.违反GPL3.0行为的表现及开源软件侵权行为认定

本案中，法院认为原告主张被告构成侵权的理由不够准确。法院虽然认可了原告罗盒公司提交的司法鉴定意见书，被控侵权软件“微信视频美颜版”与涉案的Virtual App软件中的开源代码（具体为沙盒分身功能部分的源代码）构成相似，但被告玩友公司就被诉侵权软件收取会员费的行为在性质上属于用于运营维护和技术支持的软件服务费，而非针对软件程序、文档下载的收费，故收取会员费的行为没有违反GPL3.0协议。法院认为被告玩友公司真正构成侵权的行为是未向用户提供被控侵权软件的源代码。法院查明，玩友公司提供下载被诉侵权软件安装包，但用户无法同时下载该软件的源代码。按照GPL3.0协议的规定，在发布包含适用该协议的源代码的程序副本时，无论收费还是免费都应该确保副本的接收者也能够得到源代码。所以被告玩友公司至少应该公开被诉侵权软件中适用了涉案软件沙盒分身功能部分的源代码。

至于本案中玩友公司是否应该公开整个被诉侵权软件的源代码问题，法院认为需要根据GPL3.0协议关于“传染性”的规定和涉案被诉侵权软件中源代码的结构来进行判断。首先，法院提醒被告当开源代码和闭源代码结合产生交界点时，为避免冲突，在开源代码基础上进行再创新时应当选择较为宽松的许可协议，避免因为融合程度过高而导致所有源代码都必须公开；而无法回避许可协议之间的冲突时，则应该采取简单的编程接口连接，降低软件代码运行时的融合程度。其次，法院指出GPL系列许可协议是具有“高传染性”的开源协议，除非二次创新者能够证明其修改增补的代码并非使用开源代码程序的衍生作品、未与该开源代码所在程序混合在一起、也未意图在某种存储或分发媒介上组成更大的程序，才可以认定其创新部分构成独立的作品，并不受GPL协议的约束。第三，法院认为在本案中，玩友公司未能举证证明沙盒分身功能部分源代码是独立的，也未对后续开发的代码进行分层隔离，因此被诉侵权软件应该整体适用GPL3.0协议，玩友公司应该公开整个被诉侵权软件的源代码。

（三）对开源软件侵权行为的法律救济

1.对侵权者的追责

如前文所述，法院认定GPL3.0协议是附解除条件的许可合同，凡是违反GPL3.0协议条款的行为都将导致该许可合同的自动解除。既然被告使用涉案软件开源代码的行为因未遵守GPL3.0协议相关规定而导致合同解除，其继续使用的行为就未获得许可，既构成违约也构成侵权。

法院认为违反开源软件许可协议的行为在理论上存在违约救济和侵权救济两种方式，但两种救济的形式和力度存在差别。在违约救济下，守约方可以获得的救济主要是继续履行合同和损害赔偿；在侵权救济下，被侵权人可以获得的救济包括停止侵害、损害赔偿、恢复原状和临时禁令救济等；而且违约救济下的损害赔偿责任范围小于侵权救济下的损害赔偿责任范围。两种救济方式竞合，由当事人自行选择。本案中，罗盒公司主张的是侵权救济，故法院判决玩友公司停止侵权（即立即停止在相关平台上继续下载被诉侵权软件）和赔偿原告经济损失。

2.连带责任的追究

本案中，原告罗盒公司还主张另外三位被告构成共同侵权并请求追究其连带责任。对此，法院认为，本案的另外三位被告准航公司、奥斯坦公司、详运公司仅代玩友公司收取会员费，而且已经对被诉侵权软件的著作权登记证书进行了初步审查，不宜对其施加过高的注意义务，故未认定该三家被告构成共同侵权。

需要注意的是，本案中的三位被告未被认定为共同侵权人的关键在于其本身并没有复制、发行和修改被诉侵权软件。按照GPL3.0协议的规定，该协议不对程序承担担保责任，使用该协议下包含开源代码程序的风险均应由使用者承担，除非有特殊的法律要求或书面约定，任何开源代码的著作权人都不对依据GPL3.0协议修改或发布程序的第三方对使用者造成的损失负责。换言之，对已经违反了GPL3.0协议的侵权软件或代码的复制、发行和修改行为也会存在被追究侵权责任的法律风险，而且后续的侵权者不能以源代码的前一提供者先侵权为由抗辩开源代码著作权人对其追究侵权责任。

3.损害赔偿的考量因素

本案中，原告请求的损害赔偿（1500万且不含维权费用）和最后法院判决的损害赔偿（50万且包含维权费用）之间还是存在巨大的差距。在该案中，法院在计算损害赔偿数额时综合考虑的因素包括：（1）涉案Vritual App软件的源代码所实现的沙盒分身功能是被诉四款侵权软件的基础功能，虽非应用层面的核心功能但是如果缺乏该基础功能，则四款软件将无法使用；（2）被诉四款侵权软件在各平台上下载累计上百万次；（3）罗盒公司提供了其对Virtual App商用版本对外授权许可的收费证据，法院予以认可；（4）玩友公司违反GPL3.0协议从而构成侵权的是未提供源代码的行为，因此无需调查会员费流水；（5）玩友公司的侵权行为性质、侵权时间以及拒不履行开源授权许可协议的情况；（6）原告维权的合理费用。值得注意的是，法院虽然在判决书中认定目前的证据无法证明涉案Vritual App软件的开源代码是合作作品，但是在损害赔偿部分法院仍然规定，如果有涉案开源代码的贡献者能够证明其属于合作作品作者之一的，可以基于法院判决的赔偿数额向罗盒公司主张分割赔偿款。

（一）本案的意义

罗盒公司提起的系列开源软件侵权诉讼案件可谓中国法院审理开源软件法律纠纷案件中的里程碑式的案例。本案和2021年4月深圳中院对罗盒公司诉风灵公司案的判决都明确承认了在中国法下开源许可协议的合同属性及其合法性，并明确了对于违反开源许可协议的行为，著作权人可以在违约救济和侵权救济中自行选择进行维权。较之之前中国法院在涉及开源软件法律纠纷案件中对开源协议模糊的态度，广州知识产权法院和深圳中级人民法院的明确表态无疑是对开源许可规则的一种认同和支持。

更为重要的是，广州知识产权法院在本案的判决中明确承认了GPL3.0协议的“高传染性”，即承认了在GPL3.0协议下开源程序的衍生作品或修改作品也需要遵循GPL许可协议开放其源代码。在之前中国法院审理的诸多涉及开源代码的计算机软件著作权侵权纠纷中，比较多的都是原告诉被告侵犯了其闭源的商业软件著作权，而被告抗辩原告开发的所谓商业软件是在适用GPL协议的开源代码基础上的修改和增加，其代码本身就应该开源，而不能追究使用者的侵权责任。此前，受理该类案件的法院要么不承认开源协议的法律约束力，特别是传染性条款的约束力，认为原告就其在二次开发中撰写的代码甚至整个软件享有著作权；要么虽然承认开源协议的法律约束力，但是却没有按照开源协议本身对“传染性”的界定和判断规定分析原告撰写的代码是否属于衍生作品或者修改作品而应开源。例如，在数字天堂（北京）网络技术有限公司诉柚子（北京）科技有限公司等侵犯计算机软件著作权纠纷案中，被告抗辩原告主张侵权的软件使用了受GPL协议保护的第三方开源代码，按照GPL协议的规定，原告开发的三款插件构成衍生作品，也应公开源代码。一审法院认可了GPL协议的法律约束力，但是在分析原告三个插件是否构成衍生作品时并没有遵循GPL协议的规定，而是以该三个插件均处于独立的文件夹中，该文件夹中并无GPL开源协议为由认定了三个插件的“独立性”以及GPL协议对该三插件无法律约束力；而二审法院不认同一审法院关于三个插件具有独立性的分析，但并未澄清应该如何判断独立性，而是直接回避了对GPL传染性问题的讨论，依据原告对涉案软件的三个插件进行了著作权登记认定原告对整个涉案软件享有著作权，有权禁止他人未经许可使用涉案软件。很明显，在数字天堂诉柚子公司案中一审、二审法院对GPL协议和传染性的理解是与GPL协议本身的规定有偏差的。而在广州知识产权法院对罗盒诉玩友案的判决则认可了GPL3.0协议的传染性条款，并按照其关于衍生作品的规定，判定被告在沙盒分身功能代码基础上撰写的其他应用层的代码已被“传染”，被告应该公开被诉侵权软件的全部源代码。这一认定较之前的判例已经是巨大的进步。

值得称道的是，本案法院在撰写判决书时没有局限于对案件本身的处理，还详细介绍了开源许可的若干特征，澄清了对开源许可认识上的若干误区。例如，针对将开源软件与著作权对立起来，认为开源软件没有著作权、可以任意免费使用的错误认识，法院指出“开源软件的‘自由’体现为通过著作权许可给予的自由，而不是自由得没有著作权”、“开源软件的权利人不但没有完全放弃著作权，而且还可通过开源软件许可协议寻求著作权保护”。针对认为复制、分发和修改开源代码不能收取任何费用的错误观点，法院澄清“开源软件不等于不能有商业开发”，“商业软件一般通过控制软件源代码、出售软件许可来获益”而“开源软件盈利模式多样，主要通过商业化服务模式来获得商业利益”，如“硬件捆绑、增值产品、技术支持、广告业务等”。针对所谓在开源代码基础上“研发创新”部分可以作为闭源软件进行商业许可的观点，法院更是“不厌其烦”地细致解释了如何解决软件兼容性问题以及GPL3.0协议的传染性问题，还以谷歌公司为例，介绍了其开发安卓系统时如何将使用GPL协议的开源代码限制在独立的底层Linux内核空间中，并在上层类库和应用框架及用户空间部分适用较为宽松的ASL开源协议作为隔离措施以避免GPL协议传染整个安卓系统，确保安卓系统中上层应用软件开发者得以适用ASL开源协议进行开发，从而自由选择是否公开其源代码。从一定意义上讲广州知识产权法院撰写的本案判决书已经可以作为开源合规宣传的一份生动资料，供相关企业借鉴和学习。

（二）值得进一步研究的法律问题

随着开源代码在软件开发中越来越频繁被使用以及我国产业开源生态的逐步建立，开源法律纠纷必然会在未来几年的中国呈上升趋势。涉及开源软件的法律纠纷因为涉及合同与侵权问题的竞合，涉及众多开源协议及其附加条款的解读和对软件开发应用场景的技术分析，而注定具有相当的复杂性。广州知识产权法院对罗盒诉玩友公司的判决虽然已经是具有里程碑意义的判决，分析了若干开源软件纠纷案件中的核心法律问题，但是在开源软件法律纠纷领域还有很多法律问题有待进一步的研究。

1.关于开源软件的著作权归属问题

开源生态的重要特点之一就是通过在开源社区中公开源代码并附加适用的开源许可协议，确保其他开发者可以获取、修改和增补代码，不断完善有关开源项目，从而弥补了传统私有软件的公司化和封闭性的缺陷。有别于私有软件开发者的单一，开源软件的创作者包含了项目管理人和众多的贡献者，而如何认定项目管理人和贡献者之间的法律关系，直接决定了开源软件的著作权归属问题。本案中，法院对这个问题作出了一定分析，但是似乎还存在一些模糊的边界未能澄清。第一，判断开源软件是否属于合作作品的标准是什么？是根据贡献者提交的代码的数量占比还是需要证明贡献者提交代码的“独创性”表达？具体到开源项目中又如何理解所谓“独创性”表达？第二，本案判决书认为“贡献者申请将代码并入主分支的行为视为同意接受相关开源许可协议，即贡献其代码给项目管理者和其他用户”，那么所谓的“贡献”是指授权还是放弃著作权？如果是授权，则将推导出开源软件属于合作作品的结论；而如果认为是放弃著作权，则为什么项目管理者选择和适用相关开源许可协议的行为则不被视为放弃著作权呢？很明显，将“贡献”一词理解为放弃著作权会与开源软件的基本性质和理念相悖；而将“贡献”解释为授权，则似乎又与需要单独判断开源软件是否属于合作作品的结论有一定的冲突。第三，本案判决书并没有完全否认开源软件构成合作作品的可能性，而且在判决中还认为涉案软件的贡献者如果能够证明其为合作作品作者之一，可以向原告主张分割赔偿款。本案中，法院认为即使认定开源软件为合作作品，也不会影响开源软件的项目管理人未经其他贡献者（合作作品著作权人）的授权单独就该合作作品提起诉讼的诉权，但是法院却没有回答本案中被告答辩提出的问题——作为开源软件的项目管理人（本案中为自然人罗迪）是否可以未经其他贡献者的同意将该开源软件转让给第三方（本案中为法人罗盒公司）？如果说本案中原告罗盒公司的著作权并非来自于罗迪的转让行为，那么其对涉案软件的著作权又是怎样取得的？因为在开源软件的开发中，由某个自然人在开源社区发起项目成为项目管理者，其他程序员跟进修改成为贡献者非常普遍，而后续项目管理者将相关开源软件入股成立公司或进行转让的情况也时有发生，如何厘清项目管理者和贡献者之间的法律关系，从而确定开源软件的著作权归属问题将成为审理开源许可纠纷案的不得不面对的法律问题。对此还需要结合开源软件的开发模式和有关法理进行进一步的深入分析。

2.关于“传染性”判断问题

当前由于很多国内企业尚未有最基本的开源合规理念，在被诉的开源软件侵权案件中看到的主要是非常明显的甚至可以说“低端”的违反开源协议的行为：没有附带开源协议正文、没有标注开源代码作者著作权标识、没有发布无担保声明以及将大量开源代码与自己撰写的代码整合作为闭源软件进行商业推广。对于这类明显的违反开源协议的行为，认定其构成侵权并没有太大的难度。但是随着企业开源合规体系的建立，无论是企业还是法院，都会面临如何甄别和判断闭源代码是否会被开源代码“传染”从而必须公开源代码的问题，而“传染性”的判断必然将成为开源合规和开源软件侵权纠纷处理中最具有挑战性、争议最为激烈的领域。

“传染性”问题判断的难度体现在两个层面：第一，查明相关开源协议关于“传染性”的规定存在一定难度；第二，比对这些规定，分析具体二次开发的软件对开源代码的应用场景是否是相关条款所描述的场景存在困难。首先，一些开源许可协议关于传染性规定本身用语存在模糊性，例如在GPL3.0协议中规定将一个覆盖作品纳入到“聚合体”中不会导致“聚合体”的其他部分适用GPL3.0协议。至于何为“聚合体”在GNU官网上给出了说明阐释——“聚合体”包括许多可分离的程序，这些程序在同一个CD-ROM或其他媒体上一起发布，该“聚合体”不能是覆盖程序的扩张，也不能是两个程序组合而成的大程序。而同时GNU的说明还指出关于目前区别两个可分离的程序和一个拥有两个部分的程序的衡量标准主要是通信机制和通信语义，尽管在GNU的阐释中列举了pipes、sockets和command-line arguments为通常两个独立程序之间的通信机制，但是又说如果通信语义足够紧密，交换了复杂的内部数据结构，那么即使采用上述通信机制也可以被认定为两个部分合并为一个大程序。这种反转再反转、层层叠加的阐释并没有完全厘清“传染性”的判断标准。最终GNU认为“可分离性”的判定是个法律问题，最终由法院判决决定。但由于目前世界范围内有关开源软件的诉讼案件鲜有走到需要法院区分“两个可分离程序和拥有两个部分的程序”这一步，也就无法看到法院是如何通过通信机制和通信语义分析来进行判定的。其次，对于传染性的判断依据不仅仅局限于许可协议文字表述本身，还要参考有关社区发布的问题解答以及社区中发布和更新的豁免条款。例如，GNU在其官网上还对各方针对“传染性”判断提出的若干问题进行了解答，这些解答也可以作为分析具体应用场景的参考。又如有些开源协议允许设置豁免条款，即对一些本来应该认定为被“传染”的场景在一定条件下给予豁免。在一些权利人主动性比较强的开源社区中，豁免条款可以按照权利人的意思设置和更改。要逐一查明在特定时间内针对特定应用场景是否存在豁免条款和具体应用场景是否可以适用这些豁免条款需要对相关软件技术场景有准确的理解，同时又随时跟踪相关社区的动态能及时获取相关豁免条款信息。第三，在实际软件开发中，适用不同开源协议的代码混合、开源代码和闭源代码混合的情况很常见，此时判断开源协议之间的兼容性以及开源代码和闭源代码之间的“隔离”措施是否真正能够阻断“传染性”也存在一定难度。

对开源代码“传染性”的判定，关系到对二次开发部分的代码是否构成独立作品的判断，也往往关系到有关纠纷中原告提起侵权诉讼的请求权基础或者被告的行为是否构成违反开源协议或侵权的判断。随着产业界对开源合规的深入了解，必然会产生一些处于“灰色”地带的开发行为，因此围绕“传染性”问题的争议一定会成为未来开源软件法律纠纷的焦点问题之一。

3.关于法律救济问题

关于开源软件侵权纠纷中的法律救济问题，业界一直存在一个疑问：法院是否会判决要求被控侵权软件“强制开源”？其实这个问题涉及违反开源协议行为的违约责任和侵权责任竞合的问题。按照广州知识产权法院在罗盒诉玩友案中的分析，违反GPL协议的行为既为违约行为，又因为GPL协议为附带解除条件的合同，行为人的行为将导致开源许可协议自动解除，因此对开源代码的非合规使用又同时构成侵权行为。权利人可以在追究违约责任和侵权责任中自行选择。所谓“强制开源”其实是纠正未合规使用开源代码者的违约行为，指向的应该是“履行合同”，因此属于违约责任的救济范畴。而侵权责任的救济主要对应停止侵权和损害赔偿，其中停止侵权主要指停止继续复制发行和传播侵权软件。所以法院是否在判决中要求被控侵权软件“强制开源”取决于权利人诉讼请求中寻求何种法律救济以及具体案件中法院对“传染性”作出了怎样的判断。当然值得探讨的是，法院是否可以根据案情在具体案件的判决中提供“强制开源”（或被传染部分强制开源）以“继续履行合同”和“停止侵权”二选一的救济？怎样的法律救济更具有弹性、更符合产业发展需求，也值得进一步研究。