源代码疑似被抄，第一天先做哪一张证据矩阵

吕箐翎律师处理源代码疑似被抄用的线索时，我会先把企业从“像不像”的情绪判断里拉出来。第一天不要急着发最强硬的函，而要先做一张“源代码复制第一天证据矩阵”，用它决定先补证、先保全、先谈判，还是进入诉讼准备。

先判断企业手里缺的是结论还是证据对象

很多企业来问时，手里只有界面截图、销售页面、研发同事的口头判断，或者一段被传出来的代码片段。这些材料能提示风险，但还不能直接回答侵权是否成立、赔偿能否主张、是否应当马上发函。

我通常会先拆成五个对象：自己的权利代码是什么，被控对象是源代码、交付包还是外围电子证据，双方有没有合作或人员接触路径，代码形成过程能不能还原，损失或合理开支线索在哪里。这个拆分来自著作权权利基础、知识产权证据规则和源代码固定的共同要求，不是为了拖慢行动，而是为了让下一步行动有支点。

“源代码复制第一天证据矩阵”要有六列

这张证据矩阵不是普通清单，而是一张表。第一列是权属链，放员工、外包、委托开发、交付约定、登记或内部归档材料；第二列是代码版本与提交记录，放仓库版本、提交时间、分支、哈希、发布包和交接记录；第三列是开发过程材料，放需求、设计、测试、缺陷修复和迭代记录。

第四列是接触可能，核查合作、投标、演示、试用、离职、外包或供应商接触路径；第五列是交付或销售使用证据，固定网页、软件包、销售页面、合同、演示材料或客户交付线索；第六列是损失或合理开支线索，保留调查、公证、鉴定、律师费、业务影响和替代开发成本等材料。

企业用这张表的下一步很直接：哪一列空，就先补那一列；哪一列证据可能灭失，就先做固定；哪一列已经能够闭合权属、接触和使用路径，再讨论律师函、谈判、证据保全或起诉。

证据包要先服务于比对和保全

如果后面需要司法鉴定，第一天的证据包就不能只放截图。源代码司法鉴定前，更应先固定权利代码、被控代码或外围电子证据，记录版本来源、哈希和交接过程，再把鉴定事项限定在代码表达、相似模块、通用元素排除和接触使用线索等专业事实。

这也是我不建议企业一开始就把技术报告写成“对方侵权”的原因。技术材料可以说明表达相似和模块关系，但权属链、授权边界、损失线索和法律责任仍要另行闭合。若企业还想同时主张商业秘密保护，就要把保密措施、接触范围和反向工程抗辩风险放进同一份证据包里复核。

先发函还是先保全，由矩阵缺口决定

矩阵完成后，企业可以按三种路径决策。权属链、代码版本和开发过程材料不足时，先补内部材料，避免发函后被反问权利基础；被控网页、软件包、销售页面或交付物可能下架时，先考虑证据固定；权属链、接触路径、使用痕迹和损失线索已经相对清楚时，再评估律师函、谈判、证据保全或起诉准备。

吕箐翎律师的判断是：源代码抄用争议的第一天，真正有价值的动作不是把态度说重，而是用一张证据矩阵把权属链、代码版本、接触可能、使用痕迹和损失线索排清楚；矩阵排不清，律师函、鉴定和诉讼都会被证据缺口反噬。

如果企业发现竞争对手产品、前员工项目、外包交付物或供应商方案与自己的源代码高度相似，但目前只有截图、口头描述、零散聊天记录或不完整代码片段，就应当先做律师复核。复核重点是这张证据矩阵能否支撑下一步行动，而不是简单给出“像”或“不像”的口头结论。

以上只是一般法律信息和证据组织思路，不构成针对具体案件的法律意见。是否发函、申请证据保全、谈判或起诉，需要结合代码材料、合同、人员流转、平台证据和诉讼策略单独判断。