GrapheneOS is arguing that throwing away the metadata of however many commits and squashing them into a messy tarball is not the "preferred form of the work for making modifications", and that a manual process where you have to fill out a form in order to get a Google Drive link a week later is not "a medium customarily used for software interchange" in current times. Those are quotes from the GPLv2.

Lack of a specific time limit in GPL doesn't mean there isn't one based on what's reasonable. What they're doing it not reasonable.

> Android has always been more source-open than “open source”.

This is about Pixels rather than AOSP. Google decided Pixels would no longer be supported by AOSP which is why they stopped pushing the kernel drivers, userspace drivers and other Pixel related code to AOSP. They moved to publishing kernel driver code via Google Drive after filling out a Google Forms submission. They're handling those manually. It's a ridiculous system and comes across as them wanting to make it a hassle on purpose. Perhaps that isn't the case and someone simply needs to make the decision to simply push Git tags somewhere else. They could put it on GitHub if the goal is disassociating it from AOSP.

We accepted the archaic new system while they were responding to requests in a reasonable time but that ended. It's now very inconsistent and is regularly getting delayed for weeks or more.

> The vast majority of community contributions that make it into the codebase are security fixes and small bug fixes.

Open source does not imply anything about accepting contributions. SQLite barely takes any contributions and the same applies to many projects. There were a lot more code contributions to AOSP than you're describing prior to recent changes with Android 16. It was relatively easy to contribute to the lower level parts of it.

Google are absolutely within the letter of the GPL, pedantically so. But maybe not the sprit.

We didn't have git tags when GPL was written in 1989, and while we did have sccs and rcs, (and early versions of cvs) they just weren't that widely used, and generally not used for distribution.

Even when GPL 3.0 was written in 2005-2007, source tarballs were still the primary form of distribution, even though it was starting to become standard to additionally provide anonymous cvs, svn, or one of the brand new distributed systems like git.

But these days git is the primary form of distribution, and source tarballs are noting more an afterthought. Hell, even tags are a bit of an afterthought on many projects. It's basically become the norm to expect an healthy revision history for any open source code.

Based on it's stated goals of "freedom to modify the software you use", IMO if the GPL was written (or updated) today, it would most likely require the distribution of revision history and restrict how much that history can be squashed/rewritten.

> Everything else is essentially all the work of Google and (to some extent) Samsung.

There is plenty in Android which isn't the work of Google. For starters the Kotlin implementation and the Java implementation (OpenJDK).

> Android has always been more source-open than “open source”. The vast majority of community contributions that make it into the codebase are security fixes and small bug fixes.

I believe this isn't actually about "Android" at all but rather Pixel. Android is still openly accessible on git. But the kernel sources for Pixel devices is now behind this big song & dance for some fucking inexcusable reason.

Open source doesn't imply open to contributions. And you could imagine source available software that's not open source but takes contributions (and this is not theoretical, I've seen this in the wild).

(However, that's quite orthogonal to being a dick about making the source code that you must share available)

The intent is obviously to make it hard to get the source code, which violates the license.

I see your point, However the majority of Android devices have lots of closed source firmware/drivers, a large part of the Android OS doesn't run without them.

I'm refering to Bootloaders, TrustZone OS, Trusted Applications, then firmware for Bluetooth, Wifi, GPU, Sensors and power management. All of those are always closed source binary blobs running in the background.

> Android has always been more source-open than “open source”.

I hate Google as much as the next person, and the only way with those companies would be to fine them heavily, quickly and systematically.

But it is important that we are clear about what Google does bad and what it does well. And I believe that understanding what "open source" means is important when one wants to talk about a violation of an open source licence.

Open source does not mean that they take contributions. Many firmwares used by Android are not open source, but AOSP is open source. It is licenced under a permissive licence (Apache 2, I think for everything), which makes it open source, period.

Why would it be a "stretch"?

The basic requirement is whether the source code is available - and made available. Are you certain that Google's solution here is ensuring that the source code is easily made available? So many other projects just provide a wget-able link. Why does Google want to make it harder to obtain the source code than those other projects?

> Android has always been more source-open than “open source”.

And what exactly does that mean? I don't know what your words mean here. More source open than open source? Is that a tautology?

> Everything else is essentially all the work of Google and (to some extent) Samsung.

Is it GPLv2? If so then I fail to see why anyone should get higher rights. Everyone gets the same for GPLv2. That's the whole point. I don't understand your statements here.

> “In violation of GPL” is a stretch.

The originally envisioned distribution method, in fact, was "Send FSF a blank 9-track tape and they'll fill it and mail it back". Nor, obviously, does anything prevent someone who downloads this from Drive from mirroring it on GitHub or wherever.

This is arguably bad stewardship of a historically open source project. It's certainly not a license violation.