开源代码被别人拿去用，并不是什么稀奇事。
但如果你发现，对方项目里 229 个文件有 228 个与自己的项目完全一致，连工程师随手起的 Agent 名字、Prompt 都一字不差；可原本写在项目里的 3 个作者姓名，还曾出现在对方的 Git 历史中，后来却被替换成了另一个名字——这就很难只用“开源代码复用”来解释了。
最近，AI 初创公司 Minitap 创始人兼 CEO Nicolas Dehandschoewercker 公开发文，指控 Google 新推出的开源移动自动化工具 Artemis 大量使用了其开源项目 mobile-use 的代码，却没有按照许可证要求保留原有署名。
更讽刺的是，这段被“拿走”的代码，曾在 Google 自家的基准测试中击败过Google。
从 AndroidWorld 第一名，到发现 Google 的 Artemis
Minitap，是一家来自法国的 AI 初创公司。2025 年，这支仅 10 人的团队打造了 mobile-use——一个能让 AI 智能体通过自然语言控制真实 Android 设备的开源项目。他们最初的目标很明确：造出世界上最好的移动端 AI 智能体。
他们不仅做到了，而且做得极其出色：mobile-use 在 Google DeepMind 维护的 AndroidWorld 基准测试中登顶第一，成为首个在该基准上实现 100% 任务成功率的智能体框架，解决了全部 116 项、覆盖 20 款真实应用的多步骤任务。
要知道，Google 自己的基线智能体 M3A 最初只能完成 30.6% 的任务，人类成功率也不过 80%。凭借这一成绩，Minitap随后完成了 410 万美元的种子轮融资，之后逐渐把重心转向更强大的闭源版本，如今相关技术已用于 Minitap 的自动化 QA 产品。
转折发生在今年 9 月：Google 发布了 Artemis，一个面向移动设备自动化的开源项目。
一开始，Minitap 团队并没有觉得有什么特别，反正 GitHub 上已有不少手机智能体项目，Artemis 看起来也像是“又一个 Phone Agent”——直到他们真正打开代码：“等等，这不是我们写的吗？”
随后，Minitap 开始逐个文件比对，结果让他们大吃一惊：Artemis 总共 229 个文件，其中 228 个文件与 mobile-use 完全一致！
在官方博客中，Minitap 列出了详细的代码对比：
连接 Android 设备的 adb_tunnel.py 实现完全相同；
一个名为 Hopper 的 Agent（最初只是 Minitap 团队的一个随意命名，居然也出现在了 Google 的代码库里），其 Prompt 与 mobile-use 中的每个字都一样；
还有一个用于让 Agent 停留在 WhatsApp 中的示例，其任务内容、Alice、Bob、Charlie 等名字，以及注释和清理步骤，都与 mobile-use 中的示例相同。
甚至，就连一个历史 Bug 都出现了类似痕迹：某个辅助函数会先写入结果文件，然后在下一次运行时读取自己此前生成的文件并失败。Minitap 称，他们在两套实现中复现了相同问题，而 Artemis 后续已经修复了这个 Bug。
其实单纯看到这些代码，并不是 Minitap 最在意的事情，毕竟 mobile-use 本来就是开源项目——问题出在接下来发生的事情。
3 个作者名字被换掉，Git 历史中还能看到
后来，Minitap 又进一步查看 Artemis 的 Git 历史，发现了一个最令他们心寒的细节。
在 Artemis 某个较早版本的项目文件中，曾经出现过 mobile-use 的 3 个作者：Pierre-Louis Favreau、Jean-Pierre Lo、Nicolas Dehandschoewercker。
但在后来的版本里，这 3 个名字被全部替换成了另一个人。
而且，根据 Minitap 对 Git 历史的调查，相关 Commit 中被修改的部分就是作者列表，其他代码基本没有变化。Minitap 还称，这次替换发生在今年 8 月的一次强制推送（Force Push）中。
这也是整个事件最受关注的地方：“使用开源代码”与“抹掉开源代码的来源”并不是一回事。
据了解，mobile-use 使用的是 Apache License 2.0。这是一种相对宽松的开源许可证，允许使用者复制、修改、分发代码，甚至将其用于商业项目——但“宽松”并不等于“无限制”。
Apache 2.0 第 4 条明确规定，在分发源代码形式的衍生作品时，需要保留原项目中的版权、专利、商标和 attribution notices（署名/归属声明）；如果原项目包含 NOTICE 文件，其中相关的归属声明也需要在衍生作品中保留。
而 Minitap 表示，他们不仅采用 Apache 2.0，还专门提供了 NOTICE 文件，其中明确要求进行署名。
“我们不介意 Google 使用代码，但请别删掉名字”
于是，社区讨论很快从“Google 有没有复制 Minitap 代码”，转向了另一个更具体的问题：如果代码确实来自一个 Apache 2.0 项目，那么在重新发布时，原作者的署名是否被正确保留？
Minitap 的态度其实也相当明确：他们之所以开源 mobile-use，就是希望其他开发者可以拿去使用、修改甚至继续构建新产品，Google 当然也可以这么做——问题并不是 Google 用了他们的代码，而是 Google 没有正确说明代码来源，并且删除了原作者信息。
正如 Minitap 创始人兼 CEO NicolasDehandschoewercker 在博客中所说：
“在另一个项目中看到熟悉的代码，这是我们开源项目时就知道会发生的事情。不过，如果这段代码是以谷歌的名义出现的，却没有注明其来源，这种情况就让人难以接受了。”
在社区讨论中，也有网友指出，即使暂时不讨论法律层面，开源社区依然存在一个很基本的协作规则：可以复用别人的工作，但应该让后来的人知道这项工作是谁完成的。
对于程序员来说，代码仓库里的作者信息、Commit、NOTICE 和 README，并不只是几行无关紧要的文字。它们记录了项目从哪里来、谁做过什么，也让后来者能够找到原作者、理解代码背景，并继续贡献。
Minitap 创始人也表示，自己最失望的并不是 Google 用了他们的代码，而是他们不得不通过 Google 的 Git 历史，才能重新找回自己团队的名字：
“这些代码文件的背后，是一个个活生生的人。我见证了他们为此付出的努力、倾注的心血，以及他们对所构建成果的深切在乎。我希望他们能看到自己的成果被使用，并为自己的工作感到自豪。”
Google 已补上声明，但并未解释“抹名”原因
在事件曝光后，Google 很快对 Artemis 的代码进行了修改，并在项目中添加了一份声明：“本项目包含由 Minitap 公司开发的源代码”。但截至目前，Google 尚未发布一份单独的公开声明解释此前的作者信息变更。
对此，Minitap 方面认为，这个补充实际上间接证实了 Google 已经承认相关代码来自 mobile-use，只是在最初使用时未能正确履行署名义务。
值得一提的是，Minitap 创始人在博文中透露，他们曾把 mobile-use 当作开源研究项目开发，但从今年 2 月之后，团队已经转向开发更加成熟的闭源版本。也就是说，Google Artemis 即便确实使用了此前的 mobile-use 代码，也并不等于拿走了 Minitap 当前产品的全部技术成果。他直言：“Google 目前采用的部分设计理念，实际上已经落后我们当前产品大约七个月。”
或许会有人因此质疑：既然如此，那为什么还要追究？对于 Minitap 来说，他们真正想要的其实并不复杂：代码可以拿，项目可以继续做，甚至可以做得比原项目更好，但请把那些真正写下第一行代码的人留下来。
毕竟，开源最重要的东西，有时候并不只是代码本身，还有代码背后的人。
本文来自微信公众号“CSDN”，整理：郑丽媛，36氪经授权发布。