Google stole open source code without crediting the authors (Artemis/Minitap)

谷歌在未注明原作者的情况下窃取了开源代码 (Artemis/Minitap)

I was in the office with the team when we heard that Google had released Artemis, a project for automating mobile devices. We opened the repository and started looking through it. My reaction was pretty immediate: “What the fuck? We wrote this.” 当我和团队在办公室时，听说谷歌发布了 Artemis，这是一个用于移动设备自动化的项目。我们打开了代码仓库并开始查看。我的第一反应非常直接：“搞什么鬼？这是我们写的。”

We built mobile-use as an open-source research experiment to see whether we could get AI agents to reliably interact with phones. We worked on that through February, then focused on a newer, more powerful, closed-source version that now powers QA across web and mobile at Minitap. 我们构建了 mobile-use 作为一项开源研究实验，旨在探索能否让 AI 智能体可靠地与手机进行交互。我们在二月份之前一直致力于此，随后转向了一个更新、更强大且闭源的版本，该版本目前为 Minitap 的网页和移动端质量保证（QA）提供支持。

Finding familiar code in another project is something you expect when you publish your work for people to use. Finding it under Google’s name, without an acknowledgment of where it came from, is harder to take. 当你发布作品供他人使用时，在其他项目中发现熟悉的代码是意料之中的事。但发现它以谷歌的名义发布，且没有任何来源说明，这就让人难以接受了。

Then we looked at the history and found our names in an older version. They had been removed. 随后我们查看了历史记录，发现我们的名字出现在一个旧版本中。但它们已经被删除了。

I’m disappointed in Google. And I think this matters beyond our own repository, because open source depends on people being willing to keep sharing their work. The way that work is treated matters. 我对谷歌感到失望。我认为这不仅仅关乎我们自己的代码仓库，因为开源依赖于人们愿意持续分享他们的工作成果。对待这些工作成果的方式至关重要。

What we recognised

我们发现了什么

The examples were specific. Parts of the code for connecting to Android devices matched our implementation exactly. The Hopper agent’s instructions were identical, word for word. Those matches were still present in the Artemis version we checked on September 11: here is the Artemis device code alongside ours, and the Artemis prompt alongside ours. 这些例子非常具体。连接 Android 设备的部分代码与我们的实现完全一致。Hopper 智能体的指令也是逐字相同的。在我们 9 月 11 日检查的 Artemis 版本中，这些匹配项依然存在：这是 Artemis 的设备代码与我们的对比，以及 Artemis 的提示词与我们的对比。

Fun fact about Hopper: we didn’t know what to call that agent. Jean-Pierre, one of our engineers, likes Minecraft and thought the name was cool, so we went with it. That was the reasoning. Seeing the same name attached to the same instructions in Google’s repo felt very familiar. 关于 Hopper 的趣事：我们当时不知道该给那个智能体起什么名字。我们的工程师之一 Jean-Pierre 喜欢《我的世界》（Minecraft），觉得这个名字很酷，所以我们就用了它。这就是命名的由来。在谷歌的仓库里看到同样的名字附在同样的指令上，感觉非常熟悉。

An example for keeping an agent inside WhatsApp had the same task of sending Happy New Year messages to Alice, Bob, and Charlie, with the same comments and cleanup steps. That was still there too. Compare the Artemis messaging example with the mobile-use example. 一个让智能体在 WhatsApp 内运行的示例，其任务同样是向 Alice、Bob 和 Charlie 发送新年快乐消息，并且带有相同的注释和清理步骤。这些内容也依然存在。请对比 Artemis 的消息发送示例与 mobile-use 的示例。

Older versions even shared a bug: a helper would write a results file, then fail when it tried to read its own output on the next run. We reproduced the same failure in both implementations. Artemis has since fixed it. 旧版本甚至共享了一个 Bug：一个辅助程序会写入一个结果文件，然后在下一次运行时尝试读取自己的输出时失败。我们在两个实现中都复现了同样的故障。Artemis 此后已经修复了它。

The author history was harder to understand. An earlier package file listed Pierre-Louis Favreau, Jean-Pierre Lo, and Nicolas Dehandschoewercker. The version that replaced it removed all three names and substituted another author. The only change to the files was the author list. GitHub’s activity record shows that the replacement happened through a force push in August, before our investigation this September. 作者历史记录更令人费解。一个早期的包文件列出了 Pierre-Louis Favreau、Jean-Pierre Lo 和 Nicolas Dehandschoewercker。而替换它的版本删除了这三个名字，并换成了另一位作者。这些文件中唯一的改动就是作者列表。GitHub 的活动记录显示，这次替换是通过 8 月份的一次强制推送（force push）完成的，时间在我们 9 月份调查之前。

Artemis contains its own engineering work too. It can acknowledge that work and the mobile-use code it incorporates in the same place. Yet the README we checked did not credit mobile-use. We have put the detailed comparisons, the archived files, and the timeline in a public factual record. Artemis 也包含其自身的工程成果。它完全可以在同一个地方既承认其自身的工作，也承认所整合的 mobile-use 代码。然而，我们查看的 README 文件并没有注明 mobile-use 的贡献。我们已将详细的对比、存档文件和时间线整理成了一份公开的事实记录。

分享代码应使协作变得更容易

We chose open source because we want other people to build on mobile-use. Someone should be able to take it in a direction we would never have considered. They should be able to improve it, turn it into a product, or build a competing project, within the license’s terms. 我们选择开源是因为我们希望其他人能在 mobile-use 的基础上进行构建。有人应该能够将其带向我们从未考虑过的方向。在许可协议的条款范围内，他们应该能够改进它、将其转化为产品，或者构建一个竞争项目。

There are ordinary ways to do that while keeping its origins clear. A fork links back to the original project. An imported copy can document its source. Copyright and attribution notices can stay with the code. A README can explain which parts came from elsewhere and what the new team has added. 在保持来源清晰的同时，有常规的方法可以做到这一点。Fork 会链接回原始项目。导入的副本可以记录其来源。版权和署名声明可以保留在代码中。README 可以解释哪些部分来自其他地方，以及新团队添加了什么。

Some of this is established engineering practice. Some is required by the license. The mobile-use source used for the current comparisons carries Apache 2.0, whose redistribution conditions include preserving applicable copyright and attribution notices and identifying changes. It also provides for retaining relevant attribution from an upstream NOTICE file when that file is included in the distribution. 其中一些是既定的工程实践，另一些则是许可协议所要求的。用于当前对比的 mobile-use 源码采用 Apache 2.0 协议，其再分发条件包括保留适用的版权和署名声明，并标识所做的更改。它还规定，当上游的 NOTICE 文件包含在分发包中时，必须保留相关的署名。

That information is useful to everyone who comes next. It helps people find the original maintainers, understand a design decision, report a bug, or share a fix. It gives contributors a record of what they built. It lets a new project explain its own contribution honestly. 这些信息对后续的所有人都有用。它帮助人们找到原始维护者、理解设计决策、报告 Bug 或分享修复方案。它为贡献者提供了他们所构建内容的记录。它让一个新项目能够诚实地说明其自身的贡献。

I should not need to recover an old version of a repository to discover that relationship. Maintainers already spend time answering questions, reviewing contributions, and keeping their projects working. Chasing missing attribution after a larger company republishes their work is another cost of sharing. An ecosystem that makes this routine gives people another reason to stop doing it. 我不应该需要恢复仓库的旧版本才能发现这种关系。维护者已经花费了大量时间来回答问题、审查贡献并保持项目正常运行。在大公司重新发布他们的作品后，还要去追讨缺失的署名，这是分享带来的额外成本。一个将此常态化的生态系统，只会让人们有更多理由停止分享。

I want more people publishing useful software, with more confidence that their work will still be recognised when it travels. 我希望更多的人发布有用的软件，并更有信心地相信，当他们的作品被传播时，其贡献依然会得到认可。

Our benchmark results have also been hard to get heard

我们的基准测试结果也难以被听到

We had already spent months asking for our newer results to be reflected on AndroidWorld’s leaderboard. 我们已经花了几个月的时间，要求将我们的最新结果反映在 AndroidWorld 的排行榜上。

The maintainer applied our earlier submissions, up to 91.4%, with the last confirmation in December 2025. We then submitted 94.8%, followed by 100% in our evaluation in January. We sent two follow-ups. Those four emails received no reply. Our results and task traces are available for inspection. 维护者应用了我们早期的提交（高达 91.4%），最后一次确认是在 2025 年 12 月。随后我们提交了 94.8%，接着在 1 月份的评估中达到了 100%。我们发送了两次后续跟进邮件。这四封邮件均未收到回复。我们的结果和任务追踪记录可供查阅。

As of September 11, the sheet still showed mobile-use at 91.4%, while Artemis appeared at 99.1%. These are self-reported results; the leaderboard explicitly says it does not independently verify them. That qualification applies to our reported 100% too. 截至 9 月 11 日，表格仍显示 mobile-use 为 91.4%，而 Artemis 显示为 99.1%。这些是自报结果；排行榜明确表示它不会进行独立验证。这一限定条件同样适用于我们报告的 100%。

Artemis’s own comparison chart omitted us. It included DroidRun at the same listed score as mobile-use, and an unrelated MadeAgents project called MobileUse at a lower score. Artemis 自己的对比图表忽略了我们。它包含了与 mobile-use 分数相同的 DroidRun，以及一个不相关的、名为 MobileUse 的 MadeAgents 项目，且分数较低。

We have no evidence connecting the unanswered emails or the chart omission to the removal of our names. But this is another part of our experience. 我们没有证据将未回复的邮件或图表遗漏与我们名字的删除联系起来。但这确实是我们经历的另一部分。