【案例导读】
主张他人软件侵权的权利人，自身在开发阶段使用了开源软件PHP，被诉侵权人由此主张由开源软件编写的源代码也应该开源，原告无权主张侵权。开源软件编写的源代码是否应该开源？开源软件使用手册许可证是否等同于开源软件许可证？软件著作权人是否有权对此类软件进行维权？对于以上问题，以下判决给出了答案。
【争议阶段】
原告主张被告侵犯其软件著作权，被告抗辩称原告的软件使用开源软件编写开发，应该开源且无权主张权利
【涉及技术问题】
开源软件PHP、开源软件PHP开发手册许可证CC
【案情简介】
**一、【事情起因】**A公司对C软件享有软件著作权，经调查发现，B公司使用的软件与其软件雷同，于是A公司向法院提起软件著作权诉讼。
**二、【B公司辩称】**涉案软件C是采用开源软件PHP编写，根据开源软件规则，A公司不能依据开源软件PHP编写的开源软件代码主张著作权保护。
**三、【一审法院判决】**B公司立即停止使用涉案软件，并赔偿A公司经济损失及合理开支92,000元。
**一审法院认为：**首先，B公司在审理中亦自认在软件开发中有参考A公司软件的源代码，表明已经接触了A公司软件的源代码。其次，A公司提供的证据显示，B公司涉案网站的网页及网页源代码中多处可以看出C软件字样，且通过扫描其网站上的二维码，进入的是原告网站，B公司对此又不能作出合理解释。此外，B公司虽然向一审法院提交了源代码，但在一审法院要求其于开庭后十日内向法庭提交鉴定申请，B公司又未能在法院指定的期限内提交鉴定申请。B公司辩称A公司享有著作权的软件为开源软件，无需支付费用，但又未能提供有效证据证明，一审法院对该辩称不予采信。
四、【二审法院：驳回上诉，维持一审判决】
B公司不服一审判决，提出上诉，二审法院认为：
**1. 开源软件与许可证。**就计算机软件而言，开源软件的版权持有人通常授予他人自由使用、复制、散布、研究和改进软件的权利。一般每一个开源软件都会附有一个许可证，该许可证以格式文本形式的授权许可协议体现，许可证规定了软件使用者的权利和义务，使用者只有同意遵守这个许可证才可合法使用开源软件或者使用该开源软件即视为同意接受该许可证。公认的通过开源非营利性组织OSI认证的许可证约有70种，比如BSD许可证、MIT许可证、MPL许可证、GPL许可证，不同的许可证依据不同许可协议条款对使用者要求承担的义务不同，比如GPL许可证就对使用者的限制相对严格，按照该许可证的规定，如果使用者将附有GPL许可证的开源软件中的源代码进行了修改或衍生，对于修改代码和衍生代码，使用者也必须将其以GPL许可证的方式作为开源软件发布出来，而不得将其作为闭源的商业软件发布和销售。。
**2. 开源软件手册许可证不等于开源软件许可证。**需指出本案B公司所举证据所涉PHP开源软件中文官网手册（manual）明确以CC协议（Creative Commons Attribution 3.0或更新版许可中阐明的条款及条件）为附带的开源授权许可协议，该CC协议即是一种许可证，该CC许可证条款明确“许可人在此授予您全球性、免版税、非独占并且在本作品的著作权存续期间内均有效的许可，就本作品行使以下权利：复制本作品或将本作品收入一个或多个汇编作品中……；创作和复制演绎作品，但是任何演绎作品，包括任何形式的翻译作品，均需以合理方式清楚地标示、区分或以其他方法表明原始作品已经被修改或变更；发行、公开传播本作品；发行、公开传播演绎作品。”及“当您发行或公开传播演绎作品时，许可人给获得作品的第三方提供本作品的许可，其条款和条件与您所获得的许可相同。”等内容，CC许可证要求使用者创作的演绎作品，也应传导开源属性遵循相同的CC许可证，无偿给予演绎作品的后续使用者许可。**但需明确的是该软件使用手册的开源性质CC许可证并不等同于软件的许可证，PHP软件是否开源及开源权利取决于PHP软件作者选择何种许可证，**本案中上诉人并未举证证明涉案PHP软件的许可证状况，PHP的手册文档所记载的“PHP一种被广泛应用的开源通用脚本语言”描述并不足以证明PHP软件的开源具体状况。
**3. 使用特定计算机语言编写的软件，并非该计算机语言的演绎作品。**本案A公司主张著作权保护的C软件由PHP语言编写，但计算机语言本身具有工具属性，以特定计算机语言编写的软件作品，通过作者创造性的智力劳动所表现的作品独创性与计算机语言之间并未体现以后者为基础的派生关系，故也并非属于PHP语言演绎作品。即使以演绎作品的角度审查，CC许可证的上述开源传导性，指向的是原作品的演绎作品，涉案C软件也并不受软件手册CC许可证开源义务的约束。
本案中，C软件既未附带开源CC许可证，又在实际公开发布中表明属商业软件，故B公司作为软件用户和同业者应明知C软件为非开源属性，B公司未经许可作商业性的复制使用等，构成对该作品著作权的侵权。一审判决处理得当，应予维持。
【实务操作启示】
由以上案例分析，笔者尝试归纳如下启示要点，供开发者在软件开发使用开源代码等实务操作中，作为参考：
**1. 开发者如果在开发中使用开源代码，无论是何种开源协议、无论是底层系统功能还是上层功能，都应该做好隔离工作，避免自身代码被传染强制开源，甚至出现法律纠纷等情况。**实践中通常采用套接字（socket）与命令行（command line）等技术手段，隔离开源代码与自有代码之间的数据交换/通信，从而形成“独立且分离的程序 ”，当然并不是说只要存在数据交换/通信就一定被传染，具体需要结合开源代码的功能及其在软件中所起的作用进行判断，最终确定被传染的部分，应当是与原开源软件形成密切通信，使得二者高度牵连融合成一体的程序。
以安卓操作系统为例，Google公司即通过将系统分为多个独立的不同层级框架，并对每个层级适用不同的开源授权许可协议，以解决GPL许可证的传染性问题。开发者在实际开发中，如果技术及财力条件允许，可以参考上述Google公司的做法。
**2.对于软件开发人员，应该提高自身法律意识，避免给自身带来民事纠纷甚至刑事惩罚。**软件公司使用的软件，归根结底大多数都是自有开发人员开发，程序员在开发过程中，应该划清借鉴与抄袭的范围，避免给公司及自身带来不必要的麻烦。尤其是在使用开源程序时，务必谨慎，也许因为“无心之举”会造成公司全部源代码被传染，从而被要求强制开源，这对公司商业秘密将是巨大的冲击，小型创业公司可能因此会遭受倒闭、破产，所以软件开发人员在日常开发中，尤其要有相关的意识，为了保护自身，也应该“三思而后行”。
【关联裁判规则】
【南京中院：原告使用GPL开源协议，但不公开源代码，构成违约】
原告涉案软件的主程序部分受GPL协议约束，因此原告必须公开源代码。原告未公开开源该部分软件源代码。审理期间经本院询问，原告表示不会在本案中公开开源涉案软件源代码。
原告违反了GPLV2协议要求提供相应源代码的义务，违反了GPL协议，构成违约，同时导致授权人与原告之间的授权自动解除，原告基于GPL协议获得的许可终止，原告对原GPL开源代码的继续使用系无权使用。原告起诉被告行为不当，构成侵权，但其自身首先应当规范使用开源代码，遵守开源协议，并证明自身权利的正当和合法，否则即会导致一个不当、不法的行为人指责另一个实施相同行为的不当、不法行为人的逻辑怪圏。法院如果基于原告的该权利认定其他行为人构成计算机软件侵权，即会保护原告未来公司的不当行为带来的利益，势必赋于其特殊法律地位和特别商事利益，不符合公平、诚信原则。
【最高法院：后端代码独立于前端，不受GPL协议的约束，无需强制开源】
第一，前端代码一般是关于用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是涉及用户不可见部分的编码，用以实现服务端的相关逻辑功能。同时，前端代码与后端代码是可以分别独立打包、部署的。因此，前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，原审法院认定前端代码与后端代码相互独立并无不当。
第二，A公司作为权利人在本案中明确放弃以前端代码主张权利，仅以后端代码主张权利，因此涉案软件仅为后端代码而非B公司所称前端文件和后端文件共同构成涉案软件。
第三，根据2007年6月29日发布的GPL协议第3版第5条关于“一个受保护程序和其它独立程序的联合作品，在既不是该程序的自然扩展，也不是为了生成更大的程序，且联合作品和产生的版权未用于限制编译用户的访问或超出个别程序许可的合法权利时，被称为聚合体。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分”的规定，B公司所称GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序。本案中，虽然A公司认可其前端代码中使用了GPL协议下的开源代码，但其主张权利的是后端代码，其后端代码是独立于前端代码的其他程序，并不受GPL协议的约束，无需强制开源。综上，B公司的上诉理由不能成立。
