夜雨聆风[编者按]本案一审、二审判决结果截然不同，有必要对案件一审及二审判决中对技术事实的证明过程进行分析讨论，明晰法官的审理思路及逻辑说明过程，为后续办理同类案件提供参考。鉴于本文篇幅较长，为此特分为上下两期发布。
欢迎大家参与讨论，达成共识。
电话：023-67253442
邮箱：xnzscq@163.com
前言
（2023）最高法知民终2586号判决涉及一起医疗信息系统软件著作权侵权纠纷。本案一审由北京知识产权法院审理，一审判决驳回权利人的诉讼请求；二审由最高人民法院审理，二审改判支持权利人的主要诉讼请求。本案的意义，在于其完整呈现了软件类知识产权案件中技术事实从诉前评估、诉讼标的选择、证据调查、现场勘验、程序比对，到技术事实综合认定的全过程。
软件著作权案件与一般著作权案件不同。其争议对象往往不是肉眼可以直接观察的文字、图片或视频，而是由源代码、目标程序、数据库结构、运行界面、功能模块、业务流程、安装部署文件、用户手册等多种材料共同构成的复杂技术系统。技术事实并不天然呈现在法官面前，而需要通过诉前取证、法院调查、技术分析、当事人举证、质证和法庭评价等阶段逐步形成。因此，这类案件的争议并不只有“两个软件是否实质性相似”，而是更复杂的问题。例如，权利人如何选择诉讼标的，技术材料如何转化为可被法院认定的技术事实，技术事实如何上升成法律评价等等。
本文以该案为基础，结合原被告双方在诉前和诉讼中的技术事实调查方法，讨论软件著作权案件中标的选择、公证、现场勘验、单方技术分析、反编译比对以及被告抗辩等各类法庭调查手段与案件事实之间的逻辑关系。基本观点是：软件著作权案件中的技术事实调查，本质上不是单纯的技术问题，而是诉讼证明结构的设计问题。民事诉讼中，由于原告掌握案件的启动权，可以通过采用各种调查手段对案件事实予以证明的方法，预想被告抗辩理由有针对性的对本方证明漏洞予以修补，从而更有可能预判庭审有利结果。被告虽然没有举证负担亦不能满足于抽象否认怠于诉讼举证，而应当围绕核心证明事项展开具体、可验证的反驳，甚至提供反驳的证据、使得案件事实始终处于真伪不明的混沌状态，才能彻底规避败诉风险。
本案的原被告双方基本循着这个思路进行了审理。
一、背景：本案的技术调查过程
基于（2023）最高法知民终2586号判决中的一审和二审都涉及技术事实的调查。简述如下：
一审原告主张其享有“i-DiaPro血液透析电子病历系统”V3.0计算机软件著作权，认为被诉软件“析之助血透智能信息管理系统”系离职员工接触其源代码后开发形成。被告则从权利基础、接触可能性、被诉软件来源、源代码缺失及实质性相似等方面抗辩。
原告提交了软件著作权登记证书、通过SVN服务器导出的源代码、公证材料以及相关销售合同等证据。但一审法院认为，相关证据未能证明涉案软件特定版本的完成时间、内容完整性及未被修改状态。尤其是在被告提交证据主张SVN服务器中的文件可以被修改的情况下，一审法院认为原告未能进一步证明服务器中源代码的存储完成时间及未经修改的事实。因此，一审法院并未进入完整的实质性相似判断，而是认为由于作为权利基础的涉案权利软件不能被确认，进而驳回原告全部诉讼请求。判决书对此有明确表述：在案证据不能证明涉案权利软件的完成时间、公开时间，无法进行实质性比对，故对其他侵权认定事实及责任承担不再论述。
二审中，原告围绕一审所指出的漏洞进行补强，提交了V1.0至V4.0多个版本的
软件著作权登记材料、从SVN服务器导出的涉案权利软件V3.0_7014版前后20个版本软件材料，以及从第三方医院提取固定的安装包文件等，试图证明涉案软件开发具有连续性，特定版本真实存在且与登记材料、实际运行软件之间具有对应关系。在二审阶段，案件进入更为复杂的技术比对与侵权判断。由于被诉软件源代码未能提交，法院和双方当事人并未取得最理想的源代码直接比对条件，而是围绕WebService端反编译代码、数据库还原、运行界面、可执行文件反编译、软件登记资料、软件缺陷和文档内容等替代性路径展开争议。相关材料中出现数据库部分ID字段值及创建时间完全相同、代码中存在相同错误日志、空函数、命名残留等具有较强指向性的技术现象。最终，二审法院是在补强后的证据结构基础上认定侵权成立，判令被告停止侵权、停止使用，并支持经济损失2250万元及合理开支20万元。
二、诉前诉讼标的的选择：软件著作权or商业秘密？
本案进入诉讼程序之前，权利人首先面临的是诉讼标的选择问题。从案件背景看，本案既存在以商业秘密侵权主张保护的可能，也存在以软件著作权侵权提起诉讼的空间。二者并非简单的法律适用差异，而是对应完全不同的证据结构、证明路径和诉讼风险。
若选择商业秘密路径，权利人首先需要明确商业秘密的具体内容，也即所谓“秘点”。在软件案件中，商业秘密秘点通常可能指向源代码、目标程序、核心算法、数据库设计、数据、系统架构、业务逻辑实现方式等技术信息。权利人还必须证明该技术信息不为公众所知悉，具有商业价值，并已采取相应保密措施。同时，还要证明被诉方通过不正当方式获取、披露、使用或者允许他人使用该商业秘密。在本案起诉之前，权利人虽未掌握被诉软件源代码，但已经通过第13306号公证书，对任某医院电脑中的被诉软件数据库文件、表文件、客户端程序、安装包等进行了固定；同时，权利人还掌握了被诉软件运行界面、功能模块、业务流程等外在表现材料。上述材料虽尚不足以直接等同于源代码比对条件，但已经为后续反编译分析、目标程序比对以及申请法院进一步查明技术事实奠定了基础。不过，若以商业秘密为诉讼路径，仅凭目标程序、运行界面、功能模块和业务流程等材料，要证明被诉方掌握并使用了与权利人源代码或目标程序相同的技术秘密，难度仍然较大。
商业秘密案件中，若无法证明被诉信息与权利秘点之间存在实质相同关系，便很难启动不正当获取或使用的推定。尤其在本案场景下，运行界面、功能和业务流程一般不可选择为秘点，因为机器一旦进入使用流程上述的内容可能就对社会公开。特别是，上述内容虽然可以反映软件外观和功能效果，但其与源代码、目标程序之间并非一一对应关系。相同或近似的界面和流程，可能来自相同业务需求、行业流程、用户习惯，也可能来自不同的代码实现。因此，如果以商业秘密为诉讼路径，权利人很可能首先面临秘点难以明确、涉嫌侵权信息难以取得、两者实质相同难以证明的风险。
相较之下，选择软件著作权侵权路径具有一定现实合理性。软件著作权保护的是计算机程序及其有关文档中具有独创性的表达。虽然最终仍需围绕程序表达是否构成实质性相似展开判断，但在诉讼启动阶段，权利人可以先以运行界面、功能模块、业务流程、文档内容等外在材料证明被诉软件与权利软件之间存在相似可能性，从而提出进一步查明被诉软件技术实现方式的必要性。换言之，软件著作权路径为权利人在尚未取得被诉源代码的情况下，提供了一个较为现实的进入诉讼和申请法院调查的入口。
因此，本案诉讼标的选择为软件著作权而非商业秘密，并非偶然。其背后是对既有证据条件、诉讼推进可能性以及法院调查取证空间的综合考量。
三、一审的现场勘验启动
从权利人角度看，要证明软件著作权侵权，最终必须取得可供比对的技术材料。理想状态当然是同时取得权利软件和被诉软件的源代码，并进行直接比对。但实践中，源代码往往掌握在各自当事人手中，尤其是被诉软件源代码通常由被告控制。权利人若无法直接取证，就只能依赖法院调查、现场勘验、证据保全或者责令对方提交等程序工具获取证据。
本案中，权利人直接取得被诉源代码显然不可行。被诉软件部署于医院内部环境，现场勘验可以核验软件在一定环境中的表现，例如，运行界面、功能模块和业务流程等外观材料，从而形成初步的两款目标代码实质相似的初步证据。正因如此，权利人在一审中选择申请法院现场勘验，试图通过法院中立调查方式取得被诉软件与权利软件实质相似的证据。
现场勘验并非所有案件均会被准许。法院是否启动现场勘验，通常取决于待证事实的重要性、现有证据是否足以查明事实、现场勘验是否具有必要性和可行性，以及勘验是否可能对第三方系统运行造成不当影响。本案中，权利人申请现场勘验的理由具有一定说服力：被诉软件部署在医院现场；前期公证材料已经显示两套软件在运行界面、功能模块、业务流程上存在一定相似；案件争议的关键在于被诉软件的真实技术实现尚未查明。因此，现场勘验不是为权利人弥补一般举证不足，而是为了查明被单方控制的关键技术事实。
从被诉方角度看，并不当然享有阻止现场勘验的权利。现场勘验属于法院调查取证措施，其是否启动，由法院根据案件事实查明需要决定。被诉方若仅以“不同意勘验”或者“原告举证不足”为由反对，通常难以阻断法院调查。更有效的对抗方式，应当是围绕勘验必要性、勘验范围和勘验风险展开。例如，被诉方可以主张案件争议仅限于界面或功能层面，现有截图和演示足以固定相关事实，无需进入医院系统环境；也可以主张现场提取程序文件和数据库文件可能影响医院系统运行安全，或者反编译、复制等操作可能引入新的证据争议；还可以主动提出替代性查明方案，如限定范围的功能演示、提交技术说明、提供部分非敏感文件等，以降低法院启动全面勘验的必要性。
但就本案而言，被诉方并未成功说服法院认为现场勘验没有必要。一般而言，被告是无配合原告起诉的义务的。被告阻止现场勘验的发生，大多是基于朴素的想法，即打乱原告的诉讼步骤。本案中，现场勘验这个手段对诉讼结果而言并非决定性的。
四、技术事实调查的核心，软件比对
现场勘验取得材料，只是技术事实调查的开始，而不是结束。软件案件中，除了现场勘验比对的材料外，还有原告公证的材料，总计包括程序文件、数据库、安装包、运行界面等。关键在于如何解释这些材料，如何选择比对路径，如何把技术现象组织成诉讼证明结构。
本案现场勘验后，双方围绕相关材料展开了多层次比对。涉嫌侵权方主要从WebService端反编译比对、数据库结构比对、运行界面对比、可执行文件反编译结果等方面提出意见，主张两软件整体差异较大，仅有少量相似内容，且相似部分多属于功能性表达、通用设计或者有限表达。权利方则反过来指出，被诉方选择的比对对象和方法存在偏差。例如，权利方认为WebService端并非其主张侵权的重点，案件更应当关注客户端程序；数据库中虽然表名和字段存在差异，但部分字段值、创建时间等高度一致，可能反映继受关系；反编译结果中出现的特有标识、空函数、冗余代码、相同错误等内容，并非普通功能相似，而是更具有非偶然一致性的复制痕迹。
这场比对争议说明，软件著作权案件中的技术事实并不是单一层面的。界面相似、流程相似、数据库相似、目标程序反编译相似、目标程序相似、源代码相似，分别对应不同的证明强度和不同的法律评价风险。界面和流程最直观，但容易受到功能、业务和用户习惯限制；数据库结构能够反映系统数据组织方式，但未必当然属于计算机程序作品表达；反编译结果更接近程序内部实现，但其不是源代码本身，也不是目标程序本身，受反编译工具、编译方式、优化策略、混淆处理等因素影响；目标程序相似具有较高的证明力，因为目标代码与源代码是同一作品。源代码直接比对最为理想，证明力最强，但往往最难取得。
因此，证明的核心任务，不是简单罗列哪些地方相同、哪些地方不同，而是建立一个层次分明的技术事实解释框架。首先要说明比对对象是否属于或者接近著作权保护的表达；其次要说明相似内容在软件整体中的位置、比例和重要性；再次要说明相似是否可以由功能限制、行业惯例、开发工具、第三方代码等合理来源解释；最后还要结合接触可能性、人员流动、开发时间、代码来源等事实，判断相似是否具有复制可能性。
在这一点上，权利方与被诉方均存在可以进一步提升的空间。权利方的优势在于，其逐步抓住了特有标识、空函数、冗余代码、相同错误等非偶然一致性因素。这些内容相较于界面、流程、数据库字段，更难以用普通功能需求解释，具有较强的指向性。但权利方也需要进一步说明这些相似内容的比对范围、覆盖比例、代表性以及与程序核心表达之间的关系。被诉方的优势在于，其能够从整体差异、通用表达、功能限制等角度进行抗辩。但被诉方若只是概括性主张“不同”“通用”“表达受限”等大路货的解释，而不能逐项解释权利方提出的非偶然一致性内容，其抗辩力度仍然不足，因此未能改变法庭的实质性相似的结论。
（后续）
作者简介：
沈兵，上海汉光知识产权数据科技有限公司鉴定机构负责人
