Google replaced pushing Git tags for certain source code with obtaining source code via Google Drive after making a request through Google Forms. It's completely ridiculous and they've gradually become very slow at handling requests. They're in clear violation of the GPLv2 now.

Prior to moving it to Google Drive, they started squashing the history into a single commit prior to pushing release tags. The tarballs provided via Google Drive have exactly the same source code. However, they went out of the way to make it more inconvenient in several ways.

Initially, Google would usually provide access to the tarballs within a couple hours. Lately, they're often taking weeks to get back to us. They're the ones who chose to use this archaic system instead of pushing Git tags and it's their responsibility to handle requests promptly.

These changes won't negatively impact GrapheneOS on upcoming Motorola Mobility devices. In fact, it's a major part of why our partnership exists. It only negatively impacts Pixels and hurts Google more than anyone else. Google wants to make Pixels worse for no apparent reason.

Google could simply push signed tags to Git instead of having a person assigned to go through form submissions and give access to specific files. They could also give access to folders instead of files to avoid needing to give us access to more files multiple times a month.

If they insist on using Google Drive, they could at least automate giving access. It shouldn't depend on a person going through a huge backlog as a low priority. Requests not being handled for weeks is unacceptable. They could simply push the Git tags and stop dealing with it.

They're obligated to fulfill our requests. We need each of the Beta tags because we port and test in advance. If they don't want to deal with our endless requests for each release, they can simply push the tags to Git. They chose to waste the time of several employees on this.

For Motorola devices, we plan to prepare our releases early and have everything ready for major Android updates at launch. We should be able to simply push the code to our own repositories for major Android releases. We'll need to host all the AOSP Git repositories ourselves.

@GrapheneOS I smell a forgejo instance. A trustworthy one~

@Phalzu We're probably just going to host them as Git repositories without a whole social coding platform. If we want to take pull requests ourselves without GitHub then we could host Gerrit ourselves.

@GrapheneOS

Reminds me of some "open source" apps in China that use Tencent QQ and Baidu Netdisk for distribution.

That does not necessarily make them non-free, but somehow defeats the purpose of being open source, since users have to install other proprietary apps on their device and register accounts associated with real ID to get them.

No ethical FLOSS developer should ever do that. And apparently we can't expect that from Google.

@cismonx It's incredibly backwards and very hard to understand why they want to drive away people from using their devices.

Nexus and Pixel devices had a lot of Android enthusiasts using them who are increasingly being driven away by these decisions.

They're driving a lot of people away to using iPhones rather than simply using other Android devices.

The management making these decisions largely use iPhones, not the products they're gradually stripping of their actual advantages.

@GrapheneOS @Phalzu gerrit 😭

@xyhhx @GrapheneOS @Phalzu gerrit's really good i actually stan

@GrapheneOS

this sounds like The Onion header.

@GrapheneOS

"Google starts distributing Google Android for Google Pixel via Google Drive requested via Google Forms"

@vrtrahan @GrapheneOS a few hundred thousand person hours and the funding for it

@lattera @eatham It doesn't have to explicitly specify any time constraint for it to be required to provide it in a reasonable amount of time. Law is not code and doesn't depend on everything being explicitly written down. Google is a massive tech company with enormous resources. They clearly made these changes to make it a hassle to obtain the sources. By not quickly responding to the requests and dealing with it, they're artificially delaying access and that's a violation of the license.

@lattera @eatham Aside from that, not providing it in the form of Git repositories is not providing it in the preferred form for modifying the source code. Android's tooling is based around dealing with Git repositories. Even if they strip all the history, it should still be tags in Git repositories so stuff works properly and it's split up into separate repositories in the way they did themselves. The build system uses Git revisions. It has a fallback to use a metadata file which they provide.

@GrapheneOS if the paper contains many inaccuracies, maybe it's a good idea to contact the authors and editors to get it retracted?

@danieldk @GrapheneOS I think that this kind of inaccuracies are intentional. This "work" looks like a slop that was made with premeditaion. I have also doubt if there was any review before publishing this slop.

@wod0bow @danieldk It was funded by a grant from Google, one of the authors is from Google and it lists 4 reviewers from Google. It fits neatly into Google defending banning GrapheneOS with the Play Integrity API in Europe. There's going to be a lot more of a response from us than what we already did if they don't retract or correct it soon.

@GrapheneOS i'm so unbelievably hype for the motorola devices

@GrapheneOS since when?

@idkrn They started doing this for Pixel kernel drivers after the initial release of Android 16.

@GrapheneOS this isn’t technically in GPLv2 violation, as long as they eventually fulfill the requests, as much as it sucks.

@julia GPLv2 says it needs to be provided using a medium customarily used for software interchange. Google Drive is not customarily used for providing source code. Google is purposely making it a hassle using poor software for it.

GPLv2 does not need to explicitly state any specific time requirement for it to be required to provide the sources in a reasonable time period. A court would consider their resources and tech capabilities. This is one of the largest tech companies in the world.

@GrapheneOS
I took a look at Motorola's current offerings, and there are dealbreakers with everything they offer. I'm not interested in anything with a folding screen, but I need over 250gb storage.

I'm hoping the planned device has different specs.

@TheGreatLlama @GrapheneOS

Well let's also hope you can unlock the bootloader without jumping thru hoops with Motorola customer support and forced wait times and shit before you can unlock you're device like Motorola is known for

@adamsaidsomething @TheGreatLlama It will be better for the devices supporting GrapheneOS.

@Revan_9766 The initial devices with GrapheneOS support should be available in 2027. The initial devices will be flagships so they'll be higher end hardware than Pixels at a higher price. Lower end devices will take more time to meet our requirements since the updates and security features aren't as good. It's mostly due to how Qualcomm handles it. The latest Snapdragon flagships have the best security features. We'll also need Motorola to start paying them for longer updates below flagships.

@GrapheneOS Honestly to me it is not that clear. They still use a platform customarily used for software interchange, the waiting time of a few weeks should be okay and as long as they grant access it should also be okay? Not retaining git history sucks especially but isn't the source code technically still there? Has there been some ruling on the git history thing?

@derberg

> the waiting time of a few weeks should be okay

No, it isn't. It's an artificial delay causing substantial harm through delayed security updates. That means we have to reverse engineer the code to get the patches. We can do that but it results in ongoing damages from Google's violation of the GPL license. They used to push it immediately and now there's a deliberate artificial delay to cause harm. What other reason is there for moving to a manual system with substantial delays?

@GrapheneOS Ah, found a response in which is was said that it is non-customarily. Well, it was never specific about source code. Google drive is used for software sharing. Maybe not mainly but same applies to CDs. Lots of vendors generate personal links to download from servers, lots of vendors have own portals with links and icons which start downloads. As long as it is not overly cumbersome it should be okay. Sure, the form is uncommon but not unheard of. I honestly don't see a GPLv2 violation but well, I guess somebody could ask Stallman about this Google Drive thing regarding if he things it violates it and his personal opinion. After all, he wrote the GPLv2. Or go to court.

@GrapheneOS I do agree the change is hostile. Yet I do not see anything that is really worse than what I have seen from some other big vendors to receive source code. Sure, it is cumbersome, especially for such a project.
But well, regarding the customary thing I just sent a mail out to rms asking him on writing a blog entry with examples what is OK and what not regarding the license as well as his personal opinion on the matter. Autoresponder says to wait at least 48 hours for a reply.

@GrapheneOS I do see how a court could rule in your favor with that argumentation; when it considers Google managed to do better previously. But I feel you really do need a court ruling; I personally don't see non-allowed things from the license text alone.

@derberg We didn't say it was the fact they're doing it via Google Drive using Google Forms which makes it a GPL violation. It was stated after bringing up the massive delays and then we elaborated on the situation. We didn't consider it to be a GPL violation until they started taking weeks or more to handle our requests for the sources.

What matters is how things work in 2026 especially for the Android source code. It matters how Google shares it with partners, the impact of delays and more.

@derberg Google is one of the largest tech companies in the world. It's an entirely negligible burden on them to quickly comply with these requests. They could have entirely automated it or at least made it automated after the initial request from an email. They chose to make it a manual process with a lot of friction and delays. They chose to go out of their way to go a lot of extra work for this. They have to package up source code this way and manually hand out access to those to people.

@derberg What Google is doing is far harder than simply pushing the code. It's also far harder than an automated system for providing it upon request. They're choosing to do this to create harm through delays.

The intended target of that harm is probably not GrapheneOS but rather major companies forking Android. After all, they still provide first class support for alternative operating systems on Pixels at a hardware and firmware level but are making it awful for people to use because of this.

@GrapheneOS I appreciate the update and expanding the options, but ugh at the only option aside from a Pixel is going be a $2000 phone. Maybe it's time to just opt out altogether.

@ellesaurus Motorola Signature (2026) is the regular variant of the current generation. Razr Fold (2026) and Razr Ultra (2026) are the other flagships. Future variants will be the first with the required hardware memory tagging and secure element features.

There can be support for lower end devices once the security features trickle down.

@ellesaurus Here's the Motorola Signature (2026) in India:

https://www.motorola.in/smartphones-motorola-signature/p?skuId=610

12GB RAM / 256GB storage variant is normally priced at ₹74,999.00 (784.06 USD) with taxes included and is on sale for ₹59,999.00 (627.25 USD).

It's sold at higher prices in western countries where it's around $1100 for the same model. It varies based on the country.

Pixels have a line of budget devices including the Pixel 10a which is regularly priced at $499. Base Pixel 11 is $899 and Pixel 11 Pro is $1,099.

@ellesaurus Motorola didn't launch the Motorola Signature (2026) in the US but do sell the Razr Fold (2026) and Razr Ultra (2026).

The initial devices with GrapheneOS support can be expected to be a similar set of 1 to 3 devices (regular, fold and flip). Support for lower end devices is certainly possible, but a lot of their lower end devices are MediaTek without the security protections we need.

We need budget Snapdragon devices with a newer platform bringing the same security features.