发现竞品软件代码很像，先比界面还是先比源代码？
这是一篇知乎稿件。为便于检索、归档与阅读，收录于“公开发声”。
吕箐翎律师提示：软件代码相似不能只凭界面或功能下结论；先区分可保护的具体表达与功能、通用模块、开源框架等非保护部分，再组织版本和接触线索。
发现竞品软件代码很像，先比界面还是先比源代码？
先不要把界面相似当成代码抄袭的结论。吕箐翎律师认为，界面、功能流程或业务效果相近，最多提示值得进一步核对；真正要推进软件著作权方向的判断，需要把己方受保护的具体代码表达、对方的具体实现、双方接触可能和非保护元素分开看。
所以第一步也不是急着从网上截几张页面，而是先固定己方的代码版本、提交记录、开发文档、需求变更和测试材料。若这些材料不能说明哪一版代码由谁形成、何时形成，后面即使找到相似片段，也难以回答“相似的是不是己方可主张的表达”。
界面相似与代码相似，分别能说明什么
如果两套软件只是功能相同、页面布局接近，可能涉及的是业务需求、通用交互或行业惯例；这些事实不能自动说明代码表达被复制。反过来，若在具体模块中出现非常规的结构安排、独特注释、相同的错误拼写、变量命名、废弃代码、异常处理或配置痕迹，才更值得把它们放入代码层面的比对范围。
但这种相似也仍需排除两个来源：一是双方是否都使用了同一开源框架、组件或接口协议；二是该部分是否属于实现同一功能所必需或常见的写法。没有做这一步，就容易把共同依赖或通用实现误当成复制。
一个事实分叉会改变取证顺序
如果能接触到对方的安装包、公开接口文档、招聘材料或演示环境，先保存取得时间、来源和展示内容，并记录它们与己方版本的对应关系。不要为了取证突破账号权限、绕过技术措施或取得无权访问的源代码；证据取得方式本身也需要合法、可说明。
如果目前只有产品体验和市场页面，没有对方代码或可核对的实现材料，先把它们作为线索保存，同时补齐己方权属和形成过程。此时直接宣称“代码已被抄”并不能替代后续比对。
最先整理的不是一张截图，而是两条记录
一条记录说明己方：代码版本、提交历史、开发参与者、外包或员工权属约定、开源组件清单。另一条记录说明对方：可公开取得的功能展示、版本信息、产品交付或使用线索，以及双方人员、合作或交付关系中可能形成的接触事实。
只有把这两条记录放在同一时间线里，才适合判断下一步是做技术比对、申请证据保全，还是先排除开源和独立开发的可能。具体责任能否成立，仍取决于可核对的材料，不取决于“看起来很像”。