They stopped pushing tags for any of the Pixel kernel or userspace driver repositories to AOSP. They also stopped pushing AOSP releases specific to Pixels which is why AOSP now only gets yearly releases, QPR2 releases and security backports to both of those. Other OEMs use the yearly and theoretically also the QPR2 releases. Both the yearly and QPR2 releases get monthly security backports. Since they dropped Pixel support from AOSP, they don't push the releases not shipped by other OEMs anymore.
These changes directly led to our Motorola partnership. One of their security people reached out to us after seeing our posts about this with the launch of Android 16. We haven't talked about it much since then since we adapted to it during the several weeks it delayed our Android 16 port. We then continued adapting to it and have fully worked around it. It was an ongoing problem but not a new one and we had accepted we had to deal with it as the new normal.
They were previously responding to our kernel source requests within a day. It was often done without hours. Despite the archaic system, this part wasn't that bad. Recently, they've been taking weeks or longer to get back to us for the requests which is ridiculous. It's the direct result of purposely adding a lot of friction with manual handling of the requests even if the delays weren't directly planned by management.
Weeks or months of delay is not reasonable for one of the largest tech companies in the world. GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely. They need to do it in a reasonable amount of time. What's reasonable for one of the largest tech companies in the world in 2026 with current technology is not the same as what was reasonable 30 years ago. Google chose to come up with a archaic way of distributing the sources involving someone manually going through a list and sharing Google Drive access. It's a deliberate way of making it painful. If they can't keep up with it and it gets delayed for weeks or months then they're not complying with the GPL by not providing it in a reasonable amount of time. Law is not code and a time limit not being explicitly written down doesn't mean there isn't a limit to what's reasonable for compliance.
They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels. We helped them fix serious security weaknesses for Pixels including vulnerabilities being exploited in the wild by forensic data extraction companies. Pixel security with the stock OS would be worse without GrapheneOS.
> They need to do it in a reasonable amount of time.
If they did that for years within hours and if we look at the tools available today, I would expect that "reasonable" equates to how they provided it prior: fast.
They did it for many years with 0 delay because they pushed the tags to AOSP. It was moved to Google Drive with a Google Forms setup to request access with manual fulfillment of the request. It was deliberately done to make it into a hassle. The delays are by design through making it a manual system regardless of how much of a delay was intended as part of this change. They could be automatically handling the requests especially from people who have already been given sources for a product. They're deliberately making it take substantially more work on their end to make it into more of a hassle.
I was involved in one of the communities involved in the Block Sidewalk efforts in Toronto Canada, which prevented Sidewalk Labs from moving forward on a multi-billion dollar project to redevelop a chunk of downtown Toronto.
I was at the Data Power 2017 conference in Ottawa where I shared with people (who would become key Block Sidewalk organizers) the clues I had, that Google was about to bid on the as-yet-unknown land development opportunity, closing later that month.
I had previously been in collaboration with secure ROM developers hitting their first adversarial efforts to thwart use of Android for alt app markets. I know that Google's public story of Android openness (which drove people trusting them to build a city platform) was bullshit, and I made sure many many of the key activists and public servants knew it.
While I can't know exactly how my specific actions affected things, I would guarantee that Google's adversarial positions and failed stewardship have already contributed to them losing real opportunities.
There's no reasonable delay. The source code needs to exist before binary distribution.
When google distribute the compiled code to me, I assume the source is already available.
If distribution means I buy a phone with compiled code, I expect the sources to be readily available.
I distribution means my phone download updated software - I expect the code to be available.
Only lasts until google pushes out gpl in favour of fuchsia or something - so they can finally run away from the community code they built the android system on. Bit until then I fully expect them to actually honor the license...
GPL does explicitly allow for only providing source code on request. But of course that doesn't mean you can arbitrarily delay responses to such requests.
> They'll sell far fewer Pixels because of these overall changes.
They don't even sell Pixels internationally. Can't tell you how glad I am you're moving to Motorola. I'm really looking forward to having a Motorola GrapheneOS phone!!
A reasonable interpretation would be that they had a previous process that eliminated delivery latency and required no manual manpower for responding, so changing it has been done to induce artificial friction, against the intent of the license.
That's why I said intent rather than letter. That said if we allow for arbitrary lengths of time, one could argue that sending back a reply indicating that the source will be delivered in 50-75 years is equally compliant.
Do it! GrapheneOS is a breath of fresh air compared to iOS. No more annoying pushes of Apple Intelligence, Apple Health+, Apple Music, F1 ads (to your wallet), etc. GrapheneOS gives a device that you truly own.
Well, it is only a matter of luck and internal politics, that Linux kernel hasn't yet been replaced by Zircon on AOSP, which is I guess the only GPL piece that is left from the original 1.0 version.
Fairphone with its 8-year updates, swappable battery, and decent repairability is great for those of us who doesn't like to be forced to change phones often. I'm not sure, however, what variety of distributions you mean. It supports 1 Android, and 1 de-googled Android. Which isn't bad at all, but still doesn't sound like "variety".
Wikipedia (https://en.wikipedia.org/wiki/List_of_open-source_mobile_pho...) lists /e/OS, CalyxOS, IodéOS, LineageOS, postmarketOS, Ubuntu Touch, the latter two being non-Android, the rest Android derivatives on Fairphone 5. Fairphone 6 has only /e/OS and IodéOS listed at the moment, but that will probably change after some time on the market.
There are also various reports of things like running e.g. Fedora on an FP6, https://www.notebookcheck.net/Fairphone-6-turns-into-a-Linux... or Debian on FP4/5, but those generally aren't something that is usable due to lacking support for basic things like calls.
Arguably, they aren't even distributing the source code at all anymore. The GPL defines "source code" as "the preferred form of the work for making modifications to it".
I would be willing to bet any amount of money that no Google developer makes modifications using a tarball that's missing commit history. The preferred form for making modifications is a source control repository.
While it would be nice if it worked that way, I think there are too many historical examples of tarball distribution of GPL code to make that argument.
I begrudgingly agree. I would like to make a case that times have moved on/the definition of preferred has changed; but I don't think that would hold up on its own as a legal argument.
- How hard is it for manufacturers to include the option Android/Graphene just like they have memory and storage options?
- Could this be a point where GrapheneOS disconnects from Android and become an independent OS?
> They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels.
Which brand and model is currently best supported by GrapheneOS, if I want to buy an Android device to run GrapheneOS on?
Only Pixels, most other device are ironically locked down a lot more (not allowing custom keys for verified boot) or lack modern security features (like hardware security modules).
So you'll have to wait for the mentioned Motorola Flagship
Well, it's as you wrote: they are making the source available, albeit in a very inconvenient way, and because there is no time limit specified, they're complying with the letter of the GPL (although not with its spirit), so you can't even realistically sue them. And the number of people who buy new Pixels to immediately install GrapheneOS on them is (no offense) negligible, so I don't think they'll see a sales impact from it...
Which is not to say that I'm on Google's side, this is absolutely a dick move from them, and they wouldn't have done it 20 or even 10 years ago, but today's Google is definitely no longer the "don't be evil" company.
Not in the preferred form for modification expected by the build system and not in a reasonable amount of time. It's artificially delayed with no legitimate reason.
> And the number of people who buy new Pixels to immediately install GrapheneOS on them is (no offense) negligible
Nearly all of our current users bought a device specifically to install GrapheneOS. Our current userbase is around 500k and many of those are users had one or more earlier devices with GrapheneOS. Our userbase is rapidly growing. Look up how many Pixels are actually sold in a year. It's not negligible at all.
There are also many large companies wanting GrapheneOS devices with official support from the OEM.
Sorry, I stand corrected: Despite owning a Pixel 9 Pro myself, I didn't realize Google's Android phones market share was so tiny (1.1%! according to https://www.appbrain.com/stats/top-manufacturers). In that case, of course, the number of Pixels bought because of GrapheneOS could be a significant fraction.
That’s 1.1% of ~1.1-1.2B Android phones sold per year. I dont’t know how long the average GrapheneOS user holds on to their device, but if 25% of them per year buy a new phone (rather than upcycling a used one or using their previous phone another year), that would amount to about 1% of Google’s annual sales at best.
And just to emphasize, "the preferred form of the work for making modifications to it" is a direct quote from GPLv3, under which the Linux kernel is licensed.
If GrapheneOS are finding the Google Drive option inadequate, they might choose to invoke Section 6 clause b of the GPL "Convey the object code in, or embodied in, a physical product (including a physical distribution medium)".
Note that AOSP as a whole is covered under the Apache 2.0 licence, which permits but does not obligate third-party distribution of source. That is, it's not a "copyleft" licence in the sense of the GPL.
Googles notes on why BSD/MIT/Apache licences are preferred are ... informative.
No, I'm not (a lawyer might recommend to sue, hoping for a big payout, even if the chances of it happening are small?). I looked at the GPL text, and what Google is doing is really pushing the "If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means", but others have done the same or worse, and so far fines that are really painful for a large company are few and far between...
The main thing here is it used to work faster and google surely can deliver data fast - but now they intentionally changed procedure to make it slower. That could be fined for going against the spirit of the licence contract.
For extra lulz you should get someone with a banned Google account to request the source code. Then Google needs to either unban the account, make an exception for Google docs or deliver via another mechanism.
> GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely
The GPL doesn’t require them to provide the sources to the world; it requires them to provide it only to those who are in possession of the object code, and even then, _if_ they sell the product with a written offer to get the source code (¿Do they?):
- only upon request,
- only for three years or for as long as they offer spare parts or customer support for the specific product
On top of that, they can charge money for doing that (“for a price no more than your reasonable cost of physically performing this conveying of source”)
> The GPL doesn’t require them to provide the sources to the world;
I don't see how this is relevant. The people making the request are within those boundaries. The rest is moot. The spirit of the GPL is that graphene is entitled to the GPLd source in some way and google must reasonably comply.
There might be some legal nuance here. What binaries does Google distribute and does Google provide sources of those? (I assume pixel updates count, is that pure AOSP?) Does grapheneOS request sources for beta tags that are not distributed yet in binary form?
Don't get me wrong, I still think this is shitty behavior from Google.
These changes directly led to our Motorola partnership. One of their security people reached out to us after seeing our posts about this with the launch of Android 16. We haven't talked about it much since then since we adapted to it during the several weeks it delayed our Android 16 port. We then continued adapting to it and have fully worked around it. It was an ongoing problem but not a new one and we had accepted we had to deal with it as the new normal.
They were previously responding to our kernel source requests within a day. It was often done without hours. Despite the archaic system, this part wasn't that bad. Recently, they've been taking weeks or longer to get back to us for the requests which is ridiculous. It's the direct result of purposely adding a lot of friction with manual handling of the requests even if the delays weren't directly planned by management.
Weeks or months of delay is not reasonable for one of the largest tech companies in the world. GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely. They need to do it in a reasonable amount of time. What's reasonable for one of the largest tech companies in the world in 2026 with current technology is not the same as what was reasonable 30 years ago. Google chose to come up with a archaic way of distributing the sources involving someone manually going through a list and sharing Google Drive access. It's a deliberate way of making it painful. If they can't keep up with it and it gets delayed for weeks or months then they're not complying with the GPL by not providing it in a reasonable amount of time. Law is not code and a time limit not being explicitly written down doesn't mean there isn't a limit to what's reasonable for compliance.
They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels. We helped them fix serious security weaknesses for Pixels including vulnerabilities being exploited in the wild by forensic data extraction companies. Pixel security with the stock OS would be worse without GrapheneOS.