代码相似就一定侵权吗？先看这条判断路径

【开场镜头：两段代码和一个相似界面并排】 代码相似，不等于一定侵权；界面像，也不等于代码一定被抄。吕箐翎律师的判断是：软件代码争议要先确认保护对象，再看相似部分是不是受保护的具体表达。

【字幕：第一步，先定保护对象】 第一段先讲权利代码。企业要拿得出自己的代码版本、提交记录、开发文档、需求变更、测试记录、员工或外包权属文件。这些材料要对回同一个版本：哪次需求产生了哪段代码，谁在什么时间提交，是员工开发还是外包交付，后续又怎样修改。只有登记证书或一份当前代码，不能代替代码形成过程和权利链材料。

【镜头：版本树与需求单逐项对齐】 所以，比对前先圈定的不是“这个软件”四个字，而是具体版本中由企业享有权利的代码表达。版本对不上，就容易把后来新增的内容、外部组件或已经替换的模块混在一起。

【转场：功能流程图淡出，代码结构出现】 第二段讲排除。软件里很多内容可能来自功能思想、业务流程、通用算法、开源框架、接口协议或必要表达。这些内容不能简单拿来当作“抄袭点”。比对时应标明哪一部分来自已知框架或外部组件，哪一部分受接口或功能约束，哪一部分才是可供继续核对的具体代码表达。排除理由也要和对应代码段一起保留，否则只有一个相似比例，仍然无法说明相似的究竟是通用部分还是具体表达。

【字幕：第三步，看非常规痕迹】 真正需要重点看的，是非常规模块结构、注释、错误拼写、变量命名、废弃代码、异常处理、配置项、接口封装和版本痕迹。这些特征不应脱离上下文单独截取，而要回到它在哪个模块、哪次提交中出现，后来是否被修改或删除。如果两份代码同时保留了一个不影响功能的错误拼写或废弃分支，它比“功能都是下单”更值得继续核对；但它仍是证据线索，不能脱离完整比对直接下结论。

【镜头：材料流转时间线】 第四段把可能的材料流转放回时间线。源码、测试包、外包交付物、代码仓库和内部文档分别在什么时间形成、交付或开放，可以作为理解版本关系的证据背景。这条时间线不替代代码比对，也不单独回答是否侵权；核心仍然是相似部分是什么具体表达，以及通用、开源或必要表达是否已被排除。

【镜头：证据矩阵】 第五段讲第一天动作。不要先发一封情绪化律师函。先把权属链、代码版本、提交记录、开发过程、通用内容排除、具体表达对应和材料流转时间放进同一张表。每一个相似点都应能回到对应文件、版本和提交时间，同时标明是否存在开源、通用或必要表达的排除理由。

【字幕：不同材料，回答不同问题】 权属文件回答“谁对这个版本享有权利”，开发和提交记录回答“代码怎样形成”，排除表回答“哪些相似来自共性”，具体痕迹和版本时间线才用来回答“哪些相似值得继续核对”。把这些问题混成一个相似率，容易让判断失去对象。

【收束】 代码相似争议的核心不是“像不像”，而是相似部分是不是受保护表达、能不能排除通用来源、能不能对回具体版本和形成痕迹。材料流转时间只是证据背景，不单独代替这条判断路径。