zlacker

>>uneven+(OP)
So basically to summarize, Google embargoes security patches for four months so OEMs can push out updates more slowly. And if those patches were immediately added to an open source project like GrapheneOS, attackers would gain info on the vulnerabilities before OEMs provide updates (the GrapheneOS project can see the patches, but they can't ship them). But a lot of patches end up being leaked anyway, so the delay ends up being pointless.

>>LinAGK+pJ
How does this work legally? If Android AOSP is open-source, once one OEM updates, surely the owner gets the legal right to request sources. IIRC the maximum delay is 30 days.

>>tester+S11
Almost all of AOSP is under the Apache or BSD licenses, not the GPL. Very few GPL components remain (the kernel being the large and obvious one).

So, yes, making a GPL request will work for the very few components still under GPL, if a vendor releases a binary patch. But for most things outside of the kernel, patch diffing comes back into play, just like on every closed-source OS.

>>bri3d+161
weird tangential question then: when does GPL stop being infectious?

I would understand in a modular system like an operating system: one can argue that the kernel is a single component.

But if you're buying an appliance, the OS is effectively one single unit: all linked together.

Why does a binary executable and a binary image seem to operate differently in this space - both are inscrutable?

>>dijit+Nh1
The FSF has always been pretty clear on this: you use a linker (static or dynamic) = it applies; you don't = it doesn't. They even wrote LGPL with this distinction in mind, and introduced exceptions to yacc (bison) to accommodate non-free software.

In case of binary releases, you can request the sources of the relevant subcomponent (e.g. the kernel). The component boundaries are pretty clear wrt Linux: Torvalds has made it quite clear early on, that the kernel's GPL2 does not apply to anything in the user space.

Here also, the important distinction between GPL 2 & 3: with GPL3, it would be a breach of the license to ship code on a device that does not allow the end user to update that code. Which has effectively pushed everyone away from GPL3-licensed software.

IMHO the move to GPL3 has likely caused more harm than good to the FOSS ecosystem; in some alternative universe, GPL3 never happened, most of Android's userspace is GPL2, and we get the source for everything. In both universes we still don't get to deploy changes to devices we own, so IMHO the GPL3 won us nothing.

>>rollca+Rk1
The FSF considers linking to be a definite example of derived works in general, but I don't believe they consider lack of linking to prove that something isn't a derived work.

The goal of the GPL is to flip draconian copyright maximalism on its head, and copyright laws don't talk about linkers so that can't be the deciding factor. Not to mention that it would be trivial to work around linking by creating a stub and calling the GPL code as a subprogram (in kernel contexts a spiritually similar setup is called the "GPL condom" and my impression is that most lawyers not employed by NVIDIA consider this to not be a get-out-of-jail-free card).

>>cyphar+4m1
That is explicitly mentioned in GPL FAQ:

https://www.gnu.org/licenses/gpl-faq.html#MereAggregation