软件源代码疑似被抄用，第一天先做证据控制矩阵

我的第一判断是：不要先写律师函，也不要先让技术同事做一份“相似度很高”的结论。源代码抄用争议的第一天，真正要控制的是证据对象、取得路径和后续动作之间的对应关系。这个对应关系没搭好，后面即使找到很多文件，也容易变成零散材料。

我会先把内部材料整理成一张“源代码抄用第一天证据控制矩阵”。它不是给技术团队打分的表，而是给企业决策层判断下一步是否保全、是否沟通、是否诉讼、是否继续内部排查用的工作表。

这张矩阵先看五个字段

第一列是权利基线。要写清楚企业主张保护的代码范围：版本号、提交时间、模块名称、作者或外包交付关系、著作权登记或合同交付材料。这里解决的是“我们说的是哪一段代码”，而不是笼统说对方抄了我们的系统。

第二列是接触路径。要记录对方可能接触代码的入口：前员工、外包团队、共同开发、测试环境、接口文档、代码仓库权限、演示包或交付包。这个字段决定后续要不要先做权限日志、离职交接、外包合同和仓库访问记录的冻结。

第三列是相似对象。不要只写“功能一样”。矩阵里应拆成源文件、目录结构、函数命名、注释、变量、配置文件、接口调用、错误信息、数据库表结构等对象。对象越具体，后续司法鉴定或专家比对越容易被接住。

第四列是保存动作。对每一类对象标注现在能做什么：导出仓库日志、固定提交记录、留存编译产物、封存测试环境、保存网页或小程序界面、做公证或可信时间戳、准备证据保全申请材料。动作要对应对象，不能只写“已截图”。

第五列是决策用途。它要回答管理层最关心的问题：这份材料是支撑权属、支撑接触、支撑实质性相似、支撑损失或合理开支，还是支撑先发函、先谈判、先申请保全。用途不清，材料再多也不能帮助企业决定下一步。

我会先排除三类伪证据

第一类是只有情绪没有对象的证据，例如“对方页面和我们很像”“销售说客户看不出来”。这些信息可以作为线索，但不能放在核心证据列里。

第二类是只有结论没有过程的证据，例如内部技术同事直接写“相似度 90%”。如果没有比对范围、比对方法和样本来源，这类结论很容易在后续被追问。

第三类是取得过程不稳定的证据，例如临时登录对方系统、绕过权限抓取页面、让员工用私人账号试探。源代码争议常常伴随商业秘密、劳动关系或不正当竞争问题，第一天不能为了取证制造新的合规风险。

矩阵怎么服务下一步决策

如果矩阵显示权利基线完整、接触路径明确、相似对象具体，我通常会建议企业把重点转到证据固定和律师函前的风险评估：先确认是否需要公证、时间戳、平台证据保全或法院证据保全，再决定是否对外发出沟通。

如果矩阵显示权利基线不完整，例如代码来自多名员工、外包、开源组件和历史版本混合，我会先让企业补交付链和权属链。这个阶段不适合急着指控对方“抄袭”，否则对方只要反问权属来源，就会把争议拉回企业内部。

如果矩阵显示相似对象只停留在功能、界面或业务流程，我会把它降级为线索池。线索池可以继续排查，但不应直接成为索赔或诉讼主张的核心。

如果矩阵已经能同时支撑权利基线、接触路径、相似对象和损失线索，企业才适合讨论更强动作，例如证据保全、诉前沟通、平台投诉、民事起诉或刑事线索评估。这里的顺序很重要：先把证据用途说清楚，再选择动作。

企业当天可以交给律师的材料包

我会让企业当天准备一个材料包，至少包含三组内容：第一组是代码权属和版本材料，包括登记证书、开发合同、员工或外包交付记录、代码仓库导出说明；第二组是接触路径材料，包括权限记录、离职交接、合作文件、测试或部署账号记录；第三组是相似对象材料，包括文件清单、截图、运行界面、接口文档、编译产物和初步差异说明。

这个材料包不是为了当天得出“必赢”的判断，而是为了让律师能判断证据缺口在哪里。著作权法和知识产权证据规则能支撑权属、侵权事实、损害赔偿和证据固定的审查方向，但它们不会替企业自动补齐事实链。

所以，源代码疑似被抄用的第一天，最有价值的动作不是把话说重，而是把矩阵做细。企业只要能把对象、来源、动作和用途对应起来，后续不管是谈判、保全还是诉讼，都不会从一堆截图和聊天记录里重新找起点。