> 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.
Google helped lobby the FSF to adopt GPLv3, which bans tivoization, but allows software as a service.
This is why you cannot have bash on MacOS, but Google can still use it to build surveillance capitalism, and arbitrarily enshittify your word processor.
> We might charge you a fee to cover the cost of processing. Your request must be sent according to whichever of the following rules applies:
> Within three years of the date you received the product from Google that included the component or binary files that are the subject of your request.
> How slow is "very slow?"
The answer can be found two replies after:
> 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.
> What is "certain source code"?
The OP seems to be GrapheneOS, which heavy patches AOSP.
I guess the context is Android source code and its security patches.
> Why is the OP being so coy about describing the problem?
Not sure what you mean, I think they are explicit enough.
I guess it's clear enough for developers how an upstream update should go.
If people depend on big projects like AOSP, devs should be prompt in delivering source code, especially when it is mandatory by license.
Can you give us more details on how/why you think the OP is being coy?
It isn't about AOSP but rather the Pixel OS. Android 16 dropped support for Pixels from AOSP but we're still entitled to receiving the subset of the code derived from GPL/LGPL projects. We need the Pixel kernel driver sources for each stable and beta release. We're entitled to getting those in a reasonable amount of time. Weeks of delays is not reasonable for one of the largest tech companies in the world.
They could simply share a folder with us and put all of the releases in that folder so we don't need to request each release. They're going out of the way to make it difficult by requiring us to separately request it for every single release we want. Initially, it was consistently provided in under a business day. Recently, they've regularly been taking weeks or more to provide it. It's likely going to take longer now that more people are aware of it since they're going to receive more requests for it. They could simply push it to a repository on GitHub instead of assigning employees to do this manually. If for some reason they don't want to do that, they could at least automate it. For example, they could give us access to a folder with all the releases. Needing to request every single release tag is ridiculous.
It applies to anything Google releases based on Android without pushing tags to AOSP for that fork of the code. It isn't a limited set of products but rather everything they make based on it. It applies to Android Wear, Android TV, Pixel phones and anything else not pushed to AOSP. We aren't being specific since we don't know everything they release based on Android. If they release a Beta emulator image for an upcoming version of Android without pushing tags, it applies to that too.
Google used to push all of the Pixel code from AOSP to it every month. They now only push AOSP releases intended to be used by other OEMs. That means they went from pushing each monthly, quarterly and yearly release of Android shipped by Pixels to only pushing 2 major releases per year (yearly release and QPR2) which are the only major releases used by other OEMs. They also provide security backports to those 2 major releases. They're still obligated to give us the GPL/LGPL licensed code for each Pixel OS release.
Google sold the Pixel 6 through Pixel 9a as being AOSP reference devices with 5-7 years of support from launch. They should be pushing the AOSP releases for those devices each month to fulfill their update commitment. GPL compliance is a clear legal requirement, but we think there's more than that too. Pixel 10 and later were not launched as AOSP reference devices since this changed was already made, so sure they have no obligation to provide anything beyond GPL code for those.
We didn't want to explain all this in our thread but we did explain it has to do with Pixels. It isn't only the kernel drivers. It's also the assorted set of stuff within the OS that's GPL/LGPL beyond that. There's more than there used to be since they moved to the OpenJDK libraries during the Oracle lawsuit.
I don't think they are? They could just as easily require requests for the source code to be made through the regular mail instead of a Google form. It's still (maliciously) compliant with the license.
If filling out the source code request form via Google Forms and/or accessing the download link via Google Drive requires the requester to run non-free (or at least non-GPLv2) JavaScript, then maybe it is in violation of section 6 of the GPLv2 ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein") since the requester is then required to accept an entirely different set of licensing terms and conditions.
Yeah, I agree. While this is a terrible move IMHO, from my superficial reading of the GPLv2 it doesn't really constitute a violation: the license imposes that the source be distributed to anyone who asks, potentially even charge a fee to cover its distribution costs, but it doesn't require that development happen in the open.
I mean, the only way to test this is to require of Google here to release the source code. And then look at how a court will evaluate it. For instance, what if Google never sends the source code? What if they claim that no request made it in? Though I guess this can be ensured, e. g. via letter that is registered being sent and then looking at Google's response to it.
So right now I think we all probably do not know. Google MIGHT refuse to release the source code, but it could release it - we don't know yet. Someone has to test that.
> For instance, what if Google never sends the source code? What if they claim that no request made it in?
That would be a violation of the license terms. All Google has done so far is, apparently, to make it hella annoying to access the source code (but not impossible).
It's not a customary fair of distributing software and it's not in the preferred form used by the build system which expects Git repositories. GPL not defining a time limit to comply also doesn't mean there isn't a reasonable limit on compliance time. Google is more than capable of quickly complying. It comes down to whether a judge would think what they're doing is reasonable and we don't think they would.
My guess is that all their code is in their monorepo (google3), and they don't want to set up a tool to sync it to a public git repo, so the easiest way is just to have someone create a tarball on demand.
Can’t imagine Google is making the process of obtaining source code easier on themselves though.
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.
Everything else is essentially all the work of Google and (to some extent) Samsung.
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.
We said artificially delaying it for weeks or more is how they're violating it, not using Google Drive. It's also not provided in the preferred form for modification. It isn't in the form expected by the build system and causes it to not function in the way it did for their own builds.
Well to be fair you didn't say that in the linked tweet. Delay is bad too, but again the original spirit of the license was absolutely OK with the idea of weeks-long delays. Our modern world of instant github access has spoiled us, but courts are not going to see damages from just "we had to ship a month late" unless you can show something more specific.
It's required for providing timely security patches. It's not hard to show why that's important and Google engineers have written plenty about it for us to cite. We've managed to avoid delays for security patches so far through reverse engineering and other workarounds. Having to invest time from developers paid to work on GrapheneOS in reverse engineering compiled GPLv2 code shows Google is violating the GPLv2.
Delay is frustrating, but not a violation. Just because you reverse engineered GPLv2 code doesn’t make that in violation of GPLv2, many people have done that for reasons that rhyme with yours over the decades. GPLv2 also doesn’t have any clause about security patches or if you have a requirement for a certain timeline. GPLv2 isn’t a “you agree to not be an asshole” license.
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 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.
> 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?
The word “easily” sure did sneak into this sentence
GrapheneOS is arguing that however many commits squashed into a messy tarball are not the "preferred form of the work for making modifications", and that Google Drive is not a "medium customarily used for software interchange". I think that's true.
If distributing under 3(b) then it's legitimate to only supply source on request. Historically source has been distributed without revision control history or metadata and been considered acceptable (the source tarballs on gnu.org are snapshots, for instance) so I think the preferred form argument is also tricky. I agree that there's huge value in having the individual commits, but from a GPL perspective we had this argument when Red Hat started flattening all patches in the RHEL kernel source 15 years ago.
I've been wondering about the Red Hat model! Seems like so much of modern development involves git blame or whatever to make sense of how the code came to be, and sometimes rule out an "obvious" modification that actually turns out to be a bad idea now that you know the historical context.
I don't know what "Red Hat model" you mean, but if you're referring to their code delivery: It's not a problem for their internal developers, because they can use git lol. You can theoretically go to the upstream projects individually and merge the code drop with their nearest branch, and THEN do git blame/diff to figure out the delta and history of some lines of code. There are probably a few upstream open-source projects out there with no public VCS, but those are rare.
When the build system expects a certain metadata which is removed by the force pushes or tag removal, then that is arguably not the preferred form. Grapheneos notes this elsewhere in the thread. [1]
It's an impossible stretch and also a bad idea. Insisting on that interpretation opens up other issues. Revision history may not be available in some cases for various reasons, such as if one pays someone for a large contribution. We could get into arguments about how granular commits need to be to comply with publication requirements. Digital achives containing source code files are certainly customary and easy to use, as opposed to reams of printouts. It would be just as customary and modern to publish on CD and mail the stuff out to anyone who demands the code. Continuous or timely delivery is not guaranteed by the license. One week of wait time is actually reasonable for a process like this, though I expect it might gradually get worse in line with their long-term objective of making the entire thing painful for outside developers.
Tarballs certainly aren’t in violation of the GPL, via gnu.org own source distribution methodology. It would also be a very interesting legal claim that git metadata is required, and likely something already hashed out when the government decided that metadata isn’t the same as the underlying data.
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.
> We didn't have git tags when GPL was written in 1989
The GPLv2 requires "a medium customarily used for software interchange", not "a medium customarily used in 1989 for software interchange". Customs are the customs of the time someone is releasing the work.
“a medium customarily used for software interchange“
Interesting choice of cropping for that quote.
If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data. So it would exclude distributing source code on tape, or even optical discs, as nobody uses those anymore. About the only medium used for source code distribution these days is “the internet”
You could potentially stretch this to excluding google drive, though google will argue that the medium is http, not google drive; But you can’t stretch this to requiring it be formatted as git.
And even if you did manage to successfully argue that, google would just ship it as one (tagged) commit per release. The history would still be missing.
> If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data.
I can see your point. But OTOH if providing the "preferred form of the work for making modifications" requires at least not squashing commits into a big mess to frustrate someone trying to make sense of the code (which makes it harder to modify it!), and Google is internally using Git anyway to create those commits, then it seems to me like there's an argument to be made that the customary medium used to interchange a range of Git commits is Git.
Yeah, that argument is much better; Maybe they are violating it.
What that part of the GPL does absolutely forbid is stripping out the comments from the source code, or only shipping generated source files (but not the code which generated it).
And arguably, git history is much of the same thing as comments. Especially when we have IDEs that can be configured to give us easy access to blame to help us understand the code.
The fact that commit history is not inline with the source code (or even stored as human readable files) makes it a little harder to see that git history could be considered to be part of the source code, and I do wonder where this argument stops? Should the contents of bug trackers and PRs be considered to be part of the source code? What about design documents?
GPL says we need to be provided with the preferred form for modification. Those are the Git repositories for Android source code.
For Pixel kernel drivers, Google is converting the source code from the preferred form of dozens of Git repositories to a massive monolithic tarball. The build system used for this code expects it to be a bunch of Git repositories and spews out errors without it. It does build the code but it isn't the build process they used to do it themselves which is non-compliance. We need to be provided with what is needed to build it in the same way they built it.
> 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.
It's about the Pixel kernel drivers and build system. The source code for the base kernel tree itself is still part of AOSP. Everything related to Pixels is no longer being pushed to AOSP.
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 are meant to use the yearly and QPR2 releases along with the security backports to those so that's all they push. The monthly and QPR1/QPR3 releases aren't used by their OEM partners so they stopped pushing them to AOSP. Those no longer being pushed is because of them deciding AOSP doesn't support Pixels anymore.
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.
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.
It's not AOSP but rather Pixels. Pixels are no longer support by AOSP. They went out of the way to no longer push any of the Pixel specific repositories or releases to AOSP. The impact is mainly that Pixels are now harder to support than a lot of other devices rather than easier. They'll sell far fewer Pixels over time because of these decisions.
I didn't know Pixel maintained its own kernel patches. And if there is a delay in providing that code to Pixel buyers, from my perspective, that looks like a violation of the GPL.
I think leadership in Google is getting worst day by day. The main reason to use Android is mostly sideloading and open source and they are trying to sabotage both.
It means Google is making it harder than it needs to be to obtain source code. It's a dick move, and the only plausible interpretations are that it will get harder still, and it's intended to slow down projects like GrapheneOS. Even if it can be lawyered to be in the letter of the open source licenses that apply, it's not in the spirit of those licenses.
If you're like me and struggled to parse the title, my understanding is, "To obtain certain source code from Google, you could previously reference git tags, but now you have to fill out a form and wait for a human to give you a google drive link."
Let's just forget about the tags, the point is that they're not publishing what Graphene OS needs on any git repository that they can access.
Even before that it had been jokes of repositories, but at least you didn't have to ask for someone every time and wait for them to respond to the request.
what does the license say? provide source when asked or publish source?
OSI is not clear on this either. ("Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, [...]")
Google became one of those OEMs that drag their feet and make it a hassle to publish the source code. This happens because they are not interested in open source Android anymore
I hate to be that guy but publishing source online for free theoretically involves unbounded distribution costs that can't be recovered. That isn't the issue here but it should be considered before changing a license.
Not from my perspective. I get free mapping anywhere on earth, with traffic information, and can route plan walking, cycling, driving, or public/private transport and likely journey times. I can search the world's web-published information. I'm using a powerful, relatively affordable mobile phone. I can watch anything anyone with a camera uploads to YouTube across the world. I can pay from my phone with a thumbprint verification only. I can take a photo of something and get back what it is and some information about it.
It's a generic license that doesn't say "by the way, if you've got a market cap above X then you have to host and distribute the code FOR FREE"... Putting such garbage in there would hurt small developers who made popular, nonprofit projects and probably anyone who isn't flush with cash. Imagine being legally obligated to host files in the middle of a DDoS attack, and pay the resulting AWS bill or whatever.
Let not forget that google heavily relies on opensource software.
The Linux kernel being the obvious one in this discussion, which they make extensive use of.
Google has servers inside ISP networks that distribute YouTube videos. They pay nothing for the distribution costs, I think they don’t even pay for electricity/cooling. If they wanted to distribute Android source code, they wouldn’t have to pay a dime.
Regardless of whether these costs are zero (I doubt they actually are), these licenses apply to EVERYONE who uses them, not just very wealthy companies. It would not be right to essentially require unbounded free hosting or use of specific online tools/platforms, just to be able to comply with the license.
Alas, the licences have become outdated and we haven't kept up, because most have played by the spirit of the rules up to this point. There is an expectation that source code will be readily available using modern tooling, like a version control system, but that's not what the licences actually require.
GPL requires that source code be in the preferred form for making modifications. If you use source control for your own modifications, then that's obviously the preferred form and you must distribute the source in that form.
That’s an ambitious interpretation. The preferred form for making modifications to the Linux kernel also involves having a build cache, but that’s clearly not required to remain GPL compliant.
I don't think the real focus is on the tags, but on the delay here via a form as well as human interaction.
Worded differently, the simplest way to provide the source code is IMO via a URL that you can just wget. At the least this is done by so many projects out there. Google refusing to do so means Google wants to violate the GPLv2, since their alternatives are inferior.
The license requires that it be distributed on a medium customarily used for software interchange, and I don't think you'd stand a good chance of arguing that paper satisfies that.
Unfortunately, I know more than a few companies who do that. The same kind of developer who used SourceSafe to just checkout the entire project (thus locking it) while busy with it. And then pop a intranetcrm_200826_0713.zip on SharePoint. Enough of them around still unfortunately.
No, and it doesn't even have to be provided for free as long as the price is reasonable with regard to the delivery costs. The GPL was made when mailing disks was a common way of delivering software and it is still a valid way to do it.
But the most important part is that once you have that source code, no one can stop you from redistributing it in a cheaper and more convenient way. It means that in theory, only a single person has to request the files, that person can then publish them in a public repository.
> "To obtain certain source code from Google, you could previously reference git tags, but now you have to fill out a form and wait for a human to give you a google drive link."
Couldn't simply someone mirror these Google Drive folders?
We also have mirrors of the QPR1 Beta and QPR2 Beta code there too.
It's not meant to be distributed as a tarball or a single Git repository. The build system runs Git commands to determine the revisions of each component. It's not supposed to in dozens of Git repositories. They provide repo metadata as part of the tarballs on Google Drive which you can see there but it's not a full replacement for the Git repository layout expected by builds. It's somewhat convenient having it in a monorepo but it's not the way it's supposed to be.
It would be nice if Google would simply push it to the Git repositories still available on AOSP again. The repositories still exist both internally and publicly but they're making it a hassle instead of simply pushing tags.
We publicly complained about these and other Pixel changes as they were ongoing and that directly led to our Motorola partnership. It was in Google's financial interest to work with us so we continue using Pixels and that's still the case. They're welcome to reach out to us and start collaborating again. We made a lot of upstream contributions and aren't their enemy.
Google should want more people to use their devices, apps and services. It shows how heavily they're violating antitrust laws by using monopolies to protect other monopolies when they sacrifice revenue for their devices and apps/services for it.
Doesn't their change break supply chain security on Google's end?
With git tags, presumably people spoke in terms of cryptographic hashes. Now what prevents them from serving different Google drive contents to different accounts?
If you feel so strongly that Google is working at odds with you why does your product only work on very expensive devices sold by Google? You are actively propping this company up. And I don't need to hear about the Motorola vaporware again, I'd like a real answer to this. Why are you making me shovel hundreds of dollars into Google's coffers to use GrapheneOS?
Maybe a naiive question, but couldn't you request the source code from phone companies? Say you request it from Xiaomi - sure they're not the original writers of the code, but they too "distributing GPL code" and therefore must release the code on request. They may be more amenable to your request since they have leverage with Google and are in an adversarial relationship
You can request anything from anyone, but compelling a company to follow their GPL obligations requires cooperation from the copyright holders + infinite funds for legal fees
“Couldn’t you just” couldn’t fucking GOOGLE, the don’t do evil corporation, support one of the few alternative mobile phone OSs use standard development tools, instead of being little shits?
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. Other OEMs are meant to use the yearly and QPR2 releases along with the security backports to those. Since they dropped Pixel support from AOSP, they don't push the releases not shipped by other OEMS anymore.
We were quietly unhappy about it for many months where they were responding within a day. They've recently been taking weeks or longer to get back to us for the requests. It's not a reasonable delay for one of the largest tech companies in the world. GPL doesn't set an official time to provide the sources but 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.
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 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.
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.
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 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.
> 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
> 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 by competitors. 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!!
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.
- 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?
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.
> 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.
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.
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.
Can't help but wonder if making it costly for themselves the entire point. So that they can later turn around and bill that distribution fee to the recipient.
Not the links per se (those are subject to terms of service), but the contents downloaded for those links are free to share. Anyone can throw them up in their own git repository or upload them to Github.
The era of big tech cooperation around free software is obviously over.
Those kind of moves are petty but there are worst tricks they can pull unfortunately.
It seems Grapheneos is the rare actor willing to put up a fight nowadays, and their "partnership" with Motorola seems to be a first step. They need to ensure a hardware platform.
My guess is at some point they will have to fork AOSP, just because Google will take it in directions that go against Grapheneos principles.
> My guess is at some point they will have to fork AOSP
I am still sad that Huawei didn't go this way, I thought they would with HarmonyOS.
I wonder if it could happen at some point that an alternative Android becomes so big that OEMs start supporting it. It feels like it may be interesting for the big Android manufacturers to support something like GrapheneOS?
I wonder: for those Motorola phones that will come with GrapheneOS, won't that make it cheaper for Motorola because they won't have to pay the Google licence (because those GrapheneOS-Motorola phone won't be Google-certified)?
> I wonder if it could happen at some point that an alternative Android becomes so big that OEMs start supporting it.
I think this is the huge battle GrapheneOS won with Motorola. There are probably a few manufacturers of phones unhappy or nervous regarding Google.
The next battle is really on the app front. Once a country says our government and bank apps need to run on the fork of AOSP then you will start to have a real alternative to the Google/Apple (and now Huawei) duopoly.
My guess is there are a lot of candidate countries for breaking out of the American/Chinese grab on every smartphones.
So in a way the future could look bright as long as we support GrapheneOS and Motorola.
> I wonder: for those Motorola phones that will come with GrapheneOS, won't that make it cheaper for Motorola because they won't have to pay the Google licence (because those GrapheneOS-Motorola phone won't be Google-certified)?
There's been no confirmation that any phones will come pre-installed with GrapheneOS from Motorola, just that some phones will be compatible.
My guess is Google is already applying pressure on Motorola to make sure every phone still ships with standard Android from the factory.
> Starting in 2027*, a silent update, nonconsensually pushed by Google, will block every Android app whose developer hasn't registered with Google, signed their contract, paid up, and handed over government ID.
I specifically use Android because of this, among other requirements, that Apple imposes on software development on their platform.
I do not own general purpose computers that I am not allowed to develop software for without permission. I have always avoided consoles for that reason as well (Steam Machine and other similar platforms would be fine, but I've been avoiding consoles for long enough that it's not something I really look for any more).
I was a major Apple fanboy up until the iPhone. Left the ecosystem after the iPhone and macOS started moving in that direction as well.
I'm going to miss having a smartphone that I can use with my banking and EV apps, but probably for the best to get out of Google's ecosystem. Hoping that GrapheneOS will still allow me to use some of the apps that I like.
Android has been a brutal disappointment on this front since the day it launched. Sure, you could hack various devices and spend too much time on xda-developers and get custom ROMs, but if you compare that to the openness of even a stock Windows PC it's an absolute joke. Android was supposed to be the open Linux phone, when I bought my HTC G1 full of hope; turned into an inferior iPhone wannabe with worse performance and a low quality walled garden that keeps most people in without keeping the trash out.
I switched to an iPhone last year, mostly because I was getting sick of Samsung’s shit, and google doesn’t sell their pixel phones locally (and I don’t like Oppo).
But the other reason is that most of Android’s openness is quickly disappearing, so my main argument against iPhone is gone. And on the topic of privacy, I actually trust Apple way more than I trust the company that makes most of their revenue via advertising.
Exactly this. Once the writing was on the wall that deGoogled / FOSS Android was on borrowed time (at best), a ton of the argument against iOS dissolved overnight. We can argue that Apple's anti-repair policies and anti-user-customization policies are their own evils, sure, but at least my phone works for its core tasks, and works phenomenally well at that. My deGoogled Android phones were mostly hobbled together piles of "it sometimes works, as long as I don't look at it too funny". This tradeoff was fine for fully owning my data and being able to install absolutely anything I wanted on my phone. With arbitrary APK installation disappearing, and unlocked bootloaders to install a less hostile fork of Android becoming such a rarity these days, I may as well at least not fear looking at my phone the wrong way when the moon is in alignment with the wrong star.
Source: about 12 years of Android usage (11 of those on unlocked bootloaders and custom ROMs, ~6? of those deGoogled) -> iPhone 16e.
For the first half, custom ROMs were a massive boost to the experience, but I never really bothered after 2018; You had to install so much of google's stuff to get a proper experience that it just wasn't worth it, and even then many apps were starting to throw a fit when they detected a rooted device.
And at the same time, the stock android experience from most vendors was now good enough. I didn't even check custom ROM compatibly for my last Android two purchases (both Samsung). But it was nice to have the option of rooting and maybe finding/making a custom ROM Samsung removed that in their last update to One UI :(
For me it's the data-hoovering. I don't want Samsung (or Google, or Xiaomi, or whoever) background services phoning home my location every few seconds, or being able to uniquely track my device across apps, etc.
Once my ability to run a "background spyware-less" Android device went away, so did my willingness to put up with the negative sides of the usability tradeoff.
Apple probably sends some telemetry home, but at least their business model doesn't depend on knowing the exact Pantone color of the food I ate for dinner to market a matching wall paint to me.
Edit to add: oh, yeah, you mentioning 3P apps complaining if they detected root or MicroG reminds me of many a horrible night of debugging. Ugh. What a mess.
> You had to install so much of google's stuff to get anywhere near proper experience that it just wasn't worth it
What was it? Personally, the only thing I miss from stock Android is the Google Wallet/Pay/Wallet. (I do use microG to get push notifications and embedded maps working.)
Apple already have a huge chunk of the ad pie and are growing all the time. Dont think Apple are keeping you safe from ads and all the profiling of your behaviour that involves.
Apple are still far less reliant on advertising than google; They take far stricter stances against apps tracking users than google; And they actually let me an Adblock extension (or any other extension) in Safari.
Apple is not some magic solution to the question of on-device privacy. But compared to Android, the improvement is night and day.
yes and Apple does it for the 30% lock-in. Apple does it to protect their ecosystem. Apple also does not care about their customers, their developers, their suppliers or their employees. Closed systems do not help the populous. This is about money, captive audience and subscription revenues.
Yes, and this is the reason that many of us have not, and will not, ever buy an Apple product. They are the ultimate technodictators, and their products are only for people who like to trade their freedom for moderate convenience.
Google's upcoming change means Google Mobile Services operating systems will show a warning for apps from unverified developers. Bypassing the warning will require a one-time 24 hour wait via the regular user interface. It can be immediately bypassed using Android Debug Bridge instead.
Developers with Play Store apps are already verified. It's counterproductive for app developers with existing Play Console accounts considered verified to refuse to register their apps distributed outside of the Play Store. That would encourage users to stick to the Play Store.
The problem is for developers without a Play Console account who would need to register and verify their identify to avoid their apps showing a warning. If people are already registered, they might as well list their apps distributed outside the Play Store to avoid the warning.
> Any word as to whether this will apply to GrapheneOS? If I had to choose, I'd block apps that did comply with this BS.
I doubt it, considering Android developer verification will go through Google Play Services, which GrapheneOS has siloed off from most of the OS as far as I'm aware.
Man, all of these little steps Google is taking to take the control away from the users, not to take over the world or anything else, but to force on you more accurate advertisements. What are we even doing?
Well Google is becoming worse every year, but AOSP is way ahead of Linux on Mobile, for many reasons.
The thing is, AOSP is open source. Just like Linux is not controlled by one of the TooBigTechs, I could imagine a fork of AOSP becoming a viable alternative without depending on Google anymore.
And supporting alternative Android OSes (like GrapheneOS and LineageOS) is one way to support that vision.
Linux on Mobile is nice, but unfortunately I think it's an uphill battle because of all the proprietary firmwares?
> but unfortunately I think it's an uphill battle because of all the proprietary firmwares?
In my GNU/Linux phone, all drivers are FLOSS and all pieces of firmware are backed into the replaceable peripherals (modem M.2 card and WiFi M.2 card).
I feel like supporting Android alternatives is also fighting for my rights. Isn't it?
And again, I'm really impressed by all the work done by the Linux on Mobile projects. I'm just saying it's an uphill battle, and it's nowhere close to any AOSP-based system.
One obstacle to making AOSP independent is the included apps. Last I knew they were overly basic and somewhat derelict because Google has long been favoring their own closed source counterparts, and third party manufacturers all ship their own (often kinda garbage) alternatives.
Not insurmountable at all, building decent apps isn’t rocket science, but a substantial investment of time and energy nonetheless.
hanlon's razor comes to mind. which trees are these? weird device trees that have complicated third party licensing nonsense attached?
i remember jumping through crazy hoops to interact with a google open source project years ago. i wouldn't be surprised if it's just megacorp bureaucracy.
I really don't understand the thought process here.
Judging by public statements, Google is one of the 3 big western AI companies. Surely they should be rolling in cash and working hard towards AGI.
And yet, for whatever reason, they can't help themselves from further restricting user freedoms on Android. Why?
I don't want to be conspiratorial, but surely it's not money, right? It has to be control. Someone high up at Google just seems to resent people having control over their own devices.
Both. Google has plenty of government contracts, they are undoubtedly pushing for more surveillance, and also on the inverse side, we are now in an age where users can create their own apps to do whatever they want within a few hours, sothis risks their Google Play Store profits
I genuinely believe that any human getting enough power (e.g. by moving up in a big company) tends to become a toxic asshole (without even noticing themselves). So that's one explanation.
On top of that, I believe that the sum of the actions of well-meaning people doesn't always result in something good. In big companies like Google, I'm sure that many people are taking decisions that they think are well-meaning, but the result is that Google is a toxic entity.
In other words, because Google sucks doesn't mean that all Google employees are evil. Many of them just take their high salary and try to do well, conveniently ignoring that they contribute to a toxic entity.
This is a direct consequence of their loss to Epic. They saw Apple win because they didn't have any competition to stifle, and they want the same. Pretty shit.
Many commenters agree this is not a nice move by google.
But is there any reason that google might have that they feel is legitimate?
For example, delaying releasing source until they've had a chance to update all the pixels with security patches might be good from their perspective, to reduce zero-day exploits for people they are supporting.
So all the non-pixel-specific stuff is in a publicly accessible repo? So the pixel team just decided that they wanted to keep their kimono mostly closed?
Yes, but that’s the only reference android device, so the whole ecosystem is getting pretty close to completely locked down. Google is going to require devs to register, pay and get permission to publish Android software sometime next year. Locking pixel owners out of third party operating systems means they get to force pixel owners to hand control over their devices and applications to Google.
The motorola / GrapheneOS partnership gives me some hope though. Maybe when the pendulum swings back in 2028, the US will pass consumer protection laws, and we’ll have the right to import devices that allow open ROMs, and demand they be supported by cell networks.
(I doubt the moderate democrats would support this, but I’d guess the DSA candidates could be convinced to.)
Google's intent is to make web development and mobile development so complex that you have to rely on their browser or other means to get anything done.
287 comments
[ 1.9 ms ] story [ 128 ms ] threadI am very thankful linux is gpl. Because of GPL these tech giants are forced to release source code.
Google helped lobby the FSF to adopt GPLv3, which bans tivoization, but allows software as a service.
This is why you cannot have bash on MacOS, but Google can still use it to build surveillance capitalism, and arbitrarily enshittify your word processor.
Here is the form:
https://source.android.com/opensourcerequest
This is interesting:
> We might charge you a fee to cover the cost of processing. Your request must be sent according to whichever of the following rules applies:
> Within three years of the date you received the product from Google that included the component or binary files that are the subject of your request.
That "three years" is the minimum named in the GPLv2: https://opensource.org/license/gpl-2.0
> What is "certain source code"? The OP seems to be GrapheneOS, which heavy patches AOSP. I guess the context is Android source code and its security patches.
> Why is the OP being so coy about describing the problem? Not sure what you mean, I think they are explicit enough. I guess it's clear enough for developers how an upstream update should go. If people depend on big projects like AOSP, devs should be prompt in delivering source code, especially when it is mandatory by license.
Can you give us more details on how/why you think the OP is being coy?
They could simply share a folder with us and put all of the releases in that folder so we don't need to request each release. They're going out of the way to make it difficult by requiring us to separately request it for every single release we want. Initially, it was consistently provided in under a business day. Recently, they've regularly been taking weeks or more to provide it. It's likely going to take longer now that more people are aware of it since they're going to receive more requests for it. They could simply push it to a repository on GitHub instead of assigning employees to do this manually. If for some reason they don't want to do that, they could at least automate it. For example, they could give us access to a folder with all the releases. Needing to request every single release tag is ridiculous.
Google used to push all of the Pixel code from AOSP to it every month. They now only push AOSP releases intended to be used by other OEMs. That means they went from pushing each monthly, quarterly and yearly release of Android shipped by Pixels to only pushing 2 major releases per year (yearly release and QPR2) which are the only major releases used by other OEMs. They also provide security backports to those 2 major releases. They're still obligated to give us the GPL/LGPL licensed code for each Pixel OS release.
Google sold the Pixel 6 through Pixel 9a as being AOSP reference devices with 5-7 years of support from launch. They should be pushing the AOSP releases for those devices each month to fulfill their update commitment. GPL compliance is a clear legal requirement, but we think there's more than that too. Pixel 10 and later were not launched as AOSP reference devices since this changed was already made, so sure they have no obligation to provide anything beyond GPL code for those.
We didn't want to explain all this in our thread but we did explain it has to do with Pixels. It isn't only the kernel drivers. It's also the assorted set of stuff within the OS that's GPL/LGPL beyond that. There's more than there used to be since they moved to the OpenJDK libraries during the Oracle lawsuit.
I don't think they are? They could just as easily require requests for the source code to be made through the regular mail instead of a Google form. It's still (maliciously) compliant with the license.
If filling out the source code request form via Google Forms and/or accessing the download link via Google Drive requires the requester to run non-free (or at least non-GPLv2) JavaScript, then maybe it is in violation of section 6 of the GPLv2 ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein") since the requester is then required to accept an entirely different set of licensing terms and conditions.
Get a large brigade of android users to request access to source on each security update.
So right now I think we all probably do not know. Google MIGHT refuse to release the source code, but it could release it - we don't know yet. Someone has to test that.
That would be a violation of the license terms. All Google has done so far is, apparently, to make it hella annoying to access the source code (but not impossible).
Can’t imagine Google is making the process of obtaining source code easier on themselves though.
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.
Everything else is essentially all the work of Google and (to some extent) Samsung.
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.
There is plenty in Android which isn't the work of Google. For starters the Kotlin implementation and the Java implementation (OpenJDK).
(However, that's quite orthogonal to being a dick about making the source code that you must share available)
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.
I'm sure this means the source happens to be open rather than following the spirit of open source.
The word “easily” sure did sneak into this sentence
[1] https://news.ycombinator.com/item?id=49368983
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.
The GPLv2 requires "a medium customarily used for software interchange", not "a medium customarily used in 1989 for software interchange". Customs are the customs of the time someone is releasing the work.
Interesting choice of cropping for that quote.
If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data. So it would exclude distributing source code on tape, or even optical discs, as nobody uses those anymore. About the only medium used for source code distribution these days is “the internet”
You could potentially stretch this to excluding google drive, though google will argue that the medium is http, not google drive; But you can’t stretch this to requiring it be formatted as git.
And even if you did manage to successfully argue that, google would just ship it as one (tagged) commit per release. The history would still be missing.
I can see your point. But OTOH if providing the "preferred form of the work for making modifications" requires at least not squashing commits into a big mess to frustrate someone trying to make sense of the code (which makes it harder to modify it!), and Google is internally using Git anyway to create those commits, then it seems to me like there's an argument to be made that the customary medium used to interchange a range of Git commits is Git.
What that part of the GPL does absolutely forbid is stripping out the comments from the source code, or only shipping generated source files (but not the code which generated it).
And arguably, git history is much of the same thing as comments. Especially when we have IDEs that can be configured to give us easy access to blame to help us understand the code.
The fact that commit history is not inline with the source code (or even stored as human readable files) makes it a little harder to see that git history could be considered to be part of the source code, and I do wonder where this argument stops? Should the contents of bug trackers and PRs be considered to be part of the source code? What about design documents?
For Pixel kernel drivers, Google is converting the source code from the preferred form of dozens of Git repositories to a massive monolithic tarball. The build system used for this code expects it to be a bunch of Git repositories and spews out errors without it. It does build the code but it isn't the build process they used to do it themselves which is non-compliance. We need to be provided with what is needed to build it in the same way they built it.
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.
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 are meant to use the yearly and QPR2 releases along with the security backports to those so that's all they push. The monthly and QPR1/QPR3 releases aren't used by their OEM partners so they stopped pushing them to AOSP. Those no longer being pushed is because of them deciding AOSP doesn't support Pixels anymore.
> 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.
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.
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.
Well,large parts of the linux kernel are emphatically not the work of google, of course.
And I don't doubt there's tons of other software in android that originates outside of google.
Which makes it that they are at least violating the spirit of the GPL.
https://news.ycombinator.com/item?id=49369087
We mirror the source code on GitLab. We put the upstream 17 code in the 17-base branch and our code on top of it in the 17 branch:
https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base
https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b...
We also have mirrors of the QPR1 Beta and QPR2 Beta code there too.
Even before that it had been jokes of repositories, but at least you didn't have to ask for someone every time and wait for them to respond to the request.
(that's my understanding)
OSI is not clear on this either. ("Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, [...]")
Worded differently, the simplest way to provide the source code is IMO via a URL that you can just wget. At the least this is done by so many projects out there. Google refusing to do so means Google wants to violate the GPLv2, since their alternatives are inferior.
https://distrowatch.com/ has many convenient links to URLs on the left side; I often use that to download the latest and greatest and compile it away, e. g. https://ftp.isc.org/isc/bind9/9.20.27/bind-9.20.27.tar.xz as a current example, taken from the left panel.
Not an expert in GPL, but does it say that the source code needs to be provided by a url?
Also, the OP did mentioned that Google also squashed the git commit to a single commit for whatever reason.
Would be interesting to see the court case where they argued the printed sheets machine need a bulb because of OCR!
But the most important part is that once you have that source code, no one can stop you from redistributing it in a cheaper and more convenient way. It means that in theory, only a single person has to request the files, that person can then publish them in a public repository.
Or vice-versa: you're free to sell publicly available free stuff.
https://www.gnu.org/philosophy/selling.html
It's not customary to mail software on disks anymore so it doesn't fulfill the GPL anymore.
I doubt Google is distributing the Android code to third party OEMs that way.
Judge would be like 'Mr Counsel, where does it say that what Google did violated the law'
Couldn't simply someone mirror these Google Drive folders?
https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base
https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b...
We also have mirrors of the QPR1 Beta and QPR2 Beta code there too.
It's not meant to be distributed as a tarball or a single Git repository. The build system runs Git commands to determine the revisions of each component. It's not supposed to in dozens of Git repositories. They provide repo metadata as part of the tarballs on Google Drive which you can see there but it's not a full replacement for the Git repository layout expected by builds. It's somewhat convenient having it in a monorepo but it's not the way it's supposed to be.
It would be nice if Google would simply push it to the Git repositories still available on AOSP again. The repositories still exist both internally and publicly but they're making it a hassle instead of simply pushing tags.
We publicly complained about these and other Pixel changes as they were ongoing and that directly led to our Motorola partnership. It was in Google's financial interest to work with us so we continue using Pixels and that's still the case. They're welcome to reach out to us and start collaborating again. We made a lot of upstream contributions and aren't their enemy.
Google should want more people to use their devices, apps and services. It shows how heavily they're violating antitrust laws by using monopolies to protect other monopolies when they sacrifice revenue for their devices and apps/services for it.
With git tags, presumably people spoke in terms of cryptographic hashes. Now what prevents them from serving different Google drive contents to different accounts?
We were quietly unhappy about it for many months where they were responding within a day. They've recently been taking weeks or longer to get back to us for the requests. It's not a reasonable delay for one of the largest tech companies in the world. GPL doesn't set an official time to provide the sources but 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.
Edit:
> With One UI 8, Samsung removed the OEM-unlocking capability globally,
> Samsung uses a physical Knox Warranty Bit/e-fuse. Loading unofficial software can permanently trip it.
This seems far worse than google releasing source slowly
A partnership was announced earlier this year, but no devices will be delivered until 2027.
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.
Fairphone have just announced direct sales within the past week or so (noted by others here).
I wonder actually what a court would say here and if "doesn't set a time limit" could mean "the source needs to be made available immediately". IANAL.
Not that the intent of a license can be enforced.
Someone just needs to be crazy enough to sue (and rich/lucky enough to win)
Why can't it? A license is not just a piece of text but a meeting of minds.
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.
<https://www.gnu.org/licenses/gpl-3.0.en.html>
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.
<https://source.android.com/docs/setup/contribute/licenses>
Genuinely asking: are you a lawyer?
Sounds to me that going from "it works easily and rapidly" to this deserves a big big fine. That's the only thing they understand.
Which brand and model is currently best supported by GrapheneOS, if I want to buy an Android device to run GrapheneOS on?
So you'll have to wait for the mentioned Motorola Flagship
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.
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 by competitors. 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.
Maybe a lawsuit would change things?
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...
> 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!!
2 questions:
(Former iOS user.)
Was considering a Pixel 11 Pro, just cancelled it. Will wait for the Moto release. Thanks for your work!
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”)
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.
Don't get me wrong, I still think this is shitty behavior from Google.
"b) Accompany it with a written offer, valid for at least three years, to give any third party,..."
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.
If someone on HN has received one of these links, feel free to post it here.
But I would think the link is access to google's servers, which might be different.
Those kind of moves are petty but there are worst tricks they can pull unfortunately.
It seems Grapheneos is the rare actor willing to put up a fight nowadays, and their "partnership" with Motorola seems to be a first step. They need to ensure a hardware platform.
My guess is at some point they will have to fork AOSP, just because Google will take it in directions that go against Grapheneos principles.
I am still sad that Huawei didn't go this way, I thought they would with HarmonyOS.
I wonder if it could happen at some point that an alternative Android becomes so big that OEMs start supporting it. It feels like it may be interesting for the big Android manufacturers to support something like GrapheneOS?
I wonder: for those Motorola phones that will come with GrapheneOS, won't that make it cheaper for Motorola because they won't have to pay the Google licence (because those GrapheneOS-Motorola phone won't be Google-certified)?
I think this is the huge battle GrapheneOS won with Motorola. There are probably a few manufacturers of phones unhappy or nervous regarding Google.
The next battle is really on the app front. Once a country says our government and bank apps need to run on the fork of AOSP then you will start to have a real alternative to the Google/Apple (and now Huawei) duopoly.
My guess is there are a lot of candidate countries for breaking out of the American/Chinese grab on every smartphones.
So in a way the future could look bright as long as we support GrapheneOS and Motorola.
There's been no confirmation that any phones will come pre-installed with GrapheneOS from Motorola, just that some phones will be compatible.
My guess is Google is already applying pressure on Motorola to make sure every phone still ships with standard Android from the factory.
> Starting in 2027*, a silent update, nonconsensually pushed by Google, will block every Android app whose developer hasn't registered with Google, signed their contract, paid up, and handed over government ID.
Google claims an openness that doesn’t exist anymore
I do not own general purpose computers that I am not allowed to develop software for without permission. I have always avoided consoles for that reason as well (Steam Machine and other similar platforms would be fine, but I've been avoiding consoles for long enough that it's not something I really look for any more).
I was a major Apple fanboy up until the iPhone. Left the ecosystem after the iPhone and macOS started moving in that direction as well.
I'm going to miss having a smartphone that I can use with my banking and EV apps, but probably for the best to get out of Google's ecosystem. Hoping that GrapheneOS will still allow me to use some of the apps that I like.
Time to start over.
But the other reason is that most of Android’s openness is quickly disappearing, so my main argument against iPhone is gone. And on the topic of privacy, I actually trust Apple way more than I trust the company that makes most of their revenue via advertising.
Source: about 12 years of Android usage (11 of those on unlocked bootloaders and custom ROMs, ~6? of those deGoogled) -> iPhone 16e.
For the first half, custom ROMs were a massive boost to the experience, but I never really bothered after 2018; You had to install so much of google's stuff to get a proper experience that it just wasn't worth it, and even then many apps were starting to throw a fit when they detected a rooted device.
And at the same time, the stock android experience from most vendors was now good enough. I didn't even check custom ROM compatibly for my last Android two purchases (both Samsung). But it was nice to have the option of rooting and maybe finding/making a custom ROM Samsung removed that in their last update to One UI :(
Once my ability to run a "background spyware-less" Android device went away, so did my willingness to put up with the negative sides of the usability tradeoff.
Apple probably sends some telemetry home, but at least their business model doesn't depend on knowing the exact Pantone color of the food I ate for dinner to market a matching wall paint to me.
Edit to add: oh, yeah, you mentioning 3P apps complaining if they detected root or MicroG reminds me of many a horrible night of debugging. Ugh. What a mess.
What was it? Personally, the only thing I miss from stock Android is the Google Wallet/Pay/Wallet. (I do use microG to get push notifications and embedded maps working.)
Apple already have a huge chunk of the ad pie and are growing all the time. Dont think Apple are keeping you safe from ads and all the profiling of your behaviour that involves.
https://www.businessinsider.com/apple-gets-serious-about-its...
https://www.wired.com/story/apple-is-an-ad-company-now/
https://www.bbc.co.uk/news/business-67417987
https://www.businessinsider.com/apple-tests-ai-app-store-ads...
Apple is not some magic solution to the question of on-device privacy. But compared to Android, the improvement is night and day.
yes and Apple does it for the 30% lock-in. Apple does it to protect their ecosystem. Apple also does not care about their customers, their developers, their suppliers or their employees. Closed systems do not help the populous. This is about money, captive audience and subscription revenues.
Google's upcoming change means Google Mobile Services operating systems will show a warning for apps from unverified developers. Bypassing the warning will require a one-time 24 hour wait via the regular user interface. It can be immediately bypassed using Android Debug Bridge instead.
Developers with Play Store apps are already verified. It's counterproductive for app developers with existing Play Console accounts considered verified to refuse to register their apps distributed outside of the Play Store. That would encourage users to stick to the Play Store.
The problem is for developers without a Play Console account who would need to register and verify their identify to avoid their apps showing a warning. If people are already registered, they might as well list their apps distributed outside the Play Store to avoid the warning.
I doubt it, considering Android developer verification will go through Google Play Services, which GrapheneOS has siloed off from most of the OS as far as I'm aware.
The thing is, AOSP is open source. Just like Linux is not controlled by one of the TooBigTechs, I could imagine a fork of AOSP becoming a viable alternative without depending on Google anymore.
And supporting alternative Android OSes (like GrapheneOS and LineageOS) is one way to support that vision.
Linux on Mobile is nice, but unfortunately I think it's an uphill battle because of all the proprietary firmwares?
In my GNU/Linux phone, all drivers are FLOSS and all pieces of firmware are backed into the replaceable peripherals (modem M.2 card and WiFi M.2 card).
"It's good enough for me" is not the same as "it is comparable to Android".
> And would you say you have access to all the hardware features supported by Android?
No. GNU/Linux phones require compromises. Fighting for your rights does as well.
You really are the revolutionary hero in this story, aren't you?
And again, I'm really impressed by all the work done by the Linux on Mobile projects. I'm just saying it's an uphill battle, and it's nowhere close to any AOSP-based system.
Not insurmountable at all, building decent apps isn’t rocket science, but a substantial investment of time and energy nonetheless.
i remember jumping through crazy hoops to interact with a google open source project years ago. i wouldn't be surprised if it's just megacorp bureaucracy.
Judging by public statements, Google is one of the 3 big western AI companies. Surely they should be rolling in cash and working hard towards AGI.
And yet, for whatever reason, they can't help themselves from further restricting user freedoms on Android. Why?
I don't want to be conspiratorial, but surely it's not money, right? It has to be control. Someone high up at Google just seems to resent people having control over their own devices.
I don't get it, are the government contracts somehow contingent on them oppressing users and stifling open source?
>we are now in an age where users can create their own apps to do whatever they want within a few hours, sothis risks their Google Play Store profits
If that's the reason, they're doing a pretty poor job, since it's trivially bypassable by running "adb install".
I am so thankful that the PC revolution happened way before app stores and there was a period of open source culture and open formats etc.
On top of that, I believe that the sum of the actions of well-meaning people doesn't always result in something good. In big companies like Google, I'm sure that many people are taking decisions that they think are well-meaning, but the result is that Google is a toxic entity.
In other words, because Google sucks doesn't mean that all Google employees are evil. Many of them just take their high salary and try to do well, conveniently ignoring that they contribute to a toxic entity.
But is there any reason that google might have that they feel is legitimate?
For example, delaying releasing source until they've had a chance to update all the pixels with security patches might be good from their perspective, to reduce zero-day exploits for people they are supporting.
Ransomware gangs, etc still get red carpet service.
The motorola / GrapheneOS partnership gives me some hope though. Maybe when the pendulum swings back in 2028, the US will pass consumer protection laws, and we’ll have the right to import devices that allow open ROMs, and demand they be supported by cell networks.
(I doubt the moderate democrats would support this, but I’d guess the DSA candidates could be convinced to.)