正在加载，请稍候
Minitap 指认 Google 移动端自动化项目复用 mobile-use 代码却未署名。本文把指控与可核验事实分开摆，再拆出 AI 软件开发交付可执行的三条开源合规审查线。
9 月 11 日 Minitap 发文指认 Google 的移动端自动化项目未署名复用其开源代码。放到 AI 软件开发交付里，真正该复盘的是合规该卡在哪几个环节。
Minitap 的 mobile-use 是团队在 2026 年 2 月前后做的开源研究项目，后来他们转向了闭源的商业版本。9 月 11 日的博文《I expected better from Google》由 CEO Nicolas Dehandschoewercker 署名。
博文给出的比对结论很具体，但性质上仍属当事一方的指认，不是第三方裁定。
| 博文列举的内容 | 性质 |
|---|---|
| Android 设备连接代码「与我们的实现完全一致」 | 当事方比对结论 |
| Hopper agent 的指令「逐字相同」；WhatsApp 示例里的收件人、注释与清理步骤一致 | 当事方比对结论 |
| 早期包文件列出三位作者，替换版本删掉全部三人并换成另一位作者；博文称文件内容的唯一变化就是作者列表 | 可在公开提交历史中查证 |
| GitHub 记录显示替换发生在 8 月的一次 force push，该版本现被标记为 detached | 可在公开提交历史中查证 |
| 博文称其核对的 README 未致谢该开源项目 | 当事方陈述 |
| 该项目采用 Apache 2.0，第 4 节要求保留适用的版权与署名声明、标明改动 | 许可证文本本身 |
榜单那条线要单独看。博文称团队早期提交的成绩已被合并到 91.4%（最后一次确认在 2025 年 12 月），之后提交的 94.8% 与 100% 经四封邮件跟进未获回复；截至 9 月 11 日榜单仍显示其为 91.4%，而另一个项目显示 99.1%。
关键在于博文自己承认：这些是自报成绩，榜单明确声明不做独立验证——这句话同样适用于 Minitap 自报的 100%。目前没有第三方裁定，也没看到被指方在该页面给出回应。所以结论不是「谁抄了谁」，而是「如果这件事发生在你的交付链路里，你多久能查清」。
做交付的团队容易把开源合规当成法务的事。实际情况相反：2026 年，产物的来源分散在三处，而这三处都由工程侧控制。
这件事的性质和平台工程即壁垒的讨论是同一类问题：能不能守住，取决于流程里有没有那道门，而不取决于个人细致程度。
2026 年 5 月的 GemStuffer 事件是个提醒。据 AIHOT 收录的一份取证分析，5 月 11 日前后有数百个由智能体上传的包进入 RubyGems，两天内提交量超过 2000 个，平台一度关闭新用户注册四天并移除 500 多个恶意包。该分析由作者团队自行发布，属待第三方确认的指控，但入口位置很明确：依赖清单。
把「这个库能不能用」从工程师的口头判断，变成一道有记录的门。
具体做法：任何新增依赖，在 PR 里附一行许可证字段；扫描输出要包含许可证类型、是否要求分发时保留声明、是否携带 NOTICE 文件。Apache 2.0 这类许可的要求不是「不能商用」，而是分发时保留版权与署名、标明改动、并在上游提供 NOTICE 时一并保留。
一个常被忽略的细节：署名义务跟着「分发」走，不跟着「谁写的」走。你自己重写的包装层，只要分发物里仍带着原代码，义务就还在。
模型生成的代码最难查的地方在于它看起来是新的：没有上游 URL，没有提交历史，没有作者。等交付前才发现某段实现与某个开源项目高度相似，返工面会大到无法估量。
可行的做法是在 CI 加两步，都跑在合并前：
为什么放在 CI 而不是验收前？因为 CI 的失败成本是「改一次提交」，验收前的失败成本是「重跑构建 + 重做合规评审 + 顺延交付窗口」。这类「自动化流程缺一道门」的失败模式和全自动交付失败的几个工程教训是同一个机理。
客户要的不是一份「我们很合规」的声明，而是能复核的清单。交付包里建议固定附三样东西：
第三项在 2026 年越来越不好糊弄。客户法务会问模型供应商的训练与保留条款——答案不在你的代码库里，而在采购模型服务时的合同附件里，所以要提前归档。交付物清单可以参照需求文档到验收的风控点与交付物拆解，把来源声明和 SBOM 并到同一份交付目录里。
我们经手过一个内部工具改造项目，前期赶进度，依赖清单是工程师在验收周临时补的。补的时候发现两个问题：一个组件是 AGPL，另一个组件的 NOTICE 文件从没被带进产物。
代价不在改代码。换掉 AGPL 组件要重跑集成测试，补 NOTICE 要重新打包并重签发布流程，两件事叠加把交付窗口顺延了两周多，合规评审也得重走一遍。复盘下来，真正贵的是「评审重做」，不是「代码重写」。这也是把扫描前移到 CI 的核心理由。
不够。按博文引述的第 4 节，分发时要保留适用的版权与署名声明、标明改动，并在上游提供 NOTICE 文件时保留相关署名。致谢是礼貌，保留声明是条件。README 是合适的位置之一，但声明本身要跟着代码走。
目前公开事实里没有能支持「自动继承」的依据。工程上可操作的做法是把它当成来源不明的片段处理：先扫相似度，命中再人工判断，并把判断过程留档。留痕比结论更重要。
从第一次给客户交付产物时就做。等到合规审计或客户尽调时才补，SBOM 就变成了考古，成本是平时的数倍。交付后进入维护期时再做，只会更贵。
如果客户开始问 SBOM 与来源声明，可以先看我们已交付项目里是怎么留痕的，再把你们当前的依赖清单发过来，我们按上面三条线做一次两小时的预检，联系我们安排时间。