… unless they want to participate in any way in the project that forges the software, instead of just being a disengaged consumer. Sometimes even then, they’re still affected. If that project uses GritHub, and hosts their homepage on GritHub Pages and their releases on their GritHub project, they may need to run proprietary JavaScript just to read about the app, and download a copy to install.
In most cases now, they have to run proprietary JavaScript from GritHub to browse or search Issues, or even just to read Issue discussion. If they want to open an Issue or comment on an existing one, or submit a merge request, this definitely requires running nonfree JS. For that they also need a GritHub account, which forces 2FA, and applies all sorts of Dark Patterns to try to DataFarm the person in the process of setting it up.
If the project uses other GritHub components like docs, roadmap, forum, kanban board or components post, they may need to run nonfree JS to browse any of those, and to login with an account to post in the community forum or add a tile to a kanban board (eg for feature requests).
In the discussion on GitLab about whether to re-add the Amethyst Nostr app to the F-Droid repo, @Licaon_Kter mentioned that an anti-feature flag was added to Amethyst simply because a person installing it was required to read the ToS hosted on GritHub before using it. In hindsight I agree with the logic of this. Although as I’ve written elsewhere, some of the anti-feature flags are a bit broad brush, and need to be split into a number of more nuanced and descriptive flags.