Posted by Animux 17 hours ago
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.
If they did that for years within hours and if we look at the tools available today, I would expect that "reasonable" equates to how they provided it prior: fast.
I was at the Data Power 2017 conference in Ottawa where I shared with people (who would become key Block Sidewalk organizers) the clues I had, that Google was about to bid on the as-yet-unknown land development opportunity, closing later that month.
I had previously been in collaboration with secure ROM developers hitting their first adversarial efforts to thwart use of Android 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.
Maybe a lawsuit would change things?
I wonder actually what a court would say here and if "doesn't set a time limit" could mean "the source needs to be made available immediately". IANAL.
Not that the intent of a license can be enforced.
Someone just needs to be crazy enough to sue (and rich/lucky enough to win)
> They'll sell far fewer Pixels because of these overall changes.
They don't even sell Pixels internationally. Can't tell you how glad I am you're moving to Motorola. I'm really looking forward to having a Motorola GrapheneOS phone!!
2 questions:
- How hard is it for manufacturers to include the option Android/Graphene just like they have memory and storage options?
- Could this be a point where GrapheneOS disconnects from Android and become an independent OS?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
Which brand and model is currently best supported by GrapheneOS, if I want to buy an Android device to run GrapheneOS on?
So you'll have to wait for the mentioned Motorola Flagship
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.
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.
Even before that it had been jokes of repositories, but at least you didn't have to ask for someone every time and wait for them to respond to the request.
(that's my understanding)
OSI is not clear on this either. ("Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, [...]")
Worded differently, the simplest way to provide the source code is IMO via a URL that you can just wget. At the least this is done by so many projects out there. Google refusing to do so means Google wants to violate the GPLv2, since their alternatives are inferior.
https://distrowatch.com/ has many convenient links to URLs on the left side; I often use that to download the latest and greatest and compile it away, e. g. https://ftp.isc.org/isc/bind9/9.20.27/bind-9.20.27.tar.xz as a current example, taken from the left panel.
Not an expert in GPL, but does it say that the source code needs to be provided by a url?
Also, the OP did mentioned that Google also squashed the git commit to a single commit for whatever reason.
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 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.
> 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.
We didn't have git tags when GPL was written in 1989, and while we did have sccs and rcs, (and early versions of cvs) they just weren't that widely used, and generally not used for distribution.
Even when GPL 3.0 was written in 2005-2007, source tarballs were still the primary form of distribution, even though it was starting to become standard to additionally provide anonymous cvs, svn, or one of the brand new distributed systems like git.
But these days git is the primary form of distribution, and source tarballs are noting more an afterthought. Hell, even tags are a bit of an afterthought on many projects. It's basically become the norm to expect an healthy revision history for any open source code.
Based on it's stated goals of "freedom to modify the software you use", IMO if the GPL was written (or updated) today, it would most likely require the distribution of revision history and restrict how much that history can be squashed/rewritten.
The GPLv2 requires "a medium customarily used for software interchange", not "a medium customarily used in 1989 for software interchange". Customs are the customs of the time someone is releasing the work.
Interesting choice of cropping for that quote.
If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data. So it would exclude distributing source code on tape, or even optical discs, as nobody uses those anymore. About the only medium used for source code distribution these days is “the internet”
You could potentially stretch this to excluding google drive, though google will argue that the medium is http, not google drive; But you can’t stretch this to requiring it be formatted as git.
And even if you did manage to successfully argue that, google would just ship it as one (tagged) commit per release. The history would still be missing.
I can see your point. But OTOH if providing the "preferred form of the work for making modifications" requires 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
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?
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.
There is plenty in Android which isn't the work of Google. For starters the Kotlin implementation and the Java implementation (OpenJDK).
I believe this isn't actually about "Android" at all but rather Pixel. Android is still openly accessible on git. But the kernel sources for Pixel devices is now behind this big song & dance for some fucking inexcusable reason.
They stopped pushing tags for any of the Pixel kernel or userspace driver repositories to AOSP. They also stopped pushing AOSP releases specific to Pixels which is why AOSP now only gets yearly releases, QPR2 releases and security backports to both of those. Other OEMs are meant to use the yearly and QPR2 releases along with the security backports to those so that's all they push. The monthly and QPR1/QPR3 releases aren't used by their OEM partners so they stopped pushing them to AOSP. Those no longer being pushed is because of them deciding AOSP doesn't support Pixels anymore.
(However, that's quite orthogonal to being a dick about making the source code that you must share available)
I'm refering to Bootloaders, TrustZone OS, Trusted Applications, then firmware for Bluetooth, Wifi, GPU, Sensors and power management. All of those are always closed source binary blobs running in the background.
I hate Google as much as the next person, and the only way with those companies would be to fine them heavily, quickly and systematically.
But it is important that we are clear about what Google does bad and what it does well. And I believe that understanding what "open source" means is important when one wants to talk about a violation of an open source licence.
Open source does not mean that they take contributions. Many firmwares used by Android are not open source, but AOSP is open source. It is licenced under a permissive licence (Apache 2, I think for everything), which makes it open source, period.
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 word “easily” sure did sneak into this sentence
I'm sure this means the source happens to be open rather than following the spirit of open source.
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.
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."
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."
It is definitely a dick move by Google.
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).
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,
...
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.
[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.
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.
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 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)?"
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.
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.
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.
If someone on HN has received one of these links, feel free to post it here.
But I would think the link is access to google's servers, which might be different.
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.
The thing is, AOSP is open source. Just like Linux is not controlled by one of the TooBigTechs, I could imagine a fork of AOSP becoming a viable alternative without depending on Google anymore.
And supporting alternative Android OSes (like GrapheneOS and LineageOS) is one way to support that vision.
Linux on Mobile is nice, but unfortunately I think it's an uphill battle because of all the proprietary firmwares?
In my GNU/Linux phone, all drivers are FLOSS and all pieces of firmware are backed into the replaceable peripherals (modem M.2 card and WiFi M.2 card).
Google's upcoming change means Google Mobile Services operating systems will show a warning for apps from unverified developers. Bypassing the warning will require a one-time 24 hour wait via the regular user interface. It can be immediately bypassed using Android Debug Bridge instead.
Developers with Play Store apps are already verified. It's counterproductive for app developers with existing Play Console accounts considered verified to refuse to register their apps distributed outside of the Play Store. That would encourage users to stick to the Play Store.
The problem is for developers without a Play Console account who would need to register and verify their identify to avoid their apps showing a warning. If people are already registered, they might as well list their apps distributed outside the Play Store to avoid the warning.
I doubt it, considering Android developer verification will go through Google Play Services, which GrapheneOS has siloed off from most of the OS as far as I'm aware.
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.
But the other reason is that most of Android’s openness is quickly disappearing, so my main argument against iPhone is gone. And on the topic of privacy, I actually trust Apple way more than I trust the company that makes most of their revenue via advertising.
Source: about 12 years of Android usage (11 of those on unlocked bootloaders and custom ROMs, ~6? of those deGoogled) -> iPhone 16e.
For the first half, custom ROMs were a massive boost to the experience, but I never really bothered after 2018; You had to install so much of google's stuff to get 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 :(
What was it? Personally, the only thing I miss from stock Android is the Google Wallet/Pay/Wallet. (I do use microG to get push notifications and embedded maps working.)
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.
https://www.businessinsider.com/apple-gets-serious-about-its...
https://www.wired.com/story/apple-is-an-ad-company-now/
https://www.bbc.co.uk/news/business-67417987
https://www.businessinsider.com/apple-tests-ai-app-store-ads...
Apple is not some magic solution to the question of on-device privacy. But compared to Android, the improvement is night and day.
Time to start over.
yes and Apple does it for the 30% lock-in. Apple does it to protect their ecosystem. Apple also does not care about their customers, their developers, their suppliers or their employees. Closed systems do not help the populous. This is about money, captive audience and subscription revenues.
Google claims an openness that doesn’t exist anymore