【注】原创作品，未经授权，不得复制、转载或以截图等方式盗用，违者必究
【案例导读】
主张他人软件侵权的权利人，自身在开发阶段使用了受GPLv2协议约束的开源代码，被诉侵权人依据GPLv2协议抗辩不侵权的，该抗辩能否成立？软件权利人是否有权主张他人的侵权责任？软件权利人是否应该依据GPLv2协议，开源其软件的全部源代码？对于以上问题，最高法院的以下判决给出了答案。
【争议阶段】
程序员跳槽至其他公司，利用保存的源代码，在新公司开发同类软件
【涉及技术问题】
1.使用开源代码搭建底层框架，并在底层框架基础上开发上层功能，是否均受开源协议约束？
2.使用套接字（socket）与命令行（command line）等技术手段，能否隔离开源代码与自行开发代码，从而使自有代码免于“被传染”？自行开发代码是否属于“独立且可分离”的程序？
【实务操作启示】
由以上案例分析，笔者尝试归纳如下启示要点，供开发者、程序员等相关人员，在软件开发使用开源代码等实务操作中，作为参考：
**1. 开发者如果在开发中使用开源代码，无论是何种开源协议、无论是底层系统功能还是上层功能，都应该做好隔离工作，避免自身代码被传染强制开源，甚至出现法律纠纷等情况。**实践中通常采用套接字（socket）与命令行（command line）等技术手段，隔离开源代码与自有代码之间的数据交换/通信，从而形成“独立且分离的程序 ”，当然不是说存在数据交换就被传染，具体需要结合开源代码的功能及其在软件中所起的作用进行判断，最终确定被传染的部分应当是与原开源软件形成密切通信，使得二者高度牵连融合成一体的程序。
以安卓操作系统为例，Google公司即通过将系统分为多个独立的不同层级框架，并对每个层级适用不同的开源授权许可协议，以解决GPL许可证的传染性问题。开发者在实际开发中，如果技术条件允许，可以参考上述Google公司的做法。
**2.开发者应该做好核心源代码的保密工作，防止在职及离职员工不当获取。**上述案例中，A公司主张离职员工吴某非法登录其服务器，获取涉案软件源代码，但吴某称是A公司技术人员遇到解决不了的问题，付费让其登录服务器解决，双方各执一词。一审法院最终未认定吴某非法获取A公司源代码，理由是：连离职员工都可以获取源代码，只能说A公司管理存在漏洞，其自身存在过错。可见对源代码合理保管，对软件公司非常重要。实践中基础手段包括与开发人员签订保密协议、设置保密措施、限制接触人员等方式，当然在物理及技术上还可以采取多种加密措施，软件公司可以根据自身需要选择不同的保密措施。
**3.开发者不当获取并使用他人源代码的，不要抱有侥幸心理，**比如如上述案件中，B公司通过成立“防火墙”公司C，意图隔离风险，但是目前企业查询系统及各项信息的便利获取及透明，想“刺破”一个公司的面纱，是比较容易的事，特别是涉及到刑事程序，在公安的侦查、审讯下，一切公司利益在个人利益面前，可能都显得没有那么重要。
合法经营、公平竞争、提高自身创新能力，应该是每个开发型企业遵循的基本准则。
**4.对于软件开发人员（程序员），应该提高自身法律意识，避免给自身带来民事纠纷甚至刑事惩罚。**开发人员在职期间编写的源代码，大多数公司都会在《劳动合同》中约定相关知识产权归公司所有，从法律上讲，履行公司职务开发的软件产品，属于职务作品，开发人员个人无权随意自行使用或者披露给他人使用。软件源代码可以享有著作权，也可以构成技术秘密，因此实践中遭受侵害方，可能会以侵犯著作权罪或者侵犯商业秘密罪，向公安机关报案，如果经侦查犯罪行为属实的，会移交检察院提起公诉，对于此类犯罪行为，严重的可能会被法院判以有期徒刑及罚金，开发人员的大好前程也会断送，所以在涉及源代码使用或披露前，一定要“三思而后行”。
【案情简介】
**一、【事情起因】**A公司投入巨资，经过6年开完完成某网关软件，其SVN服务器记录了整个开发过程，该公司对软件进行了软件著作权登记，并对公司相关标识注册了商标。A公司在公开招标中发现B公司研发的软件，涉嫌侵犯其软件著作权，于是购买B公司软件进行分析，发现源代码中含有A公司的特殊标记及其他相同指标，于是以侵犯著作权罪向公安机关报案。
**二、【公安机关侦查情况】**在公安机关侦查期间，分别询问B公司多名开发人员，根据询问笔录：刘某从A公司离职后，B公司招聘其做硬件开发，后刘某陆续推荐A公司离职员工 B公司任职，B公司成立C公司专门用于开发涉案软件。从A公司离职的吴某在C公司负责涉案软件的开发，吴某表示一开始还想自己开发，但后来嫌麻烦且C公司赶工期，于是其使用在A公司任职期间下载至笔记本电脑的源代码，不仅自己修改，还给整个开发团队作为参考。C公司开发小组把各自负责的模块上传至编译服务器，统一由吴某打包生成程序。经公安机关指定的鉴定机构对2款软件相似度进行鉴定，相似比例接近90%。至原告起诉至法院，公安机关未有定论。
**三、【一审法院判决】**A公司以B公司、C公司、刘某、吴某为共同被告，起诉至法院要求赔偿300万元。刘某辩称其是硬件工程师，不懂软件开发，涉案软件与其无关；B公司、C公司、吴某辩称，涉案软件是A公司在开源软件的基础上修改而成，A公司应该开源，其无权主张侵权。另外对于A公司主张吴某在离职后登录其服务器非法获取源代码，吴某辩称是A公司开发人员有技术问题请其解决，其才登录的，在修复技术问题后，A公司相关人员通过微信向其支付了报酬。
**一审法院认为：**第一，基于开源软件系统框架形成软件产品的著作权，应区分不同情况：基于开源产品本身进行的功能修改、优化及开发，应按开源协议确定其著作权归属；但只是调用开源产品或者基于开源产品之上进行的二次开发，开发者付出创造性劳动足以构成独立作品的，则开发者享有自己的著作权 。第二，根据 GPLv2协议的相关规定，GPLv2协议的许可客体是在 GPLv2协议许可下批准的受版权保护的程序以及基于该程序的衍生产品或修订版本。但不能简单认为与该程序相关的所有软件必须开源。本案中没有证据表明涉案软件各目录下均存在GPLv2协议开源代码。况且，本案中涉案软件源代码并非公开，不存在B公司、C公司有权在GPLv2协议授权下使用第三方开源程序并构建衍生软件产品的先决条件。
根据公安机关委托鉴定情况，B公司、C公司开发软件与A公司软件相似比例超过90%且含有A公司的特殊标识，足以作出B公司、C公司软件部分复制A公司软件的事实判断。综上判决B公司、C公司共同赔偿A公司50万元，刘某与吴某不构成侵权。
【最高法院二审裁判要点】
本案B、C公司基于GPLv2协议提出的不侵权抗辩，不能成立，理由：
**1. 本案系针对涉案软件的著作权侵权纠纷，而非合同纠纷。**尽管涉案软件涉及GPLv2协议这一许可合同，但在开源软件权利人并非本案当事人情形下，基于合同相对性原则，本案不宜对涉案软件是否全部或部分受GPLv2协议约束、A公司是否违反GPLv2协议、以及A公司是否因此需承担任何违约或侵权责任等问题进行审理。
2. 关于涉案软件是否受GPLv2协议约束，该问题涉及底层系统软件是否受GPLv2协议约束、上层功能软件是否构成GPLv2协议项下 “独立且分离的程序 ” 、二者间采用的隔离技术手段、通信方式、通信内容等如何界定以及软件领域对GPLv2协议传导性的通常理解与行业惯例等因素。在开源软件权利人并非本案当事人情形下，亦难以查明与GPLv2协议有关的前述系列事实。
**3. B、C公司并无证据证明A公司通过GPLv2协议已放弃其就涉案软件依据我国著作权法享有的著作权。**退而言之，即便假定A公司因违反GPLv2协议导致涉案软件存在权利瑕疵，该假定瑕疵亦不影响A公司在本案中针对被诉行为寻求侵权救济。最终维持一审判决。
**【裁判结论】**在软件尚未被开源、该软件著作权人认为其软件不受GPLv2协议约束、被诉侵权人则依据GPLv2协议提出不侵权抗辩的侵权纠纷中，软件开发者自身是否违反GPLv2协议和是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈，以免不合理地剥夺或限制软件开发者基于其独创性贡献依法享有的著作权。但需指出，本案最终认定被诉行为构成侵权并支持A公司部分诉请，并不表明A公司将来在潜在的违约和/或侵权之诉中，可免予承担其依法应当承担的违约和/或侵权责任。
在赔偿数额考量方面，应该将A公司使用开源代码进行二次开发，作为考量因素。
【关联裁判规则】
【南京中院：南京某公司诉江苏某公司侵害计算机软件著作权纠纷案（一审）】
**【关于GPL协议的约束】**原告涉案软件的主程序部分受GPL协议约束，因此原告必须公开源代码。原告未公开开源该部分软件源代码。审理期间经本院询问，原告表示不会在本案中公开开源涉案软件源代码。
原告违反了GPLV2协议要求提供相应源代码的义务，违反了GPL协议，构成违约，同时导致授权人与原告之间的授权自动解除，原告基于GPL协议获得的许可终止，原告对原GPL开源代码的继续使用系无权使用。原告起诉被告行为不当，构成侵权，但其自身首先应当规范使用开源代码，遵守开源协议，并证明自身权利的正当和合法，否则即会导致一个不当、不法的行为人指责另一个实施相同行为的不当、不法行为人的逻辑怪圏。法院如果基于原告的该权利认定其他行为人构成计算机软件侵权，即会保护原告未来公司的不当行为带来的利益，势必赋于其特殊法律地位和特别商事利益，不符合公平、诚信原则。
**【关于GPL协议的传染性】**判断GPL协议所能传染的衍生软件或修订版本，区分开源代码与自有代码，即确定自有代码是如何与开源代码结合或交互是前提。其次应结合代码的使用场景，即结合代码的功能及其在软件中所起的作用进行判断。最终确定被传染的部分应当是与原开源软件形成密切通信使得二者高度牵连融合成一体的程序，而非只要有数据交换就会构成传染。本案中，预览程序不是涉案GPL开源代码的衍生作品，未被GPL开源代码传染，故不受GPL协议的约束。原告主张该部分软件著作权的保护，以及被告是否侵害该部分软件著作权的判断，均不受GPL协议的影响。
【最高法院：北京A公司诉B公司侵害计算机软件著作权纠纷案（二审）】
【关于GPL协议的传染性】
第一，前端代码一般是关于用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是涉及用户不可见部分的编码，用以实现服务端的相关逻辑功能。同时，前端代码与后端代码是可以分别独立打包、部署的。因此，前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，原审法院认定前端代码与后端代码相互独立并无不当。
第二，A公司作为权利人在本案中明确放弃以前端代码主张权利，仅以后端代码主张权利，因此涉案软件仅为后端代码而非B公司所称前端文件和后端文件共同构成涉案软件。
**第三，根据2007年6月29日发布的GPL协议第3版第5条关于“一个受保护程序和其它独立程序的联合作品，**在既不是该程序的自然扩展，也不是为了生成更大的程序，且联合作品和产生的版权未用于限制编译用户的访问或超出个别程序许可的合法权利时，被称为聚合体。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分”的规定，B公司所称GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序。本案中，虽然A公司认可其前端代码中使用了GPL协议下的开源代码，但其主张权利的是后端代码，其后端代码是独立于前端代码的其他程序，并不受GPL协议的约束，无需强制开源。综上，B公司的上诉理由不能成立。
