Google has stopped pushing Git tags for some Android source code

Original Article ↗ Hacker News Discussion ↗

Google has stopped publishing certain Android and Pixel kernel sources via public Git tags and now requires developers to request tarballs through a Google Form, which are then delivered via Google Drive after delays of days or weeks. Commenters debate whether this satisfies the letter of GPLv2 while clearly undermining its spirit, arguing that withholding timely, git-native source makes it harder for downstream projects like custom ROMs to track changes and ship security updates. Many see the move as part of a broader trend of Android becoming less open and more tightly controlled, alongside upcoming restrictions on sideloading and third-party ecosystems.

What Changed in Google’s Source Distribution

  • Google stopped publishing certain Android-related Git tags (especially for Pixel-specific code) to AOSP.
  • For Pixel kernel drivers and other GPL/LGPL components, source is now provided via tarballs on Google Drive, obtainable only after submitting a Google Form.
  • Previously, tags were pushed regularly and tarballs (when used) were typically provided within hours; now responses often take weeks.
  • The new tarballs are monolithic, with squashed history and extra repo metadata, rather than the original structure of many Git repos.

GPL Compliance vs. “Malicious Compliance”

  • One side argues Google is in clear GPLv2 violation:
    • Weeks-long delays are not a “reasonable time” given Google’s capabilities.
    • Source is not in the “preferred form for making modifications” because Android’s build system expects multiple Git repos and runs Git commands; the tarball-only form causes errors.
  • Others argue it’s likely technically compliant:
    • GPLv2 allows source-on-request and even physical media, with no explicit time limit.
    • Historically, snapshots without full VCS history have been acceptable.
    • Google Drive + a manual process is seen as hostile but still within the letter of the license.
  • There is disagreement about whether “medium customarily used for software interchange” could exclude Google Drive or impose timing expectations.

Impact on Downstream Projects and Ecosystem

  • Custom OS projects targeting Pixels report concrete harm: delayed kernel sources block timely support for stable and beta releases.
  • Pixels were marketed as AOSP reference devices with long support windows; some argue that dropping Pixel-specific AOSP releases undermines those commitments.
  • The friction makes Pixels harder, not easier, for third-party ROMs, pushing them toward other vendors (e.g., Motorola).

Perceived Motives and Broader Concerns

  • Speculated motives include:
    • Increasing control over the Android ecosystem and third-party ROMs.
    • Slowing analysis of security patches and vulnerabilities.
    • Aligning with broader moves like tightening sideloading and developer verification.
  • Many see the change as part of a trend: Android drifting from “open” toward a more closed, iOS-like model, even if the core AOSP remains open source.