111–120 of 350 posts
Source code of which components is that? It's not very clear from the mastodon thread.
We mirror the source code on GitLab. We put the upstream 17 code in the 17-base branch and our code on top of it in the 17 branch:
https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base
https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b...
We also have mirrors of the QPR1 Beta and QPR2 Beta code there too.
Source code of which components is that? It's not very clear from the mastodon thread.
Maybe AOSP source code
“In violation of GPL” is a stretch. Can’t imagine Google is making the process of obtaining source code easier on themselves though. Android has always been more source-open than “open source”. The vast majority of community contributions that make it into the codebase are security fixes and small bug fixes. Everything else is essentially all the work of Google and (to some extent) Samsung.
> Android has always been more source-open than “open source”. The vast majority of community contributions that make it into the codebase are security fixes and small bug fixes. I believe this isn't actually about "Android" at all but rather Pixel . Android is still openly accessible on git. But the kernel sources for Pixel devices is now behind this big song & dance for some fucking inexcusable reason.
They stopped pushing tags for any of the Pixel kernel or userspace driver repositories to AOSP. They also stopped pushing AOSP releases specific to Pixels which is why AOSP now only gets yearly releases, QPR2 releases and security backports to both of those. Other OEMs are meant to use the yearly and QPR2 releases along with the security backports to those so that's all they push. The monthly and QPR1/QPR3 releases aren't used by their OEM partners so they stopped pushing them to AOSP. Those no longer being pushed is because of them deciding AOSP doesn't support Pixels anymore.
These changes directly led to our Motorola partnership. One of their security people reached out to us after seeing our posts about this with the launch of Android 16. We haven't talked about it much since then since we adapted to it during the several weeks it delayed our Android 16 port. We then continued adapting to it and have fully worked around it. It was an ongoing problem but not a new one and we had accepted we had to deal with it as the new normal.
They were previously responding to our kernel source requests within a day. It was often done without hours. Despite the archaic system, this part wasn't that bad. Recently, they've been taking weeks or longer to get back to us for the requests which is ridiculous. It's the direct result of purposely adding a lot of friction with manual handling of the requests even if the delays weren't directly planned by management.
Weeks or months of delay is not reasonable for one of the largest tech companies in the world. GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely. They need to do it in a reasonable amount of time. What's reasonable for one of the largest tech companies in the world in 2026 with current technology is not the same as what was reasonable 30 years ago. Google chose to come up with a archaic way of distributing the sources involving someone manually going through a list and sharing Google Drive access. It's a deliberate way of making it painful. If they can't keep up with it and it gets delayed for weeks or months then they're not complying with the GPL by not providing it in a reasonable amount of time. Law is not code and a time limit not being explicitly written down doesn't mean there isn't a limit to what's reasonable for compliance.
They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels. We helped them fix serious security weaknesses for Pixels including vulnerabilities being exploited in the wild by forensic data extraction companies. Pixel security with the stock OS would be worse without GrapheneOS.
Earlier quoted context omitted.
> There might be some merit to a claim that Google Drive isn't a medium customarily used for software distribution these days I suppose forcing a means to share the source code could have been too restrictive, but the GPL only speaks about the shape of the source code itself (it should be "the preferred form of the work for making modifications to it"), not how it is shared, so indeed, not a violation of the letter o…
> I suppose forcing a means to share the source code could have been too restrictive, but the GPL only speaks about the shape of the source code itself (it should be "the preferred form of the work for making modifications to it"), not how it is shared... With the greatest of respect, you've forgotten what the licenses say. GPLv2: [0] 3. You may copy and distribute the Program (or a work based on it, under Section 2)…
I stand by the position that all this doesn't seem very restrictive though. I don't think the GPL could have been without a risk of making some legitimate cases litigious or something.
Earlier quoted context omitted.
i.e. its no longer open source, now access is granted by permission.
what does the license say? provide source when asked or publish source? OSI is not clear on this either. ("Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, [...]")
Earlier quoted context omitted.
If distributing under 3(b) then it's legitimate to only supply source on request. Historically source has been distributed without revision control history or metadata and been considered acceptable (the source tarballs on gnu.org are snapshots, for instance) so I think the preferred form argument is also tricky. I agree that there's huge value in having the individual commits, but from a GPL perspective we had this…
we could argue about license semantics all day, either way Google is not being a good player
Give them a few years and they'll only provide it by printing out a copy and mailing it to you.
But is there any reason that google might have that they feel is legitimate?
For example, delaying releasing source until they've had a chance to update all the pixels with security patches might be good from their perspective, to reduce zero-day exploits for people they are supporting.
Earlier quoted context omitted.
Yes, but that person still needs to file a request and wait several days
But after one person does this, the source code access is a solved problem.