HN Debrief

Google replaced Git tags for certain source code with obtaining via Google Drive

  • Open Source
  • Legal
  • Mobile
  • Developer Tools
  • Platform Governance

The post claimed Google replaced easy access to certain Pixel source releases with a request workflow. Instead of grabbing tagged source from a Git repository, developers now have to submit a form and wait for Google to hand back a Google Drive link to tarballs. The key point was not Git tags themselves. It was that source needed to build and patch Pixel components, especially GPL kernel-related code, is no longer being published in a normal developer-friendly way. A later quote in the comments said requests that once took hours are now often taking weeks.

If you depend on Android or Pixel source drops, plan for more brittle and slower upstream access instead of assuming public repos stay usable. More broadly, treat "open source" dependencies from platform owners as governance risk, not just a licensing checkbox.

Discussion mood

Strongly negative toward Google. The anger was driven less by certainty of a license breach and more by the sense of deliberate friction, weakening Android's remaining openness, and making life harder for GrapheneOS and other downstream maintainers.

Key insights

  1. 01

    GPL likely permits request-based tarballs

    The legal weak spot in the original claim is that GPLv2 was written to allow source distribution on request, not to require public Git hosting. Snapshot tarballs without full revision history have long been treated as acceptable in practice. That means the fight is probably not over whether Google must publish tags, but over how much obstruction a court would tolerate before "source available on request" stops being real.

    Do not assume a workflow that feels anti-open-source is automatically a GPL win in court. If you need leverage, document delays, failed requests, and unusable drops rather than arguing that Git itself is mandatory.

      Attribution:
    • mjg59 #1
    • phire #1 #2
  2. 02

    This is about Pixel code, not all Android

    The missing source is not AOSP as a whole. Commenters pinned it to Pixel kernel drivers and related GPLv2 components needed to build modules and track device releases, including beta builds. That narrows the issue from "Google closed Android" to "Google controls the device-specific pieces that matter most to alternative Pixel-based distributions."

    If your product or project rides on Android, separate AOSP risk from vendor-device risk. Public platform code does not protect you if the hardware-specific layers you actually need become gated or delayed.

      Attribution:
    • kllrnohj #1
    • zb3 #1
    • HarlequinHair #1
  3. 03

    The stronger access argument is forced accounts

    The JavaScript angle did not convince many people. The more credible compliance issue would be if Google required a Google account or acceptance of separate Google terms just to exercise GPL source rights, with no offline or neutral request path. If the shared Drive link is public and fetchable with wget, that specific argument gets much weaker.

    When evaluating license risk, check the exact access path instead of the branding around it. Account requirements, mandatory clickthrough terms, and lack of a non-Google request channel are the facts worth verifying.

      Attribution:
    • compiler-guy #1
    • nomel #1
    • Dylan16807 #1
  4. 04

    A mirror would solve access, but nobody has built one

    Several people noted that once one requester receives the tarballs, they can legally mirror them. That means the bottleneck is organizational, not cryptographic. The reason it still hurts GrapheneOS is that no stable public mirror exists yet, so every release still depends on someone enduring Google's request queue first.

    If this source is strategically important to your ecosystem, do not wait for the vendor to behave better. Fund or run a public mirror and release-tracking pipeline so access no longer depends on one company's manual process.

      Attribution:
    • ajross #1
    • mjg59 #1 #2

Against the grain

  1. 01

    Some of the outrage came before basic facts

    A few people pointed out that the original complaint was light on specifics at first. It did not clearly name the affected components, the delay, or whether the problem was release tags, beta drops, or something broader. Once others supplied that context, the complaint made more sense, but the initial framing invited people to argue past each other.

    If you are escalating a licensing or platform-governance issue, publish the exact repos, artifacts, timelines, and request results up front. Precision makes it easier to rally support and harder for the target to dismiss the claim as vague outrage.

      Attribution:
    • gowld #1
    • HarlequinHair #1
  2. 02

    Bureaucracy may explain more than conspiracy

    One commenter argued this could be ordinary megacorp process rot rather than a coordinated campaign against GrapheneOS. Google has a history of strange access hoops around nominally open projects, and device trees or third-party licensing baggage can produce ugly workflows without a grand strategic motive. That does not make the outcome acceptable, but it changes what kind of fix is realistic.

    Push for evidence before locking into the most intentional explanation. If the problem is bureaucratic ownership and tooling, public pressure aimed at the right team may work faster than treating it as a top-down plot.

      Attribution:
    • a-dub #1

In plain english

AOSP ↩
Android Open Source Project, the open-source base version of Android that device makers and custom ROM projects build from.
Git ↩
A version control system used to track changes in files, especially code and text documents.
GPLv2 ↩
Version 2 of the GNU General Public License, a software license that requires distributors of covered software to provide the corresponding source code under the same license terms.
GrapheneOS ↩
A privacy- and security-focused version of Android for supported phones.
kernel ↩
In this context, a small performance-critical function, often run on a GPU or other accelerator, that does the core numerical work.
Pixel ↩
Google's line of Android phones.
wget ↩
A command-line tool for downloading files directly from a URL.

Reference links

Primary sources and policy pages

Related Android openness debate

  • Keep Android Open
    Cited as related background on concerns that Google is making Android app distribution and sideloading more restrictive.

Examples and side references