Google Artemis Code Dispute: Minitap Says Mobile-Use Credit Was Removed

Google faces an open-source attribution dispute after Minitap identified allegedly copied code and prompts inside Artemis, Google’s newly public Android automation project.

The Google Artemis code dispute concerns more than similar ideas between two mobile agents. Minitap says identical implementation details appeared in Artemis without visible credit. It also presented repository history that appears to show its developers listed as authors before those names disappeared.

That history creates the central conflict. Minitap released mobile-use under Apache License 2.0, allowing modification and commercial reuse under defined conditions. The startup objects to alleged reuse without clear provenance, not to Google building a competing tool.

The public record has already changed. As of September 13, the Artemis README states that the project includes source code developed by Minitap. That acknowledgment was absent from the version described in Minitap’s September 11 post.

Google’s current credit addresses the most visible complaint, but it does not answer every question. The remaining issues concern which components originated upstream, when attribution disappeared, and whether all applicable licensing conditions were followed.

What Minitap Found Inside Google Artemis

Minitap’s strongest evidence is the combination of matching code, matching prompts, and an earlier author list, not any single shared architectural idea.

Artemis and mobile-use both let AI agents operate phones through natural-language instructions. That broad similarity proves little because many mobile agents use screenshots, accessibility data, planning loops, and device-control tools.

Minitap’s allegations become more specific at the implementation level. Its published account identifies Android connection logic that it says matches code previously released in mobile-use.

The company also highlights an agent named Hopper. In Minitap’s system, Hopper searches large batches of screen and interaction history for information relevant to the current task.

Minitap says Artemis contained the same Hopper prompt, including matching wording and examples. Prompt identity matters because detailed instructions can act like source code within an agent system.

A generic instruction such as “search the history” could emerge independently. An extended prompt with identical structure, examples, names, comments, and cleanup behavior presents a more difficult coincidence argument.

The company also points to a messaging example. It says the two projects used the same illustrative names, comments, and sequence of operations.

Examples can reveal provenance when they preserve arbitrary choices that functionality does not require. Two implementations might independently connect to Android Debug Bridge, commonly known as ADB. They are less likely to independently choose the same fictional details throughout a longer example.

Minitap further claims that both projects shared a file-handling bug. According to its post, Artemis later corrected that behavior.

A shared defect can be meaningful evidence because developers usually copy intended behavior, not accidental failure modes. However, readers cannot treat that clue as a final technical judgment without a complete, version-specific comparison.

The most consequential evidence involves package metadata. Minitap says an earlier Artemis package file listed Pierre-Louis Favreau, Jean-Pierre Lo, and Nicolas Dehandschoewercker as authors.

Those names correspond to contributors associated with Minitap’s mobile-use work. Minitap says a later revision replaced them with another author while otherwise leaving the relevant file unchanged.

The company links that replacement to an August force push. A force push rewrites a Git branch’s visible history, potentially removing commits from the branch without instantly erasing every underlying object or external copy.

That distinction matters. Force pushes are routine during repository cleanup, but they become significant when a rewritten commit contained provenance information relevant to a later dispute.

Minitap says it recovered the earlier revision through Git history even though the commit was no longer attached to the primary branch. The allegation therefore rests partly on historical repository evidence, not only current files.

No court, regulator, or independent code-audit organization has ruled on these claims. The available evidence supports close scrutiny, but the accusation remains Minitap’s documented account.

Google has not publicly explained the authorship replacement in the materials reviewed for this article. It has also not provided a file-by-file statement describing Artemis components derived from mobile-use.

That missing explanation prevents a complete reconstruction. It does not erase the visible similarity claims or the earlier metadata described by Minitap.

The immediate change is still concrete. A small open-source team publicly challenged a Google repository, and Google’s current README now acknowledges Minitap-developed code.

Why the Google Artemis Code Dispute Matters

The pressure falls on Google because its institutional credibility makes clean provenance more important, not less important.

Open-source development depends on permission and attribution serving different functions. A permissive license gives downstream developers broad freedom, while provenance records who created the underlying work.

Minitap explicitly says reuse is welcome. Its objection is that developers should not encounter an apparently independent Google project without learning that some code came from mobile-use.

That concern extends beyond recognition. Provenance helps maintainers trace security defects, architectural decisions, upstream fixes, and incompatible modifications.

If downstream users cannot identify the source of a component, they may report bugs to the wrong team. They may also miss fixes already available in the upstream project.

Developers evaluating Artemis need to know which parts Google maintains independently. They also need to know where inherited behavior begins and where Google’s modifications diverge.

That information affects technical due diligence. A team adopting an agent for device testing must evaluate maintenance ownership, dependencies, licenses, and the reliability of benchmark claims.

The Google name raises expectations because the company publishes extensive open-source guidance. Its documentation says release reviews should check license headers and other required material before code becomes public.

Google also maintains Android, Chromium, TensorFlow, Kubernetes, and many other widely used projects. Its teams routinely ask outside contributors and companies to follow structured licensing processes.

A provenance lapse inside a Google organization therefore carries symbolic weight. Independent maintainers expect the largest software companies to model the behavior they require elsewhere.

The imbalance between the parties sharpens that pressure. A startup can publish useful research and code, yet a larger organization can attract more attention after releasing a similar system.

Search results, social distribution, and brand recognition can quickly associate an approach with the larger publisher. Missing attribution can then obscure the smaller team’s contribution even when the code remains available.

This is the primary reversal in the story. Open source gave Google permission to build from shared work, but the same openness exposed the evidence supporting Minitap’s complaint.

Public Git repositories preserve diffs, forks, cached pages, package files, and detached commits. Rewriting a branch cannot guarantee that earlier authorship records vanish from every copy.

The controversy also affects contributors beyond Minitap. Developers decide whether to publish valuable work partly by observing how downstream organizations treat origin and credit.

Permissive licenses encourage adoption because they impose fewer commercial restrictions. That model remains sustainable when users respect the limited conditions that remain and communicate provenance honestly.

If small teams believe permissive releases will be absorbed without recognition, they may delay publication. Others may choose stronger copyleft terms or keep strategically important components private.

Neither response automatically benefits users. Mobile automation improves when researchers can inspect agents, reproduce results, compare strategies, and contribute fixes across organizational boundaries.

The lesson is not that companies should avoid open-source code. It is that internal release processes must preserve upstream history before code enters a polished corporate repository.

That process should include source inventories, automated similarity checks, dependency records, license review, and human verification. A searchable engineering knowledge base can also keep provenance connected to design decisions.

Repository maintainers should document copied files and substantial adaptations before launch. Adding attribution after a dispute is better than leaving it absent, but it cannot replace a clear development record.

Google is therefore pressured to explain the sequence, not merely keep the new sentence. The organization must show whether the omission was an isolated release error or evidence of a weaker provenance process.

The Current Credit Changes the Story, but Not the History

Google’s present README acknowledges Minitap, turning the controversy from an unresolved omission into a dispute about how and why attribution vanished.

The current Artemis repository describes an Android automation system built by Google’s Pixel Test Engineering Fusion team. It presents two execution profiles and integrations for AI coding assistants.

Flash mode uses a reactive observe-and-act loop. Artemis says it typically takes three to five seconds per step while compressing older interaction history.

Pro mode uses planning and verification components. It checks proposed actions against current interface data before execution and supports longer testing workflows.

The repository also describes Model Context Protocol integration. MCP is a standard interface through which compatible AI assistants can call external tools and receive structured results.

These features show that Artemis is not necessarily an unchanged copy of mobile-use. A downstream project can combine inherited components with substantial original engineering.

That point does not contradict Minitap’s complaint. Attribution questions apply to copied portions even when a derivative system adds new interfaces, safety checks, execution modes, or diagnostics.

The current README now includes a direct statement under its license section: the project contains source code developed by Minitap. The sentence links to the mobile-use repository.

That is a meaningful correction. A developer reaching the project today can identify Minitap as an upstream source without conducting a forensic search.

However, the statement remains broad. It does not identify the files, prompts, agents, or architectural components that originated with mobile-use.

It also does not explain the earlier author metadata. If Minitap’s reconstruction is accurate, three named contributors appeared in a package configuration before being replaced.

Project-level credit and individual authorship are related but distinct. A company acknowledgment may identify the upstream organization while leaving the contribution history of specific developers unclear.

A detailed response could resolve much of the uncertainty. Google could publish the relevant commit sequence, explain the force push, and map inherited components to their original revisions.

It could also state whether the author change was accidental, part of a repository migration, or an intentional metadata normalization. Without that account, outsiders must infer intent from incomplete history.

Intent matters for public trust, but license compliance often turns on concrete distribution practices. A careless omission and deliberate removal can create similar files while representing different organizational failures.

The present correction also complicates simplistic headlines saying Google currently provides no credit. That description appears outdated as of September 13.

The accurate framing is chronological. Minitap says Artemis lacked acknowledgment when it documented the similarities, while the live repository now credits Minitap-developed source code.

Readers should also separate Google from every contributor using a Google-hosted repository. Public repositories can involve teams, contractors, transferred projects, and individual maintainers with different review paths.

The repository identifies a Google team, which makes the company an appropriate subject of scrutiny. Still, the evidence reviewed here does not establish who approved or removed the earlier names.

That uncertainty is why the Google Artemis code dispute should remain focused on records and process. Speculation about personal motives adds heat without improving verification.

The current acknowledgment strengthens one part of Minitap’s position. Google’s repository now affirmatively recognizes that Minitap code is present.

It does not independently verify every matching example described in the original post. Nor does it establish that the earlier README violated a particular license clause.

What it does establish is a provenance relationship. Artemis is not presented today as a codebase developed entirely without Minitap source.

That change reduces immediate confusion for new users. It also gives maintainers a starting point for comparing the two systems and following future fixes upstream.

Apache 2.0 Allows Reuse, but Conditions Still Apply

The legal question is narrower than the ethical dispute because Apache 2.0 permits extensive reuse without requiring every form of requested recognition.

Both projects publish code under Apache License 2.0. The license allows users to reproduce, modify, distribute, sublicense, and use covered work commercially.

Those permissions make open-source collaboration possible across competitors. Minitap cannot reasonably claim that releasing mobile-use prevented Google from building upon it.

Minitap does not make that argument. Its post says the team expected acknowledgment of the project and its contributors.

The Apache 2.0 terms impose several conditions when a party distributes the work or a derivative work. Recipients must receive a copy of the license.

Modified files must carry prominent notices explaining that changes were made. Source distributions must retain relevant copyright, patent, trademark, and attribution notices from the original source.

If the original distribution includes a NOTICE file, qualifying notices from it must remain readable in an appropriate location. The license also allows downstream authors to add their own notices.

Those rules do not translate into a universal requirement for a specific README sentence. Whether the earlier Artemis repository violated the license depends on the exact upstream notices, copied files, modifications, and distribution.

For example, an author list in package metadata can be relevant evidence of provenance. Its legal status depends on whether it qualifies as a notice that the license requires a derivative source distribution to retain.

Likewise, removing a name is not automatically unlawful in every context. Maintainers sometimes change package metadata because its “authors” field describes current package ownership rather than every upstream contributor.

The surrounding facts determine whether that explanation fits. Minitap emphasizes that the author list was reportedly the only material change in the revision it compared.

Apache guidance explains that attribution notices placed in an upstream NOTICE file receive specific treatment in downstream distributions. The visible mobile-use repository does not prominently present a top-level NOTICE file in its current root listing.

That absence would not settle the dispute. Relevant notices can also appear within source files or other covered materials, and modified-file disclosure remains a separate requirement.

The difference between license compliance and community norms is critical. Conduct can satisfy the minimum legal text while still appearing misleading or disrespectful to maintainers.

Conversely, a missing project-level thank-you does not by itself prove a license violation. Legal conclusions require a qualified review of the exact versions involved.

The available record supports describing the situation as an attribution controversy. It does not support declaring that Google committed copyright infringement or stole code as an established fact.

“Stole” is especially imprecise when the upstream project granted broad reuse rights. The real allegation is that Google used those rights without preserving adequate credit and provenance.

That allegation remains serious. Permissive licenses reduce restrictions, but they do not erase authorship or make original engineering ownerless.

Developers adopting Artemis should preserve the project’s current license and Minitap acknowledgment. They should also review any embedded notices before redistributing modified versions.

Organizations can avoid similar disputes by treating prompts and examples as provenance-bearing assets. Agent prompts increasingly contain detailed procedures that shape a system’s behavior as directly as conventional code.

A release audit should therefore compare more than dependency manifests. It should examine configuration, test fixtures, prompt templates, documentation examples, benchmark scripts, and package metadata.

Legal teams should not carry that burden alone. Engineers closest to the implementation often know which components came from experiments, internal prototypes, or outside repositories.

The best process records origin when code enters the project. Reconstructing it before publication is harder, and reconstructing it after a public accusation is harder still.

Benchmark Claims Add a Separate Source of Friction

The attribution evidence deserves evaluation on its own because benchmark disagreements neither prove copying nor excuse missing provenance.

Artemis says it exceeds 99 percent task completion on AndroidWorld. The benchmark project evaluates agents across more than 100 Android tasks involving multiple applications.

AndroidWorld provides a reproducible environment for testing whether agents can complete realistic device operations. Tasks can include changing settings, managing app content, and moving through multi-step interfaces.

A benchmark score can attract users and establish technical credibility. It can also amplify an attribution dispute when two related systems report closely competing results.

Minitap says the public leaderboard previously displayed mobile-use at 91.4 percent and Artemis at 99.1 percent. It says later mobile-use submissions reported 94.8 percent and then 100 percent.

Those numbers come from Minitap’s account and should be treated as self-reported unless the benchmark maintainers independently validate them. Minitap itself acknowledges that limitation.

The company says it contacted the leaderboard maintainers about updating the mobile-use result. It also says those attempts did not produce the requested update before the controversy.

There is no verified evidence connecting the leaderboard delay to the repository attribution issue. They involve related organizations and technology, but temporal proximity does not establish coordination.

That separation is essential. The code evidence can be compared through files and history, while the benchmark question involves evaluation versions, submission timing, task configurations, and review procedures.

Different scores can arise from legitimate causes. An agent may use another model, different prompts, updated tools, altered retry rules, or a newer benchmark environment.

A reported percentage also reveals little without methodology. Readers need the tested commit, model configuration, task subset, number of trials, failure policy, and evaluation date.

Artemis currently summarizes its result as above 99 percent. Its README does not provide every detail needed to independently reproduce that number from the headline claim alone.

Mobile-use makes its own strong performance claims. Its open-source repository says it became the first agentic framework to complete 100 percent of AndroidWorld.

Neither statement should substitute for independently reviewed results. This caution applies equally to Google and Minitap.

Benchmark transparency matters more when projects share components. If one system inherits substantial code from another, evaluators need to know which improvements caused the reported difference.

A higher score might come from novel safety checks or execution scheduling. It might also reflect revised prompts, different models, repeated attempts, or changes inherited from upstream.

Without exact configurations, observers cannot attribute the performance gap. They should avoid turning leaderboard placement into a verdict about who built the better underlying system.

The dispute still places pressure on Google’s technical narrative. Artemis presents its reliability as a defining feature, so transparent lineage would help users distinguish inherited foundations from Google’s additions.

Minitap faces a related burden. Its copying allegations are strongest when supported by durable diffs, hashes, and reproducible comparisons rather than screenshots or descriptive summaries.

Publishing a structured comparison would allow independent developers to inspect every claimed match. It would also reveal meaningful differences that should be credited to the Artemis team.

That balanced audit could improve both projects. Upstream maintainers would gain visibility into useful changes, while Artemis users could track the origins of important components.

For enterprise buyers, the practical lesson is simple. Benchmark scores and corporate branding do not replace repository due diligence.

Teams should pin tested commits, retain license materials, record model settings, and reproduce critical workflows on their own devices. Mobile agents interact with changing interfaces, so yesterday’s percentage cannot guarantee tomorrow’s reliability.

What Developers Should Watch Next

Three signals will determine whether the Google Artemis code dispute ends as a corrected oversight or becomes a deeper governance problem.

The first signal is a detailed response from Google or the Artemis maintainers. The current Minitap acknowledgment is useful, but a timeline would answer the central historical questions.

That response should identify which files or components came from mobile-use. It should also explain the author-field replacement and the August history rewrite described by Minitap.

A clear account would strengthen the oversight interpretation. Continued silence would leave the most unusual repository evidence unexplained.

The second signal is a durable provenance update. Watch for a NOTICE file, file-level headers, commit restoration, a third-party code inventory, or expanded acknowledgment of individual contributors.

Not every measure is legally required in every repository. However, a precise source map would help downstream users comply with their own redistribution obligations.

It would also make future maintenance easier. Developers could compare upstream patches and determine whether a defect belongs in mobile-use, Artemis, or both.

The third signal is reproducible benchmark documentation. Both teams can lower tensions by publishing exact commits, task configurations, model settings, retry policies, and evaluation logs.

Independent replication would show whether Artemis’s reported performance comes from its new engineering, shared foundations, configuration choices, or some combination.

These signals matter beyond one repository. AI agent development increasingly mixes source code, natural-language prompts, examples, traces, and benchmark harnesses.

Traditional dependency scanners may recognize imported packages while missing copied prompt files or manually transferred code. That gap makes human provenance review more important.

Companies should establish an intake record for every external component. The record should include the source URL, commit hash, license, notices, modifications, and responsible reviewer.

They should apply the same system to prompts. A long agent instruction can encode distinctive planning methods, tool rules, and recovery behavior even when it is stored as plain text.

Maintainers should also avoid destructive history changes near a public release when possible. If a force push is necessary, they should document why and preserve provenance in the replacement commits.

None of these practices prevents competition. They let organizations build quickly on permissive software while keeping the origin legible.

For developers choosing between Artemis and mobile-use, the dispute does not produce an automatic technical winner. Each project should be evaluated against the required platforms, workflows, models, and verification controls.

Artemis currently focuses on Android automation, developer tooling, diagnostics, and multiple execution profiles. Mobile-use presents broader Android and iOS support paths alongside its agent framework.

Users should test both against real applications rather than relying only on public percentages. They should also monitor how each project handles issues, upstream fixes, and security-sensitive device permissions.

The current acknowledgment means Google has already altered the public-facing provenance picture. The unresolved question is whether it will provide the deeper explanation that the repository history demands.

Minitap must continue making its evidence independently inspectable. Google must show that its open-source process can identify and preserve contributions from a much smaller team.

That is the lasting test. Will the new credit become the end of the matter, or the beginning of a complete public accounting of how Artemis was assembled?