源代码比对不能场景下软件著作权侵权技术比对的替代法

在软件著作权侵权案件中，源代码比对长期被视为侵权认定的“黄金标准”。然而中国裁判文书网公开信息表明，在司法实践中，因源代码比对存在客观困难导致举证受阻的情形已成为此类案件审理中较为突出的技术性难题。根据法官不得拒绝裁判原则，司法必须回应此源代码比对不能的场景，必须解决技术比对的事实查明问题。

此类源代码比对不能的场景，例如固件中（嵌入式）的软件系统，常常以目标代码烧录入存储器的形态存在。在笔者团队代理的某固件软件侵权纠纷中就遇到此认定难题，最高法院最终认为，当被诉侵权行为涉及复制芯片中的固化十六进制代码并发行计算机软件时，若难以通过源代码对比判断实质性相似，则可通过芯片中十六进制代码对比来解决实质性相似判断的问题。

在源代码比对不能的场景，司法通过依赖目标代码（二进制、十六进制等）比对来替代解决技术事实查明问题，其他还主要包括反编译比对、技术特征比对等替代性解决法。然而，此类替代方法的适用仍面临技术可靠性争议与法律标准不统一等问题，为应对这一困境，本文通过分析研究典型案例的技术论证路径，系统评估不同比对方法的效力边界，进而通过实证分析揭示现存问题，最终基于典型案例提炼判例规则，以期解决这一软著侵权比对的司法异质性问题。

作为判定著作权侵权的一项核心司法工具，实质性相似是指通过对权利人主张权利的作品与被控侵权作品进行比对，判断两者在表达上的相似程度是否达到实质性的标准。^[1]结合著作权法的基本原理以及计算机软件的特殊性，笔者认为，软件实质性相似的判定应涵盖以下两个层面的含义：从比对对象的角度来看，实质性相似主要关注权利人主张的软件与被控侵权软件在独创性表达上的相似性；^[2]从比对范围的角度来看，软件实质性相似包括文字部分的相似和非文字部分的相似。^[3]

这一双层认定框架本质上根植于《计算机软件保护条例》的立法本义，从法律解释论出发，《条例》第3条^[4]将“程序”定义为“指令序列”而非仅限于源代码，为结构性要素例如架构、接口设计和表达性要素如UI布局、运行逻辑的保护提供规范基础，体现了对“表达形式多样性”的立法精神。从技术层面来看，现代软件开发的分层抽象与编译优化导致源代码与可执行文件的非对称性，使得单纯代码比对可能掩盖实质性侵权；同时，模块化开发模式下，侵权者可通过代码重构规避文字性比对，而软件功能流程、数据结构等非代码要素反而更具侵权识别价值。从司法实践上来看，比较法实践例如美国“Altai案”^[5]的三步检验法与我国典型案例共同表明，非源代码比对方式能够填补“思想/表达二分法”在复杂软件侵权认定中的适用漏洞，其方法论本质是对“接触+实质性相似”规则的动态调适，既避免过度保护技术思想，又能有效遏制“换皮式”侵权。这一理论建构不仅回应了产业界对侵权判定的可操作性需求，亦为《著作权法》第三次修订后“视听作品”等新型客体的保护提供了类比适用的法理支点。

我国现行法律法规及司法解释尚未对非源代码比对问题作出明确规定，但通过对既有司法判例的系统梳理与实证分析，可以归纳总结出以下几种具有实践指导意义的比对方法：

（一）静态代码层——目标代码二进制一致性的直接比对模式

固件代码通常存储在硬件设备的非易失性存储器（如ROM、Flash、EEPROM）中，用于控制硬件的基本功能，是嵌入式系统的“软件+硬件”混合体。一般而言，固件代码相似性判定通常以双方源代码的比对作为首要依据。然而，由于诉讼过程中获取被控侵权方源代码存在显著困难，加之双方可能采用不同的编程语言（如C语言与汇编语言），导致源代码直接比对难以实施。在此情形下，通过提取被控侵权方计算机系统或其他硬件设备中的目标代码进行比对，已成为软件侵权认定的重要技术路径。^[6]目标代码通常以机器可直接识别的二进制代码表示，是最低层次的计算机语言，如0101110010101010，一个“0”或“1”表示有或无一个电荷，称为一个“位”。^[7]一个“字节”是一串8个二进字符（例如：“01101001”）。一个“字”是一个占用一个存储位置的“字符组”，由计算机电路作为一个单位处理和传送。^[8]

从编译原理的角度分析，在相同编译环境下，特定源代码与目标代码之间存在唯一对应关系。尽管从理论上讲，相同目标代码可能源自不同的源代码，但这种概率极低，且在司法实践中尚未发现相关实例。若被控侵权方主张相同目标代码系由不同源代码编译生成，则应承担相应的证明责任。因此，在缺乏相反证据的情况下，当双方软件目标代码完全一致时，应当认定软件构成相同；若目标代码存在实质性相似并辅以其他证据支持，则可直接认定软件构成实质性相似。上述技术路径的司法适用性在以下典型案例中得到充分体现：

案例1：凌通科技股份有限公司诉无锡中微爱芯电子有限公司侵害计算机软件著作权纠纷案^[9]

图1-被诉侵权的启动代码1

图2-被诉侵权的启动代码2

图3-涉案专利的启动代码

在该案中，最高人民法院在该案中明确指出，所谓软件相似，既包括源程序相似，亦包括目标程序相似。在被诉侵权行为涉及复制芯片中的固化十六进制代码并发行计算机软件情形下，难以通过计算机软件源代码对比的方式判断实质性相似，但是可通过对芯片中十六进制代码对比的方式，解决计算机软件实质性相似判断问题。

案例2：罗开玉等人侵犯著作权案^[10]

在本案中，法院认为，虽然固件程序固化在ROM中，但其本质仍是“可以由计算机等具有信息处理能力的装置执行的代码化指令序列”，法院创造性地指出，在刑事案件中，即使没有进行源代码比对或不可能进行源代码比对，只要目标程序比对一致，且综合考虑全案事实能够排除合理怀疑，就可以认定复制行为存在。

案例3：因泰莱公司诉远征科技公司、远征软件公司等侵犯计算机软件著作权纠纷案^[11]

本案中，法院认为，“嵌入式软件源程序可以采用包括汇编语言、C语言在内的多种语言编写，并不能仅以编写语言的不同即得出软件不同的结论，相反，在二进制代码实质相同的情形下，存在用不同语言编写的源程序的可能性极小。”

（二）逆向工程层——反编译代码的逻辑等效性比对模式

反编译，亦称反向编译，是指通过对他人软件的目标程序（如可执行程序）进行逆向分析与研究，旨在推导出该软件的设计思路、原理、结构、算法、处理流程及运行机制等核心要素。该比对方法存在一定的局限性，主要适用于C#、Java及部分脚本语言编写的软件。对于C语言等编写的软件，反编译后通常得到的是汇编语言，其可读性较差，难以直接用于比对分析。此外，反编译生成的代码与正常开发的源代码存在显著差异，这是由于编译过程中编译器对源代码进行了优化和处理，因此，基于反编译的程序比对，通常侧重于程序逻辑和缺陷的分析与判断。司法实践中，最高人民法院已通过多个案例认可了反编译代码在软件著作权侵权认定中的证据效力。

案例4：江苏擎天信息科技有限公司与南京云松信息技术有限公司、张京等侵害计算机软件著作权纠纷案^[12]

在被告未提供源代码的情况下，通过反编译产生的源代码进行比对可称为定性的关键证据。该案中，法院认为“反编译后，源程序也会发生变化，故一审法院对云松无线系统和云松异构系统相同的比例不做定量认定。”同时认为“由于云松公司等无法提供被控侵权软件登记时的源代码版本，故一审法院只能组织双方当事人，就法院保全到的被控侵权软件可执行程序反编译至源代码形式，再与擎天公司主张权利软件的源代码进行对比勘验，后一审法院在前述比对的基础上，结合云松公司电脑中存在擎天公司涉案软件源程序等事实，认定被控侵权软件侵犯了擎天公司涉案软件著作权。”

案例5：北京青檬网络科技有限公司与金华锦尚科技有限公司侵害计算机软件著作权纠纷案^[13]

案例6：南京未来高新技术有限公司、江苏云蜻蜓信息科技有限公司等侵害计算机软件著作权纠纷案^[14]

案例5-6表明，即便软件经过加固处理，通过反编译技术仍可能提取关键代码并进行有效比对。同时，法院在判断软件侵权时，不仅关注代码的文本相似性，更注重程序逻辑的一致性，从而为类似案件提供了重要的司法实践参考。

（三）动态运行层——缺陷偶同与安装特征比对模式

1.软件缺陷偶同性的间接推定

软件缺陷（Software Defect）是指计算机软件或程序中存在的、影响其正常运行的问题、错误或潜在的功能缺陷。这类缺陷的产生主要源于软件产品的特性及其开发过程的复杂性。^[15]在软件开发过程中，由于功能实现的复杂性、开发人员的技术局限性，以及运行环境的动态变化，软件缺陷几乎不可避免。此外，软件缺陷的出现具有显著的偶然性和个体差异性——不同开发人员编写的代码可能引入不同的缺陷，同一软件的不同版本也可能在修复旧缺陷的同时引入新缺陷。正因如此，不同软件之间出现相同缺陷的概率极低，这一特性使其成为软件相似性鉴定的重要依据。在司法实践中，软件缺陷的比对已被证明是一种有效的鉴定手段，特别是在无法获取源代码或目标代码的情况下。

案例7：石鸿林诉泰州市华仁电子资讯有限公司著作权侵权纠纷案^[16]

该案中，法院明确指出：“根据计算机软件设计的一般性原理，在独立完成设计的情况下，不同软件之间出现相同的软件缺陷机率极小。”这一判例充分印证了软件缺陷在侵权认定中的特殊价值：当两款软件存在相同缺陷时，其实质性相似的概率显著增大。因此，在软件著作权侵权判定中，软件缺陷的比对可与其他证据（如功能特征、文档相似性等）形成互补，为司法鉴定提供强有力的技术支持。尤其在仅能基于可执行文件分析的场景下，缺陷比对往往能揭示出代码层面的实质性相似，成为突破举证困境的关键手段。

2.软件安装目录、流程的表面相似性比对

该种比对方式一般包括对比存储双方软件的光盘内容，如目录、文件数量、名称及文件大小；对比原、被告软件安装过程的屏幕显示内容，如提示信息、安装流程等以及原、被告软件安装后的运行状况，如运行提示、帮助信息等。^[17]该方式适合需要安装的软件，一般情况下，软件的安装过程，包含了复制文件的过程，通常包括软件的目标程序、库文件资源文件等内容。因此上述比对项目的相似程度越高，软件实质性相同的可能性也越大。

案例8：新思科技有限公司、武汉芯动科技有限公司侵害计算机软件著作权纠纷案^[18]

本案中，法院基于原被告计算机软件的名称、目录结构相似，进而作为判定实质性相似的重要依据，但通常情况下，上述项目雷同只是一种表面现象，如果被告坚持要求进行软件程序对比的，则并不能仅凭此即认定软件构成实质性相同，仍需进一步对比软件的源程序或目标程序。

（四）局部外观层——用户界面独创性比对模式

我国《计算机软件保护条例》第六条规定：“本条例对软件著作权的保护不延及开发软件所用的思想、处理过程、操作方法或者数学概念等。”这一规定明确体现了著作权法“思想与表达二分法”的基本原则，即著作权仅保护具有独创性的表达形式，而不保护其背后的思想观念、技术方案或功能性内容。然而，在司法实践中，当特定创意与软件界面设计紧密结合时，若该界面设计能够体现足够的独创性表达，则可能作为汇编作品获得著作权保护。此外，对于软件中具有创新性的算法，虽然难以通过著作权进行保护，但权利人可依据《反不正当竞争法》等相关法律法规，主张其作为技术秘密获得法律保护。这种保护模式的多元化，体现了知识产权法律体系对不同类型智力成果的差异化保护机制。

案例9：北京某网络科技公司诉长沙某信息科技公司侵害计算机软件著作权纠纷案^[19]

在本案中，法院指出，代码比对并非判断计算机软件著作权侵权的必要环节。在无法进行软件代码比对时，网络游戏软件实质性相似的判断可以结合游戏软件的用途和特点，从被诉侵权游戏软件与权利软件在标题、简介信息、操作界面、人物形象、故事情节、商业标识等方面的一致性综合分析判断。

（五）数据架构层——基于数据库与数据逻辑的独创性比对模式

数据库作为数据存储的核心载体，其存储容量可轻松容纳百万至亿级数据记录。不同于简单的数据堆积，数据库采用特定的组织结构来确保高效查询，这种组织架构即为数据库结构。^[20]数据库结构设计涵盖表结构、视图、图表和函数等要素，其中表结构作为基础单元，包含表名、字段定义、数据类型（如int、float、char等）、长度限制及默认值等配置细节。不同软件即使基于相同开源模板，也会在表启用策略、命名规范和具体参数设计上呈现独特差异。数据库结构同样具有偶然性，对其进行比对也能在一定程度上帮助法官判定软件是否存在著作权侵权行为。

案例10：北京元图智慧科技有限公司、刘桥喜等侵害计算机软件著作权纠纷案^[21]

基于本案可知，在计算机软件著作权侵权认定中，数据结构相似性虽可作为判断程序实质性相似的重要参考因素，但其本身并不构成直接判定依据。该要素的主要法律价值在于强化裁判者对侵权事实的内心确信程度，需结合其他技术特征和法律规定进行综合判断。

（六）非源代码比对路径的司法适用性对比分析

通过对典型案例的实证分析，非源代码比对路径的司法适用呈现“技术场景差异化—证明力层次化—裁判逻辑互补化”的立体特征，具体路径比对如下表1所示。在技术层面，静态代码层的目标程序二进制比对（案例1-3）因编译确定性而具有直接证明力，但需排除不同编译器导致的输出差异；逆向工程层的反编译逻辑比对（案例4-6）适用于高级语言软件，但受限于代码混淆与反编译失真；动态运行层的缺陷偶同分析（案例7）与安装特征比对（案例8）通过功能性缺陷或流程异常间接推定侵权，其证明力取决于特征的独特性与行业惯例；视觉表达层的界面设计比对（案例9）和数据架构层的数据库结构分析（案例10）则作为辅助路径，在界面独创性高或数据结构定制化时增强心证。司法实践中，法院通过“直接证据优先、间接证据补强、证明责任倒置”的递进规则，构建了多路径协同的认定体系：当存在二进制一致或反编译核心逻辑相同（相似度>90%）时可直接认定侵权；对间接证据（如缺陷相同、数据库结构雷同）则需结合开发轨迹、接触可能性等综合判断，形成“技术特征—法律要件—举证分配”三位一体的裁判方法论。

表1-非源代码技术比对模式的对比表

软件著作权侵权诉讼作为民事诉讼的一种，证明责任的分配当然遵循民事诉讼的基本法律原则。根据《最高人民法院关于适用〈中华人民共和国民事诉讼法〉的解释》第九十条之规定^[22]，民事诉讼遵循“谁主张，谁举证”的基本原则，诉讼当事人对其主张所依据的事实承担证明责任，除非法律另有特别规定。同时，该司法解释第一百零八条第一款^[23]确立了“高度盖然性”的证明标准，要求承担证明责任的当事人所提供的证据，必须达到能够使审理法院对相关待证事实的存在形成内心确信的程度。^[24]

尽管“谁主张谁举证”作为民事诉讼的基本证明规则具有普适性，但在知识产权诉讼领域，权利人在证据收集与举证环节往往面临显著困难。权利人通常需要提供自身软件的源程序代码，同时还需提交被诉侵权软件的相应程序作为侵权证据。^[25]然而，司法实践中往往权利人难以获取被诉侵权方的源程序，有时甚至因技术限制无法从侵权产品中提取目标程序，这就导致其难以完成举证责任。那么，在此类举证不能的情况下，完全机械地适用举证责任规则可能会导致实质不公平。^[26]为有效纾解知识产权维权过程中的“举证难”困局，司法机关应当综合评估各方当事人对关键证据的掌控程度、举证成本差异等变量，在个案中动态调整证明责任分配，避免对形式化举证规则的僵化适用。^[27]

最高人民法院《关于民事诉讼证据的若干规定》第九十五条^[28]确立了证明妨碍制度，规定当一方当事人无正当理由拒不提交其控制的证据，且该证据内容可能对其产生不利影响时，人民法院可推定对方当事人关于该证据内容的主张成立。与此相呼应，《关于知识产权民事诉讼证据的若干规定》第二十五条^[29]进一步明确，在当事人拒不提交、提交虚假证据或实施其他妨碍证据使用行为时，法院可推定对方当事人就相关证明事项的主张成立。实务中，上述证据运用方法在大量的软件著作权案件中得以运用。

案例11：商乐松公司诉威海常青高尔夫练习场有限公司案^[30]

案例12：金精盈资讯股份有限公司与上海高英信息技术有限公司、杭州锋速投资咨询有限公司著作权权属、侵权纠纷案^[31]

由上述案例可知，在计算机软件著作权侵权案件中，当权利人因客观原因无法获取被诉侵权软件的源程序及目标程序时，法院可依据证明妨碍规则进行举证责任分配。^[32]具体适用路径如下：首先，权利人应当完成初步举证责任，通过证明被诉侵权软件与权利软件在用户界面表现形式、运行结果输出、数据结构设计、软件命名规则、文件目录结构、权利管理信息、特有功能特征、固有程序缺陷等方面存在相似性，进而初步证明两款软件之间存在关联性。在权利人完成上述举证后，举证责任即发生转移，由被诉侵权人就其未实施侵权行为提供反证。其次，若被诉侵权人无正当理由拒绝提供软件源代码或目标代码进行直接比对，则构成典型的证明妨碍行为。根据证据规则，法院可依据《关于民事诉讼证据的若干规定》第九十五条之规定，推定两款软件构成实质性相似，从而作出对被诉侵权人不利的事实认定。这种证明责任分配机制有效平衡了双方当事人的举证能力差异，体现了知识产权保护中“强保护”的司法政策导向。