Android 16 QPR1 rolled out in binary-only form to phones that are blessed by Google over two months ago, and it's only just now that they bothered to actually release the source of their open-source operating system.
And it is very important to remember: being able to do this is the reason why companies have brainwashed the Internet into choosing the MIT license for everything.
With GPL-only code, the world would be much nicer for all of us.
Nobody needed to "brainwash" me into choosing the MIT license for my projects. I choose it because I disagree with the philosophy of the GPL, and think that true freedom requires the freedom for others to make their own licensing choices. You are quite welcome to disagree with that stance, but please cut out the inflammatory language. It's not charitable towards others and it isn't healthy for good discussion.
This is probably the biggest and most successful example of utilizing non-permissive open source licensing for the public good - I’m curious why so many places I’ve worked have insisted on avoiding using libraries with GPL licenses in favor of MIT licensed projects, while at the same time hosting all of their services on different flavors of Linux.
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.
Compatibility with proprietary dependencies that the company cannot control. If I'm not mistaken, GPL requires the release of the dependencies' source code too if there are no other implementations around.
I would be happy to hear from anyone who knows about this subject if what I'm saying is correct.
See also, FreeBSD: Plenty of commercial offerings around it, no source for most of them, because the license doesn't require it. For example, there's no source for the Playstation kernels/userlands released by Sony. They only upstream some bug fixes that would be too onerous to keep in their private fork.
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.
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.
Not at all. We have a lot of experience with this with such licenses and other software. BSD as just one example. Not only do we have a pile of emperical evidence, it's also a priori obvious: they're not going to expend any effort or take any risk if its not neccessary. They can just benefit without paying.
Easy see the upstream contributions from any commercial vendor that has integrated BSD into their UNIX flavours, or the alternatives that exist nowadays for embedded FOSS operating systems, none of them GPL.
It's the tolerance against intolerance paradox, basically. The freedom to take away freedom. I'm leaning towards not giving that freedom, but it's complicated.
A good example of that is Apple moving from bash to zsh, because bash moved to GPL 3 which prevents locking down devives. It was very specifically because they wanted the freedom to take away their users' freedom.
I will say here something I have said and has proved unpopular before. The complexity is mainly something of scale. I would propose more permissive MIT style licensing for small companies, and something stricter for larger companies. It is hard to enforce (which was the main complaint I got), but it's not impossible and I think it is better than the current state of affairs.
Despite anyone's personal views, it's undeniable that corps favour a Free they can use as they wish. It's also fairly evident that they make this favour known through their culture. Brainwashing may be a bit far, but only just.
All for naught, I fear, while LLMs consume all and regurgitate license-free to vibe-coders everywhere.
Then you care about a different kind of freedom than GPL proponents: licensing freedom, rather than user freedom, basically. There is no 'true freedom', as it comes down to the point of view; no licence will give you both at the same time.
Agree 100%. I gave up on the GPL before I even knew what exactly it was about because of the zealotry of many of its proponents. I would even go as far as saying that without the FSF, GPL-like licenses would be much more common.
Any half-decent person is going to keep on breathing. It's one of the basic prerequisites of bringing some value to society. Not breathing is selfish and completely misses the point of life. If you're going to exist, then breathe; it's really as simple as that.
ideally -- without a legal system using force to stop people using knowledge (IP laws), -- i would be on your position. in fact, i used to agree with you.
but in the current reality around us, i believe it's a more nuanced issue.
> You are quite welcome to disagree with that stance, but please cut out the inflammatory language. It's not charitable towards others and it isn't healthy for good discussion.
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.
> hackers started to realize en masse that it was all a ploy to extract free labor from them.
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.
> What's actually unhealthy for good discussion is the dystopian censorship of criticisms because the truth make some people uncomfortable
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.
Others having different ideas and opinions doesn't mean that those ideas and opinions are correct, or that they are beneficial. They might be detrimental to the FOSS movement or to society in general.
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.
> 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!
> 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.
Some of the reason why the MIT license etc. is more popular surely has to do with the license text itself. I can understand the MIT license, and my corp lawyer can easily understand all the consequences of using something under MIT license. With the GPL, not so much. It's verbose and complex and has different versions.
Would it really be impossible to have a license with similar brevity as MIT but similar consequences as GPL?
Brevity maybe, but ease of understanding no. Copyleft licenses interact with copyright law in ways that permissive licences just don't need to. The closest you can get is probably MPL-2.0.
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).
No, the MIT license is short exactly because it has so little restrictions. You simply can't encode the desired result of GPL into 160 words like MIT can.
> I can understand the MIT license, and my corp lawyer can easily understand all the consequences of using something under MIT license.
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.
Right, I think people misunderstand "free" when they are dominating versus "free" when they are the smaller player. One is a tool for domination and capture, the other is a tool for freedom ESPECIALLY against a bigger player.
I mostly agree, unless the new release modifies GPL code submitted by other entities than Google - their licensing of that code under GPL would force Google to release the rest too.
Open-source projects maintained by individual developers working for free absolutely deserve more respect than that, but ones maintained by the most profitable company in the world [1] do not, especially when they go out of their way to change from doing the right thing to doing the wrong thing [2].
> ..., especially when they go out of their way to change from doing the right thing to doing the wrong thing.
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.
This means the source code is finally being released for the quarterly release that came out in september. Roms like lineageos had to target QPR0 which came out back in June but can now bring up to this. Google used to release the source to AOSP right after the releases happened, now they don't.
Additional context per fediverse thread: The GPL code (i.e. kernel) was released on time, this is the AOSP userspace portions which Google isn't legally obligated to release (which doesn't make it not a dick move not to).
What's the current status of custom ROM development these days!! I hv been out of the sync for a while. It seems mostly dead except for few players like LOS, Graphene, Paranoid (prolly), I guess there are still some smaller enthusiasts, but they probably just kang old code and features rather than providing stable support.
GOS is not "paranoid", lol, it's just releasing the fastest asd adding cherry on top, and not bundling Google services (but allowing you to install them)
If you're wondering for a possible reason and whether google is just being "lazy", see [1].
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.
And what does 'released' mean in this context? GrapheneOS has very publicly stated that security patches are under embargo, and they already have patches for the March 2026 release. See [1]:
> 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.
> (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;
it has an integrated touch screen display with a viewable diagonal size of 10,16 centimetres (or 4,0 inches) or more, but less than 17,78 centimetres (or 7,0 inches);
I wonder if 3.99 inch and 7.01 inch smartphones will start appearing again.
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.
This has absolutely nothing to do with that law, and even Google doesn't dare use it as an excuse for its behavior (as they did with GDPR by deliberately creating user friction that the European regulation did not require, and even partially forbids).
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.
What? Please explain what commitments exactly are causing Google to not release source code at the same time as the update. Until you do that, your statement is as valuable as writing 'Thanks, Obama!'
> (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;
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.
So EU mandates that security updates in either source OR binary form must hit all users in at most 4 months after they are first published, therefore Google started delaying releasing source code and will start delaying it even more?
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.
Here is a link to view it.
https://cs.android.com/android/platform/superproject/+/andro...
Can someone with more context explain what this means and maybe the background?
Android 16 QPR1 rolled out in binary-only form to phones that are blessed by Google over two months ago, and it's only just now that they bothered to actually release the source of their open-source operating system.
And it is very important to remember: being able to do this is the reason why companies have brainwashed the Internet into choosing the MIT license for everything.
With GPL-only code, the world would be much nicer for all of us.
Nobody needed to "brainwash" me into choosing the MIT license for my projects. I choose it because I disagree with the philosophy of the GPL, and think that true freedom requires the freedom for others to make their own licensing choices. You are quite welcome to disagree with that stance, but please cut out the inflammatory language. It's not charitable towards others and it isn't healthy for good discussion.
If the Linux Kernel was licensed permissively, none of the phone manufacturers would've released the source code of their kernel trees.
The GPL is the reason we have Android custom Roms today.
This is probably the biggest and most successful example of utilizing non-permissive open source licensing for the public good - I’m curious why so many places I’ve worked have insisted on avoiding using libraries with GPL licenses in favor of MIT licensed projects, while at the same time hosting all of their services on different flavors of Linux.
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.
Compatibility with proprietary dependencies that the company cannot control. If I'm not mistaken, GPL requires the release of the dependencies' source code too if there are no other implementations around.
I would be happy to hear from anyone who knows about this subject if what I'm saying is correct.
That's certainly the FSF's stance, but I don't know if it's been tested.
Lawyers are cautious people, not accepting interpretations. Until courts say otherwise, GPL is too high of a risk to use as a library.
See also, FreeBSD: Plenty of commercial offerings around it, no source for most of them, because the license doesn't require it. For example, there's no source for the Playstation kernels/userlands released by Sony. They only upstream some bug fixes that would be too onerous to keep in their private fork.
That's entirely speculative.
The speculation has merits and makes sense. But is speculative nontheless.
It's not speculation.
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.
Not at all. We have a lot of experience with this with such licenses and other software. BSD as just one example. Not only do we have a pile of emperical evidence, it's also a priori obvious: they're not going to expend any effort or take any risk if its not neccessary. They can just benefit without paying.
Easy see the upstream contributions from any commercial vendor that has integrated BSD into their UNIX flavours, or the alternatives that exist nowadays for embedded FOSS operating systems, none of them GPL.
I can get the source of the kernel, including all drivers, running on my android phone with a few clicks and build a custom ROM.
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?
It's the tolerance against intolerance paradox, basically. The freedom to take away freedom. I'm leaning towards not giving that freedom, but it's complicated.
A good example of that is Apple moving from bash to zsh, because bash moved to GPL 3 which prevents locking down devives. It was very specifically because they wanted the freedom to take away their users' freedom.
I will say here something I have said and has proved unpopular before. The complexity is mainly something of scale. I would propose more permissive MIT style licensing for small companies, and something stricter for larger companies. It is hard to enforce (which was the main complaint I got), but it's not impossible and I think it is better than the current state of affairs.
Despite anyone's personal views, it's undeniable that corps favour a Free they can use as they wish. It's also fairly evident that they make this favour known through their culture. Brainwashing may be a bit far, but only just.
All for naught, I fear, while LLMs consume all and regurgitate license-free to vibe-coders everywhere.
Then you care about a different kind of freedom than GPL proponents: licensing freedom, rather than user freedom, basically. There is no 'true freedom', as it comes down to the point of view; no licence will give you both at the same time.
Agree 100%. I gave up on the GPL before I even knew what exactly it was about because of the zealotry of many of its proponents. I would even go as far as saying that without the FSF, GPL-like licenses would be much more common.
If I zealously advocated for you continue breathing, would you strangle yourself to spite me?
Any half-decent person is going to keep on breathing. It's one of the basic prerequisites of bringing some value to society. Not breathing is selfish and completely misses the point of life. If you're going to exist, then breathe; it's really as simple as that.
ideally -- without a legal system using force to stop people using knowledge (IP laws), -- i would be on your position. in fact, i used to agree with you.
but in the current reality around us, i believe it's a more nuanced issue.
> You are quite welcome to disagree with that stance, but please cut out the inflammatory language. It's not charitable towards others and it isn't healthy for good discussion.
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.
> hackers started to realize en masse that it was all a ploy to extract free labor from them.
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.
> What's actually unhealthy for good discussion is the dystopian censorship of criticisms because the truth make some people uncomfortable
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.
Others having different ideas and opinions doesn't mean that those ideas and opinions are correct, or that they are beneficial. They might be detrimental to the FOSS movement or to society in general.
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.
> 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.
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!
The parent did say
> 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.
Some of the reason why the MIT license etc. is more popular surely has to do with the license text itself. I can understand the MIT license, and my corp lawyer can easily understand all the consequences of using something under MIT license. With the GPL, not so much. It's verbose and complex and has different versions.
Would it really be impossible to have a license with similar brevity as MIT but similar consequences as GPL?
Brevity maybe, but ease of understanding no. Copyleft licenses interact with copyright law in ways that permissive licences just don't need to. The closest you can get is probably MPL-2.0.
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).
No, the MIT license is short exactly because it has so little restrictions. You simply can't encode the desired result of GPL into 160 words like MIT can.
> I can understand the MIT license, and my corp lawyer can easily understand all the consequences of using something under MIT license.
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.
The situations which cause that obligation to kick in can be decidedly non-obvious.
Right, I think people misunderstand "free" when they are dominating versus "free" when they are the smaller player. One is a tool for domination and capture, the other is a tool for freedom ESPECIALLY against a bigger player.
This is absurd.
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.
I mostly agree, unless the new release modifies GPL code submitted by other entities than Google - their licensing of that code under GPL would force Google to release the rest too.
To be more pedantic here, Google doesn't have to publish anything anywhere.
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.
True, though I doubt that would've happened either (possibly it would have sped up this publication).
> it's only just now that they bothered to actually release the source of their open-source operating system.
Do you really need to have snark for an open source project?
Open-source projects maintained by individual developers working for free absolutely deserve more respect than that, but ones maintained by the most profitable company in the world [1] do not, especially when they go out of their way to change from doing the right thing to doing the wrong thing [2].
[1]: https://www.financecharts.com/screener/most-profitable
[2]: https://news.ycombinator.com/item?id=43484927
> ..., especially when they go out of their way to change from doing the right thing to doing the wrong thing.
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.
Yes, open source requires snark just as much as tone policing
I thought we were talking about the Android project? /sarcasm
It's Google, I think they've sucked up enough of our digital lives and economy to handle a bit of snark.
So why do you so badly want to use their operating system to care what they do and how they license it?
It's their work, their OS and we have others.
Yes. Precisely because it's "open source", not "free".
A project which uses and depends on a lot of other third-party OSS? Maybe.
This means the source code is finally being released for the quarterly release that came out in september. Roms like lineageos had to target QPR0 which came out back in June but can now bring up to this. Google used to release the source to AOSP right after the releases happened, now they don't.
Additional context per fediverse thread: The GPL code (i.e. kernel) was released on time, this is the AOSP userspace portions which Google isn't legally obligated to release (which doesn't make it not a dick move not to).
What was Googles "corporatespeak" reason for not releasing it right away?
There doesn't need to be "corporatespeak". They don't have to release it right away. They don't have to release it at all.
"Leave the billion dollar corporation alone!"
it means custom roms maintainers like lineageos, can now work on adding android 16.1 builds
Another practical consequence is that GrapheneOS may finally be able to support Pixel 10 phones.
Yep! https://piunikaweb.com/2025/11/12/grapheneos-pixel-10-suppor...
Edit: never mind, this is just an article quoting the post at the top of this discussion.
What's the current status of custom ROM development these days!! I hv been out of the sync for a while. It seems mostly dead except for few players like LOS, Graphene, Paranoid (prolly), I guess there are still some smaller enthusiasts, but they probably just kang old code and features rather than providing stable support.
Very happy with the quality of GrapheneOS and modern Google Pixel devices. Can recommend.
GOS is not "paranoid", lol, it's just releasing the fastest asd adding cherry on top, and not bundling Google services (but allowing you to install them)
Ik GOS is not paranoid, "prolly" -> I wasn't sure whether Paranoid is still alive or not, it was there last year though
Paranoid is another custom ROM - GP wasn't calling Graphene paranoid.
If you're wondering for a possible reason and whether google is just being "lazy", see [1].
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...
> certain commitments they need to make depending on when the source code is released
…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.
And what does 'released' mean in this context? GrapheneOS has very publicly stated that security patches are under embargo, and they already have patches for the March 2026 release. See [1]:
> 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;
it has an integrated touch screen display with a viewable diagonal size of 10,16 centimetres (or 4,0 inches) or more, but less than 17,78 centimetres (or 7,0 inches);
I wonder if 3.99 inch and 7.01 inch smartphones will start appearing again.
That should be easy for foldables: an external sub 4" display and an over 7" main display.
>google has certain commitments
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.
This has absolutely nothing to do with that law, and even Google doesn't dare use it as an excuse for its behavior (as they did with GDPR by deliberately creating user friction that the European regulation did not require, and even partially forbids).
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.
What? Please explain what commitments exactly are causing Google to not release source code at the same time as the update. Until you do that, your statement is as valuable as writing 'Thanks, Obama!'
Yea, GP sounds like they want to drag "EU Bad" into this discussion.
I fail to see how this EU regulation promotes releasing software Closed Source and demotes releasing it Open Source.
> (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;
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.
So EU mandates that security updates in either source OR binary form must hit all users in at most 4 months after they are first published, therefore Google started delaying releasing source code and will start delaying it even more?
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.
Parts of AOSP like the apps have been in limbo for way longer than that, maybe since Android 12.