zlacker

[return to "GrapheneOS accessed Android security patches but not allowed to publish sources"]
1. LinAGK+pJ[view] [source] 2025-09-11 13:55:38
>>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.
◧◩
2. tester+S11[view] [source] 2025-09-11 15:39:01
>>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.
◧◩◪
3. bri3d+161[view] [source] 2025-09-11 16:02:00
>>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.

◧◩◪◨
4. dijit+Nh1[view] [source] 2025-09-11 17:10:56
>>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?

◧◩◪◨⬒
5. nottor+XK1[view] [source] 2025-09-11 20:15:34
>>dijit+Nh1
> the OS is effectively one single unit: all linked together

If your appliance runs linux it has separate components just like desktop linux.

You want to do as little as possible in kernel space, and depending on the appliance there isn't even any need for it.

So, like desktop linux, you can have closed source binaries on top of the kernel.

◧◩◪◨⬒⬓
6. dijit+mL1[view] [source] 2025-09-11 20:18:38
>>nottor+XK1
I just don’t see the distinction as clearly when it’s a single binary that cannot be decoupled or introspected.

Why is it if I build a static binary with GPL code and distribute it I must open source my changes; but if you do the same as a whole OS it’s not necessary.

Feels like it should all be fine or none of it is fine somehow.

◧◩◪◨⬒⬓⬔
7. nottor+tM1[view] [source] 2025-09-11 20:25:54
>>dijit+mL1
If you go that way, every bash script you've ever written should also be under the GPL.

And R code, at a quick glance.

[go to top]