1) floppy disks are not customarily used for software interchange - where they are still used (aircraft software updates, bits of San Francisco's streetcar infrastructure) it's weird enough to be remarked upon. 2) the cost to Google of finding enough working floppies and paying someone to dump that much code onto them, then mailing them out, then having the other end just say "disk 323 was corrupted by USPS X rays, p…
Mostly agreed. However you can solve the problem of having x% of disks corrupted via error correcting codes. It's what Google already does for their own internal storage: when you own millions of hard disks, some of them will inevitably fail.
Doesn't their change break supply chain security on Google's end? With git tags, presumably people spoke in terms of cryptographic hashes. Now what prevents them from serving different Google drive contents to different accounts?
It doesn't break supply chain security for anybody with power to change the situation.
It is an easy to overlook this, but even for someone in position of power to change, creating different code with the same hash is borderline impossible.
It doesn't break supply chain security for anybody with power to change the situation.
It is an easy to overlook this, but even for someone in position of power to change, creating different code with the same hash is borderline impossible.
Non-sequitor? They're not providing a (sha-1) hash, they're providing source code to integration partners using their business channels, not public git providers. Those business channels include contracts etc to "secure their supply chain".
You and I aren't in those business channels, and we're not being given anything with a hash. There's simply no hash to collide with?
I really don't understand the thought process here. Judging by public statements, Google is one of the 3 big western AI companies. Surely they should be rolling in cash and working hard towards AGI. And yet, for whatever reason, they can't help themselves from further restricting user freedoms on Android. Why? I don't want to be conspiratorial, but surely it's not money, right? It has to be control. Someone high up a…
“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.
GrapheneOS is arguing that throwing away the metadata of however many commits and squashing them into a messy tarball is not the "preferred form of the work for making modifications", and that a manual process where you have to fill out a form in order to get a Google Drive link a week later is not "a medium customarily used for software interchange" in current times. Those are quotes from the GPLv2.
It's an impossible stretch and also a bad idea. Insisting on that interpretation opens up other issues. Revision history may not be available in some cases for various reasons, such as if one pays someone for a large contribution. We could get into arguments about how granular commits need to be to comply with publication requirements. Digital achives containing source code files are certainly customary and easy to use, as opposed to reams of printouts. It would be just as customary and modern to publish on CD and mail the stuff out to anyone who demands the code. Continuous or timely delivery is not guaranteed by the license. One week of wait time is actually reasonable for a process like this, though I expect it might gradually get worse in line with their long-term objective of making the entire thing painful for outside developers.
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…
I've been wondering about the Red Hat model! Seems like so much of modern development involves git blame or whatever to make sense of how the code came to be, and sometimes rule out an "obvious" modification that actually turns out to be a bad idea now that you know the historical context. GrapheneOS might have a better case though if it's not just about understanding the code but about how the Android build system e…
I don't know what "Red Hat model" you mean, but if you're referring to their code delivery: It's not a problem for their internal developers, because they can use git lol. You can theoretically go to the upstream projects individually and merge the code drop with their nearest branch, and THEN do git blame/diff to figure out the delta and history of some lines of code. There are probably a few upstream open-source projects out there with no public VCS, but those are rare.