https://cs.android.com/android/platform/superproject/+/andro...
Tl;Dr: google has certain commitments they need to make depending on when the source code is released. Expect more delays moving forward thanks to this law.
[1]: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL...
I wonder if 3.99 inch and 7.01 inch smartphones will start appearing again.
also this: does this mean that foldable phones with three 3.99" screens are excluded
It reads to me like the opposite. Another case of manufacturers being unable to release updates in a prompt manner. Google delaying the release gives them more time to update.
…or when OS updates are released, see Annex II B 1.2 (6) (c) and (d) ("Smartphones" > "Design for reliability" > "Operating system updates")
So given that the updates were already released months ago, the release of the source code is irrelevant.
> 2025110800: All of the Android 16 security patches from the current December 2025, January 2026, February 2026 and March 2026 Android Security Bulletins are included in the 2025110801 security preview release. List of additional fixed CVEs:
So, have they been released? No. So the clock hasn't started ticking yet. This EU law made security worse for everyone as patches that are done today are not released for 4+ months.
Note: These are CLOSED source blobs GrapheneOS is shipping. If they were open source, the 4 months clock would trigger immediately but they are not allowed to do this themselves as they get the patches from an OEM partner. GrapheneOS shipping these CLOSED source blobs, that Google has NOT released does not trigger the timer.
I do accept that QPR1 was 'released' by Google on Pixel months ago, and therefore the timer started, however, Google will likely pick and chose what is best for OS updates/security patches. It explains why AOSP is now private/closed source and embargos are being used to get around the laws requirements.
[1]: https://grapheneos.org/releases#2025110800
From the EU law:
> (c) security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
> (d) functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
Either way, I don't understand what point you're trying to make. Even after reading your other comments here in this subtree, I don't see anything in the regulation you linked that would have delayed the source code release of Android 16 QPR1, given that the QPR1 binaries had already been released.
If this open-source release was to contain new patches, they must now ship these changes within 6 months. The Pixel OS release counts as the first 6 month timer. The source code release, by definition, now counts as the 2nd timer.
I expect the closed source binaries and public source code to be the same, but that may not always be the case. So OEMs are expected to at least in 6 months ship an update with the open-source code.
> or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider
They have not released the source code, but they have released an update of their operating system on their reference Pixel hardware.
Therefore, all devices must update within 4 months of that Pixel release, regardless of source drops, per this law
I would also argue a closed source release in August 2025 would start the first 6 month timer (February 2026) and the source code release to trigger another timer (if they differed in any way between the closed source release).
A lot of this law is abstract and only if the EU challenges Google's approach would it be decided how it's meant to be applied in reality.
Your comment seemed to imply that a source release would trigger a different timer than a binary release, which is explicitly covered as the same thing in the law - for both the 4 and 6 month timers.
I fail to see how this EU regulation promotes releasing software Closed Source and demotes releasing it Open Source.
> (d) functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
So if Google releases an update for Pixel, the 'clock' starts ticking from that date, otherwise, it goes by when the source code is released. Google can pick and choose what works best for them and their partners according to these rules.
Hence why delaying the source code may be preferable. This is why security patches are being delayed as per GrapheneOS (under embargo)
For example: Google releases Android 20, under embargo to all OEMS, this is not released on Pixel, is entirely closed source (hence why AOSP is now private) and therefore doesn't trigger the law. Android 20 could be ready for months, but until it's released on Pixel or open source, those clauses are not triggered. This is already happening to security patches, see my comment above.
A more correct expectation would be that now Google will start delaying all security updates (both binary and source) until all their important downstream vendors are able to release in time.
Even that is doubtful, as Google would have to take the reputational damage for an ongoing exploitation of a security issue.
The functional updates though might get slowed down.
It's quite bad as security patches used to take around a month, now it's around 4 months and the patches are being leaked to threat actors who can exploit the bugs until the patches are released.
Example: A patch is fixed on September 1st, released under embargo/closed source to all OEMs. Pixel issues the patch in December 1st publicly (either source code/software update), they now have until April 1st (4 months) to release it according to the law. So the patch is 7 months old before it has to be released according to the law.
All the march 2026 updates are done, now, today, and ready/waiting, but they are not released by Pixel/open source. Once that happens the timer will begin.
This EU law has made security far worse.
I don't get it. Why not release it now and start the timer now? Shitty OEMs would get in trouble (not Google) and that would be a fantastic outcome. Am I missing something?
Stop blaming the EU. They didn't make security worse. It's Google and the other manufacturers who decided to respond to this law by using a loophole that made security far worse.
Now, we have patches already for March 2026 in November 2025. Once the March 2025 patches are shipped by Google, OEMs have 4 months for all OEMs to ship it (deadline being July 2026).
Consider this scenario:
Patch for bug lands January 2026. Google decides to either release a Pixel OS update or release the source code in 8 months time containing this patch for whatever reason. Then a 4 month timer starts for all OEMs to ship that patch. Meaning a patch that has existed from January 2026 can now be shipped by January 2027 under this system and fully comply with the law. This patch may be under active exploit as OEMs have leaked it which again, GrapheneOS have admitted is happening.
Previously, patches would be landing within the month. All google must do is ensure this patch is not included in any pixel OS update or public source code release.
Yes, Google is responsible, but when the EU touts laws as fining 4% of global turnover (in the case of GDPR), then they are going to be taken seriously, which means OEMs demanding Google not release the update for Pixel/source code until they are ready and use this loophole as they are doing.
The loser is ultimately the end user who has a weaker more exploitable device for months.
In reality, it's a purely political decision to curb the development of third-party ROMs, because the AOSP source code exists with all the merges and is distributed to vendors (like Samsung). However, it's not necessarily just to target GrapheneOS and LineageOS; it might also be to target the Chinese market, particularly Huawei, which uses this source code for HarmonyOS.
This is the entire reason AOSP went private/closed source, and why Google is delaying security patches as per GrapheneOS. The March 2026 patches are already released by GrapheneOS as closed source blobs. They are not allowed to release them as open source by embargo (essentially NDA). Why do you think Pixel hasn't shipped security patches earmarked for March 2026? There are some critical bugs those patches fix, why not release them today, right now or next month? Because if Pixel releases just a single patch, via a Pixel update or posts it on AOSP, the 4 month timer begins for every single OEM with a phone in the EU. By making the patches under embargo, Google gets to control exactly when the timer starts to coordinate with their OEMs. So the slowest OEM gets to control the entirety of Androids security model.
Ask yourself, why doesn't GrapheneOS just release their patches publicly/open source? Why have different 'security releases' with closed source blobs?
Because if they did:
1: They lose their partner OEM access to these patches
2: Every OEM would be required to release those same patches 4 months to the day GrapheneOS releases them.
And that's exactly what the law was about, this timer is a good thing. Now they should close the "artificial delay" loophole.
I don't think that's true since the regulation you linked says:
> (c) security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
(emphasis mine)
GrapheneOS is not the OS provider in this context, Google is.
> at the latest 4 months after the public release of the source code of an update of the underlying operating system
So if somebody reverse engineers the patch, or releases the patch under embargo (which the OEMs would have the source code) that would count as a 'public release'. So GrapheneOS can ship closed source patches as you are right, they are not the provider. If GrapheneOS released the source code they are getting from their OEM then it would count as a 'public release of the source code'.
A patch in itself can be considered an 'update of the underlying operating system' and therefore the moment it becomes public it needs to be patched by all OEMs within 4 months.
GrapheneOS have themselves said that if somebody did reverse engineer the closed source blobs and posted them publicly they could then ship the patches openly at that point but not until.
It must be stated a lot of the wording of this clause and interperetation of what is/is not considered 'publicly releasing source code' is up for debate/courts to settle.
kamranjon•2mo ago
josephcsible•2mo ago
bitpush•2mo ago
Do you really need to have snark for an open source project?
pseudosavant•2mo ago
wongogue•2mo ago
josephcsible•2mo ago
[1]: https://www.financecharts.com/screener/most-profitable
[2]: https://news.ycombinator.com/item?id=43484927
goku12•2mo ago
And let's not forget this part. Android is a member of the mobile platform duopoly. Another similar project - Chrome - is almost a monopoly among web platforms. Both these projects exploit the open source label and most people's false belief that open source somehow equates to respect and protection of user rights. (Philosophically, it's only free software that cares about user rights. Both projects are textbook examples of non-free open source software.) This actually protects these projects to some extend from criticisms and penalties against the dark patterns that they employ to corrupt and exploit both the mobile and the web ecosystems. They absolutely don't deserve the same considerations as the passionate and underpaid small teams or individual maintainers.
ehnto•2mo ago
izacus•2mo ago
It's their work, their OS and we have others.
dvdkon•2mo ago
Caring about the products you use is pretty standard behaviour, and when the product changes under the user's hands, it's normal to complain. It can resolve the issue faster and less painfully than switching products would.
izacus•2mo ago
The fact of the matter is that Android is fully funded and developed by Google and you kinda don't have much standing to control what they do with their project and how - especially if all you can say is that their work is bad.
You can be unhappy about it, but it doesn't change that its their work and their money on the line here with very little relationship to you or your wishes. You're not even a paying customer.
This doesn't apply to "any product or changes" at large.
guizadillas•2mo ago
izacus•2mo ago
You don't become a paying customer of Linus when you get a Thinkpad with Ubuntu.
guizadillas•2mo ago
I don't become a PAYING customer of Linus because Thinkpad didn't pay for Ubuntu (and if anything was paid I would become a customer of Canonical)
ehnto•2mo ago
izacus•2mo ago
ehnto•2mo ago
Being more constructive, the future isn't looking bright for freedom of choice in mobile OSes, as governments and banks enforce use of approved apps on approved devices for identification and banking. Without one of either an Android or an iPhone, things get difficult. My government for example can consider a phone running something like GrapheneOS a Criminal Device.
Android is the most open of the two, being open source, so it would be nice if it stayed that way.
MarsIronPI•2mo ago
estimator7292•2mo ago
o11c•2mo ago
With GPL-only code, the world would be much nicer for all of us.
semi-extrinsic•2mo ago
Would it really be impossible to have a license with similar brevity as MIT but similar consequences as GPL?
dtech•2mo ago
debugnik•2mo ago
The GPL is particularly bad here as it pretends to define what is or isn't a derivative work, which is outside the scope of a licence but within the scope of a court. The EUPL was created partly because EU directives bound the viral clause in ways the FSF won't admit to, although that one isn't simple either (I'm not a fan of its compatibility clause).
graemep•2mo ago
Sounds like you need a better lawyer.
The consequences of the GPL are not all that complicated. In most cases it boils down to offering the source if you distribute the code outside your organisation.
regularfry•2mo ago
graemep•2mo ago
regularfry•2mo ago
fsflover•2mo ago
It's like saying that display is a "random artifact" of a computer not making any difference in its design or usage.
regularfry•2mo ago
this_user•2mo ago
Therein lies the problem. When dealing with the law, you don't want to be relatively sure that you won't go to prison or won't get sued for $1M, you want to be completely sure.
Something like the GPL is complex and non-standard as far as its interactions with the legal system go, because it is essentially a sort of hack of copyright law. If it goes before a court, you have no idea what might potentially happen. So rather than deal with that kind of complexity and uncertainty, you'd use something under MIT or Apache License that is just much better understood.
graemep•2mo ago
Not really. Unless you are redistributing it does not affect you at all.
> Something like the GPL is complex and non-standard as far as its interactions with the legal system go
it is widely used, and most people are running some copyleft software anyway, most commonly GPL or a variant such as LGPL. Linux servers, Android phones, routers, web browsers....
lelanthran•2mo ago
Any IP lawyer who hasn't come across the GPL yet is probably not worth listening to.
I mean, would you listen to a bridge engineer who hasn't yet heard of a calculator? Sure, they may understand their shit, but if they haven't heard of calculators yet they are clearly not in the industry.
Any IP lawyer who hasn't yet read the GPL and formed a professional opinion on it isn't equipped to handle IP matters at all.
fweimer•2mo ago
bigstrat2003•2mo ago
oliwarner•2mo ago
All for naught, I fear, while LLMs consume all and regurgitate license-free to vibe-coders everywhere.
goku12•2mo ago
It is no more inflammatory than the coordinated war that was waged against copyleft licenses on tech fora and social media for more than a decade before hackers started to realize en masse that it was all a ploy to extract free labor from them. There are legitimate uses for permissive licenses and I still use them for those. But the big players certainly pushed them well beyond those cases where they made any sense. More than enough evidence has since emerged that prove this to be the case.
It does no one any favors to deny the presence of bad actors and their malintent behind the utter mess we find ourselves in right now. I find it disturbing that whenever people express their frustration regarding this, there are attempts to shoot them down with accusations of inflammatory language, political correctness, etc. But the truth is that the big players have caused far far more damage than any inflammatory citicism they face for it now. What's actually unhealthy for good discussion is the dystopian censorship of criticisms because the truth make some people uncomfortable. Every bit of harsh criticism they receive here is something they willfully and rightfully earned.
embedding-shape•2mo ago
I think you're missing the point.
There are developers who prefer MIT not because they're a "big player" or "because truth make people uncomfortable", people simply have different preference for what the ideal license is for their project.
If you cannot deal with that, that sounds like a you problem, but judging by your comments, you're not exactly gonna re-evaluate with a different perspective, since you seem unable to understand others have different ideas and opinions than you.
fsflover•2mo ago
> There are legitimate uses for permissive licenses and I still use them for those.
The parent didn't talk about forcing developers to choose copyleft. And you ignored the stated legitimate reasons for choosing copyleft in most cases if you care about the society.
coldtea•2mo ago
So "to each their own" only goes so far.
One can very well accept that other devs/teams have different ideas and opinions && that they can (by law) have such ideas and opinions, but also think that they have them for the wrong reasons, and that they shouldn't have them, and that we'd all be better off if they didn't.
goku12•2mo ago
> There are developers who prefer MIT not because they're a "big player" or "because truth make people uncomfortable", people simply have different preference for what the ideal license is for their project.
Did you miss this part in my comment?:
> There are legitimate uses for permissive licenses and I still use them for those.
Or this part from GP's comment?:
> being able to do this is the reason why companies have brainwashed the Internet into ...
Or this part?:
> ... choosing the MIT license for everything
(emphasis mine) All of these imply that the companies did a mass campaign and not individual brainwashing. They also imply that the MIT license is not suitable for everything and by corollary that there are instances where they do apply. All of it are aimed at the companies that resorted to these underhanded tactics. Where does any of these imply that every single use of the MIT license is due to brainwashing? I can't understand how anyone concludes instead that it's all a personal attack on MIT license users (that includes me too).
> If you cannot deal with that, that sounds like a you problem, but judging by your comments, you're not exactly gonna re-evaluate with a different perspective, since you seem unable to understand others have different ideas and opinions than you.
Not only does one have to deal with people reinterpreting others' comments according to their convenience, they also have to withstand guilt tripping based on it. And the irony is that you cite my complaint about the same issue for it!
graemep•2mo ago
There are at least three different groups of people here:
1. Those paid to write permissively licensed software - not free labour.
2. Those who are happy to be free labour. I read a comment by a BSD developer about being very proud and happy to be able to buy a games console that ran on a BSD derived OS.
3. Naive people who are are shocked when someone creates a proprietary fork of their code. It is something that they explicitly gave everyone permission to do, and it is something that has been happening for decades - I can think of Windows using BSD network code in the early 90s, but there are probably much earlier examples. Apple's OSes are very high profile examples since 2001, and Nextstep before that.
The last group have themselves to blame. Did they not take the trouble to understand a legal document? Do they know nothing about the history of their industry? Do they takes steps to stop it - for example by doing releasing updates under a copyleft license?
I agree with you that big players do push licenses that suite themselves, but it relies on either deliberate choice or foolishness by contributors for it to work. I also think copyleft is usually of greater benefit to society.
goku12•2mo ago
ahartmetz•2mo ago
sgc•2mo ago
walterbell•2mo ago
Large companies will self-enforce, as they already do with GPL and "open" LLMs that are dual licensed by company size. Small companies don't care either way and are hard to enforce, so that works.
Any pointers to open/closed vendors and projects which use this kind of honor system?
EU CRA has "commercial use" definitions to differentiate OSS contributors and OSS consumers.
sgc•2mo ago
graemep•2mo ago
attila-lendvai•2mo ago
but in the current reality around us, i believe it's a more nuanced issue.
MYEUHD•2mo ago
The GPL is the reason we have Android custom Roms today.
berkes•2mo ago
The speculation has merits and makes sense. But is speculative nontheless.
pjmlp•2mo ago
kuschku•2mo ago
Where can I get the source of the exact kernel running on iOS devices, including all drivers?
How about the Playstation 4 or 5? Where can I get the source of their FreeBSD fork?
fabrice_d•2mo ago
No, most drivers are closed source and you can just extract binary blobs for them. They run as daemons that communicate through the binder ipc - Android basically turned the Linux kernel into a microkernel.
pjmlp•2mo ago
Traditional Linux drivers are considered legacy in Android.
https://source.android.com/docs/core/architecture/hal
oneshtein•2mo ago
guerrilla•2mo ago
MYEUHD•2mo ago
In order to build a custom Rom, you need three things: the kernel tree, the device tree, and the binary blobs.
The binary blobs can be extracted from a running phone.
The kernel tree is GPL-licensed, so almost all phones have kernel trees releases, and if they don't you can ask the manufacturer for it.
The device tree on the other hand, is created from scratch for each phone. As such, there is no pre-existing license, and therefore no legal obligation to release device tree sources, so almost no manufacturer does. The only notable exception is Google with their Nexus and Pixel phones. (But this has stopped since with the Android 16 release)
We can safely assume that the manufacturers that don't release the device trees, wouldn't have released kernel trees if they weren't obliged to.
To go into more details:
The device trees are relatively easy to make. So, their absence doesn't represent a big hurdle. See for example https://xdaforums.com/t/guide-how-to-make-a-device-tree-for-...
But adding support for a device to the Linux Kernel requires _huge_ reverse-engineering efforts. This is why there's still no fully functional Android build for iPhones.
Someone•2mo ago
And a license to use the binary blobs for that purpose. Is it a given that doing that is allowed?
qdotme•2mo ago
Some have "interoperability exceptions" - so if you have been granted a license to something, you can reuse it in different context (so for instance you could run Microsoft Office on WINE even if Microsoft's license forbids it).
Some have restrictions on redistribution (but the builds just using the blobs from the old filesystem are fine).
A lot of that is in the gray area, and for that very reason many builds don't actually redistribute blobs - they extract and reuse them live.
samrus•2mo ago
creshal•2mo ago
smallnix•2mo ago
Are you arguing that more good things would go upstream if it were licensed non-permissive or are you giving an example were it works well enough?
dsr_•2mo ago
It's not healthy.
kamranjon•2mo ago
It definitely seems like MIT is favored by big corps but at the end of the day, they’ll use GPL licensed code if it’s the best option. Which makes me wonder why it’s so demonized.
yupyupyups•2mo ago
I would be happy to hear from anyone who knows about this subject if what I'm saying is correct.
regularfry•2mo ago
fweimer•2mo ago
whatevaa•2mo ago
Octoth0rpe•2mo ago
That linux uses GPL is entirely irrelevant to the vast majority of uses of it. What hosting services are customizing their kernels with proprietary code?
shadowgovt•2mo ago
Because failing to manage their GPL obligations led to a lawsuit for D-Link followed by a compulsion to release a lot more code than they ever planned to share online, to the company's detriment.
You can pretty much look at the stock value before and after they lost the lawsuit. There was, notably, a big value spike immediately after, but the value then settled down to an average of around 15 a share, markedly below their previous 30 a share.
For some companies, the value is in the proprietary content and using GPL would be shooting themselves in the foot.
nrclark•2mo ago
The tl;dr is that for any GPLv3 software that you ship, you have to also give your users a way to install a modified copy. If you're trying to ship a secured product, that basically means that you have to give code/rootfs signing keys to your customers. This is a non-starter for many kinds of products that need tamper protection (whether for product, legal, or safety reasons).
The Linux kernel remains on GPLv2, and is still used quite heavily. Most GNU software (coreutils, gcc, etc) moved to GPLv3 and then commercial companies abandoned them in favor of permissively-licensed replacements.
Y_Y•2mo ago
Fuck that. If it's my device then I want to have control. If I want to violate part 15 of the FCC rules then I'm going to do it and nobody is going to stop me. This paternalistic rubbish has to stop, I'm sure your company would love to retain ultimate control of the thing you've sold me, but that's not compatible with a free society.
nrclark•2mo ago
samrus•2mo ago
Welcome back 2005 bill gates
oneshtein•2mo ago
josephcsible•2mo ago
josephcsible•2mo ago
F3nd0•2mo ago
jajuuka•2mo ago
miroljub•2mo ago
beeflet•2mo ago
F3nd0•2mo ago
josephcsible•2mo ago
You're mixing up freedom and power. See https://www.gnu.org/philosophy/freedom-or-power.en.html for an explanation.
kelnos•2mo ago
cxr•2mo ago
shadowgovt•2mo ago
cxr•2mo ago
samrus•2mo ago
utopiah•2mo ago
ncruces•2mo ago
Most of, if not all, code that was released today was written by Google. Then can release it, or not release it, regardless of license.
Android was never a community project with outside contributions. The license does not limit the original authors.
I'm not saying Google shouldn't have released them immediately. But GPL vs Apache vs MIT has absolutely nothing to do with it.
Vinnl•2mo ago
miroljub•2mo ago
According to the GPL, the only thing they would have to do is provide source code to the users of their software upon their request.
Vinnl•2mo ago
lenerdenator•2mo ago
Personally, I MIT/BSD my stuff because, well... it means I don't have to think about it ever again. If I do GPL, I have to make sure that I'm following the rules set out in that license and making sure others who have based their code on my project have done the same.
And that's, like, work, man, especially if you don't have a foundation and legal eagles on your side to double-check that everything's kosher.
Linux is an exception, not a rule, in how GPL is usually handled in FLOSS projects.
pwg•2mo ago
I do not believe the GPL requires that you make sure others who fork your code follow the GPL's rules.
It places restrictions on those others, but does not require you verify that those others follow the restrictions.
lenerdenator•2mo ago
BenjiWiebe•2mo ago
It doesn't force you to go after them.
With MIT, you Google would have no obligation at all to provide anything.
lenerdenator•2mo ago
That's just it, though. If it doesn't carry any sort of possibility of being enforced, well... why bother? I could just go with the easier-to-understand license, like someone upthread mentioned.
If we're going to see the promised tech ecosystem that GPL's authors aimed to provide, we're going to need more people to take it seriously. Most people don't want to take it seriously, and if that's the case, we're better off if they just went with MIT/BSD.
pessimizer•2mo ago
The GPL is a statement you're making about the rights that other people are granted when it comes to your code. It's not a personal pledge. Exactly like every other license btw; they aren't oaths. You're also not required to police or sue people who break your license. It's your code.
pwg•2mo ago
Very simplified differences:
GPL: you shared the code with others, those others, if they modify your code, must continue to share their changes with others
MIT: you shared the code with others, those others can do as they please, including not sharing any changes they make to the code with anyone
hilios•2mo ago
If its all your own stuff you don't really have to care about the license. Otherwise the rules are pretty simple, include a GPL license and if requested by a user supply the source code (which you can even charge some money for).
>and making sure others who have based their code on my project have done the same.
If you don't care what others do with it, you don't have to enforce it.
As the sole copyright holder (A)GPL only gives you more options.
singpolyma3•2mo ago
RicoElectrico•2mo ago
rkagerer•2mo ago
jhasse•2mo ago
joecool1029•2mo ago
gpm•2mo ago
berkes•2mo ago
thevillagechief•2mo ago
jamesnorden•2mo ago
rk06•2mo ago
lawn•2mo ago
degamad•2mo ago
Edit: never mind, this is just an article quoting the post at the top of this discussion.
jeffbee•2mo ago