lobsters score: 4 · tags: vcs
As per usual, the GNU Project’s obsession with pointing at Javascript winds up discrediting way too much of the actual criticism worth pointing to. It’s a bit hard to take this obsession with how Javascript is bad and evil seriously, when literally every single modern web feature is Javascript, since we stopped trying to overload HTML with things.
It’s just such an incoherent and backwards criticism to me, with no clear origin point besides “it’s really easy to execute Javascript”, which just reeks of GNU demanding a certain level of operational complexity to run software… which is a bit odd.
As for the other criticism, it’s… just a mixed bag. The less picky ones are that the Choose a License stuff is meaningless minutiae, the Copilot criticism is on point.
The centralization argument is just… odd? There’s still remarkably little within Github that creates platform lock-in besides the network effect. Achievements are a feature hardly exclusive to Github (my least favorite forum software, Discourse, notoriously also uses them; it’s hard to consider this a criticism of Github when plenty of OSS software has similar things). The patch workflow Github uses is odd, but it’s undeniably a lot more user friendly than patch submissions, in the sense they don’t have to learn git’s data model.
The criticism of actions is just bad. Preventing people from running insecure actions as a negative point is a real “we don’t believe passwords should exist”, which at one point was a real position held by the GNU if memory serves me right. Similarly, the reality of actions is that there’s just very little incentive to write any Action that does anything more complicated than compile and push to some sort of artifact/container registry or runs a linter you can run on your own device. I dunno, I’d believe this was a bigger issue if porting to a different kind of runner wasn’t at most a single afternoon of work/you can just run builds on your own system.
As for email addresses not being shown; I’d personally argue that requiring email in git is a problem in and of itself, and tellingly both GitHub and GitLab offer git mail masking services that let you hide your mail, while still attributing it to your account. It permanently nails an unnecessary piece of information most people would consider to be rather sensitive PII (even if email gets leaked all the time) as part of a workflow’s history. Saying GitHub refuses to expose them easily is if anything more of a positive to GitHub. Ideally it’d be made optional within git itself, the only thing you really need is the name field so that attribution is taken care of.
score 1 · canonical
I’d personally argue that requiring email in git is a problem in and of itself
While I have used this as a useful point of contact before when makers don’t provide that info, not enough folks talk about Pijul Identities which doesn’t use name + email as an identifier in commits. What’s nice is that you can freely change your email or name (marriage, deadname, & so on) & it doesn’t necessarily need to be exposed—or worse like in Git’s case, is tied to the state of the hash meaning you normally can’t talking a maintainer into updating that info in their Git history if you wanted.
score 1 · canonical
As per usual, the GNU Project’s obsession with pointing at Javascript winds up discrediting way too much of the actual criticism worth pointing to. It’s a bit hard to take this obsession with how Javascript is bad and evil seriously, when literally every single modern web feature is Javascript, since we stopped trying to overload HTML with things.
Believe it or not. They are not arguing for JavaScript to be not used at all. They are asking against nonfree JavaScript, which is actually most of JavaScript that is sent to users computer. What they basically don’t like here is that the users don’t even realize that they are running random nonfree programs on their computers.
I thought recently HTML and CSS have getting nicer features which allow you to do a lot without JavaScript, maybe I am mistaken.
score 1 · canonical
both GitHub and GitLab offer git mail masking services that let you hide your mail, while still attributing it to your account
I don’t know how well GitLab’s works, but for GitHub the answer is that it just keeps your email off the most obvious places in the Web UI. If you can clone a repo, you can see the email address used for commits, naturally. And if you don’t feel like cloning a repo, you can view a commit in the web UI and append
.patchto the URL to see the raw patch file, which includes the email of the committer.This doesn’t strike me as a big deal, so I guess I’m not in the “email addresses are rather sensitive PII” camp. My larger gripe is that they go stale, and I’d prefer if git had UI to map old ones to new when looking at logs.
score 1 · canonical
I’ve shallow cloned repos just to mail the maintainer—which is really helpful when trying to avoid using MS GitHub.
score 1 · canonical
The masking service is actual masking, not web UI masking.
They allow you to generate a noreply email for your account, and you can configure git to use that email. As long as you do that, your email shouldn’t end up in any git logs, while still being associated to the right account on the Github/Gitlab forge.
There’s a reference to it here on Github’s site, and the same documentation for gitlab.
score 1 · canonical
Interesting! I didn’t know they also offered that. I was thinking of the feature where they let you keep your email address private in the UI.
That said, the masking you’re talking about wouldn’t have occurred to me because none of my repositories ever begin their lives on github. They only wind up there when I need to share them in an ecosystem that expects it. So a noreply @users.github.com (or wherever) would never make it into my gitconfig in the first place, and I think I’d be too unhappy about tying my email address to one hosting service to ever do that.
score 2 · canonical
To be fair, you can always set something similar up on your own that isn’t tied to any specific forge; you can set your git email to something like sinkhole at domain dot tld, where the domain is one you control.
Then have your mail server put anyone who sends email to the sinkhole address onto a spamlist, as they’re harvesting git logs for emails. Only turn it off temporarily when adding the sinkhole as a commit address to a git forge.
A bit more complicated, but you can genericize the setup.
I also looked it up, and Forgejo apparently also allows you to do this, but it’s controlled by an admin setting and the address you’re meant to use is in a popover (and is only documented in their configuration file). It uses the structure username at noreply dot DOMAIN, with DOMAIN being the domain forgejo is running on. That means pretty much every git hosting tool of note that isn’t just “here’s the repo and a clone url” supports it. (Since selfhosting is pretty much either Gitlab or Forgejo these days.)
score 1 · canonical
I wish I could delete my account. I need more projects to move (name Nix + Nixpkgs)… I’ve talked ad nauseam about all of these points but I still get slapped with “network effect” as if developers aren’t technical enough to move elsewhere. Realistically, it seems often the last bit is that their YAML-spaghetti CI is free as in beer.
score 1 · canonical
Don’t you have to apply to get it on? Last I checked it wanted to be directly compatible YAML spaghetti too which I think was the wrong call.
score 1 · canonical
True. But Nix could probably afford to do their own CI? GNU Guix does, https://ci.guix.gnu.org/
score 1 · canonical
Perhaps. But the pain threshold to move away from GitHub is a lot higher because of the needed funds, developer time and maintenance needed to get CI set up.
score 1 · canonical
The GNU project has published ethical repository criteria and evaluated common forges on them. The only forge (besides their own Savannah) that scores “good enough to recommend” on them is Sourcehut.
For anyone wondering Codeberg.org would score F, just like GitHub. One reason is that it requires JS, and while Codeberg’s JS code is free software it isn’t labeled in the GNU approved way.
I am disappointed that the GNU project tells everyone how wrong they are but seems unable to create new software that aligns with their values and vision.
score 1 · canonical
I am disappointed that the GNU project tells everyone how wrong they are but seems unable to create new software that aligns with their values and vision.
Huh? I thought Savannah was their aligned software?
score 1 · canonical
As @yossarian noted my emphasis was on “new” software. Savannah is dated, doesn’t have modern features projects expect and doesn’t appear to be a forge developers want to use. (Even GNU projects like GUIX and GIMP use Codeberg and GNOME Gitlab instead.)
EDIT: Ideally there would be a “GNU forge software” that is so good it’s actually used widely beyond GNU.
score 1 · canonical
I wish they would run a forgejo instance for savannah.
They do use gitlab for CI though: https://emba.gnu.org/emacs/emacs/-/pipelines
score 1 · canonical
Yeah, I somehow wound up on the mailing list for that project, and the discussions around Codeberg are just a dumpster fire. (And IIRC, the “improperly labeled” javascript isn’t even used for a critical function!)
The funny thing about all of that is that Codeberg is probably even better aligned overall with GNU mission than sourcehut. Sourcehut allows private, non-free repositories, where Codeberg does not. The fact that they can’t recommend codeberg.org because of these criteria is a sign (to me) that the criteria need to be fixed.
I don’t recall whether there was more than just the javascript labeling, but if there was, it was similarly nitpicky. Things like wordsmithing just how they recommended a particular license, etc. I do believed someone suggested a perfectly reasonable way to address this in the recommendation (along the lines of saying to potential users “we know the javascript is free, so you can approve it in librejs”) but no consensus could be developed.
It’s sad to watch one project pick at another project that’s so neatly aligned.
score 2 · canonical
Forbidding users to use your software whichever way they see fit is not consistent with open-source software, according to freedom zero of Stallman’s manifesto.
score 1 · canonical
deleted by creator
While your statement is correct, it’s an absolute non-sequitur here. The ethical repository criteria don’t discuss the software used to run a repository, but rather repository hosting services. And Stallman’s organizations have aways restricted certain uses of their services.
A good example is Savannah; that is only for hosting Free software, just like Codeberg.
FWIW, all 3 of the services I’ve mentioned here (Savannah, Sourcehut, Codeberg.org) are run using Free software, which is self-hostable and carries no restrictions on what you can do with it as long as you comply with the terms of the copyleft license it’s released under.
The criteria that ~pyfisch linked, which Stallman had a heavy hand in writing and editing, state explicitly that in order to receive an “A” grade, a service:
Does not permit nonfree licenses (or lack of license) for works for practical use. (A4)
score 4 · canonical
I am not sure what you are alluding too. Codeberg is a platform and therefore can impose limits on what content they host (e.g. ban cryptocurrency and vibecoding content). Forgejo, the software used by Codeberg, is released as free software so users can use it however they want.
score 3 · canonical
Per the “Extensive Use of Nonfree JavaScript” bit, avoiding “nonfree” software is getting more challenging in life beyond coding. It’s getting harder to feel it’s “wrong” when I see it in more places.
For example, my town is amazing and set up free, underground composting bins all over parks and neighborhoods and stuff. However, random people used them as trash cans if left unlocked. So they set up a program where you register with the town online and then can open the bins via bluetooth and smartphone app. But only a smartphone app. The only way to participate is to use a proprietary, nonfree app.
So when I read things like
users who refuse the JavaScript Trap find that any interaction beyond simply viewing repositories is impossible
in this article, I wonder what the general solution is. “Avoid Github” means not using it even though friends and colleagues are there. “Avoid $SMARTPHONE_APP” means not participating in my community’s environmental efforts. Neither of these seem “right”, even though free software seems “right”.
Beating the drum of avoiding nonfree software seems like it’s gotten less effective as software shows up more in real life. I would get more out of articles like this if they came with recommended alternatives. Not just “Use Source Hut or Codeberg” or whatever, but alternatives meaning how to participate differently within a societal mesh that otherwise doesn’t think about software freedom when locking compost bins.
score 1 · canonical