从确权到维权:计算机软件著作权纠纷的实务要点与合规指引·下篇

接触是指被诉侵权人具有接触权利软件的机会。原告不需证明被告实际看到了源代码，只需证明存在接触的可能性即可。常见的接触情形包括：被告或其核心人员曾与原告存在劳动关系、合作关系，或权利软件已公开发布。

在（2023）最高法知民终1105号案中，邓某才曾在百某公司担任软件开发工程师，参与了北某、恒某等研发项目的开发工作，其离职后，百某公司在其工作电脑中发现包含“某某835”命名的文件夹，而速某公司被诉侵权软件的名称即为“某某835”。最高人民法院据此认定邓某才具有接触权利软件的可能性。

在（2024）最高法知民终353号案中，雷某、林某、邱某曾在创某公司工作，分别担任UI设计师和Python工程师，在职期间均可接触到“earth地球”软件的相关文档及源代码。三人离职后先后入职亚某公司，最高人民法院认定亚某公司具备接触权利软件的可能性。

实质性相似是指被诉软件与权利软件在源程序、目标程序或文档方面构成实质性的相似。源代码比对是认定实质性相似的最直接方式，但并非唯一方式——被告拒不提供源程序时，可通过目标程序比对、运行界面比对、特有信息比对等方式综合判断。

（一）源程序比对

源程序是程序员按照特定编程语言规范编写的、人类可读的计算机语言指令。 司法实践中，源程序反映了作者对计算机软件作品的表达，将权利软件与被诉侵权软件的源程序进行比对，是判断实质性相似最直接的方式。

比对时，应先排除公有领域内容、有限表达、第三方开源代码等不受保护的部分，再对文件名、文件内容、函数、变量等要素进行分析。

例如，在（2023）最高法知民终2573号案中，司法鉴定意见将被诉侵权软件与权利软件的FPGA程序执行代码进行比对，相似度达91.98%至93.83%，最高人民法院采纳该鉴定意见认定构成实质性相似。

（二） 被告拒绝提供源程序时的替代方法

在被告拒不提供源程序的情况下，法院可通过目标程序比对、反编译比对、运行界面比对等方式进行综合判断。

《北京市高级人民法院侵害著作权案件审理指南》第11.6条、第11.8条规定：被告拒不提供被诉侵权软件源程序的，可以将双方软件的目标程序进行对比；被诉软件目标程序中存在权利软件特有内容的，可以认定两款软件构成实质性相似。该规则的依据在于举证责任的分配，被告控制着被诉软件的源代码，无正当理由拒绝提交的，应承担不利后果。

在（2023）最高法知民终1105号案中，速某公司自认被诉侵权软件系第三方制作，却拒不提供源代码，亦不提供第三方信息。鉴定机构将权利软件与被诉软件的目标代码进行比对——即可视化部分进行日志输出比对，不可视化部分通过比对双方代码中出现的公司名称信息进行判断。最高人民法院认定该比对方法并无不当，据此认定构成实质性相似。

在（2023）最高法知民终3172号案中，一审法院两次责令被告提交FPGA源代码，被告无正当理由均未在指定时间提交，逾期提交的源代码生成的目标代码与被诉侵权产品提取的目标代码存在较大差异，且被告拒绝提供原始编译环境。最高人民法院认定，被告无正当理由逾期提交代码、拒绝提供编译环境，导致待证事实无法查清，依法推定侵权成立。

（三）侵权表征推定

被诉软件中存在权利软件的特有信息（如相同的包名、相同的超链接、相同的QQ群链接、相同的错误信息等），且被告无法作出合理解释的，法院可据此认定实质性相似。

在（2024）最高法知民终353号案中，创某公司通过司法鉴定证明“一个地球”软件与“earth地球”软件存在相同的包名、相同的“Intent过滤器”规范、相同的超链接、相同的QQ群链接等特有信息。亚某公司未提交源代码比对，亦未对上述相似之处作出合理解释。最高人民法院认定侵权成立。

第三部分 风险防控与合规

基于前文的分析，本节从企业实务需求出发，按研发阶段提出可落地的合规建议。

一、研发前的合同安排

1.委托开发合同中必须明确约定著作权归属。如约定“源代码及全部衍生权利的著作权归委托方所有”，并要求受托方交付完整源代码及开发文档，约定其不得将同类核心代码用于其他客户产品。

2.合作开发合同中明确共有方式与行使规则。未约定且不可分割使用的，由合作作者共同共有，行使须协商一致，一方擅自登记容易引发权属纠纷。合规要点：明确按份共有或共同共有，约定各方行使权利的具体规则。

3.研发人员入职时签署职务作品归属协议。如在劳动合同中细化岗位职责描述，明确“本职工作中明确指定的开发目标”，确保与软件研发工作的对应关系。对核心研发人员可设置竞业限制条款，但须注意期限和补偿标准应符合法律规定。

二、研发过程的证据留存

1.规范使用版本管理系统（Git/SVN）。提交记录包含完整的时间戳、提交人和变更内容，是证明创作事实的最客观证据。

2.完整归档开发过程文档。设计文档、会议纪要、往来邮件、工作日志等，是印证创作链条完整性的关键佐证。单一证据容易被质疑，多项证据相互印证才能形成完整的证据链条。

3.关键版本做哈希时间戳存证。如每季度对主分支的主版本做一次第三方存证，锁定代码在特定时间点的状态，防止事后被质疑篡改。

4.在代码中嵌入标识性信息。包括企业名称、自定义的无意义字词、独特的变量命名规则等。被诉侵权软件中一旦出现这些标识，将成为认定“接触”和“实质性相似”的有力证据，甚至相同的设计缺陷和冗余信息都可能成为胜诉关键。

三、技术与权利保护

1.对核心技术软件加入反编译技术保障措施，防止对方通过反向工程轻易获取源代码。对外销售或许可时，在合同中增加“未经许可不得反编译/反向工程”条款。

2.软件开发完成后及时办理著作权登记。登记虽非权利产生条件，但登记证书在诉讼中是最低成本的初步证据，登记时间越早证明力越强。核心算法模块可单独登记，与整体软件登记形成矩阵式保护。

3.核心模块对外发布前，对代码包做电子数据保全公证。既锁定发布时间，也确定权利软件的基准版本，同时服务于确权和维权需求。

4.保留公开发布时的署名证据。官网页面、应用市场页面等对外发布的署名证据，是证明“公开时间”和“署名事实”的重要材料。

四、开源代码合规管理

开源代码的不当引入是企业最常见的被诉风险源。“开源”不等于“免费使用”，不同许可证约束力差异显著。MIT、Apache 2.0、BSD 3-Clause允许商业使用，一般不要求公开衍生代码；GPL、AGPL具有“传染性”，引入此类代码的衍生作品须以相同许可证开源。违反开源协议使用条件的，协议自动解除，使用行为失去合法基础。

可以考虑建立开源代码使用清单，逐项审查许可证类型，定期复核。引入GPL/AGPL类代码前进行法律合规审查，评估对整体软件著作权的影响。同时注意开源代码与自研代码的隔离，若核心代码独立且可分别部署，开源协议的“传染性”通常不波及其他独立部分。

五、人员离职管理

核心研发人员离职是权属流失和侵权风险的重要源头。离职时要求返还全部源代码和开发文档，签署保密确认函。对已签署竞业限制条款的人员，确认其履行情况。

六、合规审查常态化

上述措施的落地有赖于常态化的审查机制，而非一次性文件。可以考虑将以下事项纳入年度或季度合规审查清单：开源代码使用清单的更新与许可证复核；核心研发人员职务作品协议的签署情况；版本管理系统和第三方存证的执行情况；核心软件著作权登记的及时性等。

结语

软件著作权的保护，始于确权、成于维权。确权不清，维权便失去了前提；侵权认定不明，合规便失去了方向。本文以“确权”与“维权”为主线，梳理了权属认定与侵权判断的核心规则，并围绕开源合规、证据留存、员工管理、合同约定等实务场景提出了风险防控思路。规则是固定的，但实务是复杂的。纠纷发生之前，证据越完整、越清晰，企业在争议中的主动性就越强。诉讼是最后的手段，而真正的保护，来自每一行代码被写下时的那份严谨与远见。

参考：

1.朱玮洁，《计算机软件著作权侵权的裁判路径与证明规则》，知产前沿，2026年7月17日。

2.何渊、侯楠竹，《计算机软件著作权侵权判定方法之探》，《中国审判》。

3.安筱琼、姜润，《人工智能时代软件著作权侵权案件之诉讼策略》，《中国律师》2026年第6期。

4.参考（2023）最高法知民终1105号裁判文书。

5.参考（2023）最高法知民终2586号裁判文书。

6.参考（2023）最高法知民终1771号裁判文书。

7.参考（2023）最高法知民终1591号裁判文书。

8.参考（2024）最高法知民终353号裁判文书。

9.参考（2023）最高法知民终2573号裁判文书。

10.参考（2023）最高法知民终3172号裁判文书。

11.参考（2023）最高法知民终1975号裁判文书。

12.参考（2025）沪民终651号裁判文书。