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

如果企业发现自己的软件源代码疑似被竞品、外包方或离职人员抄用，第一天不要先把问题写成“对方侵权了”。吕箐翎律师的判断是：先做一张源代码证据矩阵表，把权属链、代码版本、形成过程、接触可能、交付使用和损失线索放在同一页，再决定发函、保全、谈判还是起诉。

我会先把“像不像”拆成可证明的对象

我不会只看前端页面、功能名称或客户反馈。软件争议里，真正要先拆的是：谁拥有这段代码，代码从哪个版本开始形成，哪些提交记录、需求文档、测试记录和交付记录能说明形成过程，对方是否有接触源代码或目标代码的机会。

《中华人民共和国著作权法》可以支撑作品权利和侵权责任的一般框架，但它不能替企业自动证明“这段代码就是我的”。所以第一天的动作不是把结论说满，而是把证据对象先排出来，避免后面发函、谈判或诉讼时只剩情绪和截图。

源代码证据矩阵是一张能决定下一步的表

我通常会让企业把第一天材料做成“源代码证据矩阵表”。这张表至少有六列：权属链，放员工开发、外包合同、委托开发或交付文件；代码版本，放仓库分支、提交记录、哈希值和发布时间；形成过程，放需求变更、开发文档、测试记录；接触可能，放外包权限、离职交接、客户演示或接口开放记录；使用线索，放对方产品页面、交付材料、销售宣传或部署痕迹；损失和合理开支，放订单流失、维权支出和取证成本线索。

这张表不是装饰性的材料清单，而是第一天的比对表和决策表。如果权属链和版本记录不完整，先补内部材料；如果接触可能强但代码比对还没有做，先安排技术比对和证据固定；如果使用线索已经外溢到销售或交付，再评估发函、保全或诉讼节奏。

证据包先固定什么，后续动作才不乱

源代码争议的证据包不只是一堆截图。它至少要把代码仓库、提交记录、需求或测试材料、外包或员工权属文件、对方产品使用线索、销售或交付痕迹放进同一套目录里。目录里的每一项都要对应矩阵表中的字段，否则后续律师函、谈判和起诉都会缺少落点。

吕箐翎律师的处理习惯是先看证据矩阵的空格：空在权属链，就先补合同和开发记录；空在代码相似性，就先做版本封存和技术比对；空在使用线索，就先固定页面、交付、销售和沟通材料。矩阵空格决定第一天动作，而不是愤怒程度决定动作。

为什么不能第一天就只发律师函

第一天直接发函的风险，是把对方提前惊动，却没有把自己的代码版本、提交记录和交付链固定好。对方一旦下架、替换版本或清理痕迹，企业后面再补证据会更被动。

如果矩阵显示权属链、版本链和接触可能都比较清楚，企业可以把律师函、证据保全、谈判方案或起诉准备排成先后顺序。如果矩阵只显示“功能相似”，但没有源代码版本、形成过程和接触可能，下一步应先补材料和做技术比对，不宜把侵权结论写死。

企业下一步看矩阵，不看口头判断

吕箐翎律师的判断是：软件源代码争议的第一天，最有价值的不是一句“对方抄了”，而是一张能让企业决定发函、保全、谈判或起诉顺序的源代码证据矩阵表。

如果企业已经掌握代码仓库、提交记录、外包或员工权属文件、对方产品使用线索，却无法判断是否足以发函或申请证据保全，就应让律师复核这张表和证据包的缺口。复核重点不是替企业承诺结果，而是判断材料缺口、风险边界和下一步动作是否匹配。

以上是基于公开法律和本轮证据包的一般法律信息，不构成针对个案的法律意见；具体案件仍要结合代码、合同、人员权限、取证方式和商业目标单独判断。