从维权的视角审视开源软件的合规使用

可见，在开源模式下，开源软件的开发者常常有较大的不确定性，而且这些开发者与发起人没有直接联系。如何判断开源软件的权利主体，变得复杂起来。

1. 开源项目主分支版本的权利主体：项目发起人

在L公司诉F公司侵害计算机软件纠纷案[2]中，L公司将涉案软件V APP的初始软件共计3万余行上传到GitHub网站，附加LGPL3.0许可证（后变更为GPL3.0许可证），以供GitHub网站上的注册用户可参与开发。具体而言，用户将修改内容上传提交，并向项目发起人发出请求，此时提交的源代码存在用户的分支版本之中，并未直接修改项目发起人的主分支版本。若发起人认定修改内容，将修改内容用于主分支版本，形成新的主分支版本，相应的提交者成为贡献者。至起诉时，该软件的贡献者显示有34人。被告认为，原告仅为开发工作的召集者和开发者之一，该软件显名作者达34人，原告没有提供证据证明这34位作者将著作权转让给其行使，无权主张著作权。

深圳市中院审理认为，GitHub网站显示项目发起人L公司的股东在GitHub上传了V APP的初始源代码，L公司负责开发运营，且涉案软件登记证书载明原告系V APP1.0的著作权人，与GitHub网站上的内容可相互引证。原告将V APP的初始源代码上传至GitHub网站，后续开源版本系在此基础上迭代演进而来。此外，被告对涉案软件权属虽不认可，但未提交相反证据。综上，法院认为现有证据可以证明原告系GitHub网站上开源软件V APP的著作权人之一。

针对L公司提起本案诉讼是否需要GitHub网站上显示的34位贡献者授权，法院认为，原告将V APP的初始版本源代码在GitHub网站上公开发布，系原告主张权利的基础。其次，发起人对用户提交的源代码进行取舍，对主分支版本的源代码形成起到了决定作用。再次，贡献者选择在GPL3.0许可证的V APP上传自己的源代码，视为按照GPL3.0许可给发起人及其他用户使用。最后，开源项目的贡献者往往人数众多、互不相识又身居世界各地，且随着项目修改处于持续增加、变动之中，若要全体一致同意，实则导致维权无从提起。综上，原告有权提起本案诉讼，无需贡献者的同意或授权。

然而，法院并未讨论涉案软件是否属于合作作品，贡献者是否属于合作作者。该案中，用户修改源代码上传提交，发起人对修改的源代码审查同意后纳入主分支版本，两者达成合作开发的事实与合意，形成的主分支版本属于合作开发的软件。根据《计算机软件保护条例》，合作开发的软件著作权由合作开发者书面约定，若无约定的，须区分可分割使用的软件和不可分割使用的软件，确定著作权行使规则。该案中，涉案APP系一款插件化框架虚拟引擎系统，可能被认定为不可分割使用的软件，其著作权由原告与34位贡献者共同享有。然而，原告未与贡献者签署书面合同约定著作权归属的情况下，则按照不可分割作品的规则共同行使著作权。对于合作作者之一对不可分割作品的维权，法院通常有两种处理方式：一是要求所有合作作者共同起诉（或其他作者出具授权书）；二是追加其他共同著作权人作为原告。

就此，对于不排除可能投入商业化使用的开源项目的主分支版本而言，我们建议，开源项目发起人与贡献者书面约定合作开发的软件的著作权归属。若约定共同享有著作权的，建议书面就贡献者与发起人之间行使诉讼维权的相关权利进行约定。

此外，若企业基于商业上的考虑，难以履行许可证义务，但仍希望使用开源软件时，可以单独向项目发起人寻求使用许可。寻求许可时，可以请发起人提供相应的著作权权属证明，例如计算机软件登记证书。

2. 开源项目分支版本的权利主体：分支版本的开发者

前述案件并未涉及开源项目下基于初始版本形成的分支版本的权利主体。分支版本是用户基于开源项目初始版本修改衍生形成的版本，与主分支版本的区别在于，主分支版本经过发起人审核同意后纳入初始版本，而分支版本未经发起人审核同意（也可能审核未通过），也没有被发起人纳入初始版本，单独形成分支版本。分支版本通常属于初始版本的改编作品（或称演绎作品）。根据著作权法，改编作品的著作权由改编者享有，但行使著作权时不得侵犯原作品的著作权。由此，分支版本的开发者享有分支版本的著作权。

若企业拟使用分支版本，可以向分支版本的开发者寻求许可。同时，除非分支版本和初始版本的许可证允许不经许可的分发行为，使用分支版本开展发行出版等商业行为还应取得初始版本作者的许可。因此，企业在寻求分支版本开发者许可时，可同步确认初始版本的许可证是否允许商业使用的分发行为。

(二) 违反开源许可证的企业可否基于开源软件开发的软件主张著作权？

有企业担心自己在他人的开源软件基础上开发的软件，是否享有著作权并能否提起著作权侵权之诉，特别是在没有完全遵守开源许可证前提下进行的开发。

我们认为，即使开发者违反开源软件许可证，这种情形下基于他人开源软件基础上开发的软件属于演绎作品，开发者仍有权就违法改编的软件主张著作权。只是不同于授权改编的软件享有完全的著作权，法院在考虑违法改编软件的损害赔偿数额时，须排除原作品的部分，仅考虑开发者改编的部分，以及侵权人侵犯改编部分的著作权情况，予以赔偿[3]。

同时，有企业在被起诉侵权时主张，原告的软件含有他人在先开源软件，能否以此主张原告不具有权利基础？实践中，原告和被告可能都使用了在先的第三方开源软件，因此，原告主张软件著作权时，应排除开源软件的部分。然而，若被诉企业提出前述抗辩时，应根据谁主张谁举证的原则提出相应的证据证明，否则仍按照署名、著作权登记等一般规则确定权利主体。实践中，在原告软件闭源的情况下，以含有他人在先开源软件主张原告不具有权利基础来抗辩侵权往往会遇到较大的取证难问题。

(三) 为什么鲜有基于开源许可证的违约之诉？

在违反许可证使用开源软件的情况下，开源软件权利人有权选择提起合同违约之诉或侵权之诉，然而，实践中无论是在我国或者境外司法判决中，以违约的诉由提起诉讼的案件却非常少见。经过对比分析，这主要是由于相较于侵权之诉，开源软件权利人提起违约之诉存在诸多不利。以下是根据我国法律，从管辖法院、适用的法律、证明责任以及违约责任承担等方面进行的分析。

就管辖法院和适用法律问题上，开源许可证作为软件权利人选择的著作权许可合同，法律允许当事人约定争议解决条款。然而，在开放源代码促进会（Open Source Initiative）认证的9个常见开源许可证中，仅Mozilla Public License 2.0规定了争议解决条款。而该争议解决条款规定，本许可证有关的诉讼由被告主要经营所在地法院管辖，并适用被告主要经营所在地的法律，可谓选择了便于使用人诉讼的约定[4]。而对于未约定争议解决条款的许可证而言，若出现合同纠纷，则按照一般的合同纠纷争议解决规则确定管辖法院以及适用的法律。虽然我国《民事诉讼法》《涉外民事关系法律适用法》及相关司法解释对于合同未约定管辖法院和适用法律的情况有所规定，但实践中明确管辖法院和适用法律的过程较为复杂，且存在一定不确定性，这给权利人带来维权上的不便。由此可见，不同于其他合同中，当事人通常约定对一方或双方有利（或便利的）的管辖法院以及适用的法律，开源软件许可证似乎偏向于便利被告应诉。

开源许可证在出现之初，可能因为技术人员未考虑诉讼事项，因此没有规定争议解决条款。但是，随着开源软件数十年的发展，开源许可证的参与起草主体早就注意到知识产权争议处理的事项，但仍未在后来的更新版本加入争议解决条款。对此我们认为，开源许可证如此安排的原因可能出于鼓励来自各地的开发者使用开源软件。开源软件的生命力在于广泛参与，通过适当限制权利人的合法权益，允许和鼓励大众参与，避免开源软件的使用人因担心被诉而怯于使用开源软件。

除了上述管辖和冲突法上对开源软件权利人造成的不便外，违约之诉在证明责任以及责任承担方面，也并不对权利人维权特别有利。

在证明责任上，权利人在违约之诉中，须证明权利人与使用人之间存在开源软件使用的合同，且使用人违反合同项下的义务。实践中，开源软件权利人通常将许可证条款与软件一起发布。但是，若使用人将许可证删除，仍使用开源软件，实质上违反合同义务。但此时，权利人可能难以证明其与使用人之间就开源许可证存在合意，尤其当使用人声称其获得开源软件时并未附许可证。

在损失赔偿上，违约责任的损失赔偿额应相当于因违约给开源软件权利人所造成的损失。然而，开源软件权利人通常免费许可他人使用，可能难以证明因使用人违约遭受了何种经济损失。而相较于违约责任，侵权责任增加了赔礼道歉、消除影响的责任方式，而且，对故意侵权、情节严重的行为，权利人还可以要求承担惩罚性赔偿。在损害赔偿上，侵权责任以开源软件权利人的实际损失或侵权人的违法所得计算金额

综合上述，若开源软件权利人对违法使用人提起违约之诉，选择适用法律和管辖法院就成了摆在眼前的第一道难题。而且，在违约的证明和损失赔偿方面也存在诸多限制。由此，开源软件权利人提起违约之诉难谓一种好的诉讼途径。可能正是因为如此，实践中并未看到开源软件权利人对违法使用人提起违约之诉。

(四) 违反传染性开源许可证开发的软件是否可能被强制开源？

大部分企业会选择对其使用开源软件开发的软件代码和相关文档采取商业秘密的保护方式。若企业未按许可证开源时，法院是否有权要求强制开源，是他们最关心的问题之一。我们尚未查询到国内并不多的开源软件司法判例中有开源软件权利人起诉请求法院判令强制开源的。由于暂未有权利人提出此项诉讼请求，法院亦没有就强制开源问题作出判决，以下分别从合同违约和侵权责任角度来做分析。

从合同违约责任来看，若开源许可证规定衍生程序或修订版本应当使用相同的许可证公开源代码，但使用人未公开源代码，属于合同违约行为。而公开源代码属于非金钱债务。《民法典》第580条规定，当事人一方不履行非金钱债务或者履行非金钱债务不符合约定的，对方可以请求履行，但是有下列情形之一的除外：

法律上或者事实上不能履行；
债务的标的不适于强制履行或者履行费用过高；
债权人在合理期限内未请求履行。

我们认为，公开源代码可能属于“债务的标的不适于强制履行”的情形。公开源代码属于计算机软件的发表行为，属于著作人身权。强制公开源代码意味着强制作者公开发表源程序。这项义务具有人身属性，在性质上不适于强制履行。

就继续履行著作人身权属性的合同义务问题，上海一中院曾就《委托创作协议》的委托人请求法院判令受委托人继续履行协议（协议期间创作的作品都属于协议作品，只能交予委托人发表，不得交予第三人发表的合同义务）的诉讼请求进行判决[5]。法院认为，涉案合同的继续履行义务涉及受委托人的创作自由，具有人身属性，在性质上不适于强制履行。如果强制受委托人不得创作协议作品以外的作品，也不符合著作权法鼓励创作的立法目的。因此，在受委托人违约时，委托人不得请求继续履行，只能请求支付违约金或者赔偿损失。

前述案件中强制履行的合同义务是受委托人创作的作品是否必须交予委托人发表，涉及受委托人就其创作的作品的发表权，属于著作人身权。此处讨论的继续履行强制开源的义务亦涉及到软件开发者对源程序的发表权，同属于人身属性的义务，应同属于债务标的不适于强制履行的情形。或许有人认为，使用者违约行为在先，而且强制公开源代码并未要求使用者继续创作作品，应当强制履行。对此，我们认为，强制履行发表作品的行为，涉及到开发者对作品享有的人身性权利，但并未损害开源软件权利人的人身性权利。在此情况下应优先保护作者的发表权，同时给予守约方请求赔偿损失的补偿。

除了上述的违约责任，对于侵权之诉能否强制使用者开源，我们认为答案也是否定的。首先，强制开源的依据来自开源许可证的规定，著作权法并无此项侵权责任方式。其次，著作权的权利内容亦没有强制后续使用者公开源代码的内容。因此，开源软件权利人很难基于著作权要求使用人公开源代码。

(五) 如何认定受开源许可证影响的软件部分？

违反开源许可证的企业在风险评估时，往往会需要界定受到开源许可证影响的软件部分。总体而言，受到影响的部分应当根据开源许可证的条款确定，部分有传染性的开源软件许可证要求后续软件开源，并不意味着与开源软件相关的所有软件必须开源，比如GPL许可证强制开源的要求限于使用开源软件形成的派生软件或修订软件，不包括与开源软件联合的其他独立软件。以下是我国司法实践中已经明确独立软件的三个案例。

1. 使用开源语言软件开发的应用程序

在W公司诉A公司计算机软件著作权纠纷案[6]中，涉案软件S系统根据开源软件PHP语言编写。开源软件PHP语言的使用手册附CC3.0许可证。CC3.0许可证要求后续修改的演绎作品或汇编作品使用相同的许可证。被告主张，涉案软件S系统应当根据CC3.0许可证的要求公开源代码，但未公开源代码，无权主张著作权保护。

宁波中院二审认为，涉案S软件由PHP语言软件编写，但PHP语言软件的使用手册许可证不等同于PHP语言软件的许可证，其次，即使PHP语言软件使用CC3.0许可证，该许可证的开源要求指向的是原作品的演绎作品。然而，计算机语言软件本身具有工具属性，使用PHP语言软件编程的S软件与PHP语言软件之间并未体现以后者为基础的派生关系，不属于PHP语言软件的演绎作品，不受PHP语言许可证约束。

2. 网站的后端程序独立于开源软件开发的前端程序

在B公司诉S公司侵害计算机软件著作权纠纷案[7]中， B公司在前端程序使用了GPL许可证的开源软件，在诉讼中明确放弃以前端程序主张权利，仅以后端程序主张权利。被告S公司认为，前端程序不能独立工作，必须调用后端程序的图片，两者存在交互且没有进行有效隔离，不是相互独立的，根据GPL许可证的传染性规定，B公司的前端程序与后端程序共同构成其主张著作权的软件，整个软件应视为前端程序的修订版本，应当遵循GPL许可证免费开源。

最高院二审认为，前端代码一般是关于用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是涉及用户不可见部分的编码，用以实现服务端的相关逻辑功能。同时，前端代码与后端代码可以分别独立打包、部署。因此，前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，应认定前端程序与后端程序相互独立。B公司仅以后端程序主张权利，因此涉案软件仅后端程序，而非S公司所称前端程序与后端程序共同构成涉案软件。GPL许可证的传染性包括基于开源软件的衍生程序或修订版本，但不包括与其联合的其他独立程序。综上，B公司主张权利的后端程序不受GPL许可证约束，无需强制开源。

由此可见，仅仅因为一款软件与开源软件之间需要交互，认定前者属于开源软件的修订版本或衍生程序，显然难以成立。软件的运行通常需要与其他软件交互配合，这也是计算机软件提供系统性功能的要求。基于前述技术要求，GPL许可证的传染性不及于与衍生程序或修订版本联合的其他独立软件，既避免GPL许可证的传染性失去边界，也符合GPL许可证鼓励开源的同时维护开发者合法权益的初衷。

3. 将开源软件的衍生程序与其他程序放在不同文件夹，单独进行计算机软件登记

在S公司诉Y公司侵害计算机软件著作权纠纷案[8]中，S公司主张著作权保护的三个功能插件在H软件压缩包内提供下载，解压后，三个功能插件以三个独立的文件夹形式存在。在H软件的根目录以及涉案三个功能插件文件夹内不存在GPL许可证，在压缩包其他文件夹中有GPL许可证。S公司还提供了与三个功能插件相对应的三份计算机软件登记证书。被告Y公司认为涉案三个插件应受GPL许可证约束。

北京高院二审认为，Y公司认可涉案三个插件中并无GPL开源协议，在H软件的根目录下亦不存在GPL开源协议，且S公司对三个插件分别进行计算机软件登记，应当认定涉案软件与其他有GPL协议的软件属于独立软件。综上，对Y公司涉案三个插件应受GPL协议约束的主张不予支持。

综上，小结上述三个案例，法院在实践中在认定独立软件时，通常以软件的分工、功能等进行认定，并辅以计算机软件登记进行判断，而不是以软件是否打包提供下载等形式进行认定。就此，企业在商业上考虑单独提供还是与其他开源软件打包提供，并不会影响被认定为受许可证约束。

(六) 开源软件使用的相关建议

使用开源软件有利于企业降低开发成本，提高开发效率，但也伴随着风险。为降低开源软件使用的法律风险，我们建议企业做好以下工作：

建立软件开发记录的机制。将使用开源软件的情况记录在案，以便根据开源许可证确认权利义务。软件开发记录还可以作为企业保护自身创新成果的权属证据。有时候，即使做了软件开发记录，企业仍难以完全了解软件是否含有开源代码，此时可以考虑借助专业的开源代码检测工具，识别软件中的开源代码。
注意将使用开源软件开发的程序与未使用开源软件开发的程序进行隔离。有些开源许可证有传染性条款，隔离程序有利于将其他未使用开源软件的程序，形成独立程序，避免受到开源许可证传染性的约束。同时，在有条件的情况下，考虑不同软件在功能、分工、所用技术等方面的差别，进行分别独立打包、部署、进行计算机软件登记，有利于其他联合的软件被认定为独立软件。
若企业在有些程序中使用开源代码，有些程序中未使用开源代码时，建议可对开发过程和使用的内容进行详细记录，根据实际使用情况对不同的程序进行分别打包，按相应的要求附上许可证，避免在共同的目录下附上许可证。同时，如前所述，对不同的程序进行单独的计算机软件登记，有助于证明该程序为独立软件，将证明衍生程序或修订版本的证明责任转移到对方身上。
评估自身使用开源软件的需求，视情况尝试寻求软件权利人的单独许可。有时，企业根据其商业安排，难以遵守开源许可证时，可以就其实际需要与权利人单独协商，获得使用许可，避免侵权。

此外，若企业希望利用开源软件帮助开发工作，同时希望开发出完全独立于开源软件的新软件，可以考虑采取净室开发模式（cleanroom engineering），既借鉴开源软件，又避免侵犯开源软件著作权。在净室开发模式下，企业将参与软件开发的程序员分为两个小组：

第一组就需要解决的问题，研究他人的开源软件源程序，总结软件的结构、组织和思路，然后向第二组程序员描述问题和可借鉴的思路；
第二组程序员根据第一组程序员对问题和解决思路的描述，没有接触开源软件源程序的情况下，进行软件开发。

由于著作权法保护表达不保护思想的原则，在净室开发模式下，真正编写源代码的第二组程序员始终未接触开源软件的源程序。即使借鉴开源软件的组织架构思路，最后形成的源程序通常不会与开源软件构成实质性相似，由此避免侵权。就此，企业还应对净室开发模式通过内部规章制度予以明确，并详细记录软件开发过程，以佐证确实采用了此种独立开发模式。