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

企业发现软件源代码疑似被抄用时，我不会建议第一反应就发函或公开指责。吕箐翎律师的第一判断是：先把权属、表达、版本、接触和使用线索放进同一张证据矩阵，再决定下一步动作。

先别把界面相似当成结论

软件著作权争议里，真正需要先分开的不是“像不像”，而是哪些内容可能属于受保护的代码表达，哪些只是功能、流程、接口或通用实现。我的处理习惯是先把客户拿来的截图、安装包、代码仓库、交付文件分层，避免把业务流程相似误写成源代码抄袭结论。

这一步对应的企业动作很具体：先冻结现有仓库权限和导出记录，保留当前版本哈希、提交日志、编译包、演示视频或销售页面，不要边调查边改库、删库或重命名文件。证据被自己改乱后，后面即使申请证据保全或做技术比对，也会先被追问版本来源。

第一张表不是诉讼清单，而是决策矩阵

我会让企业先做一张“源代码抄用第一天证据矩阵”。这张矩阵至少要有六个字段：权属链、被疑似抄用的代码表达、版本和提交记录、对方接触可能、交付或销售使用线索、损失或合理开支线索。

权属链用来回答谁有权主张；代码表达用来排除纯功能或通用元素；版本和提交记录用来固定时间顺序；接触可能用来判断对方是否有取得代码的路径；交付或销售使用线索用来判断是否需要尽快保全；损失和合理开支线索只作为后续测算入口，不能在第一天直接写成赔偿结论。

我会先排三个风险顺序

第一，先看权属链是否断裂：软件著作权登记、委托开发合同、员工职务开发材料、外包交付记录、开源组件清单是否能互相对上。权属链不稳时，贸然发函容易把争议焦点从抄用转成“你有没有权利”。

第二，再看代码表达是否具体：能否指出异常命名、注释、废弃代码、配置结构、接口封装或版本痕迹，而不是只说页面、功能或业务逻辑相似。这个动作决定后续能不能进入专业比对或司法鉴定准备。

第三，看证据是否会流失：如果对方页面、接口、应用包、销售材料或仓库访问记录可能随时变化，企业应优先考虑公证、时间戳、平台取证或向法院申请证据保全的路径，而不是先把完整论证发给对方。

证据矩阵怎么决定下一步

如果矩阵显示权属链完整、代码表达指向具体、接触路径清楚，并且对方使用线索可能继续扩散，企业可以考虑先做证据保全和律师函策略，而不是只内部讨论。如果矩阵只有界面相似、功能相似或客户口头判断，则更适合先补仓库记录、合同链和技术比对对象。

如果矩阵已经能对应到损失、违法所得、许可费参照或合理维权支出线索，这些字段可以进入后续谈判和诉讼准备；但它们在第一天的作用是提示要保留哪些票据、订单、报价、服务器记录和维权支出，不是承诺固定赔偿金额。

吕箐翎律师的判断是：源代码抄用争议的第一天，企业要先证明“我有什么代码、对方可能用了什么、证据现在在哪里”，再决定发函、保全、谈判还是起诉。

什么时候该让律师介入

如果企业已经发现仓库权限混乱、外包合同没有源代码归属条款、员工离职前后有异常下载、对方产品仍在销售，或者只剩截图但没有可比对代码版本，就不适合只靠内部技术同事写一份说明。律师审查的重点不是替企业把情绪写重，而是把证据矩阵转成可使用的函件边界、保全申请材料、谈判底线或诉讼准备清单。

以上内容是一般法律信息和证据组织思路，不等于对个案侵权成立、赔偿金额或诉讼结果的判断。具体案件还需要结合代码来源、合同条款、技术比对对象和证据保存状态单独评估。