软件代码相似不是截图能证明，先固定样本和排除项

软件著作权争议中，当事人常拿几张页面截图说“对方系统和我们一样”。吕箐翎律师的实务判断是，页面相似可以提供线索，但代码相似不能只靠截图证明。第一步要固定样本和排除项。

软件案件最容易混淆三件事：功能相似、表达相似、代码复制。功能和业务逻辑本身不等于著作权保护对象，真正要看源代码、目标代码、界面表达、文档表达和版本记录。

先确认保护对象

权利软件包括源代码、目标代码、界面、图标、说明文档、接口文档、数据库结构、部署脚本和测试数据。不同对象的证明方式不一样。

如果争议焦点是源代码复制，就围绕代码版本和提交记录；如果焦点是界面，就固定页面布局和素材；如果是文档，就比对文字、图表和结构。不要把所有问题都笼统写成软件侵权。

样本来源要可靠

权利代码要有版本号、提交记录、开发文档、软件著作权登记材料和保存路径。被控代码可能来自法院保全、对方提交、安装包、服务器镜像、目标代码、运行页面或外围文件。

样本从哪里来，什么时候取得，是否完整，是否被修改，都会影响后续比对。样本不稳，鉴定结论也会被质疑。

排除通用元素

代码相似不必然等于复制。开源框架、通用库、接口协议、低代码平台、行业标准、模板代码和必要表达，都可能造成相似。

有价值的相似点通常是非常规模块组织、相同注释、相同错误拼写、相同历史残留、特殊变量命名、相同异常处理和相同业务转换逻辑。

拿不到源代码时先固定外围

很多案件一开始拿不到对方源代码。可以先固定安装包、运行环境、网络请求、文件结构、接口返回、错误提示、版本号、日志和演示过程。

这些外围证据不能完全替代源代码比对，但能帮助判断是否申请证据保全、现场勘验或司法鉴定。

下一步

吕箐翎律师建议，软件代码相似案件先做三张表：权利样本表、被控样本表、排除项表。

我还会要求企业说明代码形成过程。谁提出需求，谁提交代码，哪个版本交付客户，哪些模块来自开源或外包，哪些是内部长期迭代形成。没有形成过程，只拿一个最终压缩包，很难说明权利基础。

如果案件涉及员工离职、外包团队或技术合伙人，还要同步看合同和权限记录。代码相似只是结果线索，权属、接触机会、下载外发、后续使用和客户交付，才会共同决定案件能不能站住。

我会提醒企业保留原始载体。代码压缩包、仓库镜像、服务器快照、安装包和日志，尽量不要只保存二次整理后的文件。原始来源越清楚，后续比对、保全和质证越稳。技术团队方便查看的材料，不一定就是法庭上好用的证据。

还要把开源组件清单提前列出。很多相似点来自共同框架或公开库，如果不先排除，企业容易把普通技术相似误判成复制。排除项做得越细，真正有价值的相似点越突出。

表格完成后，再考虑技术比对和鉴定事项。不要要求鉴定机构直接判断“是否侵权”，更适合的问题是代码表达是否相似、哪些部分相似、哪些属于通用元素。本文是个人实务观点，只提供一般法律信息参考。