软件交付起争议，先把证据分成 3 类

软件项目一旦起争议，最常见的误区是拿出付款回单、软著证书或一个压缩包，就直接问：代码是不是已经交了？权利是不是归我？对方是不是侵权？

这三个问题不能用同一份材料一次回答。先把证据分成三类，再决定缺什么。

第 1 类：合同履行——约定交什么，实际交了什么

这类材料解决的是“交付有没有完成、完成到哪一步”。优先放在一起核对：

• 合同中约定的成果、交付范围和履行方式
• 对应版本的仓库、分支、提交记录或交付清单
• 验收材料，以及与该版本对应的实际使用事实

关键不是手里“有代码”，而是现有材料能否对上：这份代码是不是合同约定的那个成果？是不是争议所涉的那一版？是否有材料显示它已被交付、验收或实际使用？

第 2 类：代码权属——谁开发，谁有权作出安排

即使合同写有“成果归甲方”，仍需核对实际开发主体及相应授权链。这里要单独核对：

• 实际开发主体是谁
• 该主体与开发方之间的关系和授权材料
• 员工开发、外包开发或第三方组件，各自的授权链是否与主张相对应

这类材料回答的是：开发方究竟有权对哪些代码作出转让、授权或其他安排。它与“项目款是否已付”“系统是否能运行”不是同一个问题。

第 3 类：侵权主张——被主张的对象，能不能落到具体事实

如果已经主张对方侵权，不能从“我曾委托开发”直接跳到“对方用了我的代码”。应先把主张落回具体对象：

• 被主张的是哪段代码、哪个功能或哪个版本
• 它与合同约定、交付记录和开发来源能否逐一对应
• 有关使用行为的材料，是否能与该对象而非泛泛的“软件项目”对应

交付是否完成、权利如何安排、是否构成侵权，可能相互关联，但各自需要不同材料支撑。前两类没对清，第三类结论就应收窄。

三个“看似有用，其实不能单独定案”的材料

付款记录：能说明付款事实，不能单独说明交付范围、具体版本或权利安排。

软件著作权登记：不能单独替代对合同约定、实际开发主体和具体版本来源的核对。

单一压缩包：不能单独证明它就是约定范围内的完整交付，也不能单独说明它与验收或实际使用的版本一致。

最后按这个顺序整理

1. 先列出本次争议究竟在问交付、权属，还是侵权。
2. 对每个问题分别归档对应材料，不把付款、登记或压缩包当作万能证明。
3. 对不上版本、主体或合同范围的地方，明确标成“待补核对”，不要提前写成确定结论。