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

我的实务判断是，企业第一天不要先写一封情绪很重的律师函，也不要只拿几张界面截图去判断“对方抄了”。我会先把权属、代码版本、接触可能和对外使用证据放进同一张源代码抄用证据矩阵，再决定是发函、申请证据保全、谈判还是起诉。

先把问题从“像不像”拆成“能不能证明”

源代码争议最容易走偏的地方，是把产品界面相似、功能相似或者前员工离职后的竞争关系，直接当成软件著作权侵权结论。吕箐翎律师处理这类问题时，会先把客户的问题拆成三个层次：自己的代码是不是能证明权属和形成过程，对方代码或产品中有没有可比对的具体表达，对方是否存在接触、取得、交付、销售或使用线索。

这个拆分很重要。著作权法可以支撑软件相关著作权保护和侵权责任框架，但具体案件里仍要回到保护对象、可保护表达、相似部分、接触可能和损失证据。只说“功能一样”或者“页面长得像”，通常不足以决定下一步动作。

第一张表不是诉讼表，而是证据矩阵

我通常会让企业第一天先做一张“源代码抄用第一天证据矩阵”。这张矩阵至少要放进六类对象：权属链，代码版本与提交记录，需求、设计、测试等开发过程材料，前员工、外包方或合作方的接触可能，交付、销售、部署或宣传使用证据，以及损失、合理开支或许可费参照线索。

这张矩阵的作用不是马上证明侵权成立，而是让企业知道下一步该选哪条路。权属链和版本记录完整，才有基础谈保护对象；代码相似性证据足够具体，才有必要考虑比对或鉴定；接触和使用线索存在，才有理由推进证据保全、发函或谈判；损失和合理开支线索可整理，才谈得上赔偿路径。

代码比对要看具体表达，不能只看业务流程

软件著作权侵权比对前，我会先提醒企业排除功能思想、业务流程、通用算法、开源框架、接口协议和必要表达。真正值得放进矩阵的，是非常规模块结构、注释、错误拼写、变量命名、废弃代码、异常处理、配置项、接口封装和版本痕迹等更接近代码表达的对象。

如果企业只有产品截图和竞品页面，第一天的动作应当是补证据，而不是直接升级对抗。可以先固定自己代码仓库的提交历史、版本哈希、开发文档和交付记录，同时整理对方产品的公开页面、安装包、接口表现、宣传材料和销售线索。矩阵里每一格都要标明来源、保存方式和是否需要进一步取证。

接触可能和使用证据决定动作强弱

源代码疑似被前员工、外包方、技术合作方或供应商抄用时，我会特别看接触路径。仓库权限、下载记录、访问日志、离职交接、外包合同、保密条款、交付验收记录、客户部署材料和销售页面，往往决定企业是先内部锁证、先发函，还是先申请证据保全。

这里的风险边界也要讲清楚：前员工去了竞争对手，不等于当然抄代码；外包方参与过开发，也不等于当然无权使用全部成果；界面相似，也不等于源代码表达相同。矩阵的价值，是把这些容易混在一起的事实拆开，避免企业用一个单薄结论去承担不必要的发函、诉讼或商业谈判风险。

赔偿线索第一天也要留，但不要倒推结论

著作权法第五十四条提供了实际损失、侵权获利、权利使用费参照、法定赔偿、惩罚性赔偿条件和合理维权开支等赔偿框架。第一天的证据矩阵可以同步记录客户流失、订单转移、价格报价、对方销售线索、许可费参照、取证费用和律师费等线索。

但我不会建议企业用赔偿预期倒推侵权结论。赔偿线索只能说明后续路径要不要继续投入，不能替代权属、代码表达、接触可能和使用证据。矩阵如果显示核心证据缺口很大，下一步可能是补齐版本留痕、做内部权限核查或寻求证据保全，而不是急着把索赔金额写进律师函。

企业下一步怎么用这张矩阵

吕箐翎律师的判断是：软件源代码抄用争议第一天的关键，不是先喊“侵权”，而是用一张证据矩阵同时固定权属链、代码版本、接触路径、使用线索和损失线索，再选择发函、保全、谈判或诉讼。

企业可以把矩阵分成“已经有证据”“需要补证据”“需要对方或平台配合取得”“需要法院保全或鉴定支持”四列。若权属和版本证据完整、接触路径清楚、对外使用线索明确，可以考虑更强的发函、保全或诉讼准备；若只有界面相似或员工流动线索，下一步应先补代码形成过程、权限日志和交付记录。

如果企业已经准备发函、报案、申请证据保全或启动诉讼，但矩阵里缺少权属链、代码版本、接触记录、对方使用证据或损失线索，就应当先让律师复核材料缺口和路径选择。以上只是一般法律信息，不构成针对具体案件的法律意见。