On September 11, French startup Minitap published a post accusing Google's mobile automation project Artemis: three blocks of code are identical to their own open-source project mobile-use, down to the agent name "Hopper." What stings even more: an old package file that credited three Minitap engineers was overwritten in August 2026 by a force push, replacing their names with someone else's. Apache 2.0 is clear: if you use it, keep the credits.
Three blocks of code identical, even the Easter egg name carried over
On September 11, Minitap audited Google's Artemis repository and identified three code segments that overlap with their own mobile-use—from Android device connection implementation to WhatsApp scenarios, matching even the cleanup steps and comments where the agent sends New Year greetings to Alice, Bob, and Charlie. The version number was pinned at 3.6.3, but the author field had been swapped from three Minitap engineers' names to "somew1nd" and an Outlook email address.
The name "Hopper" was itself a private Easter egg the Minitap team had planted—one team member happens to be a Minecraft fan and borrowed it casually. The Google repository uses the same name and the same block of instructions; when the authors saw it, they put it bluntly: "very familiar."
There was also a bug in the old version: the helper wrote its output file first, then on the next pass tried to read its own freshly written output and crashed immediately. Minitap reproduced the same failure across both codebases; Artemis later fixed it.
One force push, three names vanished into thin air
In August 2026, the Artemis repository performed a force push that replaced Pierre-Louis Favreau, Jean-Pierre Lo, and Nicolas Dehandschoewercker in the package file with another author. The GitHub activity log still carries traces of that push, and the old version is no longer visible on the main branch—ordinary visitors opening the repo see only the post-replacement state.
When Minitap obtained the GitHub activity record, they found the only change in the commit was those three attribution lines; the other 228 files were untouched. Git marks this old commit as detached—meaning it once existed but no longer points to any active branch, and once nothing references it, it gets garbage collected.
The author field in the package file is metadata read by npm, so attribution travels with the package as soon as anyone runs npm install. A full overwrite erases the three names outright; adding a new author field would leave the originals in place.
Section 4 of the Apache 2.0 license requires that any redistribution must preserve the original copyright notice, attribution notice, and mark modified files. Those three lines were both the overwritten proof of authorship and content the license requires to be kept—which is why the overwrite reads to Minitap as a license violation, not just a credit dispute.
The license says it clearly, yet this rule is often treated like air
Apache 2.0 lets you take the code, make money from it, rename it—but it does not let you erase the source. Section 4 specifies that redistribution must preserve the copyright and attribution notices, mark modifications, and if the upstream has a NOTICE file (a license-attached attribution file), the names inside must travel along too.
Minitap's article splits this into two halves: forking (copying someone else's code repository to your own account and continuing development) naturally leaves a backlink on GitHub, imported copies can note the source in comments, the README can list which parts came from where—these are engineering conventions; but some of these preservation steps are mandated by Section 4 of Apache 2.0, not a matter of politeness. Minitap says it plainly: some are engineering convention, some are license requirement. Playing by the rules isn't a gift from big companies—it's right there in the terms.
Attribution isn't just a legal obligation. It helps newcomers find the original author, understand a design decision, report a bug, or submit a fix; it leaves contributors a record of "I built this," and gives new projects a way to account for their own contributions.
And maintainers are already spending time responding to issues, reviewing PRs, and keeping the project running—after a big company republishes their code, they then have to chase down "please put our names back." That cost is an extra burden the open-source ecosystem places on contributors.
After four emails, the top spot still shows a name other than Minitap
91.4% stays on the leaderboard, 94.8% and 100% weren't picked up, not one of the four emails got a reply.
The last time the AndroidWorld leaderboard recorded mobile-use's score was 91.4%, last confirmed in December 2025. Minitap then submitted 94.8%, followed by their self-measured 100%—these two follow-up emails plus the two earlier submissions add up to four emails, none of which received a reply. As of September 11, the mobile-use entry on the leaderboard remains stuck at 91.4%, while Artemis shows 99.1%. On the same leaderboard, the two numbers sit 7.7 percentage points apart: one is the original project's last recorded score, the other is the score of the party that folded it into their own product. Minitap also notes that the AndroidWorld leaderboard itself states "results are self-reported and not independently verified"—the same caveat applies to their self-reported 100%. This is a self-reported score, not a third-party verified vendor benchmark (a model-side self-tested and published result).
Artemis's own comparison chart doesn't list mobile-use either. The chart only includes DroidRun, which scored similarly, and a similarly-named but unrelated MadeAgents project called MobileUse. A chart that should arguably demonstrate "we do this better than whom" skipped the original project that also runs AndroidWorld entirely.
There are three observable checkpoints: whether the leaderboard picks up the 94.8% and 100% results; whether Artemis's README adds mobile-use attribution after September 12; and whether the AndroidWorld maintainers offer any clarification on the "results not independently verified" caveat.
Want to see for yourself? Three sets of links to follow
Minitap has made all the evidence into public material; readers can click and verify.
Start with Minitap's original post at minitap.ai/blog, and scroll to the bottom to find two sets of side-by-side links: Artemis device connection code vs. mobile-use device connection code, and the Artemis Hopper prompt vs. the mobile-use prompt. Open each file and compare the prompt text—Minitap says "word for word," character-for-character identical, and a quick visual scan confirms it. The WhatsApp example also has a pair: Artemis messaging example compared with the mobile-use example, the demo sending "Happy New Year" to Alice, Bob, and Charlie, with comments and cleanup steps laid out. Then look at the author list swap: open the mobile-use side, where Pierre-Louis Favreau, Jean-Pierre Lo, and Nicolas Dehandschoewercker are all present; then open the post-replacement Artemis version, where the author has become "somew1nd" with an Outlook email—and the entire commit changed only that one author field.
To go a step deeper, GitHub's activity record shows the replacement happened in a force push in August 2026, before Minitap's September investigation.
A force push in Git collaboration overwrites history, so whether the old version is still visible afterward depends on whether the repo was forked or referenced before the force push—the detached version 3.6.3 Minitap provides is exactly that kind of leftover trace.
The old bug can still be reproduced: check out mobile-use's old commit and run it following the reproduction script from the original blog, and you'll see that error message. This step is for readers willing to install dependencies and set up an Android debugging environment.
One thing to acknowledge up front: all the observations above are based on Minitap's own compiled materials and commit history still accessible on GitHub, with no third-party independent audit. Whether the code matches qualify as "substantially similar" is a legal judgment, and whether Apache 2.0 Section 4's attribution-preservation obligation has been satisfied is also up to a court to decide. As of now, Google has not made a public response.
Even if you're not an engineer, there's one thing you can do: wait for Google's next README update, or any public statement from the Pixel Test Engineering team. In open-source disputes, changing a single line in a repository's README or adding a Credit section is the lowest-cost signal of clarification. Only if the README quietly adds mobile-use's source after September 11 will it show Google has acknowledged that connection; until then, the absence of that addition signals it has no intention of responding at the documentation level.
Open Minitap's original post, open the four side-by-side Artemis vs. mobile-use links one by one, and visually compare the prompts and device connection code.
Locate the detached version of Artemis 3.6.3 on GitHub, compare the author lists before and after the replacement, and record whether the force push timestamp predates Minitap's investigation.
Check out mobile-use's old commit, follow Minitap's steps to reproduce the "helper reads its own output and fails" bug, and confirm whether the error message matches the old Artemis version.
Watch the Artemis repository's README and see if later versions add mobile-use attribution; not adding it is also a signal.
Wait for a public response from Google or Pixel Test Engineering—none so far—and keep an eye on Hacker News and minitap.ai/blog for updates.
Source: Hacker News: AI Hot Thread, citing Minitap's official blog. Scope note: Minitap is a party to the dispute; this article presents a one-sided account, though the code diffs, GitHub activity records, and Apache 2.0 Section 4 it cites are publicly verifiable. As of publication, Google has not made a substantive public response.