Google Artemis Accused of Reusing Code: The Boundaries of Mobile AI Agents Are Harder to Handle Than Benchmarks

Google’s mobile AI agent project Artemis has recently been accused by the open-source project Minitap of reusing code, prompts, and test cases. Nicolas Dehanshuweik, co-founder and CEO of Minitap, said that implementations in Artemis related to connecting to Android devices, Hopper agent instructions, and WhatsApp messaging tasks contain code that is word-for-word identical to Minitap’s open-source mobile-use project.

More difficult still, this dispute is not only about “whether the code looks alike.” It also involves compliance with open-source licenses, attribution, conflicts of interest involving benchmark maintainers, and how large companies incorporate community contributions. For developers working on Computer Use, mobile agents, and automated testing, this is more significant than an ordinary plagiarism accusation: the core assets of mobile agents are shifting from model weights to an entire stack of device connectivity layers, task prompts, test environments, and evaluation data.

It Was Not Just a Few Lines of Code That Were Allegedly “Word-for-Word Identical”

Minitap’s mobile-use is an open-source mobile automation project designed to let AI control real Android devices through natural language. It is not merely a UI scripting tool: the model must understand the task, plan multiple operations, execute actions such as tapping, typing, going back, and opening apps through device connectivity capabilities, and finally determine whether the task has been completed.

According to Minitap, Google Artemis reused the following categories of content:

• Android device connectivity implementation: responsible for enabling the agent to communicate with real devices and execute actions;
• Hopper agent instructions: used to constrain how the agent understands and completes mobile tasks;
• WhatsApp messaging task implementation: covering typical workflows involving multiple pages, text input, and message sending;
• Prompts and test cases: affecting not only how the program operates, but also directly influencing evaluation results.

The most substantial allegation is that relevant code from the two projects was considered “word-for-word identical.” If the overlap consisted only of common Android automation APIs or similar task descriptions, it could still be explained as independent implementations of the same problem. But when the device connectivity, agent instructions, specific tasks, and test samples all contain extensive overlap, the dispute shifts from “convergent technical approaches” to whether the requirements of the open-source license were fully satisfied.

This is also why mobile agent projects are more prone to attribution disputes than traditional model repositories. Model invocation interfaces are often clear, and code boundaries are relatively easy to define. A mobile agent, by contrast, is a pipeline: prompts determine how the model thinks, the tool layer determines what the model can do, and test cases determine how the system is evaluated. Copying any one of these components can ultimately change the project’s capabilities.

Apache 2.0 Does Not Mean “Use It Without Conditions”

According to reference materials, the relevant Minitap code is licensed under Apache 2.0. This license is relatively permissive regarding commercial use and modification, and developers can generally incorporate the code into their own projects. But “open source” does not mean “without conditions.”

Apache 2.0 generally requires downstream projects to retain copyright notices and the license text. If the original code is modified, the modifications must also be indicated. Projects should additionally preserve necessary attribution and notices. The license provides developers with considerable freedom to reuse the code, but it does not leave room for “deleting the original authors’ names.”

According to reports, files in the Artemis package that originally listed the names of Minitap authors Pierre-Louis Favre, Jean-Pierre Lo, and Nicolas Dehanshuweik were replaced through a force push in August. After the incident was questioned, Google added a source notice to the code: “This project contains source code developed by Minitap.”

This addition addresses part of the surface-level question of whether the source was identified, but it does not necessarily end the dispute automatically. Developers should verify at least three aspects:

1. Whether the original copyright notices have been retained in full;
2. Whether the project includes the Apache 2.0 license text and relevant notices;
3. Whether modifications to, refactoring of, or reorganization of the code are clearly documented.

For large companies, the compliance challenge is usually not a lack of awareness of licensing requirements. Rather, internal code synchronization, automatically generated release packages, and force-push workflows may overwrite attribution information. But once a project is publicly released, internal process problems do not change the fact visible to downstream users: whether the code and copyright information in the final repository comply with the license requirements.

Why Benchmark Rankings Have Become Part of the Dispute

Another thread in the incident concerns the AndroidWorld benchmark. Minitap had repeatedly requested that outdated benchmark results on the AndroidWorld leaderboard be updated, but received no response for a long time. Meanwhile, Google Artemis ranked second, and its score had just been updated in August. The issue is that AndroidWorld itself is maintained by Google.

Two points need to be distinguished carefully here. First, a delay in updating the leaderboard does not by itself justify the conclusion that Google manipulated the scores. The reference materials currently present Minitap’s concerns and the timeline, rather than a completed independent audit. Second, when the maintainer of an evaluation also has a participating system, it naturally leads outsiders to pay closer attention to whether the evaluation rules, submission materials, version dates, and reproduction conditions are transparent.

Agent benchmark scores are especially susceptible to testing details. Whether a system can complete a task such as “send a message to a contact” depends not only on the underlying model, but also on:

• Whether the test device and Android version are identical;
• Whether the initial interface, account status, and network environment are standardized;
• Whether the task prompts are made fully public;
• How failed retries, timeouts, and human intervention are counted;
• Which version of the agent, tools, and model is used for evaluation;
• Whether test cases maintain the same level of difficulty across different projects.

If test cases, prompts, or device connectivity code are reused, it becomes difficult to clearly separate “model capability” from “systems engineering capability.” More realistically, whoever controls the benchmark may also help define what counts as “task completion.” This is why mobile agent evaluations should not publish only an overall score; they should also disclose the versions, scripts, device images, action traces, and failure samples.

Where the Real Risks Lie When Large Companies Reuse Open Source

The open-source community does not oppose the adoption of code by large projects. The purpose of many open-source licenses is precisely to allow mature implementations to be used, modified, and commercialized by more people. The core question is not “Why did Google use Minitap’s code?” but whether it retained attribution, documented modifications, and enabled downstream users to trace the source of its dependencies as agreed.

This is particularly important for AI agent development. Today’s agent projects often combine dozens of components: model SDKs, browser or phone control layers, task planners, evaluation frameworks, prompt templates, and datasets. If a team scans only source code written in Python, JavaScript, and other languages, but does not scan prompts, JSON test samples, benchmark scripts, and device configuration files, it may overlook content that is actually subject to licensing or copyright restrictions.

From an engineering management perspective, teams should establish at least the following processes:

• Record the commit, license, and imported files for every external repository;
• Automatically retain NOTICE files, copyright notices, and dependency lists in release packages;
• Separately identify the sources and licenses of prompts, test samples, and datasets;
• Maintain audit records for force pushes, file replacements, and synchronization scripts;
• Publish system versions, model versions, and test environments for public evaluations;
• Provide reproducible evaluation entry points for the same benchmarks used by competing projects.

These tasks may sound less “cool” than model training, but they determine whether an agent project can be adopted with confidence by enterprises and the community.

Minitap’s Claims Also Need to Be Viewed in Their Timeline

After writing the relevant open-source code, Minitap moved on to using closed-source code to support its existing products. Dehanshuweik said that today’s Minitap is “a completely different entity” and believes Google is already seven months behind in technological progress.

This statement has two implications. First, the open-source repository may show the capabilities of only one stage of the project and cannot represent the full technical capabilities of Minitap’s current closed-source products. Second, the adoption of open-source code does not mean that downstream projects obtain the capabilities, data, or commercial authorization of later closed-source versions.

For readers, what is more worth watching is how Google responds next: whether it fully restores attribution information, explains why the files were replaced, addresses questions about AndroidWorld ranking updates and evaluation transparency, and makes more complete dependency and test materials public in future versions of Artemis.

This Is Not an Ordinary “Code Plagiarism” Story

For now, the more accurate description remains “an allegation of inadequate attribution and license compliance,” rather than an infringement conclusion confirmed by a court or independent institution. But the incident has already exposed a reality in the mobile AI agent sector: competition is shifting from “whose model is stronger” to “who possesses the more complete execution loop.”

Within this loop, open-source projects contribute device adaptation, tool calling, and task samples; large companies provide models, computing power, and distribution platforms; and benchmarks rank the systems. If any party treats another’s engineering work, test data, or evaluation infrastructure as its own default asset, it may gain faster iteration in the short term, but it will damage the credibility of the entire ecosystem in the long term.

For developers, the most practical conclusion is simple: before using open-source code, do not look only at whether the repository can be git cloned; and before releasing an agent, do not check only the model license. Putting code, prompts, test cases, datasets, and evaluation environments into a single dependency inventory is the minimum-cost way to address the complex copyright boundaries of mobile automation projects.

If Artemis later adds more complete source attribution and reproduction materials, this dispute may become an open-source compliance case study. If questions about evaluation and code attribution continue to go unexplained, it could become a turning point prompting developers to reconsider the credibility of large companies’ agent benchmarks.

Sources

• ITHome: Open-Source AI Mobile Automation Project Minitap Accuses Google of Stealing Its Code: Reports Minitap’s concerns regarding Artemis’s code, prompts, test cases, license attribution, and AndroidWorld ranking.

Note: This article was compiled based on public reports. The descriptions concerning code reuse, license compliance, and evaluation rankings retain qualifiers such as “allegation” and “concern,” and do not treat the unilateral claims of either party to the dispute as final conclusions.