I can't think of a legitimate reason to check this and refuse to run in a secondary profile. But banking apps sure love to cargo-cult invasive nonsense.
Nitter itself is still fine, there are like 2 public-ish instances I‘m aware of but I think people should go out and host some in more private communities/run one over Tor or something
From HN's PoV, the issue is that there aren't well-known workarounds which can be used for X.com / Twitter.com submissions. HN's principle concern is more that any discussion on such posts will largely revolve around the regwall / paywall, which doesn't advance HN's own prime directive: <https://news.ycombinator.com/item?id=27901918>
Probably the best use case for onion routing and IPFS. Each X URL gets a content addressable IPFS URL, served via an onion site that should be hard to take down.
Browser->Tor Onion site->IPFS as storage system pull through cache->X
Or just a .onion for the frontend and code forge + another server at some clearnet domain proxying it (until taken down and replaced with the new one) would probably work fine. The hidden service can even terminate TLS with a valid cert for the clearnet domain.
True, I suggested IPFS as an hidden content addressable, globally distributed caching proxy and persistent object store. Run it from outside the reach of the US legal framework, like private/shadow libraries/archives (as you could consider it an archive of X, with public access when available).
Another idea I recently had was extending Karakeep (https://github.com/karakeep-app/), which has robust archiving capabilities today, to enable announcing archived URLs via a DHT and serving the archive bundle as a torrent (similar to how the Internet Archive creates a torrent file for each item). With some work, it would be the equivalent of a distributed Wayback Machine, with each instance able to act as both scraper and server. With a browser extension that could query this DHT, you could retrieve an archived version of any URL that has been archived by cherry picking from the swarm (each URL becomes a magnet torrent URL, very similar to IPFS, but with less bootstrapping required imho).
> We didn't have git tags when GPL was written in 1989
The GPLv2 requires "a medium customarily used for software interchange", not "a medium customarily used in 1989 for software interchange". Customs are the customs of the time someone is releasing the work.
“a medium customarily used for software interchange“
Interesting choice of cropping for that quote.
If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data. So it would exclude distributing source code on tape, or even optical discs, as nobody uses those anymore. About the only medium used for source code distribution these days is “the internet”
You could potentially stretch this to excluding google drive, though google will argue that the medium is http, not google drive; But you can’t stretch this to requiring it be formatted as git.
And even if you did manage to successfully argue that, google would just ship it as one (tagged) commit per release. The history would still be missing.
> If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data.
I can see your point. But OTOH if providing the "preferred form of the work for making modifications" requires not squashing commits into a big mess to frustrate someone trying to make sense of the code (I'm sure the Google engineers making modifications prefer to look at individual commits!), and Google is using Git anyway to create those commits, then it seems to me like there's an argument to be made that the customary medium used to interchange a range of Git commits is Git.
Yeah, that argument is much better; Maybe google are violating the GPL.
What that part of the GPL does absolutely forbid is stripping out the comments from the source code, or only shipping generated source files (but not the code which generated it). And arguably, git history is much of the same thing as comments. Especially when we have IDEs that can be configured to give us easy access to blame to help us understand the code.
The fact that commit history is not inline with the source code (or even stored as human readable files) makes it a little harder to see/argue that git history could be considered to be part of the source code, and I do wonder where this argument stops? Should the contents of bug trackers and PRs be considered to be part of the source code? What about design documents?
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.
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]
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.
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.
I can't think of a legitimate reason to check this and refuse to run in a secondary profile. But banking apps sure love to cargo-cult invasive nonsense.
reply