软件源代码疑似被抄用，第一天先看证据路径表

吕箐翎律师的判断是：第一天不要只凭界面相似、功能相同或员工口头判断发函。源代码争议的风险边界在于，像不等于侵权，功能相同也不等于代码表达被复制；企业应先做一张证据路径表和一份边界清单，再决定保全、谈判还是起诉。

我会先拆三条证明路径

我会先把客户说的代码被抄了拆成三条证明路径：第一，己方有没有清楚的权利基础；第二，对方有没有接触到具体版本；第三，相似点是不是落在代码表达而不是功能思想。这个拆分不是形式动作，因为软件著作权侵权比对不能只看前端页面、业务流程或功能目的，还要排除通用算法、开源框架、接口协议和必要表达。

第一天的动作应落到一张表格：源代码抄用证据路径表。表里至少要有权利基础、代码版本、相似表达、形成过程、接触可能、使用和损失线索六个字段。企业用这张表决定下一步：权利基础缺口大，就先补合同和开发材料；相似表达薄弱，就不要急着发函；接触和使用线索清楚，再考虑证据保全、谈判或起诉。

证据路径表不是材料清单

吕箐翎律师通常会把证据路径表当成决策工具，而不是材料清单。每一栏都要对应一个动作。

• 权利基础：软件登记证书、委托开发合同、员工职务成果文件、外包交付记录，用来判断谁能主张权利。
• 代码版本：仓库提交记录、发布时间、哈希、打包记录，用来固定己方代码形成时间。
• 相似表达：非常规模块结构、注释、错误拼写、变量命名、废弃代码、异常处理、配置项，用来避开只比功能的风险。
• 形成过程：需求变更、测试记录、开发文档、分支合并记录，用来说明代码不是临时拼出来的。
• 接触可能：合作交付、离职下载、外包访问、客户试用、权限日志，用来判断对方是否可能接触。
• 使用和损失线索：对方销售页面、交付材料、招投标文件、客户反馈、合理维权开支，用来决定赔偿或谈判口径。

这张表的下一步很具体：缺哪一栏就先补哪一栏；对方控制关键证据时，才把保全范围、书证提出范围和发函措辞一起设计。否则，风险不是发函不够强，而是过早发函暴露自己的证据缺口。

边界清单要先排除不能证明的部分

源代码争议还需要一份边界清单。清单里至少写明哪些内容不能直接当作侵权证据：功能相同不等于代码相同，界面相似不一定证明源代码复制，接口名称接近也不能替代具体表达比对，登记证书不构成完整权利链。

我不建议企业第一天就把所有相似点写成侵权结论。更稳的做法是先用边界清单排除通用功能、必要表达、开源框架和独立开发可能，再把剩下的非常规模块结构、注释、错误拼写、变量命名、废弃代码、异常处理和配置项放进比对表。

登记证书只能放在权利基础栏

软件著作权登记证书有证明价值，但它不能替代代码形成过程和权利链证据。企业如果只有证书，没有仓库记录、开发文档、员工或外包权属文件，后续很容易被对方拉回谁写的、什么时候写的、写到什么范围的基础争议。

吕箐翎律师的处理习惯是把登记证书放在权利基础栏，而不是把它当成整张证据包。登记证书帮助说明权利主张入口；版本记录、提交记录、合同和交付材料，才决定这个入口能否支撑发函、保全或诉讼。

什么时候应当请律师复核

如果企业已经准备发函、申请证据保全、要求平台或客户下架、启动谈判，或者发现权属文件、外包合同、开源组件、仓库权限日志存在缺口，就应当在行动前做律师复核。复核重点不是把话写得更强，而是确认证据路径表、边界清单和证据包能不能支撑当前动作。

吕箐翎律师的判断是：源代码抄用争议第一天最重要的不是先表态，而是先把证据路径表、边界清单和证据包做成同一套决策材料；能证明的部分推进保全、谈判或起诉，不能证明的部分先补材料或收缩主张。

以上是一般法律信息和材料整理思路，不构成针对个案的法律意见。具体案件仍需结合代码版本、合同、访问记录、对方使用方式和可取得证据判断。