[HN Gopher] Android 16 QPR1 is being pushed to the Android Open ...
___________________________________________________________________
Android 16 QPR1 is being pushed to the Android Open Source Project
Author : uneven9434
Score : 236 points
Date : 2025-11-13 03:49 UTC (19 hours ago)
(HTM) web link (grapheneos.social)
(TXT) w3m dump (grapheneos.social)
| kamranjon wrote:
| Can someone with more context explain what this means and maybe
| the background?
| josephcsible wrote:
| 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.
| bitpush wrote:
| > 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?
| pseudosavant wrote:
| I thought we were talking about the Android project?
| /sarcasm
| wongogue wrote:
| A project which uses and depends on a lot of other third-
| party OSS? Maybe.
| josephcsible wrote:
| 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
| goku12 wrote:
| > ..., 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.
| ehnto wrote:
| It's Google, I think they've sucked up enough of our
| digital lives and economy to handle a bit of snark.
| izacus wrote:
| 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.
| dvdkon wrote:
| Applying your argument more broadly, we shouldn't
| critique any product or changes made to it, and I don't
| see any reason why that should be true.
|
| 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 wrote:
| No, my argument is not what you applied here.
|
| 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 wrote:
| wym we are not paying customers? every person with an
| android phone is a paying customer indirectly and can
| complain about its development
| izacus wrote:
| You're a paying customer of Samsung et. al.
|
| You don't become a paying customer of Linus when you get
| a Thinkpad with Ubuntu.
| ehnto wrote:
| You said we can be unhappy, which is what the grandparent
| was being, but you took issue with that anyway. I imagine
| people in deep enough to care about the downstream
| release cycle of android are well aware of the power
| structures at play. Being under the thumb of a massive
| corporate is not an enviable position but here we are,
| and here we complain.
| izacus wrote:
| Sure, but they also get a full opensource operating
| system for free in exchange.
| ehnto wrote:
| I don't.
|
| 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 wrote:
| Yes. Precisely because it's "open source", not "free".
| estimator7292 wrote:
| Yes, open source requires snark just as much as tone
| policing
| o11c wrote:
| 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.
| semi-extrinsic wrote:
| 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?
| dtech wrote:
| 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.
| debugnik wrote:
| 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).
| graemep wrote:
| > 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.
| regularfry wrote:
| The situations which cause that obligation to kick in can
| be decidedly non-obvious.
| graemep wrote:
| How so?
| this_user wrote:
| > In most cases
|
| 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 wrote:
| > 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.
|
| 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 wrote:
| > 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.
|
| 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 wrote:
| There are whole industries built around the notion that
| "License: MIT" is everything that is required to meet the
| notification requirements in the license. So I wouldn't
| say that the MIT license is easy to understand.
| bigstrat2003 wrote:
| 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.
| oliwarner wrote:
| 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.
| goku12 wrote:
| > 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.
| embedding-shape wrote:
| > 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.
| fsflover wrote:
| 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.
| coldtea wrote:
| 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.
| goku12 wrote:
| > 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!
| graemep wrote:
| > 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.
| goku12 wrote:
| People being naive doesn't give the bad actors the right
| to exploit them. That's victim blaming. The
| responsibility falls squarely on the actors who actively
| made the unethical/immoral choice.
| ahartmetz wrote:
| 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.
| sgc wrote:
| 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.
| walterbell wrote:
| This may already exist in practice.
|
| 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.
| graemep wrote:
| 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.
| attila-lendvai wrote:
| 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.
| MYEUHD wrote:
| 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.
| berkes wrote:
| That's entirely speculative.
|
| The speculation has merits and makes sense. But is
| speculative nontheless.
| pjmlp wrote:
| 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.
| kuschku wrote:
| 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?
| fabrice_d wrote:
| > 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.
|
| 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 wrote:
| Indeed, since Android 8 all drivers are in userspace and
| use Android IPC to talk to the Linux kernel.
|
| Traditional Linux drivers are considered legacy in
| Android.
|
| https://source.android.com/docs/core/architecture/hal
| guerrilla wrote:
| 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.
| MYEUHD wrote:
| 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.
| Someone wrote:
| > In order to build a custom Rom, you need three things:
| the kernel tree, the device tree, and the binary blobs.
|
| And a license to use the binary blobs for that purpose.
| Is it a given that doing that is allowed?
| qdotme wrote:
| IANAL; but - jurisdiction dependent.
|
| 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.
| creshal wrote:
| 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.
| smallnix wrote:
| > They only upstream some bug fixes that would be too
| onerous to keep in their private fork.
|
| 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_ wrote:
| They're privatizing their profits and socializing their
| losses.
|
| It's not healthy.
| kamranjon wrote:
| 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.
| yupyupyups wrote:
| 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.
| regularfry wrote:
| That's certainly the FSF's stance, but I don't know if
| it's been tested.
| fweimer wrote:
| It depended on whether the programs were distributed
| together. So it wasn't okay to link against OpenSSL for
| GNU/Linux distributions (although interpretations
| varied). For a time, this was used to push GNUTLS as an
| alternative to OpenSSL. But it was generally agreed upon
| that it was okay to link against CryptoAPI on Windows
| because you would not distribute Windows code along with
| your GPL binaries.
| whatevaa wrote:
| Lawyers are cautious people, not accepting
| interpretations. Until courts say otherwise, GPL is too
| high of a risk to use as a library.
| Octoth0rpe wrote:
| > while at the same time hosting all of their services on
| different flavors of Linux.
|
| 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 wrote:
| > 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
|
| 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 wrote:
| I think that a lot of companies stepped back from the GPL
| when GPLv3 was announced, because it puts some pretty
| severe restrictions on how you can productize.
|
| 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 wrote:
| > 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).
|
| 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 wrote:
| Would you feel the same way if we're talking about your
| car's driver-assistance ECU? If you can change its
| contents, then so can a remote attacker.
| F3nd0 wrote:
| 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.
| jajuuka wrote:
| User freedom isn't really that though. It's corporate
| goodwill. If a company uses GPL code and doesn't release
| it what is the enforcement mechanism? A lengthy court
| proceeding that can go either way and will likely
| bankrupt the less wealthy party. Or if they are in
| another country they can tell you to piss off and you
| have no way of getting the code. We see this all the time
| with China. In essence, they are the same but one allows
| you ask nicely and hope that the corporation is feeling
| generous.
| miroljub wrote:
| 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.
| beeflet wrote:
| If I zealously advocated for you continue breathing,
| would you strangle yourself to spite me?
| F3nd0 wrote:
| 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.
| josephcsible wrote:
| > true freedom requires the freedom for others to make
| their own licensing choices
|
| You're mixing up freedom and power. See
| https://www.gnu.org/philosophy/freedom-or-power.en.html
| for an explanation.
| kelnos wrote:
| You may disagree with the overly-derogatory term
| "brainwash", but I think it is true that corporations
| have been spreading FUD around coopyleft licenses for a
| while now, and the balance has tilted toward permissive
| licenses for new projects.
| cxr wrote:
| So what's your rationale for denying recipients true
| freedom and choosing to shackle them under the terms of
| the MIT License?
| utopiah wrote:
| 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.
| ncruces wrote:
| 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.
| Vinnl wrote:
| 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.
| miroljub wrote:
| 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.
| Vinnl wrote:
| True, though I doubt that would've happened either
| (possibly it would have sped up this publication).
| lenerdenator wrote:
| Never attribute to malice that which can be explained by
| laziness.
|
| 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 wrote:
| > and making sure others who have based their code on my
| project have done the same.
|
| 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 wrote:
| Then what's the practical difference between that and
| MIT/BSD licensing?
| BenjiWiebe wrote:
| Obviously, GPL allows you (and others) to request source
| code when Google uses a modified version of your code to
| make millions.
|
| It doesn't _force_ you to go after them.
|
| With MIT, you Google would have no obligation at all to
| provide anything.
| lenerdenator wrote:
| > It doesn't force you to go after them.
|
| 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 wrote:
| There's no difference _for you_. It 's your code.
| Choosing a particular license can't restrict how you
| yourself use it. An absurdly common business model is for
| you to relicense to BSD/MIT/proprietary for a particular
| customer who pays you to; it's the same code, you're just
| not obligating that customer to share their changes if
| they redistribute it.
|
| 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 wrote:
| > Then what's the practical difference between that and
| MIT/BSD licensing?
|
| 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 wrote:
| >If I do GPL, I have to make sure that I'm following the
| rules set out in that license
|
| 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 wrote:
| Except Google also violates the GPL so that's not the only
| relevant factor.
| RicoElectrico wrote:
| Why it seems that MPL is left out of the discussion? I find
| its clauses a reasonable middle ground.
| rkagerer wrote:
| Have they been in breach of GPL terms during the intervening
| two months?
| jhasse wrote:
| Most of Android isn't GPL, so I would guess not.
| joecool1029 wrote:
| 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.
| gpm wrote:
| 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).
| berkes wrote:
| What was Googles "corporatespeak" reason for not releasing it
| right away?
| thevillagechief wrote:
| 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.
| jamesnorden wrote:
| "Leave the billion dollar corporation alone!"
| rk06 wrote:
| it means custom roms maintainers like lineageos, can now work
| on adding android 16.1 builds
| lawn wrote:
| Another practical consequence is that GrapheneOS may finally be
| able to support Pixel 10 phones.
| degamad wrote:
| 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.
| jeffbee wrote:
| The largest and most widely used open source project in history
| is releasing one of their periodic updates, and lots of people
| with no industry (or life) experience are going to complain
| about it.
| charcircuit wrote:
| Here is a link to view it.
|
| https://cs.android.com/android/platform/superproject/+/andro...
| e40 wrote:
| Since when did they stop using Gerrit? On mobile and it doesn't
| appear to be that.
| zorgmonkey wrote:
| They still use gerrit, that site is a code search UI that
| they have that is also a very nice way to navigate the code.
| tripdout wrote:
| They still do. This is Android Code Search, which is a
| typical file tree and contents viewer.
| virajk_31 wrote:
| 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.
| subscribed wrote:
| 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)
| 13hunteo wrote:
| Paranoid is another custom ROM - GP wasn't calling Graphene
| paranoid.
| virajk_31 wrote:
| Ik GOS is not paranoid, "prolly" -> I wasn't sure whether
| Paranoid is still alive or not, it was there last year though
| celsoazevedo wrote:
| Paranoid Android (operating system): https://en.wikipedia.org
| /wiki/Paranoid_Android_(operating_sy...
| preisschild wrote:
| Very happy with the quality of GrapheneOS and modern Google
| Pixel devices. Can recommend.
| a456463 wrote:
| It is certainly not dead. The dead thing should be forced
| obsoletion and vendor lock-in. Dead is a subjective term.
| aboringusername wrote:
| 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...
| userbinator wrote:
| _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.
| pmontra wrote:
| That should be easy for foldables: an external sub 4" display
| and an over 7" main display.
| charcircuit wrote:
| >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.
| realusername wrote:
| Parts of AOSP like the apps have been in limbo for way longer
| than that, maybe since Android 12.
| codethief wrote:
| > 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.
| aboringusername wrote:
| 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;
| codethief wrote:
| Doesn't the embargo concern the _source code_ of the
| patches (and detailed information about the CVEs), not the
| release of the patched binaries?
|
| 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.
| aboringusername wrote:
| It's a rather intriguing concept, because it can be the
| case that the binaries Google released in QPR1 and their
| source code are different in some way. OEMs must ship
| QPR1 as Google released publicly within 6 months.
|
| 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.
| 0zymandiass wrote:
| You've explicitly quoted that source releases are not
| relevant:
|
| > 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
| aboringusername wrote:
| I would argue QPR updates are functionality and subject
| to the 6 month test.
|
| 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.
| 0zymandiass wrote:
| I believe QPR includes security fixes as well, which
| should trigger the 4 month timer
|
| 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.
| phoronixrly wrote:
| 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!'
| berkes wrote:
| 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.
| aboringusername wrote:
| > (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.
| phoronixrly wrote:
| 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.
| aboringusername wrote:
| See my comment [1]. This is already happening with
| security patches and GrapheneOS has already commented on
| their socials about the situation.
|
| 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.
|
| [1]: https://news.ycombinator.com/item?id=45914692
| zb3 wrote:
| > 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?
| selectodude wrote:
| Because shitty OEMs pay Google a lot of money to put
| Google Mobile Services on their shitty phones and it's
| bad to piss off your customers (note: you are not a
| Google customer if you use Android).
| fph wrote:
| > This EU law has made security far worse.
|
| 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.
| aboringusername wrote:
| Before the EU law, Android would release monthly
| bulletins, and patches would take about a month before
| being released on Pixel devices, once known as 'best in
| class' security. GrapheneOS have themselves admitted this
| has changed from 1 month to 4. This has been done to
| comply with this new EU law.
|
| 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.
| xzjis wrote:
| 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.
| aboringusername wrote:
| It absolutely has everything to do with this new law. For the
| first time, depending on when Google releases source code, or
| releases a Pixel update, the timer (4 months for security, 6
| months functionality) starts. This has never existed before
| in Android OS' history that updates are timed (in law)
| according to Pixel updates/software updates or open source
| releases. This law also applies to Apple but they will have
| no problems as they are compliant anyway as they control
| software/hardware entirely and it's closed source.
|
| 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.
| zb3 wrote:
| > 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.
|
| And that's exactly what the law was about, this timer is a
| good thing. Now they should close the "artificial delay"
| loophole.
| codethief wrote:
| > 2: Every OEM would be required to release those same
| patches 4 months to the day GrapheneOS releases them.
|
| 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.
| aboringusername wrote:
| You're not reading the interpretation correctly:
|
| > 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.
___________________________________________________________________
(page generated 2025-11-13 23:01 UTC)