计算机软件案件知识产权法律问题研究

目次

一、计算机软件案件的概况及特点

二、计算机软件案件审理中反映的问题

三、对策建议

（一）软件侵权纠纷

1.关于权利主体身份的确定

2.关于侵权事实的固定

3.关于实质性相似的认定

4.关于最终用户侵权责任的认定

5.关于赔偿责任的确定

6.关于涉开源软件纠纷的审理

（二）软件合同纠纷

1.关于开发成果验收合格的认定

2.关于合同目的是否实现的认定

3.关于合同解除后的处理

一、计算机软件案件的概况及特点

（一）概况

2017年1月，南京、苏州知识产权法庭成立，跨地区集中管辖包括全省涉计算机软件案件在内的技术类案件（本文以南京和苏州两个知识产权法庭跨区域集中管辖审理的计算软件案件为样本，不包括江苏省其他法院受理的名为技术合同纠纷实为计算机软件合同纠纷案件，也不包括2022年5月1日起不再实行集中管辖的计算机软件合同纠纷案件）。6年来，两法庭审理涉计算机软件案件共计1711件。除因受疫情以及2022年5月1日起不再由法庭对技术类合同纠纷案件集中管辖等因素影响，受理的案件数量略有下降外，案件整体呈逐年递增趋势。其中，2021年为409件，同比增长最多，为56.7%。

（二）特点

1. 从领域来看，涉新兴领域案件不断增长。近年来涉计算机软件案件已不再局限于传统的制造（企业生产、销售、管理等）、服务（家政、教育、物流）、零售、餐饮等领域，涉医药、游戏、数字化农业、新能源、生命科学、光学、云计算、物联网等新兴领域案件不断出现，反映了新兴领域对信息化软件的需求上升。除了纯粹的商业领域，部分机关事业单位也在消防、城市管理、交通管理等领域展开智能化、信息化建设，政府订单的商业需求不断扩大。此外，随着移动互联网的发展，各行业对移动应用软件需求井喷，涉及移动端计算机软件合同纠纷明显增长。课题组通过审理案件发现，新能源充电桩APP、数字化农业APP、光学仪器实验APP、居家养老综合性APP、智能健身房模块、社区综合服务管理信息化平台、智慧教育教师服务空间平台等促进数字化场景融合应用的人工智能技术和通用软件开发在不断加快推进。

2. 从关联度来看，案件发生的数量及类型与地区软件产业发展紧密相关。软件产业蓬勃发展导致本地涉软件案件数量不断增加。2020年江苏共有5768个软件产品通过评估，数量位居全国第一，但过半软件产品出自南京，南京已形成以“一谷两园”等国家级园区为重点，以徐庄、建邺、鼓楼高新区等省级软件园、互联网产业园为支撑的集聚发展格局。同样，苏州经济发达，科技创新能力较强，软件产业发展迅速，涉软件案件占比较大。6年内南京知识产权法庭新收涉计算机软件纠纷案件991件，占技术类案件19.7%；苏州知识产权法庭新收涉计算机软件纠纷案件653件，占技术类案件12.3%（不包括2022年5月1日起作为非技术类案件审理的涉计算机软件合同纠纷案件）。

3. 从类型来看，主要以软件开发合同和软件著作权侵权纠纷为主，开发合同纠纷增长迅速、占比大。两法庭审理涉计算机软件开发合同纠纷案件1009件，占全部计算机软件类案件69.2%，反映出基于传统产业智能化升级改造，各地产业数字化转型升级中存在巨大工业软件需求，引发软件开发相关纠纷频发。更为重要的是，以上案件的争议焦点主要集中于完成的开发功能是否达到验收标准的争议，需要查明的功能点数量通常较多。例如在苏州知识产权法庭审理的某企业管理系统开发案中，双方当事人争议的功能点多达126项，包括合同内需求94项、合同外需求32项。该法庭审理的涉BI系统开发案中，当事人提出的系统报错问题共计39项，每项均需要细致、专业的分析和鉴定，案件审理难度大。

4. 从标的额来看，大标的额案件上升趋势明显。大标的额案件不断增加反映了当事人知识产权保护意识增强，客观上也符合创新要素高度活跃所应匹配的高保护需求。2017－2021年，立案标的额为100-500万元的案件233件，500-1000万元的案件58件，1000万元以上的案件25件。其中，2020、2021两年大标的额案件增长态势尤为显著。从案件类型来看，大部分软件开发合同案件标的额在100万元以下，高标的额的案件多为软件侵权案件。如在《传奇》网络游戏案件中，权利人起诉金额高达9900万元，系苏州知识产权法庭目前受理的最高额的计算机软件案件。此外，在涉SolidWorks系统、HyperMesh软件、Genesis系列软件侵权的多起案件中，起诉金额均超过1000万元。

5. 从性质来看，涉开源软件的新类型纠纷大量涌现。因软件开源极大程度提升了供给和需求两侧产品的技术创新能力，开源生态已经成为软件产业国际竞争的战略制高点。由于我国目前尚未形成较具规模的开源社区和较权威的开源软件行业自律组织，软件使用者对于开源规则不了解、掌握不深或漠视等原因，权利人以软件使用者违反开源协议中的著作权声明义务为由提起诉讼的案件数量在近两年呈爆发趋势。同时，开源的实质虽然是技术资源的免费开放共享，但是开源软件并不直接等同于免费软件。如从2020年下半年开始，商派软件有限公司以网站登记经营者未经授权以盈利性为目的使用其商城软件源代码为由提起大量诉讼。在南京知识产权法庭审理的计算机软件开发合同案件中，曾发现受托方在软件开发过程中大量使用未经授权的开源软件源代码，并作为开发成果提交委托方，如果委托方使用该软件系统，存在巨大的侵权风险。因此，开源软件给软件产业带来发展机遇的同时也带来了新的法律风险。

二、计算机软件案件审理中反映的问题

（一）软件侵权案件

1. 举证难度大。软件案件所涉证据具有技术性强、涉及面广、极易消失等特性。对于原告而言，举证难主要体现在侵权主体认定及损害赔偿额确定方面。侵权主体举证难一方面是权利人很难发现终端用户的侵权使用行为；另一方面，终端用户商业性使用盗版软件，在接到诉讼材料后通常会第一时间关停被诉侵权网站、注销ICP域名备案，甚至部分网站在建立之初即未进行ICP域名备案，导致侵权主体难以确定。侵权赔偿额举证难主要体现在由于侵权行为隐蔽，权利人难以掌握侵权人经营场所内盗版软件的实际使用情况、安装套数等具体信息。

对于被告而言，举证难主要是对于侵权认定及法律责任确定，被告难以提供有效抗辩证据。尤其是在商业建站软件批量案件中，被告往往自身无建站能力，多委托他人建站或通过网络平台购买建站服务。因涉及金额不大，大多不会签署正式合同并开具发票，因此部分被告在诉讼中无法举证有效的建站主体身份、交易记录、委托合同等证据，导致在侵权认定及责任判定时不得不承担举证不能的后果。

2. 侵权判定规则尚不明确。就目前司法实践而言，“接触+实质性相似”仍是软件著作权侵权判定普遍适用的原则，即原、被告的计算机软件表达相同或实质相似，并且有证据证明被告具备接触原告软件代码的可能性，则可以认定被告存在软件著作权侵权行为。但在司法实践中，一些具体的侵权判定标准依然较为模糊，如关于实质性相似的判定标准问题，目前我国现行法律法规及司法解释并无明确指引。

关于核心源代码抄袭问题，当核心源代码的数量在整个软件全部源代码中的比例不高，但是对实现软件功能起关键性作用时，如何判断被抄袭的部分源代码侵权问题，在审判实践中仍是一大难题。若单纯按照代码行数判断比例，而忽略了代码的本质，对软件权利人极不公平。

尤其是在刑事案件审判中，如何满足刑事案件入罪标准，仍有待法律或司法解释进一步明确。又如关于开源软件二次开发问题，部分软件基于基础开发包进行了二次开发，基于公知代码开发出具有独创性的核心代码，如简单适用常规的侵权比对方式，则可能会出现关键技术实质性相似的软件，仅因为代码语言表达形式不同而被认定为不构成实质性相似。在此情形下，是否应当认定两者构成实质性相似及如何处理思想与表达的区分，仍需进一步研究明确。

3. 诉前证据保全对赔偿额的确定未能充分发挥有效作用。诉前证据保全的主要目的是固定侵权证据，实践中往往采用抽样方式，随机挑选被诉侵权企业办公场所内的若干台电脑，从中确定安装有侵权软件的数量。权利人在主张损害赔偿数额时，一般会根据抽样调查结果，按比例推算侵权数量。此时，被诉侵权企业大多抗辩不应按抽查比例推算实际安装数量，法院也并非一律以诉前证据保全的抽查数量作为计算损害赔偿的依据。如在苏州知识产权法庭审理的涉HyperMesh系统侵权纠纷案中，法院认为涉案的 HyperMesh 软件售价较高，权利人并未举证中小规模企业存在购买10余套软件的实际需求，根据诉前证据保全查到的安装数量乘以其正版软件单价的计算方式缺乏现实合理性，故未支持权利人主张的赔偿计算依据。又如在涉SolidWorks系统侵权纠纷案中，法院同样以权利人未就与德尚公司性质及规模相类似企业对涉案软件的实际需求数量进行举证为由，未采纳诉前证据保全结果。可见，诉前证据保全除了固定侵权事实之外，在确定损害赔偿额方面未能有效发挥作用。

（二）软件合同案件

1. 事实查明难。计算机软件的开发一般包括用户需求、方案设计、软件开发、测试、安装、迭代更新等环节。在签订计算机软件开发合同时，委托方提出的需求往往比较笼统和概括，约定的软件功能属于框架性标准，开发过程中不断变更需求，对阶段性产品提出修改，具体的开发标准通常处于边开发、边确定的状态，导致软件开发标准的细化和变更贯穿于整个合同履行期间。而且，当事人履约过程中的沟通一般通过即时聊天工具和电子邮件，需要通过审查大量的电子证据才能确定合同具体的约定内容和开发标准。更有甚者，因未能固定沟通的证据，案件事实难以完全还原。

同时，由于计算机软件的易灭失性和易修改性，在诉讼时某一方认为软件已被修改，并非当时部署的软件，或者因软件部署环境资源到期回收导致部署的软件被删除，委托方不认可开发方提供的备份软件，最终难以确定开发成果的具体内容。上述原因导致计算机软件合同类案件审理中，事实还原程度低，需要法官从大量琐碎的电子证据中提取有效信息，并根据逻辑推理，结合商业交易习惯和日常生活经验法则，适用高度盖然性证明标准来认定事实。

2. 验收标准不明确。由于软件开发合同的交付标的具有抽象性，即使将软件安装在委托方指定机器上，也不代表开发方已经按照合同约定完整地履行了合同义务，需要通过运行软件才能判断是否符合合同约定的软件功能。实践中，合同往往对产品的功能、性能或者验收标准没有约定，或约定较为模糊，在此情况下，如何认定交付的软件是否符合合同约定，成为判断难题。同时，软件故障在计算机软件开发中不可避免，软件故障是否影响软件功能的实现，以及软件故障在完成情况中所占的比例，亦无具体标准。南京知识产权法庭作出判决的软件开发合同纠纷中，有80%的案件存在事实查明困难，有60%的案件即便查明了基本事实，仍存在功能标准模糊问题，这两点是导致举证和庭审不断反复、诉讼被拖延的主要原因。

三、对策建议

针对调研中发现的问题，结合现行法律、法规、司法解释和审判经验，课题组提出如下对策和建议，以期进一步推动软件产业振兴：

（一）软件侵权纠纷

法院要通过软件著作权侵权案件的审理，保护软件著作权人的创新利益，制止损害进一步扩大，以进一步激励软件开发创新；通过侵权认定、保护范围和保护强度确定等裁判思路，促进软件开发企业进一步提高创新质量，让更多高质量软件涌现，推进软件企业努力攻坚“卡脖子”技术，实现科技自立自强；引导开源软件使用人、后续开发者等主体尊重行业规则，维护合法、正当开发生态。此外，还应当注重保护公众对软件的正当、合理使用权益。

1. 关于权利主体身份的确定

软件著作权权利主体的认定与一般作品权利主体认定的思路基本一致。原告提交的软件著作权登记证书、软件源代码可以作为权属认定的初步证明。在一些权属争议较大的案件中，可以通过比对原告提交的涉案软件源代码和版权中心登记的软件源代码、结合署名信息等进一步确认权利归属。如在某嵌入式软件侵权纠纷案中，原告在版权中心登记的软件源代码仅为该全部源代码的部分内容，无法进行全面对比，且原告产品中使用的嵌入式软件为二进制代码，与源代码分属软件的不同表现形式，在技术上无法进行直接对比。针对上述问题，法院首先将版权中心登记的部分源代码与原告自身提供的完整电子版源代码的相应部分对比；在确认两者一致的基础上，又将原告提供的完整电子版源代码编译成二进制代码，再与其产品中软件的二进制代码对比。最终，根据两者一致的结论，确认原告权利主体身份。

2. 关于侵权事实的固定

首先，侵权证据的取得。权利人可以通过诉前证据保全，最大程度固定侵权事实，确定侵权数量和规模。在诉讼中应当引导权利人积极举证侵权企业规模及实际需求，在实际需求与诉前证据保全结果基本符合，且侵权企业在保全过程中未就抽样检测提出异议的，可以采纳保全结果，并据此计算损害赔偿数额。如涉及SolidWorks软件侵权案中，诉前证据保全现场实施过程有侵权企业研发部人员协助在场见证，其对清点电脑及检查过程均未提出异议，现场保全中亦未对保全中采用的抽查方式提出异议，故法院结合侵权企业规模等因素慎重考量后，采纳了诉前证据保全结果。其次，应当合理分配举证责任。在权利人已穷尽举证能力，初步证明待证事实成立的情况下，可以适当转移举证责任，责令侵权人提供相反证据。依法适用证据披露和举证妨碍制度，责令持有证据的被告提供相关证据。对于无正当理由拒绝提供或提供虚假证据、提供证据不完整甚至毁灭证据的，积极适用举证妨碍制度，根据案件情况作出对其不利的事实推定。此外，可结合计算机软件侵权隐蔽性强的特点，创新调查取证方式，依法支持运用现代技术保全或获取的证据。计算机软件权利人使用时间戳、区块链等方式保全证据，采用远程登录Telnet命令等技术取得的证据，如果符合证据条件的，应当依法予以认定。

3. 关于实质性相似的认定

司法实践中，对实质性相似的认定，主要有以下4种方法：

一是源代码比对。将责令被告提交、被告主动提交等获得的被告源代码与原告提交的源代码进行比对，是最有效、最直接的内容比对方法，但诉讼中直接获取被告源代码的可能性极小。

二是目标代码比对。被告的目标代码通常可以通过证据保全获得，在被告没有提供相关证据的情况下，目标代码实质性相似且有其他证据予以佐证时，或者通过目标程序代码反编译的程序代码进行比对，构成相同或者实质性相同时，可以认定双方软件构成实质性相似。例如在某嵌入式软件侵权纠纷案中，被诉侵权软件和权利人软件的源代码分别采用汇编语言和C语言编写，不具备进行直接对比的条件，法院通过比对二者的二进制代码即目标代码，最终认定二者构成实质性相似。

三是综合比对。以软件的组织结构、处理流程、所用数据结构、产生的输出方式、要求的输入形式等方面的相似来综合判定。该比对方法主要适用于最终用户计算机软件著作权侵权纠纷，即企业安装标准化的盗版软件著作权侵权情形。比对的主要内容包括比对存储原被告软件的光盘内容、软件安装过程的屏幕显示内容、软件安装后的目录以及其中的文件等。如在某建站软件侵权系列纠纷中，部分被告拒不提供源代码，法院根据二者在软件界面、运行参数、数据库结构等方面相同或实质性相似，被告的软件存在与原告软件路径一致、名称一致的文件，且被诉侵权软件保存有原告的权利管理信息、署名信息，据此认定二者构成实质性相似。

换言之，在被告无正当理由拒绝提供源代码或目标代码的情况下，应当充分考虑到此类案件原告举证的客观困难，结合双方提交的证据，合理推定原被告软件是否构成实质性相似。

四是缺陷性特征比对。在无法比对双方源代码，也无法获得被告目标代码的情况下，根据双方软件运行过程中存在的共同缺陷性特征，推定双方软件构成实质性相似。如涉某S型线切割机床单片机控制器系统软件侵权纠纷案中，法院根据原被告软件均出现相同缺陷性特征，结合二者在加工运行时存在相同的特征性情况、软件的使用说明书基本相同、控制器的整体外观和布局基本相同等相关事实，在被告无正当理由明确表示拒绝提供源代码的情况下，认定被控侵权软件与原告软件构成实质性相似。

在根据上述方法认定双方软件构成实质性相似，特别是将源代码和目标代码比对时，两者相似度达到多少即可以认定双方软件为实质性相似，目前实践中仍无明确统一的规则，也无相关规定。曾有鉴定专家表示，在排除合理来源的情况下，若两个软件之间的相似度达到80%，那么认定软件实质性相似是非常合理的；若相似度只是在70%－80%之间，就其实质性相似问题可能还需要其他方面证据进行佐证；若相似度低于70%，则需要进行大量证据的证明，才能初步认定实质性相似；若相似度低于60%，基本不应该被认定为实质性相似。

但这并非一成不变的规则，北京市海淀区人民法院曾经利用鉴定机构报告认定的20%相同比例认定被告软件侵权，因此，在确定具体相似度时，仍需结合个案具体情形判定。同时，可以对不同功能的代码赋予不同的相似系数，如接口库代码、开源代码等部分可以赋予其小于1的相似系数；而对于实现软件核心功能、由权利人完全独立开发的代码赋予其大于1的相似系数，再通过将整个软件中不同功能代码的比例乘以其相似系数后相加，得到两个软件代码的最终相似程度。通过此种比对方式，可以使得最终的比对结果更加符合实际，对最终裁判结果也更具有参考性。

此外，实质性相似判断中的一个难点问题，就是前文提到的关于核心源代码的保护问题，主要有两种情形：一是计算机软件的核心源代码在整个软件代码中仅占较小的比例，但却起到了关键性作用，这种核心源代码被抄袭后如何进行认定？二是被控侵权方仅借鉴了核心源代码的原理或者技术方案，但通过其他表达方式对相关功能进行了重现，这种情形下是否可以认定两者构成实质性相似？如何对权利人的权利进行相应保护？

对此，课题组认为，针对第一种情形，可以适用前文所提及的相似系数方式，通过计算结果确定相似程度；针对第二种情形，如果被控侵权方仅是借鉴了核心源代码的原理或者技术方案，通过其他的表达方式进行了重现，这种情形下不宜认定构成著作权侵权。《计算机软件保护条例》第六条规定，对软件著作权的保护不延及开发软件所用的思想、处理过程、操作方法或者数学概念等，因此，著作权法仅保护表达不保护思想的基本原理在软件著作权侵权认定中应当予以遵循。这种情形之下，权利人的核心源代码可以考虑通过其他方式予以保护。

其一，可以采取黑盒方式实现核心源代码功能，将核心源代码的功能通过加密函数、加密动态链接库的方式进行实现，减少他人通过反编译等方式得到核心源代码的可能。

其二，通过申请专利的方式对核心源代码或软件方案进行保护。目前世界各国均对软件专利的申请条件给予一定程度的放宽，且通过专利可以非常全面地保护计算机软件中的核心技术方案。我国《专利审查指南》目前对涉及计算机程序的专利申请区分两种情况加以处理:（1）如果仅利用计算机程序这一手段实现了某种数学计算方法和规则，则该程序实际上是智力活动的规则和方法的一种表现形式，不能被授予专利权。（2）如果涉及计算机程序的发明专利申请的解决方案，执行计算机程序的目的是解决技术问题，在计算机上运行计算机程序，从而对外部或内部对象进行控制或处理，所反映的是遵循自然规律的技术手段，并且由此获得符合自然规律的技术效果，则这种解决方案属于专利保护的客体。

例如，某人针对便携式计算机、手机等移动设备存储容量较小的技术问题，设计了一种利用虚拟设备文件系统来扩充移动设备存储容量的方法，使移动设备能够将服务器上的大容量存储空间用于存储本地数据。该设计方案实现了对设备存储容量的扩充，是利用自然规律的技术方案，属于专利法保护的客体，可以对该计算机程序授予专利权。

4. 关于最终用户侵权责任的认定

“最终用户”在相关法律规定中并无统一定义，《计算机软件保护条例》第三十条表述为“软件的复制品持有人”，而最高人民法院《关于审理著作权民事纠纷案件适用法律若干问题的解释》第21条则称之为“计算机软件用户”。最终用户侵权模式主要表现为在自身商业活动中使用计算机软件，但并未改变原告计算机软件的内容，也未向公众提供原告计算机软件。如其非商业性使用权利人软件，则可以豁免侵权；同时，在商业性使用的前提下，如其系主观上无过错的善意用户，则一般不承担赔偿责任，但应当停止使用侵权软件。因此，实践中对于最终用户主观过错的认定，成为确定是否承担侵权责任的关键，即被告作为最终用户主观上对于软件属于侵权复制品是否明知或应知。

具体判断时可以考虑：最终用户购买软件支付的价款是否合理；是否从合法的软件销售商处购得；最终用户对软件的认知能力等。如苏州知识产权法庭在涉HyperMesh计算机软件著作权侵权案中，考虑到被诉侵权企业高管人员系相关领域内的专业人士，对盗版软件的甄别能力相对较强，并据此对其苛以较高的注意义务。此外，也有专家认为，如被告虽未复制权利人软件，但知道他人为其复制软件，且该计算机软件的使用属于被告正常商业经营活动范围，则可以认定被告与该他人共同侵害了原告计算机软件的复制权。

5. 关于赔偿责任的确定

通过加大损害赔偿力度，不断提高企业正版化意识。一是坚持从源头打击和遏制侵权。在苏州知识产权法庭审理的国内某商用开源软件批量维权案件中，合理分配举证责任，对网站经营者与建站主体确定不同力度的损害赔偿金额。在侵权人能够初步举证被诉侵权网站的建站主体时，合理确定侵权人应当承担的法律责任，充分体现制止和打击从侵权网站的建设环节即源头环节侵权行为的价值导向，防止出现越起诉侵权主体越多的情形，及时制止侵权行为持续，防止侵权损失加剧。

二是妥善适用法定赔偿。合理运用法定赔偿制度具有的补偿权利人损失、惩罚侵权行为的双重功能，结合在案证据及侵权情节，妥善确定赔偿数额。如在涉Nastran、Adams、Patran系列计算机软件侵权案中，法院重点考虑被诉侵权企业的经营规模以及对于所涉软件的实际需求，以此作为确定著作权人因丧失交易机会而实际遭受的损失数额或者被诉侵权企业因逃避著作权许可而实际获取的收益数额的计算基础，并参考被诉侵权企业的行业属性、注册资本、公司人员以及年经营额等基础数据，采信权利人举证的具有一定可比性的企业实际使用软件数量等证据作为侵权数量的计算依据，结合正版软件价格、侵权情节、被诉侵权企业实施软件正版化采购需求进度等因素，酌情确定损害赔偿金额为135万元。

三是积极适用惩罚性赔偿制度。注重惩罚导向，从严惩治恶意侵权、重复侵权、以侵权为业等严重侵权行为，显著提高侵权成本。如涉HyperMesh计算机软件侵权案中，结合被诉侵权企业在所述领域内的专业化程度，以及诉前证据保全中确定至少有11台电脑含有涉案软件安装信息，认定其系明知侵权而大量安装、使用HyperMesh软件以及权利人的其他软件，属于侵权情节恶劣，据此依法适用两倍的惩罚性赔偿。

6. 关于涉开源软件纠纷的审理

目前，开源软件已成为各行业信息系统的重要组成，全球各领域应用开源软件占比逐渐增长。2020年，物联网行业89%的代码库中包含开源代码，生产制造和网络安全领域开源代码占比均为84%，移动应用软件、教育技术、医药健康以及营销技术行业开源代码占比均为82%。由此，涉开源软件的知识产权纠纷逐渐增多。在审理涉开源软件案件中，应当把握以下几点：

一是开源协议具有双务性，行使权利的同时应当承担相应义务，否则会导致权利终止。开源软件通常指授权人根据相应开源协议，将其源代码向公众公开，并允许用户在开源协议约定的条件内自由使用、修改和分发。开源软件的授权人将其享有的著作财产权和部分人格权授予用户，作出一定让渡，其目的是创设一种自由开发、使用或传播的环境，推动软件开发创新和产业蓬勃发展。开源协议已经成为业内共同认可和遵守的契约文本，是有效平衡软件专有权与公众使用权的重要依据，履行相关协议义务也是诚实信用原则的体现。只有信守开源软件所附条款，才能推动开源软件正当有序传播和使用，让社会公众能够享有开源软件带来的便利与发展成果。开源软件强调自由，但不意味着否认知识产权的存在，而是依赖于现有著作权法律体系，因此，开源软件及其衍生软件或修改版本的著作权仍然存在，且权利类型并未缺少。开源软件的著作权人仍享有复制权、发表权、修改权、署名权、保护作品完整权、获得报酬权等权利，其只是通过许可的方式将其中的某些权利如复制权、修改权等授权给不特定公众，系授权人在享有著作权的情况下，将权利有条件地让渡。软件使用人如果违反开源协议，则其行为构成违约的同时，亦构成著作权侵权。

在山东省济宁市罗盒网络科技有限公司诉福建风灵创景科技有限公司、北京风灵创景科技有限公司、广东省深圳市腾讯计算机系统有限公司侵害计算机软件著作权纠案中，法院认为，GPL3.0协议是一种民事法律行为，具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国合同法调整的范围。若用户违反 GPL3.0 协议的使用条件来复制、修改或传播受保护的作品，其通过 GPL3.0 协议获得的授权将会自动终止。本案中被告本应当遵循 GPL3.0协议向公众无偿开放源代码，但因被告拒不履行 GPL3.0 协议规定的使用条件，根据 GPL3.0 协议第 8 条自动终止授权的约定及民法总则第一百五十八条的规定，被告通过该协议获得的授权已因解除条件成就而自动终止。被告对原告权利软件实施的复制、修改、发布等行为，因失去权利来源而构成侵权。

二是开源并非不侵权的必然抗辩理由。在涉开源软件侵权案件中，因为原告软件代码包含开源协议代码内容，被告往往以原告应当依照开源协议的规定承担开源义务为由进行不侵权抗辩。被告的抗辩能否成立，关键在于原告主张权利的软件是否受开源协议的约束。就GPL开源协议来说，涉及协议的传染性及其阻断问题。目前司法实践中，法院采用GPL协议规定的单独程序原则，来判断原告主张权利的软件是否受该协议的约束，作为传染性阻断的依据。在不乱买电子商务（北京）有限公司诉北京闪亮时尚信息技术有限公司侵害计算机软件著作权案中，最高人民法院在终审判决中对GPL协议的传染性给出了认定：GPL协议的传染性，应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序。最高人民法院认为，前端代码与后端代码可以分别独立打包、部署。

因此，前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体。本案中，虽然原告认可其前端代码中使用了GPL协议下的开源代码，但其主张权利的是后端代码，其后端代码独立于前端代码的其他程序，并不受GPL协议约束，无需强制开源。在数字天堂（北京）网络技术有限公司诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司侵犯计算机软件著作权案中，法院根据GPL协议的例外条款，认定原告软件整体未受GPL传染，其著作权不受开源协议的限制，最终支持原告诉请。法院判决认为，对于原告涉案3个插件而言，在其所处文件夹中并无GPL开源协议文件，而HBuilder软件的根目录下亦不存在GPL开源协议文件的情况下，尽管HBuilder软件其他文件夹中包含GPL开源协议文件，但该协议对于涉案3个插件并无拘束力。

据此，涉案3个插件并不属于该协议中所指应被开源的衍生产品或修订版本，被告认为原告软件为开源软件的相关抗辩不能成立，被诉行为构成对著作权人复制权、改编权及信息网络传播权的侵犯。由此可见，虽然对GPL开源协议传染性的阻断需要根据个案情况进行判断，以正确划定法律边界，但上述两个案件也提供了一般性的判断准则，即单独程序原则。

三是开源软件使用者不应当违反开源规则。从2021年开始，软件权利人以软件使用者违反开源协议中的著作权声明义务为由提起诉讼的案件大量增长。某公司以网站所有者使用其建站软件代码，但未按照其《最终用户授权许可协议》保留版权标识和权利人网站链接在全国范围提起大规模的诉讼。最高人民法院在判决中认定，软件著作权人免费提供可由不特定用户免费下载使用的建站软件，在用户协议中明确要求免费使用软件的用户须保留著作权人的版权标识和有关链接信息，用户免费下载使用该建站软件时去除版权标识和有关链接信息，其行为侵害计算机软件著作权人的署名权，应当依法承担停止侵害、赔偿损失的责任。

（二）软件合同纠纷

法院要通过涉软件合同案件的审理，依法认定合同效力，尽可能维持合同有效；依据诚信原则，尊重商业惯例，认定并惩治违约行为，尤其是让恶意违约方付出高昂代价，推动合同依约履行；充分考量合同主体履约过程中的资金投入、技术创造、技术服务等付出，公平合理地确定违约责任及合同解除后的法律责任；引导软件开发、转让、服务等相关主体规范、完善合同内容，减少争议发生。

1. 关于开发成果验收合格的认定

软件开发成果验收是否合格是审理中最常见的争议问题，委托方通常以开发成果未验收合格为由主张付款条件未成就。

主要争议包括：一是开发成果是否验收；二是交付的成果是否符合验收标准。关于开发成果是否验收，需要根据双方在履约过程中的具体行为表现认定。如在某阅卷平台软件开发合同纠纷案中，合同约定双方需出具书面验收合格文件，但实际履行过程中，双方仅通过邮件沟通验收事项，而未有书面文件。法院认为，根据开发方在邮件中向委托方发送了项目验收申请报告，正式提出验收申请，此后在长达3个多月的沟通过程中，委托方对涉案阅卷平台软件多次进行了测试和验收，后双方又签订验收及代码交接协议明确承诺就验收阶段付款。因此，虽委托方未按软件开发合同约定出具书面验收合格文件，但其在经过多次测试及验收后签订验收及代码交接协议，结合软件开发合同对验收款定义、付款条件的约定，应视为委托人以其行为表明对阅卷平台软件验收合格。

关于交付成果是否符合验收标准，需要注意以下几点：一是委托方主张的技术问题是否属于合同约定的开发范围。合同就相关功能问题的描述通常较为抽象和笼统，而委托方主张的技术问题涉及具体功能，此时判断验收是否符合标准，需要确定委托方主张的技术问题是否属于合同约定的功能需求。如在某健康监护APP软件开发合同案中，委托方主张开发方未完成合同内需求50项，开发成果验收不合格。法院通过分析合同约定以及软件代码，结合终端的展示情况，综合判定上述50项功能需求中，有38项属于合同外需求，不应当予以评判。

二是合同履行过程中双方是否就新功能的开发达成了合意。囿于软件开发合同交付标的的抽象性，加之双方在计算机知识、行业认知等方面的差距，软件开发合同签订过程中，双方通常仅约定总体开发目标，具体的功能需求通常在开发过程中通过补充协议、邮件往来、即时聊天、会议磋商等方式明确和完善。审理中应当对上述事实及证据进行审查，判断委托方是否在合理的时间和范围内明确需求，所提之需求是否符合合同的总体目标。如在某应急救援虚拟教学训练系统软件开发合同案中，双方确认的第一阶段开发成果的验收纪要中添加了增加场景展示模块要求，法院认为上述新要求应视为双方就第二阶段开发所作的补充约定，具有合同效力。

2. 关于合同目的是否实现的认定

判断合同目的是否实现是认定委托方是否享有法定解除权、开发方是否有权要求合同继续履行的关键，审查要点包括：

一是软件主体功能是否开发完成。如软件主体功能已经开发完成，仅有个别功能缺失或者存在瑕疵，则不能认定合同目的无法实现，亦不能据此主张解除合同。如在某在线试衣APP开发合同案中，开发成果在商户端、试衣间等功能上具有缺失和不完善，开发方提出该些功能系难以避免的BUG，且属于软件交付后可以改进内容。法院则认为，尽管在合同履行中有进行软件功能补丁的可能和必要，但该开发成果尚不能实现合同约定的APP软件开发的主要目的，显然应当确定为合同主要义务未完成，而非软件补丁的合同后续义务，据此驳回开发方要求继续履行合同的诉讼请求。而在某健康监护APP软件开发合同案中，法院参照软件开发合同中约定的功能描述，认定委托方主张的未开发完成事项属于可以及时进行修复的BUG，不影响软件需要实现的主体功能，不足以致使合同根本目的无法实现，据此驳回委托方解除合同的诉讼请求。

二是开发方是否完成合同附随义务。由于软件的后期维护、BUG修复、版本升级等具有较强专业性，如合同约定此属于开发方的附随义务，开发方虽未履行，但不影响开发成果主体功能实现，则可能构成违约；如影响主体功能实现，则可能导致开发方根本违约，委托方可以解除合同。

3. 关于合同解除后的处理

合同解除后，应当审慎适用恢复原状规则。技术合同解除后已经履行的部分并非当然恢复原状，而是应当根据履行情况和合同性质加以权衡。软件开发合同解除后应否恢复原状，特别是开发方先期收取的开发款应否返还，需综合考量软件开发合同自身特点、开发方实际履行情况、开发方有无过错及过错大小、开发方实际投入的工作量及已完成的成果等多种因素，秉持诚信原则和公平原则加以判断。软件开发合同解除的原因如不应当归责于开发方，则开发方在开发过程相应阶段收取的款项并不失去继续保有的正当性。