They stopped pushing tags for any of the Pixel kernel or userspace driver repositories to AOSP. They also stopped pushing AOSP releases specific to Pixels which is why AOSP now only gets yearly releases, QPR2 releases and security backports to both of those. Other OEMs use the yearly and theoretically also the QPR2 releases. Both the yearly and QPR2 releases get monthly security backports. Since they dropped Pixel support from AOSP, they don't push the releases not shipped by other OEMs anymore.
These changes directly led to our Motorola partnership. One of their security people reached out to us after seeing our posts about this with the launch of Android 16. We haven't talked about it much since then since we adapted to it during the several weeks it delayed our Android 16 port. We then continued adapting to it and have fully worked around it. It was an ongoing problem but not a new one and we had accepted we had to deal with it as the new normal.
They were previously responding to our kernel source requests within a day. It was often done without hours. Despite the archaic system, this part wasn't that bad. Recently, they've been taking weeks or longer to get back to us for the requests which is ridiculous. It's the direct result of purposely adding a lot of friction with manual handling of the requests even if the delays weren't directly planned by management.
Weeks or months of delay is not reasonable for one of the largest tech companies in the world. GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely. They need to do it in a reasonable amount of time. What's reasonable for one of the largest tech companies in the world in 2026 with current technology is not the same as what was reasonable 30 years ago. Google chose to come up with a archaic way of distributing the sources involving someone manually going through a list and sharing Google Drive access. It's a deliberate way of making it painful. If they can't keep up with it and it gets delayed for weeks or months then they're not complying with the GPL by not providing it in a reasonable amount of time. Law is not code and a time limit not being explicitly written down doesn't mean there isn't a limit to what's reasonable for compliance.
They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels. We helped them fix serious security weaknesses for Pixels including vulnerabilities being exploited in the wild by forensic data extraction companies. Pixel security with the stock OS would be worse without GrapheneOS.
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.
> 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!!
> They need to do it in a reasonable amount of time.
If they did that for years within hours and if we look at the tools available today, I would expect that "reasonable" equates to how they provided it prior: fast.
They did it for many years with 0 delay because they pushed the tags to AOSP. It was moved to Google Drive with a Google Forms setup to request access with manual fulfillment of the request. It was deliberately done to make it into a hassle. The delays are by design through making it a manual system regardless of how much of a delay was intended as part of this change. They could be automatically handling the requests especially from people who have already been given sources for a product. They're deliberately making it take substantially more work on their end to make it into more of a hassle.
I was involved in one of the communities involved in the Block Sidewalk efforts in Toronto Canada, which prevented Sidewalk Labs from moving forward on a multi-billion dollar project to redevelop a chunk of downtown Toronto.
I was at the Data Power 2017 conference in Ottawa where I shared with people (who would become key Block Sidewalk organizers) the clues I had, that Google was about to bid on the as-yet-unknown land development opportunity, closing later that month.
I had previously been in collaboration with secure ROM developers hitting their first adversarial efforts to thwart use of Android for alt app markets. I know that Google's public story of Android openness (which drove people trusting them to build a city platform) was bullshit, and I made sure many many of the key activists and public servants knew it.
While I can't know exactly how my specific actions affected things, I would guarantee that Google's adversarial positions and failed stewardship have already contributed to them losing real opportunities.
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.
> They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels.
Which brand and model is currently best supported by GrapheneOS, if I want to buy an Android device to run GrapheneOS on?
Only Pixels, most other device are ironically locked down a lot more (not allowing custom keys for verified boot) or lack modern security features (like hardware security modules).
So you'll have to wait for the mentioned Motorola Flagship
Well, it's as you wrote: they are making the source available, albeit in a very inconvenient way, and because there is no time limit specified, they're complying with the letter of the GPL (although not with its spirit), so you can't even realistically sue them. And the number of people who buy new Pixels to immediately install GrapheneOS on them is (no offense) negligible, so I don't think they'll see a sales impact from it...
Which is not to say that I'm on Google's side, this is absolutely a dick move from them, and they wouldn't have done it 20 or even 10 years ago, but today's Google is definitely no longer the "don't be evil" company.
Not in the preferred form for modification expected by the build system and not in a reasonable amount of time. It's artificially delayed with no legitimate reason.
> And the number of people who buy new Pixels to immediately install GrapheneOS on them is (no offense) negligible
Nearly all of our current users bought a device specifically to install GrapheneOS. Our current userbase is around 500k and many of those are users had one or more earlier devices with GrapheneOS. Our userbase is rapidly growing. Look up how many Pixels are actually sold in a year. It's not negligible at all.
There are also many large companies wanting GrapheneOS devices with official support from the OEM.
Sorry, I stand corrected: Despite owning a Pixel 9 Pro myself, I didn't realize Google's Android phones market share was so tiny (1.1%! according to https://www.appbrain.com/stats/top-manufacturers). In that case, of course, the number of Pixels bought because of GrapheneOS could be a significant fraction.
That’s 1.1% of ~1.1-1.2B Android phones sold per year. I dont’t know how long the average GrapheneOS user holds on to their device, but if 25% of them per year buy a new phone (rather than upcycling a used one or using their previous phone another year), that would amount to about 1% of Google’s annual sales at best.
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.
We need something other than Android, and we need the government to make sure we can run Android apps (like government ID and banking apps) without being spied on. They've been doing whatever the f they like for long enough if you ask me.
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
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.
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.
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.
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.
My personal website isn't customarily used for software interchange, but http is. I think getting into discussions about which websites are acceptable and which aren't feels like a bad place.
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.
1) floppy disks are not customarily used for software interchange - where they are still used (aircraft software updates, bits of San Francisco's streetcar infrastructure) it's weird enough to be remarked upon.
2) the cost to Google of finding enough working floppies and paying someone to dump that much code onto them, then mailing them out, then having the other end just say "disk 323 was corrupted by USPS X rays, please send again" 20 times, would massively outweigh the benefits of making this awkward
Mostly agreed. However you can solve the problem of having x% of disks corrupted via error correcting codes. It's what Google already does for their own internal storage: when you own millions of hard disks, some of them will inevitably fail.
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.
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.
GrapheneOS is arguing that throwing away the metadata of however many commits and squashing them into a messy tarball is not the "preferred form of the work for making modifications", and that a manual process where you have to fill out a form in order to get a Google Drive link a week later is not "a medium customarily used for software interchange" in current times. Those are quotes from the GPLv2.
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.
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]
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.
GrapheneOS might have a better case though if it's not just about understanding the code but about how the Android build system expects that everything is in Git.
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.
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.
Lack of a specific time limit in GPL doesn't mean there isn't one based on what's reasonable. What they're doing it not reasonable.
> Android has always been more source-open than “open source”.
This is about Pixels rather than AOSP. Google decided Pixels would no longer be supported by AOSP which is why they stopped pushing the kernel drivers, userspace drivers and other Pixel related code to AOSP. They moved to publishing kernel driver code via Google Drive after filling out a Google Forms submission. They're handling those manually. It's a ridiculous system and comes across as them wanting to make it a hassle on purpose. Perhaps that isn't the case and someone simply needs to make the decision to simply push Git tags somewhere else. They could put it on GitHub if the goal is disassociating it from AOSP.
We accepted the archaic new system while they were responding to requests in a reasonable time but that ended. It's now very inconsistent and is regularly getting delayed for weeks or more.
> The vast majority of community contributions that make it into the codebase are security fixes and small bug fixes.
Open source does not imply anything about accepting contributions. SQLite barely takes any contributions and the same applies to many projects. There were a lot more code contributions to AOSP than you're describing prior to recent changes with Android 16. It was relatively easy to contribute to the lower level parts of it.
Google are absolutely within the letter of the GPL, pedantically so. But maybe not the sprit.
We didn't have git tags when GPL was written in 1989, and while we did have sccs and rcs, (and early versions of cvs) they just weren't that widely used, and generally not used for distribution.
Even when GPL 3.0 was written in 2005-2007, source tarballs were still the primary form of distribution, even though it was starting to become standard to additionally provide anonymous cvs, svn, or one of the brand new distributed systems like git.
But these days git is the primary form of distribution, and source tarballs are noting more an afterthought. Hell, even tags are a bit of an afterthought on many projects. It's basically become the norm to expect an healthy revision history for any open source code.
Based on it's stated goals of "freedom to modify the software you use", IMO if the GPL was written (or updated) today, it would most likely require the distribution of revision history and restrict how much that history can be squashed/rewritten.
> 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 not squashing commits into a big mess to frustrate someone trying to make sense of the code (I'm sure the Google engineers making modifications prefer to look at individual commits!), and Google is 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 google are violating the GPL.
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/argue 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.
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)
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.
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
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.
(1) Niemand ist verpflichtet, deutsche Euro-Gedenkmünzen im Betrag von mehr als 200 Euro bei einer einzelnen Zahlung anzunehmen. Erfolgt eine einzelne Zahlung sowohl in Euro-Münzen als auch in deutschen Euro-Gedenkmünzen, ist niemand verpflichtet, mehr als 50 Münzen anzunehmen; dies gilt auch dann, wenn der Gesamtbetrag 200 Euro unterschreitet."
(1) No one is obliged to accept German commemorative euro coins totalling more than 200 euros in a single payment. If a single payment is made using both euro coins and German commemorative euro coins, no one is obliged to accept more than 50 coins; this also applies if the total amount is less than 200 euros."
> This is explicitly about commemorative coins, not regular ones.
The formulation is not so easy to read (very common for German laws), but it includes also the regulations for normal coins:
"Erfolgt eine einzelne Zahlung sowohl in Euro-Münzen als auch in deutschen Euro-Gedenkmünzen, ist niemand verpflichtet, mehr als 50 Münzen anzunehmen; dies gilt auch dann, wenn der Gesamtbetrag 200 Euro unterschreitet."
"If a single payment is made using both euro coins and German commemorative euro coins, no one is obliged to accept more than 50 coins; this also applies if the total amount is less than 200 euros."
So, there exist two cases in which the vendor is not obliged to take more than 50 coins:
- The payment consists of both normal Euro coins and German commemorative euro coins
- The payment is less than EUR 200.
--
Independently, there does exist another source of law by which the vendor is not obliged to take more than 50 coins: Artikel 11 der EG-Verordnung Nr. 974/98 des Rates über die Einführung des Euro, EU-Amtsblatt L139 vom 11. Mai 1998:
"As from 1 January 2002, the participating Member States
shall issue coins denominated in euro or in cent and
complying with the denominations and technical specifications which the Council may lay down in accordance
with the second sentence of Article 105a(2) of the Treaty.
Without prejudice to Article 15, these coins shall be the
only coins which have the status of legal tender in all
these Member States. Except for the issuing authority and
for those persons specifically designated by the national
legislation of the issuing Member State, no party shall be
obliged to accept more than 50 coins in any single
payment."
Relevant part of this article:
"Except for the issuing authority and
for those persons specifically designated by the national
legislation of the issuing Member State, no party shall be
obliged to accept more than 50 coins in any single
payment."
To clarify given the subject at hand: German courts are 100% not going to find a Google Drive link to be disallowed by the GPLv2. That's literally about physical coins.
It's not even that. Downstream projects host their own mirrors already, this is an annoying hoop to jump through for the maintainers (basically suck down a bunch of tarballs for every release, analogous to grabbing stuff from FTP sites back in the day), but not exactly a terrible hardship compared to the really very significant work of maintaining a large project.
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.
There might be some merit to a claim that Google Drive isn't a medium customarily used for software distribution these days, but, yeah, it's definitely not paying a thousand+ cent bill in pennies, and I'm skeptical that it's a violation of the letter of the GPL.
> There might be some merit to a claim that Google Drive isn't a medium customarily used for software distribution these days
I suppose forcing a means to share the source code could have been too restrictive, but the GPL only speaks about the shape of the source code itself (it should be "the preferred form of the work for making modifications to it"), not how it is shared, so indeed, not a violation of the letter of the GPL I think.
It's like what we had in France and the Hadopi, which requested ISPs to share the IP addresses of people torrenting a defined set of files. One of them sent them printed on paper... (But the malicious compliance was cool in this case).
> I suppose forcing a means to share the source code could have been too restrictive, but the GPL only speaks about the shape of the source code itself (it should be "the preferred form of the work for making modifications to it"), not how it is shared...
With the greatest of respect, you've forgotten what the licenses say.
GPLv2: [0]
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
...
GPLv3: [1]
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer [to convey the source code upon request]... on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
...
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. ...
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
This unambiguously speaks about the form in which the source code is shared. If the licenses didn't specify this, folks would be compliant with the letter of the license by shipping you a printout of the source code and everything you need to build it and charging you for both the labor to generate that enormous, heavy-ass printout and shipping and handling to get it to you. [2]
[2] To downvoters: Don't forget that OCR was decent even back in the 1990s... certainly good enough for a good-quality printout in a fixed-width font to be -strictly speaking- machine-readable, and it has only gotten better as time has wobbled on. If you don't believe my account of the history, go look up how Zimmerman exported copies of PGP back when it was considered an export-controlled munition.
Indeed, you are right, my phrasing "but the GPL only speaks about the shape of the source code itself" is somewhat wrong or at least incomplete. I should have been more careful. It does force some stuff about how to convey the corresponding source; and it seems the GPLv3 tries to close some loopholes or address some situations more explicitly. You cited the parts of the GPLv2 and GPLv3 I should have.
I stand by the position that all this doesn't seem very restrictive though. I don't think the GPL could have been without a risk of making some legitimate cases litigious or something.
> I stand by the position that all this doesn't seem very restrictive though.
Is your position that it's less restrictive than it needs to be?
If that's not your position, then I'm not at all sure why you're bringing this up. If that is your position, then I disagree with you. The entire point of the GPL is to require distributors to "share and share alike". It's not a "sue everyone into oblivion" license, it's a "don't be a fuckin asshole with this gift I gave you to use, inspect, and modify however you wish... pass it along to others under the same terms" license.
I think the GPL doesn't impose much on how one should be redistributing the source code.
I'm not sure I would like it to me more restrictive, and I completely agree with your reading (starting from "The entire point of the GPL...").
> If that's not your position, then I'm not at all sure why you're bringing this up.
My initial reply to you was me mostly agreeing with you: distributing via Google Drive is probably not a violation of the letter of the GPL. Making it a pain to get the source code is an obvious violation of its spirit though (your "don't be a fuckin asshole" point).
>> my phrasing ... is somewhat wrong
> It's completely wrong.
Well, what concrete restriction you see in the GPL about how to redistribute the source code, apart from "you must make it available in a reasonable way (and tell people they can get it, the GPLv3 is more explicit about this but Android doesn't have GPLv3 code AFAIK)?"
People are getting way too bent out of shape over that "medium customarily used for software interchange" bit. It doesn't mean github. It doesn't mean "the medium I use most commonly".
Basically, if you think courts are going to be OK with interpreting "download from this FTP site" as acceptable but "download the same tarball from Drive" as unacceptable, you're fooling yourself.
Drive is fine, given the spirit of the license. It's merely inconvenient.
I hope you're not including me in "people". Remember that I said:
There might be some merit to a claim that Google Drive isn't a medium customarily used for software distribution these days, but ... I'm skeptical that it's a violation of the letter of the GPL.
I was quoting the text of the GPL to point out to jraph that it absolutely does restrict how source code is distributed to ensure that licensees are obligated to distribute in a format that's actually useful to the typical recipient, rather than permitting a licensee to ship a couple-hundred pounds of printouts and still be in compliance with the license.
While I don't find any requirements on how timely the source distribution must be upon request, one can reasonably say that there must be a line between 1 nanosecond and 1 century.
Google can trivially provide it nearly instantly with no hardship. In fact, it's much harder for them to implement manual handling than automation. They have no justification for it beyond deliberately making it harder. It does have to be provided in a reasonable time or the license wouldn't work. What amount of time is reasonable is up to a court.
Google being incapable of timely handling of these requests is not believable. They're one of the largest tech companies in the world. They deliberately moved from a system without any need for manual handling of requests to requiring it with the clear goal of creating a hassle. By failing to provide it for long enough periods of time to cause tangible harm to people relying on it, they're failing to comply with the license.
Courts would most definitely make a distinction here. For instance, one century would mean "refusing to release the source code".
We should test how long it takes Google to release source code upon request. And whether it is 100%. I think we should test whether Google fulfils the GPL here. That's now a challenge.
Difficult to say at the moment, but there might be some speculation as to why.
One might be that they dont security patches reverse engineered and vulnerabilities to come out faster (some critical and high severity fixes in GPU drivers/bootloaders were often delayed), and this decision was done long before LLMs were considered powerful/useful for vulnerability research.
Second reason might be simply "Control of the android ecosystem", Google may just want to build a wall around android and make it frustrating for other vendors to compete.
Third, again, this is only speculation, is the current push for electronic ID in the EU and other countries, as well as DRM/copyright protections for media and locally ran LLMs (we've heard of how google pushed small LLMs with chrome updates), if they can do the same on some high end android devices, Google would be more invested into further locking down Android devices.
> 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.
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?
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.
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.
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 anywhere near 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.
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.
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.
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.
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.
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.
Google uses libraries licensed under GPLv2 in Android (I’m not sure which specific part of Android the author is talking about), and so is required to make the full source code available for anyone to view. They previously used to publish release tag tarballs, but now require you to fill out a Google form and then (weeks later) will share the source with you on Google Drive.
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.
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.
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.
The software also isn't in the preferred form for modification. The build system which runs Git commands and doesn't work as intended without it. You have to make a Git repository for it to work and there's meant to be a separate one for each separate component. It spews out errors.
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).
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.
Switching from Git tags to Google Drive downloads technically satisfies GPL but makes it much harder for downstream projects to track changes. The inconvenience is the point.
> 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.
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.
IANAL, but I don't think you're interpreting that correctly.
I believe section 3.b and 3.c are the rights this is referring to, where you can request the source, and even be changed for the physical act. Suggesting this extends to the license of the implementation of their contact system doesn't make sense. No method of contact, except physical, is going to meet your requirements, including sending postage, where the software used to sort your mail is not GPL.
I can see an argument that Google is requiring you to enter into a separate agreement with them (the terms they require you to agree to when using Google Forms) to request access to the GPL licensed source.
You do not enter into an agreement with the vendor of the software the postal service uses to sort your mail.
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.
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.
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.
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.
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
Pixel kernel drivers which are GPLv2, you need them to build the kernel modules from source. Git tags in this case refer to beta versions, but it being "beta" doesn't mean they can delay the release.
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.
RE satisfying GPL, the google drive thing is annoying, and I called it paying a bill in pennies in another comment, But RedHat is 100x worse.
They might actually be violating the gpl because of the attempt to set terms on redistribution and the retaliation (kill your account and block future access) if you do.
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)?
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.
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.)
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.
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.
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."
> "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 supposed to be 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 meant to be and the build system makes it clear that it isn't happy about it despite running.
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.
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
“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?
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
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?
It is an easy to overlook this, but even for someone in position of power to change, creating different code with the same hash is borderline impossible.
Non-sequitor? They're not providing a (sha-1) hash, they're providing source code to integration partners using their business channels, not public git providers. Those business channels include contracts etc to "secure their supply chain".
You and I aren't in those business channels, and we're not being given anything with a hash. There's simply no hash to collide with?
It was initially taking under a business day for them to respond, but our recent requests have often taken weeks for them to get back to us. We want the code for all the Beta releases and are entitled to it.
There are other branches there with it for Android 17 QPR1 Beta and Android 17 QPR2 Beta.
Google could save everyone including themselves a lot of hassle by simply publishing it to GitHub. If they don't want to push it to AOSP for weird organizational reasons as part of saying AOSP doesn't support Pixels, fine. Taking weeks or more to get back to us isn't reasonable for one the largest tech companies in the world.
It's also questionable whether what they're providing is truly the preferred form for modification considering the build system is quite unhappy about the lack of Git repositories. They had to provide a repo manifest metadata file to work around part of it.
It also isn't only them pushing the boundaries of the GPL.
Pixel 9a and earlier were sold as the official Android Open Source Project (AOSP) reference devices. They made a commitment to providing 7 years of updates for the Pixel 8 and later. Android 16 declared Pixels were no longer AOSP reference devices and stopped providing any support for them. From our perspective, Google hasn't fulfilled their update commitment for the Pixel 6 through Pixel 9a. It's fair to say the Pixel 10 and later weren't sold as AOSP reference devices and didn't have any commitment to providing sources as part of the updates, but that isn't the case for the earlier devices.
No it's not, because "one person" has to keep sitting up and begging for access, every time there's a new release, over and over and over and over and over.
Submitting the form isn't too hard, so there's not much to be gained by getting a non-affiliated volunteer to do it. Also if they're not the ones requesting it, it becomes hard to ascertain the authenticity of the links (eg. it doesn't contain a backdoored kernel).
They stopped pushing tags for any of the Pixel kernel or userspace driver repositories to AOSP. They also stopped pushing AOSP releases specific to Pixels which is why AOSP now only gets yearly releases, QPR2 releases and security backports to both of those. Other OEMs use the yearly and theoretically also the QPR2 releases. Both the yearly and QPR2 releases get monthly security backports. Since they dropped Pixel support from AOSP, they don't push the releases not shipped by other OEMs anymore.
These changes directly led to our Motorola partnership. One of their security people reached out to us after seeing our posts about this with the launch of Android 16. We haven't talked about it much since then since we adapted to it during the several weeks it delayed our Android 16 port. We then continued adapting to it and have fully worked around it. It was an ongoing problem but not a new one and we had accepted we had to deal with it as the new normal.
They were previously responding to our kernel source requests within a day. It was often done without hours. Despite the archaic system, this part wasn't that bad. Recently, they've been taking weeks or longer to get back to us for the requests which is ridiculous. It's the direct result of purposely adding a lot of friction with manual handling of the requests even if the delays weren't directly planned by management.
Weeks or months of delay is not reasonable for one of the largest tech companies in the world. GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely. They need to do it in a reasonable amount of time. What's reasonable for one of the largest tech companies in the world in 2026 with current technology is not the same as what was reasonable 30 years ago. Google chose to come up with a archaic way of distributing the sources involving someone manually going through a list and sharing Google Drive access. It's a deliberate way of making it painful. If they can't keep up with it and it gets delayed for weeks or months then they're not complying with the GPL by not providing it in a reasonable amount of time. Law is not code and a time limit not being explicitly written down doesn't mean there isn't a limit to what's reasonable for compliance.
They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels. We helped them fix serious security weaknesses for Pixels including vulnerabilities being exploited in the wild by forensic data extraction companies. Pixel security with the stock OS would be worse without GrapheneOS.
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.
Thanks for GrapheneOS, and shame on Google.
> 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!!
Are you sure, I got one and I'm in Central Europe.
Should have said "worldwide". I apologize for the confusion.
They definitely sell them in the UK too, the OP is just wrong.
Me too, and I'm in Australia...
They're from Brazil, Google doesn't sell pixels there
> They need to do it in a reasonable amount of time.
If they did that for years within hours and if we look at the tools available today, I would expect that "reasonable" equates to how they provided it prior: fast.
They did it for many years with 0 delay because they pushed the tags to AOSP. It was moved to Google Drive with a Google Forms setup to request access with manual fulfillment of the request. It was deliberately done to make it into a hassle. The delays are by design through making it a manual system regardless of how much of a delay was intended as part of this change. They could be automatically handling the requests especially from people who have already been given sources for a product. They're deliberately making it take substantially more work on their end to make it into more of a hassle.
I was involved in one of the communities involved in the Block Sidewalk efforts in Toronto Canada, which prevented Sidewalk Labs from moving forward on a multi-billion dollar project to redevelop a chunk of downtown Toronto.
I was at the Data Power 2017 conference in Ottawa where I shared with people (who would become key Block Sidewalk organizers) the clues I had, that Google was about to bid on the as-yet-unknown land development opportunity, closing later that month.
I had previously been in collaboration with secure ROM developers hitting their first adversarial efforts to thwart use of Android for alt app markets. I know that Google's public story of Android openness (which drove people trusting them to build a city platform) was bullshit, and I made sure many many of the key activists and public servants knew it.
While I can't know exactly how my specific actions affected things, I would guarantee that Google's adversarial positions and failed stewardship have already contributed to them losing real opportunities.
I understand - you said that before - I was just interpreting to what the GPL means with "reasonable time".
Maybe a lawsuit would change things?
...hoping a Google Gemma agent can handle those Google Forms and Google Drive for you too!
> GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely.
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.
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.
Not that the intent of a license can be enforced.
Compliance with the intent of the law is one of the things courts get to decide on.
Someone just needs to be crazy enough to sue (and rich/lucky enough to win)
In the US? Under the current political and economic circumstances? Against Google's legal department? I wouldn't get my hopes up...
No, it would be in Canada.
i have owned nearly every Google phone since the G1. i will not be purchasing any future devices from them unless they change course.
What will you purchase instead? It sucks that the modern smartphone OS market is a duopoly.
Since they're saying "Google phone", not "Android phone", I imagine the next purchase could be a Samsung or such.
Comments elsewhere in this thread say other major brands are even more locked down.
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
The Motorola one, when it comes with GrapheneOS!
> They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels.
Which brand and model is currently best supported by GrapheneOS, if I want to buy an Android device to run GrapheneOS on?
Only Pixels, most other device are ironically locked down a lot more (not allowing custom keys for verified boot) or lack modern security features (like hardware security modules).
So you'll have to wait for the mentioned Motorola Flagship
Well, it's as you wrote: they are making the source available, albeit in a very inconvenient way, and because there is no time limit specified, they're complying with the letter of the GPL (although not with its spirit), so you can't even realistically sue them. And the number of people who buy new Pixels to immediately install GrapheneOS on them is (no offense) negligible, so I don't think they'll see a sales impact from it...
Which is not to say that I'm on Google's side, this is absolutely a dick move from them, and they wouldn't have done it 20 or even 10 years ago, but today's Google is definitely no longer the "don't be evil" company.
> they are making the source available
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.
> so you can't even realistically sue them
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.
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.
I really cross my fingers your partnership with Motorola will be successful
We need something other than Android, and we need the government to make sure we can run Android apps (like government ID and banking apps) without being spied on. They've been doing whatever the f they like for long enough if you ask me.
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.
(that's my understanding)
i.e. its no longer open source, now access is granted by permission.
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
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.
Spirit of the law vs Letter of the law argument. Which ever side of the coin you stand on.
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.
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 is worth what, a trillion dollars?
It doesn't if you use a better theory
Google literally has infinite money.
Infinite money in the pursuit of profit or an ego trip of an exec. No money for the benefit of community or society.
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.
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.
> Google refusing to do so means Google wants to violate the GPLv2
Not an expert in GPL, but does it say that the source code needs to be provided by a url?
GPL doesn't require them to publish the source in git. FWIW, Google can be compliant and publish the source in Physical Medium too if they opt too.
Also, the OP did mentioned that Google also squashed the git commit to a single commit for whatever reason.
Can't wait for pallets of paper to get shipped out to comply maliciously
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.
Google Drive is customarily used for software interchange?
My personal website isn't customarily used for software interchange, but http is. I think getting into discussions about which websites are acceptable and which aren't feels like a bad place.
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.
Floppy disks.
1) floppy disks are not customarily used for software interchange - where they are still used (aircraft software updates, bits of San Francisco's streetcar infrastructure) it's weird enough to be remarked upon. 2) the cost to Google of finding enough working floppies and paying someone to dump that much code onto them, then mailing them out, then having the other end just say "disk 323 was corrupted by USPS X rays, please send again" 20 times, would massively outweigh the benefits of making this awkward
Mostly agreed. However you can solve the problem of having x% of disks corrupted via error correcting codes. It's what Google already does for their own internal storage: when you own millions of hard disks, some of them will inevitably fail.
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.
As far as I understand, they could send it to you printed and bound and charge you for the paper and postage if they want to.
No. In fact, the GPL states that the actual cost of delivery can be charged (consider this is from times when people still post-mailed floppy disks).
“In violation of GPL” is a stretch.
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.
GrapheneOS is arguing that throwing away the metadata of however many commits and squashing them into a messy tarball is not the "preferred form of the work for making modifications", and that a manual process where you have to fill out a form in order to get a Google Drive link a week later is not "a medium customarily used for software interchange" in current times. Those are quotes from the GPLv2.
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.
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]
[1] https://news.ycombinator.com/item?id=49368983
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.
GrapheneOS might have a better case though if it's not just about understanding the code but about how the Android build system expects that everything is in Git.
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.
we could argue about license semantics all day, either way Google is not being a good player
Oh, I agree there.
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.
Lack of a specific time limit in GPL doesn't mean there isn't one based on what's reasonable. What they're doing it not reasonable.
> Android has always been more source-open than “open source”.
This is about Pixels rather than AOSP. Google decided Pixels would no longer be supported by AOSP which is why they stopped pushing the kernel drivers, userspace drivers and other Pixel related code to AOSP. They moved to publishing kernel driver code via Google Drive after filling out a Google Forms submission. They're handling those manually. It's a ridiculous system and comes across as them wanting to make it a hassle on purpose. Perhaps that isn't the case and someone simply needs to make the decision to simply push Git tags somewhere else. They could put it on GitHub if the goal is disassociating it from AOSP.
We accepted the archaic new system while they were responding to requests in a reasonable time but that ended. It's now very inconsistent and is regularly getting delayed for weeks or more.
> The vast majority of community contributions that make it into the codebase are security fixes and small bug fixes.
Open source does not imply anything about accepting contributions. SQLite barely takes any contributions and the same applies to many projects. There were a lot more code contributions to AOSP than you're describing prior to recent changes with Android 16. It was relatively easy to contribute to the lower level parts of it.
Google are absolutely within the letter of the GPL, pedantically so. But maybe not the sprit.
We didn't have git tags when GPL was written in 1989, and while we did have sccs and rcs, (and early versions of cvs) they just weren't that widely used, and generally not used for distribution.
Even when GPL 3.0 was written in 2005-2007, source tarballs were still the primary form of distribution, even though it was starting to become standard to additionally provide anonymous cvs, svn, or one of the brand new distributed systems like git.
But these days git is the primary form of distribution, and source tarballs are noting more an afterthought. Hell, even tags are a bit of an afterthought on many projects. It's basically become the norm to expect an healthy revision history for any open source code.
Based on it's stated goals of "freedom to modify the software you use", IMO if the GPL was written (or updated) today, it would most likely require the distribution of revision history and restrict how much that history can be squashed/rewritten.
> 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 not squashing commits into a big mess to frustrate someone trying to make sense of the code (I'm sure the Google engineers making modifications prefer to look at individual commits!), and Google is 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.
But the stronger argument is that the Android build system expects everything to be in Git: https://news.ycombinator.com/item?id=49368983
Yeah, that argument is much better; Maybe google are violating the GPL.
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/argue 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?
It's clear to me: the request is about sending a particular version of the source code. No other versions, so no history.
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.
> Everything else is essentially all the work of Google and (to some extent) Samsung.
There is plenty in Android which isn't the work of Google. For starters the Kotlin implementation and the Java implementation (OpenJDK).
> Android has always been more source-open than “open source”. The vast majority of community contributions that make it into the codebase are security fixes and small bug fixes.
I believe this isn't actually about "Android" at all but rather Pixel. Android is still openly accessible on git. But the kernel sources for Pixel devices is now behind this big song & dance for some fucking inexcusable reason.
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.
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)
GitLab is MIT licensed, but also has also parts which are source available but not MIT licensed. Contributions to both are possible.
The intent is obviously to make it hard to get the source code, which violates the license.
I see your point, However the majority of Android devices have lots of closed source firmware/drivers, a large part of the Android OS doesn't run without them.
I'm refering to Bootloaders, TrustZone OS, Trusted Applications, then firmware for Bluetooth, Wifi, GPU, Sensors and power management. All of those are always closed source binary blobs running in the background.
> Android has always been more source-open than “open source”.
I hate Google as much as the next person, and the only way with those companies would be to fine them heavily, quickly and systematically.
But it is important that we are clear about what Google does bad and what it does well. And I believe that understanding what "open source" means is important when one wants to talk about a violation of an open source licence.
Open source does not mean that they take contributions. Many firmwares used by Android are not open source, but AOSP is open source. It is licenced under a permissive licence (Apache 2, I think for everything), which makes it open source, period.
Why would it be a "stretch"?
The basic requirement is whether the source code is available - and made available. Are you certain that Google's solution here is ensuring that the source code is easily made available? So many other projects just provide a wget-able link. Why does Google want to make it harder to obtain the source code than those other projects?
> Android has always been more source-open than “open source”.
And what exactly does that mean? I don't know what your words mean here. More source open than open source? Is that a tautology?
> Everything else is essentially all the work of Google and (to some extent) Samsung.
Is it GPLv2? If so then I fail to see why anyone should get higher rights. Everyone gets the same for GPLv2. That's the whole point. I don't understand your statements here.
> 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
"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?"
I'm sure this means the source happens to be open rather than following the spirit of open source.
> “In violation of GPL” is a stretch.
The originally envisioned distribution method, in fact, was "Send FSF a blank 9-track tape and they'll fill it and mail it back". Nor, obviously, does anything prevent someone who downloads this from Drive from mirroring it on GitHub or wherever.
This is arguably bad stewardship of a historically open source project. It's certainly not a license violation.
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.
It's paying a bill in pennies.
> It's paying a bill in pennies.
This is actually a problem that is solved in German law:
§ 3 Münzgesetz (MünzG), Absatz 1 [§ 3 Coins Act, article 1]
"§ 3 Annahme- und Umtauschpflicht
(1) Niemand ist verpflichtet, deutsche Euro-Gedenkmünzen im Betrag von mehr als 200 Euro bei einer einzelnen Zahlung anzunehmen. Erfolgt eine einzelne Zahlung sowohl in Euro-Münzen als auch in deutschen Euro-Gedenkmünzen, ist niemand verpflichtet, mehr als 50 Münzen anzunehmen; dies gilt auch dann, wenn der Gesamtbetrag 200 Euro unterschreitet."
https://www.gesetze-im-internet.de/m_nzg_2002/__3.html
Translation based on the one created by DeepL:
"§ 3 Obligation to Accept and Exchange
(1) No one is obliged to accept German commemorative euro coins totalling more than 200 euros in a single payment. If a single payment is made using both euro coins and German commemorative euro coins, no one is obliged to accept more than 50 coins; this also applies if the total amount is less than 200 euros."
This is explicitly about commemorative coins, not regular ones.
> This is explicitly about commemorative coins, not regular ones.
The formulation is not so easy to read (very common for German laws), but it includes also the regulations for normal coins:
"Erfolgt eine einzelne Zahlung sowohl in Euro-Münzen als auch in deutschen Euro-Gedenkmünzen, ist niemand verpflichtet, mehr als 50 Münzen anzunehmen; dies gilt auch dann, wenn der Gesamtbetrag 200 Euro unterschreitet."
"If a single payment is made using both euro coins and German commemorative euro coins, no one is obliged to accept more than 50 coins; this also applies if the total amount is less than 200 euros."
So, there exist two cases in which the vendor is not obliged to take more than 50 coins:
- The payment consists of both normal Euro coins and German commemorative euro coins
- The payment is less than EUR 200.
--
Independently, there does exist another source of law by which the vendor is not obliged to take more than 50 coins: Artikel 11 der EG-Verordnung Nr. 974/98 des Rates über die Einführung des Euro, EU-Amtsblatt L139 vom 11. Mai 1998:
> https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELE... (German)
> https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE... (English)
"As from 1 January 2002, the participating Member States shall issue coins denominated in euro or in cent and complying with the denominations and technical specifications which the Council may lay down in accordance with the second sentence of Article 105a(2) of the Treaty. Without prejudice to Article 15, these coins shall be the only coins which have the status of legal tender in all these Member States. Except for the issuing authority and for those persons specifically designated by the national legislation of the issuing Member State, no party shall be obliged to accept more than 50 coins in any single payment."
Relevant part of this article:
"Except for the issuing authority and for those persons specifically designated by the national legislation of the issuing Member State, no party shall be obliged to accept more than 50 coins in any single payment."
To clarify given the subject at hand: German courts are 100% not going to find a Google Drive link to be disallowed by the GPLv2. That's literally about physical coins.
It's not even that. Downstream projects host their own mirrors already, this is an annoying hoop to jump through for the maintainers (basically suck down a bunch of tarballs for every release, analogous to grabbing stuff from FTP sites back in the day), but not exactly a terrible hardship compared to the really very significant work of maintaining a large project.
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.
There might be some merit to a claim that Google Drive isn't a medium customarily used for software distribution these days, but, yeah, it's definitely not paying a thousand+ cent bill in pennies, and I'm skeptical that it's a violation of the letter of the GPL.
It is definitely a dick move by Google.
> There might be some merit to a claim that Google Drive isn't a medium customarily used for software distribution these days
I suppose forcing a means to share the source code could have been too restrictive, but the GPL only speaks about the shape of the source code itself (it should be "the preferred form of the work for making modifications to it"), not how it is shared, so indeed, not a violation of the letter of the GPL I think.
It's like what we had in France and the Hadopi, which requested ISPs to share the IP addresses of people torrenting a defined set of files. One of them sent them printed on paper... (But the malicious compliance was cool in this case).
> I suppose forcing a means to share the source code could have been too restrictive, but the GPL only speaks about the shape of the source code itself (it should be "the preferred form of the work for making modifications to it"), not how it is shared...
With the greatest of respect, you've forgotten what the licenses say.
GPLv2: [0]
GPLv3: [1] This unambiguously speaks about the form in which the source code is shared. If the licenses didn't specify this, folks would be compliant with the letter of the license by shipping you a printout of the source code and everything you need to build it and charging you for both the labor to generate that enormous, heavy-ass printout and shipping and handling to get it to you. [2][0] <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
[1] <https://www.gnu.org/licenses/gpl-3.0.html>
[2] To downvoters: Don't forget that OCR was decent even back in the 1990s... certainly good enough for a good-quality printout in a fixed-width font to be -strictly speaking- machine-readable, and it has only gotten better as time has wobbled on. If you don't believe my account of the history, go look up how Zimmerman exported copies of PGP back when it was considered an export-controlled munition.
Indeed, you are right, my phrasing "but the GPL only speaks about the shape of the source code itself" is somewhat wrong or at least incomplete. I should have been more careful. It does force some stuff about how to convey the corresponding source; and it seems the GPLv3 tries to close some loopholes or address some situations more explicitly. You cited the parts of the GPLv2 and GPLv3 I should have.
I stand by the position that all this doesn't seem very restrictive though. I don't think the GPL could have been without a risk of making some legitimate cases litigious or something.
> my phrasing ... is somewhat wrong
It's completely wrong.
> I stand by the position that all this doesn't seem very restrictive though.
Is your position that it's less restrictive than it needs to be?
If that's not your position, then I'm not at all sure why you're bringing this up. If that is your position, then I disagree with you. The entire point of the GPL is to require distributors to "share and share alike". It's not a "sue everyone into oblivion" license, it's a "don't be a fuckin asshole with this gift I gave you to use, inspect, and modify however you wish... pass it along to others under the same terms" license.
I think you got me wrong.
I think the GPL doesn't impose much on how one should be redistributing the source code.
I'm not sure I would like it to me more restrictive, and I completely agree with your reading (starting from "The entire point of the GPL...").
> If that's not your position, then I'm not at all sure why you're bringing this up.
My initial reply to you was me mostly agreeing with you: distributing via Google Drive is probably not a violation of the letter of the GPL. Making it a pain to get the source code is an obvious violation of its spirit though (your "don't be a fuckin asshole" point).
>> my phrasing ... is somewhat wrong
> It's completely wrong.
Well, what concrete restriction you see in the GPL about how to redistribute the source code, apart from "you must make it available in a reasonable way (and tell people they can get it, the GPLv3 is more explicit about this but Android doesn't have GPLv3 code AFAIK)?"
People are getting way too bent out of shape over that "medium customarily used for software interchange" bit. It doesn't mean github. It doesn't mean "the medium I use most commonly".
Basically, if you think courts are going to be OK with interpreting "download from this FTP site" as acceptable but "download the same tarball from Drive" as unacceptable, you're fooling yourself.
Drive is fine, given the spirit of the license. It's merely inconvenient.
> People are getting way too bent out of shape...
I hope you're not including me in "people". Remember that I said:
I was quoting the text of the GPL to point out to jraph that it absolutely does restrict how source code is distributed to ensure that licensees are obligated to distribute in a format that's actually useful to the typical recipient, rather than permitting a licensee to ship a couple-hundred pounds of printouts and still be in compliance with the license.While I don't find any requirements on how timely the source distribution must be upon request, one can reasonably say that there must be a line between 1 nanosecond and 1 century.
Google can trivially provide it nearly instantly with no hardship. In fact, it's much harder for them to implement manual handling than automation. They have no justification for it beyond deliberately making it harder. It does have to be provided in a reasonable time or the license wouldn't work. What amount of time is reasonable is up to a court.
Google being incapable of timely handling of these requests is not believable. They're one of the largest tech companies in the world. They deliberately moved from a system without any need for manual handling of requests to requiring it with the clear goal of creating a hassle. By failing to provide it for long enough periods of time to cause tangible harm to people relying on it, they're failing to comply with the license.
Courts would most definitely make a distinction here. For instance, one century would mean "refusing to release the source code".
We should test how long it takes Google to release source code upon request. And whether it is 100%. I think we should test whether Google fulfils the GPL here. That's now a challenge.
GPL says that you can give that link to anyone you want.
If someone on HN has received one of these links, feel free to post it here.
I think - if the code is in fact GPL - you can give the code to anyone you want.
But I would think the link is access to google's servers, which might be different.
But why? What can be the internal justification? What do they think they win by doing this?
Difficult to say at the moment, but there might be some speculation as to why.
One might be that they dont security patches reverse engineered and vulnerabilities to come out faster (some critical and high severity fixes in GPU drivers/bootloaders were often delayed), and this decision was done long before LLMs were considered powerful/useful for vulnerability research.
Second reason might be simply "Control of the android ecosystem", Google may just want to build a wall around android and make it frustrating for other vendors to compete.
Third, again, this is only speculation, is the current push for electronic ID in the EU and other countries, as well as DRM/copyright protections for media and locally ran LLMs (we've heard of how google pushed small LLMs with chrome updates), if they can do the same on some high end android devices, Google would be more invested into further locking down Android devices.
It can be also a temporary obstacle until they get rid of Linux kernel and replace it with kernel from Fuchsia or something.
Classical not being evil stuff by Google.
The third reich loved administrative processes too.
Relevant: https://keepandroidopen.org/
> 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.
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?
Any inconveniences with Linux phones are less annoying to me than what Google is doing to AOSP. My next phone will run postmarketOS.
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?
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.
It doesn't apply to GrapheneOS.
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.
Doesn’t Apple do the same?
The difference is that Apple always did it with iOS and Google did not. Many chose Android because of that.
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.
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.
Yeah, I was a loyal Android user for 15 years.
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 anywhere near 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.
>makes most of their revenue via advertising.
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...
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.
Time to start over.
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.
Does it matter that Apple does the same?
> Doesn’t Apple do the same
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.
Did Apple claim iOS is open source?
Well, https://github.com/apple-oss-distributions/xnu is, but it's not enough to make you an iPhone.
AOSP is open source. The Android running on most manufacturer-branded phones isn’t.
So you're saying Google should stop open sourcing Android? That should like a bad incentive to make to defend Apple.
Apple is at least honest at that point.
Google claims an openness that doesn’t exist anymore
Google has no choice, the moment they stop releasing Android sources, a chinese consortium will just take over and they will lose ownership of Android
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.
Can someone explain what this means? Am not familiar with the terminology
Google uses libraries licensed under GPLv2 in Android (I’m not sure which specific part of Android the author is talking about), and so is required to make the full source code available for anyone to view. They previously used to publish release tag tarballs, but now require you to fill out a Google form and then (weeks later) will share the source with you on Google Drive.
Android is built on the linux kernel which uses GPLv2
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.
Google apparently wants everybody to know how much they hate abiding by the terms of open source licenses.
Every year a new low.
isn't this just malicious compliance? not clear how this would violate GPLv2?
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.
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.
The software also isn't in the preferred form for modification. The build system which runs Git commands and doesn't work as intended without it. You have to make a Git repository for it to work and there's meant to be a separate one for each separate component. It spews out errors.
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).
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.
But google already built a tool to do exactly that: https://github.com/google/copybara
Switching from Git tags to Google Drive downloads technically satisfies GPL but makes it much harder for downstream projects to track changes. The inconvenience is the point.
Quoting the first tweet:
> 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.
> They're in clear violation of the GPLv2 now.
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.
> I don't think they are?
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.
IANAL, but I don't think you're interpreting that correctly.
I believe section 3.b and 3.c are the rights this is referring to, where you can request the source, and even be changed for the physical act. Suggesting this extends to the license of the implementation of their contact system doesn't make sense. No method of contact, except physical, is going to meet your requirements, including sending postage, where the software used to sort your mail is not GPL.
I think it’s nuanced
I can see an argument that Google is requiring you to enter into a separate agreement with them (the terms they require you to agree to when using Google Forms) to request access to the GPL licensed source.
You do not enter into an agreement with the vendor of the software the postal service uses to sort your mail.
If they do force you into google forms and you can't send a letter then that's a potential issue.
Making you run javascript is a weaker argument...
Don't they force you to sign up for a Google account to be able to gate access to a Google Drive file?
No. As long as the sharing permission is “Anyone with the link”, then anyone can download from that link with wget or whatever.
Is that the permission they use? Who knows? But it’s at least possible.
There's an easy way to put them into compliance violation:
Get a large brigade of android users to request access to source on each security update.
Didn't Google work very hard to avoid any GPL in Android, apart from the kernel? What is in there that is GPL?
I assume Linux.
I am very thankful linux is gpl. Because of GPL these tech giants are forced to release source code.
But Linux allowed Tivoization though.
There are worse things than Tivoization.
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.
How slow is "very slow" ? What is "certain source code"? Why is the OP being so coy about describing the problem?
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
> 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.
Is it about Android code?
Could this be related to the upcoming change (close) of the apk side-loading?
I don't think it is directly related, other than Google being Google and deserving big big fines for being evil.
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.
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.
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.
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
>Both. Google has plenty of government contracts, they are undoubtedly pushing for more surveillance,
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".
It's a bit unclear what this is about exactly. What releases are we talking about? How git tags come into play here?
Pixel kernel drivers which are GPLv2, you need them to build the kernel modules from source. Git tags in this case refer to beta versions, but it being "beta" doesn't mean they can delay the release.
Google needs to lose in court here. This company is getting more and more evil by the day.
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.
That's like this fun fact where Microsoft needs to send you source code via post when you mail them a 5$ check. lol
Yo Louis Rossmann, do your thing!
RE satisfying GPL, the google drive thing is annoying, and I called it paying a bill in pennies in another comment, But RedHat is 100x worse.
They might actually be violating the gpl because of the attempt to set terms on redistribution and the retaliation (kill your account and block future access) if you do.
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 have feeling that is related to their upcoming changes that make sideloading harder
Source code of which components is that? It's not very clear from the mastodon thread.
Pixel kernel drivers.
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.
Maybe AOSP source code
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.
https://news.ycombinator.com/item?id=49369087
Google doing anti competitive bullshit? Never
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.
This just breaks legitimate downstream distros that target Pixel devices.
Ransomware gangs, etc still get red carpet service.
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.)
Shameful acts.
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.
"Free" as in "free to play by our rules or suffer"
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.
What is the alternative?
GrapheneOS
HarmonyOS?
Hopefully. I don't trust them neither, but they do have no powers over me.
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."
> "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?
Yes, and we do mirror their 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.
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 supposed to be 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 meant to be and the build system makes it clear that it isn't happy about it despite running.
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.
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
“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?
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
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?
It doesn't break supply chain security for anybody with power to change the situation.
It is an easy to overlook this, but even for someone in position of power to change, creating different code with the same hash is borderline impossible.
Non-sequitor? They're not providing a (sha-1) hash, they're providing source code to integration partners using their business channels, not public git providers. Those business channels include contracts etc to "secure their supply chain".
You and I aren't in those business channels, and we're not being given anything with a hash. There's simply no hash to collide with?
A git hash is cryptographically secure. It doesn't matter how you distribute it. That is the entire point you're missing.
Yes, but that person still needs to file a request and wait several days
It was initially taking under a business day for them to respond, but our recent requests have often taken weeks for them to get back to us. We want the code for all the Beta releases and are entitled to it.
This is the relevant code for Android 17:
https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base
https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b...
There are other branches there with it for Android 17 QPR1 Beta and Android 17 QPR2 Beta.
Google could save everyone including themselves a lot of hassle by simply publishing it to GitHub. If they don't want to push it to AOSP for weird organizational reasons as part of saying AOSP doesn't support Pixels, fine. Taking weeks or more to get back to us isn't reasonable for one the largest tech companies in the world.
It's also questionable whether what they're providing is truly the preferred form for modification considering the build system is quite unhappy about the lack of Git repositories. They had to provide a repo manifest metadata file to work around part of it.
I wholeheartedly agree. Making it more difficult to obtain GPLed source code than it was before is fundamentally a dick move.
It also isn't only them pushing the boundaries of the GPL.
Pixel 9a and earlier were sold as the official Android Open Source Project (AOSP) reference devices. They made a commitment to providing 7 years of updates for the Pixel 8 and later. Android 16 declared Pixels were no longer AOSP reference devices and stopped providing any support for them. From our perspective, Google hasn't fulfilled their update commitment for the Pixel 6 through Pixel 9a. It's fair to say the Pixel 10 and later weren't sold as AOSP reference devices and didn't have any commitment to providing sources as part of the updates, but that isn't the case for the earlier devices.
But after one person does this, the source code access is a solved problem.
No it's not, because "one person" has to keep sitting up and begging for access, every time there's a new release, over and over and over and over and over.
Maybe we colld getan AI agent to pester them with forms?
What consequences do you imagine if they (rightfully) choose to ignore it?
But nobody has done this, which is why it's a problem for Graphene
Maybe should someone should do it then?
Submitting the form isn't too hard, so there's not much to be gained by getting a non-affiliated volunteer to do it. Also if they're not the ones requesting it, it becomes hard to ascertain the authenticity of the links (eg. it doesn't contain a backdoored kernel).
They are, which is how they know how long it's taking.
Give them a few years and they'll only provide it by printing out a copy and mailing it to you.
Don't give them ideas!
Seriously, if we keep this up they'll be sending us pallets of punch cards before you know it.