Google's Artemis Now Credits the Project It Copied. The Credit Arrived in a Commit, Not in the Issue Asking for It.

What changed inside google/artemis this week, which Apache 2.0 conditions actually bind, and the one check every open-source maintainer should run on their own repository today

Open artemis/clients/adb_tunnel.py in Google's Android automation agent right now and the file opens with a standard Apache header, "Copyright 2026 Google LLC," followed fourteen lines later by something you do not usually see in a Google first-party repository:

# Portions of this file are derived from mobile-use (https://github.com/minitap-ai/mobile-use)
# Copyright 2025-2026 Minitap, Inc. Licensed under the Apache License 2.0.

That header did not exist in the commit a small startup cited when it published, on September 11, a detailed case that Artemis had incorporated its code without credit. The README line crediting Minitap did not exist either. Both are there now. The issue asking for them, filed the same day, still has no assignee, no label, and no reply.

That is the interesting part. Not the copying, which is permitted. Not the omission, which got corrected. The sequence.

What Minitap found, and how

Minitap is a mobile QA company. In early 2026 it published mobile-use, an Apache-2.0 agent that drives Android and iOS devices from natural-language instructions using the accessibility tree, then moved its commercial effort to a closed-source successor. Its LICENSE reads Copyright 2025 Minitap, Inc. Its star count is somewhere under three thousand; three sources checked this afternoon disagreed by about six percent, so no exact figure here.

When Google released Artemis, Minitap's engineers read it. CEO Nicolas Dehandschoewercker's post lists what they recognised, with file-level links in both trees: the ADB tunnel implementation matching line for line, the Hopper agent prompt identical word for word, an app-lock messaging example carrying the same task of sending new-year messages to Alice, Bob and Charlie with the same comments and cleanup steps, and, in older versions, a shared bug where a helper wrote a results file and then failed reading its own output on the next run.

Matching code is suggestive. It is not proof of provenance, because two implementations of an ADB tunnel have reason to converge and a prompt can be rewritten from the same docs. What made the case close was the package metadata. Per the issue Minitap filed, an early Artemis pyproject.toml carried mobile-use's own version number, 3.6.3, and listed three Minitap authors by name under a Google LLC copyright header. A later commit replaced those three names with a different author and left the other 228 files untouched. GitHub's force-push activity record dates that replacement to August, before Minitap went looking in September.

A version string and an author list are not code. They are the kind of thing that only ends up in your file if your file started as somebody else's file. And the only reason anyone can see the earlier version is that GitHub kept a record the repository's own tree no longer shows. github.com/<owner>/<repo>/activity?activity_type=force_push is a page almost nobody opens. It is also, in this case, the entire evidentiary basis for an attribution claim against a company with more lawyers than Minitap has employees.

What Apache 2.0 actually requires

Worth being precise here, because "stole" is the word in the Hacker News title and it is not the word in the license.

Apache 2.0 permits exactly this. Section 2 grants a perpetual, irrevocable right to reproduce, prepare derivative works of, and distribute the work. Google was entitled to take mobile-use, fold it into Artemis, and ship it under its own name. The conditions live in section 4, and there are four of them. You must give recipients a copy of the license. You must cause modified files to carry prominent notices stating you changed them. You must retain, in the source form of any derivative work you distribute, all copyright, patent, trademark and attribution notices from the original. And if the original includes a NOTICE file, your derivative must include a readable copy of its attribution notices, in a NOTICE file, in the source or documentation, or in a display the work generates.

mobile-use has a NOTICE file, which makes that fourth condition live. Its text is unusually candid about the line between obligation and request:

ATTRIBUTION REQUEST: While the Apache 2.0 license only requires preserving copyright notices, we kindly request that derivative works, redistributions, or products inspired by the logic/architecture of this repository include a prominent attribution to "Minitap, Inc." in the documentation and "About" sections of the software. This is a request, not a legal requirement.

So Minitap wrote down, in advance, which part of what it wanted was enforceable and which part was manners. That is a better-drafted NOTICE than most projects ship, and it is part of why the complaint reads as credible rather than aggrieved.

Measured against section 4, the version of Artemis Minitap examined was short. Measured against the version on main this afternoon, the attribution notices are present: a derivation header with Minitap's copyright line in the source file, and a line in the README's License section reading "This project includes source code developed by Minitap, Inc." Section 4(d) explicitly allows the NOTICE attributions to live "within the Source form or documentation," so a README line plus per-file headers is a defensible way to satisfy it without shipping a NOTICE file of your own. Artemis does not have one. mobile-use does.

Where it still diverges, by Google's own rulebook

Minitap's post makes one argument sharper than the license argument, and it holds up after the fix.

Google publishes its own process for releasing code. On third-party components it is explicit: for first-party Google open source projects, any code Google does not own the copyright to must be placed in a third_party directory at the root of the project, and every directory inside third_party needs a LICENSE file containing the full license text and copyright notice for that library. On headers it is equally explicit: for files in the third_party directory, leave the existing headers in place, and if you have modified a file, append "Google LLC" to the copyright line.

Artemis does neither. The mobile-use-derived code lives in artemis/clients/, artemis/agents/ and artemis/sdk/examples/, not under third_party/. There is no per-library LICENSE file. And the repaired header leads with "Copyright 2026 Google LLC" and appends the Minitap derivation underneath, which is the reverse of the order Google's own document prescribes. You can argue this is cosmetic. You can also notice that the whole purpose of the third_party convention, stated in that document, is to help Google and downstream users comply with license requirements, and that a repository which had followed it would never have produced this story.

One more artifact survived the cleanup. The docstring in adb_tunnel.py still reads "This replaces the need for the lim CLI for ADB tunneling." lim is a Minitap tool. Google now ships a file explaining its purpose in terms of a product its README does not mention.

What this says about where enforcement lives

A maintainer published evidence on a Saturday and a credit line appeared in a trillion-dollar company's repository within about a day. Treat that as the good news, because it is. Google did not stonewall; it shipped a diff.

But read the routing. Minitap did three things: filed an issue in the repository, contacted the Google team directly, and published a blog post that reached the Hacker News front page at 132 points. The thing that changed is the code. The issue, which is the channel the project provides for exactly this request, sits with no assignee, no label and no reply. So does the separate grievance in the same post, where Minitap says four emails asking AndroidWorld to update mobile-use's score from 91.4% to its claimed 100% went unanswered while Artemis appears on that leaderboard at 99.1%.

I want to be fair about that last number, and Minitap is: the post says out loud that the AndroidWorld sheet does not independently verify submissions, which applies to Minitap's claimed 100% exactly as much as it applies to Google's 99.1%. Two unverified self-reports, one of which got onto the chart.

The pattern is that attribution in open source is technically a license condition and practically a reputational one. Nothing in Apache 2.0 comes with an enforcement body. What moved here was attention, and attention is not a mechanism you can rely on, because it is not available to most maintainers most of the time. Minitap got it because the counterparty was Google, the evidence was unusually clean, and the CEO could afford to spend a week on it.

Put this into practice

If you publish open source, four of these take under ten minutes and are worth doing before you need them.

Open your own force-push activity page now. Go to github.com/<your-org>/<your-repo>/activity?activity_type=force_push and look at it while nothing is wrong. Knowing that page exists and what it shows is most of the value; discovering it mid-dispute is how you lose a week.

Put identifying metadata where a copy would carry it. Minitap's case turned on a version number and an author list in pyproject.toml, not on the code. Whatever your ecosystem's manifest is, pyproject.toml, package.json, Cargo.toml, go.mod, fill in the author and version fields properly. They travel with a copy and they are awkward to scrub cleanly.

Write a NOTICE file that separates obligation from request. Copy the structure Minitap used: state the copyright, state what the license actually requires, then state plainly what else you would like and label it as a request rather than a requirement. It costs four lines, it makes your NOTICE attributions binding under section 4(d), and it makes any future complaint read as precise instead of entitled.

Check that your LICENSE has a name in it. Of the eight trending repositories verified for this run, three had a license problem: one shipped the unedited Apache template with Copyright [yyyy] [name of copyright owner] still in it, one had no LICENSE file at all, and one sitting behind 2,833 stars was under a custom non-commercial license rather than the MIT everyone assumes. An unfilled template is the one that bites hardest, because it reads as permissive while naming nobody who could enforce it.

If you are the one doing the incorporating, use the convention. Put the code in third_party/, keep its LICENSE, keep the original header and append yours. That is Google's documented process and it exists precisely so that the question "where did this come from" never has to be reconstructed from a force-push log.

Honest limitations

I did not run either project, and nothing here is a code-similarity analysis. Minitap published file-level links in both trees and I read the pairs it pointed at; I did not independently diff the repositories, and I did not attempt to determine how much of Artemis is derived versus original. Artemis clearly contains substantial work that is not mobile-use.

I verified the current state directly: the README line and the adb_tunnel.py derivation header are present on main as of this afternoon, and absent at commit 0860788, the one Minitap cites. I did not establish exactly when they were added or by whom, and I did not find any public Google statement about it. The fix may predate Minitap's post, may have followed it, or may have followed the Hacker News thread. The sequence I describe is the sequence of what is publicly visible, which is not the same as causation, and I am not claiming Google acted because of the post.

The license reading here is mine, from the text of Apache 2.0 section 4 and the two projects' files. I am not a lawyer and this is not legal advice. In particular, whether a README line plus per-file headers fully discharges section 4(d) in the absence of a NOTICE file is the kind of question that has a real answer I am not qualified to give, and Minitap's own NOTICE text sensibly declines to treat its preferred outcome as a requirement.

The AndroidWorld figures on both sides are self-reported to a leaderboard that states it does not verify submissions. I did not open the sheet to confirm the current numbers, and the comparison chart in the Artemis repository is Google's own chart.

What to take from it

The part of this story that generalises is not about Google. It is that the only durable record of who wrote the code turned out to be a log page, and the only effective enforcement turned out to be an audience. Both of those are things you either set up in advance or do not get.

So set up the cheap half. Fill in the manifest. Write the NOTICE. Put a name in the LICENSE. Look at your force-push page once, today, while it is boring.

And if you are the larger party in one of these, the lesson is cheaper still: a credit line costs nothing and a week of somebody reading your repository line by line costs you considerably more than that.

Sources: Minitap's post · google/artemis issue #40 · google/artemis README · minitap-ai/mobile-use · Apache License 2.0 · Google's open source release guidance

Medium metadata

Title: Google's Artemis Now Credits the Project It Copied. The Credit Arrived in a Commit, Not in the Issue Asking for It.
Subtitle: What changed inside google/artemis this week, which Apache 2.0 conditions actually bind, and the one check every open-source maintainer should run on their own repository today
Tags: open source, apache license, github, ai agents, software engineering
Canonical: import from the fervorai.dev URL
Kicker image suggestion: a force-push activity log page, rendered plainly, with one entry highlighted