移动应用代码抄袭取证与开源合规整改指南

在二次创作与开源分发交叉的生态中，“代码被原样搬运”并不罕见。这类争议的走向，往往不取决于谁的声量大，而取决于谁拿出的证据链更完整、方法更经得起推敲。本文以一次真实核查为例，拆解一套可复用的完整方法：从建立比对基线、历史版本正向对照，到方法级严格匹配与许可证合规判定，最后给出可直接套用的整改清单。

一、先立基线：把“共同祖先”从证据池中彻底剔除

代码比对的第一个陷阱是假阳性。两个分发物中都存在的实现，未必意味着抄袭——它们可能同时来自原作本体、通用引擎、公开的第三方库，或双方共同依赖过的某个上游版本。如果把这些内容计入证据，对方只需一句“上游本来就有”，就能让整份证据作废。

规范的做法是先构建“共同原始基线”：

1. 取得双方公认的基线版本 APK；
2. 对其全部命名空间下的代码方法做完整内容核对（本次案例中为 54,219 个方法）；
3. 登记其中所有完整方法序列，以及具有一致性的连续长指令片段；
4. 后续比对中，凡能被该基线解释的内容，一律不作为己方独有成果的证据。

这条纪律可以概括为“宁可少，不可滥”：原作、引擎、通用库与共同基线内容，无论与当前版本多么相似，都不进入证据池。证据池越小、越纯，单项证据的证明力越强。

二、历史对历史：拒绝“用现在倒推过去”

第二个陷阱是时间错位。若只拿己方最新版本与对方分发物比对，等于在方法论上默许了“从当前状态倒推历史状态”，这会给对方留下合理的质疑空间：你如何证明当年发布的版本就是这样？

因此核查必须坚持“同代比对”：使用己方精确归档的历史发布 APK 及与其绑定的源码包，与对方对应时期的分发版本做直接比较，而非用现行版本反推。同时，把比对范围限定在项目源文件之内，避免构建产物与通用资源制造噪音。

工程上这意味着一件事：每个对外发布版本，都必须有可复现的产物归档与版本号一一绑定的源码快照。没有这个习惯，取证在起点上就输了。

三、严格匹配：什么样的“相同”才算证据

比对的目标不是“找相似”，而是“找无法被任何合理来源解释的相同”。完整筛查流程如下：

1. 初筛得到的完整方法匹配，逐个与共同基线重新比对；
2. 排除长度不足阈值的短片段——短指令序列在编译产物中的碰撞概率极高，不具备区分度；
3. 通过筛查的匹配才进入证据池。

示意伪代码：

for m in initial_full_method_matches:
    if common_baseline.explains(m):        # 能被共同基线解释
        discard(m)
    elif consistent_instructions(m) < 10: # 一致指令不足阈值
        discard(m)
    else:
        evidence_pool.add(m)               # 进入证据池

本次案例中，筛查后仍存活 906 个严格匹配的方法，每个都保留了至少 10 条一致且无法被基线解释的指令条目，其中包括分段下载与下载事务实现这类控制流复杂、天然碰撞率极低的长方法。

“严格匹配”的技术含义必须交代清楚，否则会被误读为宽松的模糊匹配：

• 调用对象：invoke 指令的目标一致；
• 完整字符串：字符串常量逐字节一致，而非仅语义相近；
• 寄存器分配：局部变量到寄存器的映射一致；
• 分支结构：跳转目标构成的流程拓扑一致；
• 异常处理：异常表的覆盖范围与处理入口一致。

共同基线的筛查则另行使用明确公示的指令规范化规则，保证筛查过程可复现、可被第三方独立验证。这一点至关重要：证据的说服力不来自结论本身，而来自“任何人按同样步骤都能得到同样结果”。

四、许可证核查：与抄袭指控并行的第二条证据线

代码搬运往往同时触发许可证问题。若己方历史源码包中带有 GPL（GNU 通用公共许可证）及相关的许可声明，对方的分发行为就要接受另一重检验。

本案中，历史源码包内的 GPLv3 及相关许可声明已逐一核对，据此可以向发布者提出明确质询：这些被许可证覆盖的具体实现来自何处、做过哪些修改、对应源码是否交付以及如何交付。

实际检查结论是：在已取得的 APK 及随附材料中，尚未发现与两个分发版本相匹配的完整对应源码交付入口与必要许可材料；资源包中附带的 JavaScript 文件也无法覆盖已被发现的 Java/native 实现，更缺少必要的构建材料。若发布方认为相关材料已通过其他渠道交付，则应给出具体版本、地址与可核验的说明。

五、什么才算“完整的对应源码”

这是争议中最常见的认知误区，需要按许可证定义澄清。以 GPLv3 为例，“对应源码”（Corresponding Source）不是“把几个源文件打包”，而是一个明确定义的集合，包括：

• 生成、安装、运行（对可执行作品而言）与修改该作品所需的全部源代码；
• 控制上述活动的脚本；
• 必要的构建说明。

据此可以判定，以下做法均不构成合格交付：

• 只提供不含修改内容的上游仓库链接——缺失的恰恰是“修改”本身；
• 只提供部分资源文件——无法复现实际分发物；
• 提供另一个版本的源码——与实际分发的二进制不对应。

六、网络分发的合规判定：以第 6(d) 条为标尺

对通过下载方式分发 APK 的场景，GPLv3 第 6(d) 条给出了明确的替代交付路径：在目标代码下载位置的旁边，提供对应源码的等效、无需额外付费的访问位置，并在所需期间保持可用。实践中有三个要点：

1. 源码可以托管在其他站点，不要求照搬权利方的目录结构或页面形式——合规关注的是可获取性，而非形式一致性；
2. 访问入口应当明示且无门槛；
3. 对此前已经取得 APK 的存量用户，发布者同样有义务告知其获取对应源码与许可材料的途径。

七、可直接套用的整改清单

把上述判定标准落成对发布方的整改诉求，也可作为同类争议的通用模板：

1. 溯源说明：分别说明各分发版本涉及的上游项目、版本或提交，以及修改范围；对证据有异议的，提供可逐项核对的材料。
2. 补齐源码：为每个已分发版本补齐受 GPL 覆盖的作品及其修改的完整对应源码，含生成、安装、运行与修改所需代码、控制脚本与必要构建说明。仅给上游链接、部分资源或其他版本源码，均不能替代。
3. 补齐声明：保留适用的版权、许可证、免责声明与合理归属声明，附许可证全文；显著标明已作修改及相关日期；并履行其他组件各自的许可要求。
4. 分发合规：按第 6(d) 条在 APK 下载旁提供等效、免费的对应源码访问位置，并在所需期间保持可用，同时通知已获取 APK 的用户如何获取材料。

八、给开发团队的预防性建议

这次核查能够成立，前提是权利方长期保持了两个工程习惯：发布产物精确归档、产物与源码包绑定存档。对企业团队而言，建议将这两步固化到持续集成流水线中：

• 构建产物入库时，同步固化源码快照与第三方依赖的许可证清单；
• 定期执行依赖扫描，提前发现潜在的许可冲突；
• 归档保留期限覆盖产品的全生命周期。

这不仅是合规防御，也是争议发生时唯一拿得出手的“在场证明”。

结语

代码抄袭争议的胜负不在声量，而在证据链：基线是否排除干净、比对是否坚持历史对历史、匹配是否保留全部语义信息、源码交付是否满足许可证定义。把每一步都做成可复现、可核验的动作，对话才有基础，整改才有抓手。用工程纪律对待取证，用许可证文本对待合规——这是每一位开发者与团队在面对类似争议时都应掌握的方法论。