Google Now Ships Some Android Source as a Drive Tarball You Request by Form. GrapheneOS Says That Breaks GPLv2.
For certain Android source code, Google no longer pushes Git tags. You fill in a Google Form, wait, and eventually receive a link to a tarball on Google Drive. GrapheneOS, which maintains a hardened Android build and therefore needs that code on a schedule, says the wait is often weeks and that Google is "in clear violation of the GPLv2 now."
The story hit the top of Hacker News on 20 August with hundreds of comments. Most of the argument was about whether it is technically a licence violation. I think that is the least interesting question in the whole thing.
What actually changed
Two things, and only one of them gets discussed.
The first is the delivery mechanism. Git tags are the standard way to mark a release in a repository: anyone can fetch a specific version automatically, on their own schedule, with no human on the other end. Replacing that with a form submission means a person at Google has to process your request before you get anything. GrapheneOS reports that this frequently takes weeks.
The second is the artifact itself. GrapheneOS says Google squashes development history into single commits before releasing the code. You get the state of the tree, not the sequence of changes that produced it. For anyone auditing security-relevant code, that is the difference between reading a changelog and being handed a snapshot and told to diff it yourself.
The second change is the one that matters more and got the least attention.
The GPLv2 argument, honestly stated
GPLv2 requires that anyone distributing software built on GPL-licensed code make the corresponding source available. Parts of Android are governed by it, most obviously the Linux kernel. GrapheneOS argues that a form, a multi-week wait, and a Drive link do not meet that bar.
Whether that is correct has not been adjudicated. The licence text requires that source be made available. What it does not do is specify a delivery mechanism, a maximum acceptable latency, or a required level of commit granularity. Those have been argued in open source circles for decades without resolution, largely because GPLv2 was drafted when "provide source on a physical medium for a reasonable fee" was a serious option.
Hacker News commenters landed on "malicious compliance," which is a reasonable read: Google may be meeting the letter of the licence while making the process as inconvenient as it can. Others pointed out that weeks of latency inside a company that size is also a plausible description of ordinary bureaucratic decay rather than strategy. Both can be true.
One technical detail is worth holding onto, because it cuts against the strongest version of the accusation: git push does not transfer tags by default. Pushing tags requires an explicit flag or an explicit refspec. The absence of tags on a public repository is therefore consistent with a deliberate policy decision and also consistent with someone changing a CI job and not noticing. From outside, you cannot distinguish the two, and nobody has produced evidence that settles it.
Google has not publicly responded. No legal action has been announced, and GrapheneOS has not said whether it will pursue a formal enforcement complaint.
GrapheneOS is routing around it
Rather than wait, GrapheneOS says it plans to host its own AOSP repositories for upcoming Motorola devices, expected to be available in 2027.
Think about what that sentence costs. A small independent project is taking on the hosting, bandwidth, and maintenance burden of mirroring an operating system's source tree, because the upstream distribution channel got slow. The work does not produce a single new feature. It buys back a property the project used to get for free: being able to fetch source when they need it rather than when someone else gets around to it.
That is the real price of this kind of change, and it does not appear in any licence dispute.
Why I care about this and I do not build Android anything
I do not ship an Android ROM. Neither do most people reading this. The reason this story stuck with me is that it is a clean example of a failure mode I do not have a good defence against.
When I audit dependencies, I check licences, maintenance activity, download counts, open CVEs, and how many people have commit access. Every one of those is a property of the code. None of them measures whether I can still get the code on the timeline I need it.
"Open source" gets treated as a binary in every dependency review I have ever run. It is not. It is a bundle of properties, and access latency is one of them, and it is the one that can degrade to near-uselessness without a single line of the licence changing. A project can stay MIT-licensed forever while the release cadence goes from weekly to twice a year, the tags stop, the changelog gets squashed, and the maintainer stops answering. At no point does your audit fire.
I checked my own stack after reading this thread and found two dependencies where my actual answer to "what happens if upstream goes quiet for six months" was that I would notice when something broke. That is not a plan.
What I would actually do
For each dependency you would genuinely struggle to replace, write down two things.
The first is how you get updates. Not "it is on GitHub." Specifically: is it an automated fetch you control, or does it depend on someone else performing an action? Package registry, Git tag, and vendored copy are all automated. A form, an email to a maintainer, or a Discord DM are not.
The second is your fallback if that channel stops working for six months. For most things the honest answer is "vendor the current version and stop upgrading," and that is a perfectly good answer as long as you have written it down before you need it. The failure is discovering during an incident that you never had one.
That is maybe twenty minutes of work for a small project. It is the only part of this story that transfers.
Where this could be wrong
The strongest counter to everything above: this affects specific parts of the Android source, not AOSP wholesale, and the projects hurt by it are a small set of ROM maintainers with unusually demanding needs. Framing it as a general warning about open source risks inflating one company's process change into a trend that nobody has demonstrated exists.
It is also true that GrapheneOS is an interested party with a documented history of publicly and forcefully criticising Google, and "in clear violation of the GPLv2" is a legal conclusion stated by a project, not a finding by anyone with authority to make one. I have taken their factual description of the process at face value because Google has not disputed it, but that is not the same as verification.
Author
Lukas
@lukcombinator