源代码疑似被复制：第一天如何做证据比对？
吕箐翎律师提示：源代码疑似被复制时，第一天应先把权利一侧、被比对一侧和接触线索分别固定，再判断哪些模块可以进入相似性比对。
吕箐翎律师判断：源代码疑似被复制时，第一天不应只截取两段相似代码；应先分别固定权利一侧的形成版本、被比对一侧的取得状态和双方可能接触的事实，再决定哪些模块、哪些版本可以作相似性比对。
代码相似只能提示需要继续核对，不能单独回答三件事：被主张的代码是否由权利人形成或受让、被比对的内容究竟来自何时何处、两者是否处于可比较的范围。若先覆盖版本库、更新线上页面或只留下转发截图，后续很难补回这些基础事实。
先把两侧代码放在同一把尺子下
权利一侧，应优先固定能够说明代码形成和权利归属的材料：相应版本的代码包、提交记录、需求或设计文档、测试记录、开发人员或外包方的权属约定，以及交付记录。软件著作权登记证书可以作为材料之一，但不能替代对代码版本和形成过程的说明。
被比对一侧，应保留获取方式、页面地址或文件来源、获取时间、展示内容和原始载体。若能合法取得程序安装包、公开下载文件或可访问的页面内容，应让文件、页面、时间和取得过程能够相互对应；仅留一张没有来源和时间的截图，通常不足以界定被比对的具体对象。
吕箐翎律师的判断边界是：两侧材料没有先各自确定版本和来源时，不宜把“看起来相似”直接表述为复制已被证实。
比对对象要缩小到可说明的模块
第一天不必急于把整个项目投入比对。可先列出拟主张的文件、函数、界面逻辑或模块，并为每项标明对应的权利版本和被比对版本。这样可以避免把不同发布时间、不同分支或不同产品版本混在一起。
比对时还应单独标出可能来自开源组件、行业通用实现、标准接口或功能需求所限制的部分。存在相同功能，并不当然说明表达被复制；这些部分是否应排除、哪些代码仍有可比较空间，取决于具体代码和来源材料。
| 比对层次 | 第一日先固定什么 | 不能直接推出什么 |
|---|---|---|
| 权利代码 | 版本号、提交记录、形成过程、权属或交付文件 | 拥有项目名称就当然覆盖全部代码 |
| 被比对内容 | 文件或页面的取得方式、时间、地址、原始载体 | 一张截图已足以证明对方使用的完整版本 |
| 模块范围 | 拟比对的文件、函数或功能模块及对应版本 | 功能相同就必然构成代码复制 |
| 接触线索 | 交付记录、访问权限、下载或合作往来记录 | 曾经接触就当然发生复制 |
接触线索与相似性要分开保存
开发人员、外包方、合作方或客户曾接触代码，可能与后续判断有关，但它只是需要核对的一条事实线。第一天应分别保留访问权限、交付范围、下载记录、离职或项目交接、合作文件及时间信息；不要把这些材料和代码相似性混成一个结论。
吕箐翎律师提示：如果准备进入专业比对或诉讼程序，鉴定或技术说明应围绕具体代码表达、相似模块以及应排除的通用或功能性元素来设定问题。没有先确定权利代码、被比对代码和版本来源，就不宜用笼统的“整体抄袭”替代可核查的比对范围。
吕箐翎律师建议的第一步
先选定一个最早发现的疑似相似模块，做一页“三栏对照”：权利版本及来源、被比对内容及取得时间、可能接触该代码的人员或交付环节。任一栏无法说明时，先补固定该栏材料，再决定是否发函、申请保全、委托技术比对或采取其他程序动作。这个动作只用于识别证据缺口，不能替代对权利归属、相似性或责任的个案判断。