Hacker News Reader

Comment by flotzam | Hacker News Reader

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.

View on HN

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 argument when Red Hat started flattening all patches in the RHEL kernel source 15 years ago.

When the build system expects a certain metadata which is removed by the force pushes or tag removal, then that is arguably not the preferred form. Grapheneos notes this elsewhere in the thread. [1]

[1] https://news.ycombinator.com/item?id=49368983

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 expects that everything is in Git.

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.

we could argue about license semantics all day, either way Google is not being a good player

Oh, I agree there.

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.

Tarballs certainly aren’t in violation of the GPL, via gnu.org own source distribution methodology. It would also be a very interesting legal claim that git metadata is required, and likely something already hashed out when the government decided that metadata isn’t the same as the underlying data.

Reply on news.ycombinator.com