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

源代码疑似被复制，第一天先不要急着定性

如果企业刚发现竞品产品、离职人员项目或技术合伙人新项目疑似使用了自己的源代码，第一天最重要的不是先喊“侵权成立”，而是先把可比对、可追溯、可提交的证据对象固定下来。我的判断是：先做“源代码复制第一天证据矩阵”，再决定是否进入鉴定、函件、谈判、保全或诉讼路径。

我处理这类问题时，会先把客户带来的材料分成两组：一组证明“我方代码从哪里来、归谁、版本是什么”，另一组证明“对方可能接触、复制、使用或交付了什么”。这一步做不清，后面的相似性比对、商业秘密主张、技术合同责任和证据保全都会失焦。

这张矩阵先放六类对象

“源代码复制第一天证据矩阵”至少应把六类对象放在同一张表里：权属链、代码相似性、形成过程、接触可能、交付或销售使用、损失或合理开支线索。它不是为了第一天就证明案件结果，而是为了让企业知道下一步该补哪类材料、先保全哪类对象、鉴定事项该怎么收窄。

权属链先看代码仓库、开发合同、职务成果或合作成果约定、软件著作权登记材料、版本发布记录和交接记录。代码相似性先保留我方权利代码、疑似被控代码或外围电子证据、版本来源、哈希值和提取过程。形成过程要看提交记录、分支、需求文档、测试记录和发布时间线。

接触可能不要只写“他以前在公司工作过”。更有用的是账号权限、下载记录、离职交接、保密协议、技术资料接触范围和后续项目使用线索。交付或销售使用则要对应产品页面、安装包、接口文档、客户交付记录或演示环境。损失和合理开支线索可以先记录销售替代、客户流失、维权支出和保全成本，但不要在第一天把它写成确定赔偿额。

我会先缩小鉴定事项，而不是把全部代码丢给鉴定

吕箐翎律师的判断是：源代码纠纷的第一天证据工作，关键不是把所有文件堆起来，而是把“权利代码、被控代码、接触使用线索、版本哈希和交接记录”先固定成可验证矩阵。

我通常会把鉴定问题先压缩到专业事实：代码表达是否相似，相似模块在哪里，哪些属于通用元素或开源第三方组件，哪些能和接触使用线索对应。这样做的目的，是避免企业把股权矛盾、离职情绪、商业秘密边界和著作权比对混在一起，导致律师函、保全申请或鉴定委托都没有稳定对象。

如果矩阵显示我方只有代码登记证书，却没有版本形成过程、仓库提交记录、哈希和交接记录，下一步应先补权属链和版本链；如果矩阵显示被控代码无法取得，只能看到产品或安装包，就应先评估是否申请证据保全、是否通过外围电子证据锁定版本和使用范围；如果矩阵显示对方有接触权限但缺少保密边界，还要回看合同、制度、权限和离职交接材料。

企业下一步按矩阵缺口决策

这张矩阵可以直接决定企业的下一步动作。权属链缺口大，就先补合同、登记、提交记录和交接材料；相似性材料不足，就先固定我方版本、哈希、被控版本来源和外围电子证据；接触使用线索薄弱，就先整理权限、下载、交接、客户交付和产品上线记录；损失线索不足，就先保留销售替代、客户沟通和合理开支凭证。

企业不宜在矩阵未闭合前直接对外承诺“必然侵权”或“必然胜诉”。更稳的做法是：先用矩阵判断是否进入律师函、谈判、证据保全、司法鉴定或诉讼准备，并把每一步的材料对象和风险边界写清楚。

什么时候需要律师介入

如果企业已经发现代码仓库、离职交接、外部产品、安装包、客户交付记录或权限日志之间存在对应关系，但说不清权属链、版本哈希、相似模块、保密边界和使用范围，就应当尽快让律师参与证据矩阵和鉴定事项设计。这里的重点不是替企业预判结果，而是防止关键电子证据被覆盖、被控对象取错、函件口径过满或后续保全申请缺少对象。

以上是基于现有证据规则、著作权、商业秘密和技术合同边界的一般法律信息，不构成对具体案件的法律意见。具体是否构成侵权、是否适合保全、鉴定或诉讼，还需要结合代码、合同、权限、交付和使用证据逐项判断。