公司发现软件源代码疑似被抄用，第一天该先固定哪些证据？

先别急着只拿界面截图去发律师函。软件源代码抄用争议，第一天最重要的不是把对方定性成侵权，而是把“权属、代码、接触、使用、损失”放进同一张证据矩阵。否则后面即使方向是对的，也可能因为证据链断开，导致函件、谈判、保全或诉讼都变得被动。

一、先判断争议对象是不是“代码表达”

著作权法保护的是作品表达，不是抽象功能、业务想法或需求描述。软件场景里，企业容易把“功能一样”“页面很像”“流程差不多”直接说成抄代码，但这些只能作为线索，不能直接替代代码层面的比对。

第一天要先把对象拆开：源代码文件、模块结构、注释、变量命名、异常处理、配置项、接口封装、废弃代码、提交记录和版本痕迹。真正有用的通常不是一句“很像”，而是能说明哪些具体表达、哪些非常规痕迹、哪些开发过程材料互相印证。

二、证据矩阵至少放六类材料

第一类是权属链：软件著作权登记材料、委托开发合同、员工开发职责、交付确认、版本发布记录。登记证书有帮助，但不能单独替代真实开发和权利归属材料。

第二类是代码版本与提交记录：代码仓库、commit、分支、tag、打包记录、上线记录、缺陷修复记录。要保留原始环境和导出过程，避免只截几张图。

第三类是开发过程材料：需求文档、原型、接口文档、测试记录、迭代记录、内部评审记录。这类材料能解释代码为什么这样形成。

第四类是相似性对象：不是泛泛说“功能一致”，而是列出具体文件、函数、注释、错误拼写、废弃逻辑、命名习惯和配置结构。

第五类是接触可能：合作谈判、外包交付、员工离职、供应商访问权限、账号日志、下载记录、邮件或聊天记录。没有接触链，很多“相似”会变成解释空间很大的事实。

第六类是使用和损失线索：对方产品页面、销售材料、投标文件、客户交付记录、价格变化、替代订单、维权合理开支。著作权法第五十四条涉及实际损失、违法所得、许可费参照、法定赔偿和合理开支，但第一天通常只能先固定线索，不能拍脑袋写出赔偿数字。

三、第一天不要做三件事

不要只发威胁性律师函。函件一旦把对象、权属或金额说满，后面证据补不上，会反过来削弱谈判位置。

不要让技术同事直接改仓库、删日志、重跑构建。争议发生后，保存原始状态比“整理得更好看”更重要。

不要把所有材料一次性发给对方。可以先内部分级：哪些用于初步沟通，哪些只在保全、诉讼或正式谈判阶段使用，哪些涉及商业秘密需要脱敏。

四、一个可执行的第一天顺序

先冻结内部证据：仓库、权限日志、合同、交付记录和版本包。再做一页材料索引，标注来源、时间、保管人和能证明的问题。然后让技术人员做“相似点清单”，但不要让技术结论替代法律判断。最后再决定路径：先沟通、先申请证据保全、先发函，还是先补权属和开发过程材料。

这个顺序的价值在于把争议从情绪判断拉回到证据对象。源代码抄用案件里，真正决定后续动作的，往往不是第一天说得多强硬，而是第一天有没有把关键材料按矩阵留住。

FAQ

已经有软件著作权登记证书，还要代码仓库和开发记录吗？ 要。登记证书可以帮助证明权属线索，但代码形成过程、版本记录和相似性对象仍然重要。

界面和功能高度相似，能不能直接认定抄代码？ 不能直接认定。界面和功能可以提示风险，但还要回到代码表达、接触可能、开发过程和具体相似点。

以上是一般信息，不替代个案法律意见。知乎上如果你遇到的是外包交付、员工离职带走代码、竞品上线高度相似等具体情况，可以把权属链、仓库记录、相似点清单和接触材料先整理出来，再联系吕箐翎律师做个案分析。