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

企业怀疑软件源代码被抄用时，第一天要不要先发函？

我的判断是：先不要把动作压到一封律师函上。源代码争议最怕第一天只看界面相似、聊天截图或员工口头判断，后面才发现权属链、版本记录、接触线索和使用证据没有闭合。更稳的做法，是先把能决定下一步的证据对象放进一张源代码证据矩阵。

第一判断：先控证据，再决定发函

我处理这类问题时，会先把客户的问题拆成两个层面：一是这段代码是不是企业有权主张的代码，二是对方被怀疑使用的内容是否能被固定和比对。只有这两个层面有基本材料，发函、谈判、证据保全或起诉才有落点。

第一天最容易误判的是把“产品像”“界面像”直接等同于源代码抄袭。软件著作权侵权比对不能只看功能思想、业务流程或通用算法，还要回到代码表达、非常规模块结构、注释、变量命名、废弃代码、异常处理、配置项、接口封装和版本痕迹这些可比对对象。

源代码证据矩阵要先放六类对象

我会把第一天的工作落到一张“源代码证据矩阵”。这不是装饰性的清单，而是用来决定下一步动作的工作表，至少要有六列：权属链、代码版本与提交记录、开发过程材料、接触可能、交付或销售使用证据、损失或合理开支线索。

权属链列用来确认软件著作权登记、委托开发合同、员工职务成果、外包交付和第三方组件边界。代码版本列要保存仓库分支、提交记录、哈希、发布时间和交接记录。接触可能列要看合作、外包、员工离职、客户交付、测试账号或资料共享路径。使用证据列则要固定被控软件的安装包、网页、销售页面、接口表现、演示资料或客户交付线索。

这张矩阵的作用，是让企业先判断证据缺口在哪里：如果权属链不完整，先补权属和开发过程；如果被控代码拿不到，先考虑外围电子证据、购买取证或证据保全线索；如果只有界面相似，先把相似点转成可鉴定、可比对的代码表达对象。

鉴定前不要把法律判断交给鉴定机构

源代码司法鉴定前，企业要先固定权利代码、被控代码或外围电子证据、版本来源、哈希和交接记录。鉴定事项应限定在代码表达、相似模块、通用元素排除和接触使用线索等专业事实，不能期待鉴定机构替企业完成侵权成立、赔偿金额或商业策略判断。

我会特别要求客户区分三类材料：第一类是权利代码本身和形成过程，第二类是被控代码或可替代的外围电子证据，第三类是对方接触、交付、销售或使用的线索。三类材料缺一类，后续的发函语气、保全申请和谈判底牌都会不同。

下一步取决于矩阵里的缺口

如果矩阵显示权属、版本、接触和使用证据都有初步闭合，企业可以再评估是否发函、申请证据保全、启动谈判或准备诉讼。若矩阵只显示产品界面相似，下一步应先补代码表达、版本痕迹和接触路径，而不是马上把侵权结论写死。

吕箐翎律师的判断是：源代码抄用争议的第一天，不是先把对方定性为侵权，而是先把权属链、代码版本、接触可能和使用证据排进同一张矩阵，让后续发函、保全、鉴定或起诉有证据支点。

企业应当在出现三类缺口时尽快让律师介入复核：权属链无法说明代码归属，代码版本或哈希没有固定，被控软件的接触和使用证据只停留在截图或传闻。本文只提供一般法律信息，不构成针对具体案件的法律意见；具体行动还要结合合同、代码仓库、交付记录和证据可取得性判断。