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

吕箐翎律师的第一判断是：不要先凭界面相似、员工口头判断或一段代码截图就发函。软件源代码争议第一天最容易错在把“像不像”“谁写的”“对方有没有接触”“损失怎么证明”混成一个结论，企业应该先把证据对象拆开。

先别急着把相似当成侵权结论

我会先问企业一个更小的问题：现在能证明的到底是代码相似、功能相似，还是界面或业务流程相似。只有把这个问题拆开，后面的发函、谈判、证据保全或起诉才不会被对方一句“只是功能相同”打散。

源代码类纠纷的第一天，不适合直接写成“对方侵权”。更稳的做法，是先形成一张“源代码抄用第一天证据矩阵”，把权属、版本、开发过程、接触可能、使用场景和损失线索分别放进去。矩阵不是为了把案件做复杂，而是为了决定下一步到底是先补证、先谈判，还是先申请证据保全。

这张矩阵至少要放进六类对象

第一类是权属链：软件著作权登记材料、劳动或外包开发约定、代码仓库权限、交付确认和版本归档。它回答的是“这段代码是不是企业有权主张的代码”。

第二类是代码版本和提交记录：仓库提交历史、分支记录、发布时间、关键函数或模块的形成时间。它回答的是“企业自己的代码在什么时间已经形成”。

第三类是开发过程材料：需求文档、设计文档、测试记录、迭代记录和开发沟通记录。它不是装饰材料，而是用来说明代码不是事后拼出来的。

第四类是接触可能：合作、外包、离职、供应商交付、账号权限、接口开放、测试环境访问等记录。没有接触路径时，单靠相似性往往很难支撑企业马上采取强动作。

第五类是对方交付或销售使用证据：产品页面、演示环境、合同交付、下载包、客户使用记录、销售宣传和版本说明。它决定企业要不要把维权目标从“停止使用”扩展到损失或收益线索。

第六类是损失或合理开支线索：替代开发成本、客户流失、维权支出、技术比对费用和可能的权利使用费参照。著作权法上的赔偿框架需要证据承接，第一天就要知道哪些材料以后可能补不上。

吕箐翎律师会先用矩阵分出三条路

我通常不会让企业第一天只做一份措辞很重的律师函。更实际的顺序是：先看矩阵里哪一列是空的，再决定动作强度。

如果权属链和版本记录不完整，下一步通常是先补内部材料和代码仓库证据，不急着对外定性。如果接触可能和对方使用证据比较清楚，可以考虑先做技术比对、证据固定，再评估发函或谈判。如果对方正在销售、交付或继续扩散，企业就要同步评估证据保全、禁用要求、诉讼节奏和损失线索。

这就是矩阵的价值：它不是一张资料清单，而是一张动作分流图。企业用它能看出自己是在补权属、补相似性、补接触路径，还是已经接近对外行动节点。

常见误区是只盯一段相似代码

只截一段相似代码，很容易漏掉三个关键问题：这段代码是不是受保护表达，对方有没有合理来源，企业能不能证明自己的形成时间和权属链。软件争议不是截图竞赛，真正能推动下一步的是证据之间能不能闭合。

吕箐翎律师的判断是：软件源代码疑似被抄用时，第一天先做证据矩阵，比先写强硬结论更重要；矩阵能把权属链、代码版本、接触可能和损失线索分开，让企业知道下一步该补证、谈判、保全还是起诉。

什么时候应该尽快让律师介入

如果企业手里只有界面截图、离职员工怀疑、客户反馈或零散代码片段，却还缺权属链、提交记录、接触路径或对方使用证据，就不宜直接把材料发给对方摊牌。这个材料缺口本身就是律师复核触发点。

企业可以先把“源代码抄用第一天证据矩阵”整理出来，再让律师判断哪一列会影响发函措辞、证据保全申请、谈判底线或起诉路径。本文只是一般法律信息，不替代对具体代码、合同、证据和案件管辖的个案法律意见。