2026 年 9 月 11 日，移动自动化公司 Minitap 发文称，Google 名下的移动设备智能体项目 Artemis 使用了其开源项目 mobile-use 的部分代码和代理提示词，却未在当时的 README 中说明来源。9 月 12 日，Artemis 主分支新增提交，在 README 和相关文件中补入 Minitap 与 mobile-use 的署名。这次变化说明，代码以 Apache 2.0 开放，不等于复用者只放一份许可证就完成了来源治理。
公开记录能确认什么
Minitap 展示的仓库记录包括多组可对照内容：连接 Android 设备的实现、Hopper 代理说明、示例任务以及旧版本中共同出现的缺陷。它还指出，Artemis 较早的 pyproject.toml 曾列出三名 mobile-use 作者，后来一次历史替换移除了这些名字。9 月 11 日创建的公开 Issue 要求项目说明派生关系、恢复适用的版权与署名信息，并给原作者和贡献者记名。
这些材料足以证明双方代码之间存在需要说明的来源关系，但“是否构成法律意义上的侵权”仍需要结合具体文件、原始提交时间、许可证义务和司法辖区判断。Minitap 自己也承认 Artemis 包含独立工程工作，并说明排行榜结果属于项目方自报、没有经过独立验证。因此，文章不能把一方的控诉直接写成已经裁定的事实。
23个文件补署名，还不等于争议全部结束
Artemis 仓库在 9 月 12 日 02:59 UTC 的提交中修改了 23 个文件：README 明确写入项目包含 Minitap 开发的源代码，多份实现文件增加“部分源自 mobile-use”的说明和版权信息。这个动作与 Minitap 的核心诉求方向一致，也让后来使用 Artemis 的开发者能追溯上游。
不过，截至核实时时，相关 Issue 仍处于开放状态，仓库也没有看到解释作者名单为何变化的正式说明。补充署名解决了当前版本的可见性问题，不自动回答过去版本是否完整履行 Apache 2.0 条款，也不能替代双方对具体代码范围的确认。
AI项目复用开源代码要做四项检查
- 记录来源：无论是 fork、复制目录还是让编码代理导入片段，都要保留上游仓库、提交哈希和修改记录。
- 逐文件核对义务：检查 LICENSE、NOTICE、版权头和变更说明，不能只在仓库根目录放一份同名许可证。
- 把代理输出当普通代码审查：AI 生成或搬运的代码同样要做相似度、依赖来源与许可证扫描，责任不会因为“由模型完成”而消失。
- 分开处理评测与归属：性能榜单需要可复现实验和独立核验，代码来源则依赖版本历史与授权记录，两者不能互相替代。
Artemis 的后续修正是积极信号，也给开源 AI 团队提了一个现实问题：模型和代理提高了复用速度，却没有自动补齐来源说明。把溯源、署名和许可证检查接进合并流程，成本远低于项目发布后再追查历史。
