3 ms·

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

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 11mo ago
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 11mo ago
  > (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 11mo ago
    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 11mo ago
      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 https://news.ycombinator.com/item?id=45914692
      - zb3 11mo ago
        > 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 11mo ago
        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).

berkes 11mo ago

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 11mo ago
> (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 11mo ago
  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 11mo ago
    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 https://news.ycombinator.com/item?id=45914692
    - zb3 11mo ago
      > 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 11mo ago
        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).