The #FSD purpose is to help people “find freedom-respecting programs”. Browsing the directory reveals copious freedom-disrespecting resources. For example:
- projects jailed in MS #Github (amid substantial ethical issues)
- projects jailed in #Gitlab·com (amid substantial ethical issues)
- projects with resources (docs, forums, wikis, APIs, etc) that are jailed in #Cloudflare’s walled garden (amid substantial ethical issues)
FSF has no tags for these anti-features. It suggests a problem with integrity and credibility. People expect to be able to trust FSF as an org that prioritizes user freedom. Presenting this directory with unmarked freedom pitfalls sends the wrong message & risks compromising trust and transparency. Transparency is critical to the FOSS ideology. Why not clearly mark the freedom pitfalls?
UPDATE
The idea of having exclusive clubs with gatekeepers is inconsistent with FSF’s most basic principles, specifically:
All important site functionality that's enabled for use with that package works correctly (though it need not look as nice) in free browsers, including IceCat, without running any nonfree software sent by the site. (C0)Does not discriminate against classes of users, or against any country. (C2)Permits access via Tor (we consider this an important site function). (C3)
Failing any of those earns an “F” grade (Github & gitlab·com both fail).
If Cloudflare links in the #FSF FSD are replaced with archive.org mirrors, that avoids a bulk of the exclusivity. #InternetArchive’s #ALA membership automatically invokes the Library Bill of Rights (LBR), which includes:
V. A person’s right to use a library should not be denied or abridged because of origin, age, background, or views.VI. Libraries which make exhibit spaces and meeting rooms available to the public they serve should make such facilities available on an equitable basis, regardless of the beliefs or affiliations of individuals or groups requesting their use.VII. All people, regardless of origin, age, background, or views, possess a right to privacy and confidentiality in their library use. Libraries should advocate for, educate about, and protect people’s privacy, safeguarding all library use data, including personally identifiable information.
The LBR is consistent with FSF’s principles so this is a naturally fitting solution. The Universal Declaration of Human Rights is also noteworthy. Even if the FSD is technically not a public service, the public uses it and FSF is an IRS-qualified 501(c)(3) public charity, making it public enough to observe these UDHR clauses:
art.21 ¶2. Everyone has the right of equal access to public service in his country.art.27 ¶1. Everyone has the right freely to participate in the cultural life of the community, to enjoy the arts and to share in scientific advancement and its benefits.
These fundamental egalitarian principles & rights are a minimum low bar to set that cannot be construed as “unreasonable” or “purist” or “extremist”.
Personally I would have some sort of notice regarding these on affected projects, but I don’t think it’s enough to warrant slapping an anti-feature flag on them just because of the author’s choice of code respoitory hosting provider or CDN.
You can git pull those repos fully with free software. Only contributions are locked away, but it is the directory of free software programs you can download and use.
Should users be able to see bug reports?
Just tried to see the bug reports for a gitlab·com project. This is what I get:
Being able to see bug reports is not required to use the software. You’ve made the decision to block Cloudflare, so now you face the consequences of not being able to access certain websites. Expecting free software developers to ensure that every single part of the experience is seamless for users who decide to block certain services is not reasonable.
Being able to see bug reports is not required to use the software.
That doesn’t quite answer the question. Nor is it strictly true. Bug tracker info is rich in workarounds for problems that hinder the use of the software.
You’ve made the decision to block Cloudflare,
Cloudflare’s decision, not mine. Cloudflare along with projects that use it made the (often unwitting) decision to block me, among other excluded people. Could I have executed Cloudflare’s non-free javascript to use the website, which is pushed contrary to FSF criteria C0? Perhaps, I didn’t try. Though I’ve run their garbage in the past and found that it rarely works anyway because the CAPTCHA servers themselves tend to be tor-hostile.
It’s worth noting that when execution of JavaScript of any kind is imposed in order to obtain information, it’s not a document; it’s an application.
Expecting free software developers to ensure that every single part of the experience is seamless for users who decide to block certain services is not reasonable.
Expecting FSF to facilitate exclusion of free software documentation and resources (the status quo) is not reasonable.
What is reasonable is FSF supporting their own principles:
All important site functionality that's enabled for use with that package works correctly (though it need not look as nice) in free browsers, including IceCat, without running any nonfree software sent by the site. (C0)Does not discriminate against classes of users, or against any country. (C2)Permits access via Tor (we consider this an important site function). (C3)
The Library Bill of Rights (LBR) is also quite reasonable:
V. A person’s right to use a library should not be denied or abridged because of origin, age, background, or views.VI. Libraries which make exhibit spaces and meeting rooms available to the public they serve should make such facilities available on an equitable basis, regardless of the beliefs or affiliations of individuals or groups requesting their use.VII. All people, regardless of origin, age, background, or views, possess a right to privacy and confidentiality in their library use. Libraries should advocate for, educate about, and protect people’s privacy, safeguarding all library use data, including personally identifiable information.
The Universal Declaration of Human Rights is also reasonable:
art.21 ¶2. Everyone has the right of equal access to public service in his country.art.27 ¶1. Everyone has the right freely to participate in the cultural life of the community, to enjoy the arts and to share in scientific advancement and its benefits.
These are good ideas. These fundamental principles & rights are a minimum low bar to set that cannot be construed as “not reasonable.”
If Cloudflare links in the #FSF #FSD are replaced with archive.org mirrors, that automatically invokes the Library Bill of Rights (as InternetArchive is an ALA member). The LBR is also consistent with FSF’s principles.
Posting a top-level comment to also point out that the info you linked about Cloudflare includes a conspiracy theory that it is an NSA honeypot. Doesn’t exactly seem like a reliable source to use for the claims you’re making.
Bruce Schneiere has frequently covered data sharing between US tech giants and intelligence agencies in his blog. It’s widely accepted. To call that a “conspiracy theory” is severely out of touch, post-Snowden revelations. At best, it’s only true as a technicality (that is, the US does not admit that the Snowden leaks are real so the official narrative still differs). It’s naïve to accept the official narrative and ignore Snowden’s leaks. Bruce Schneiere concurs with Snowden’s revelations & often acknowledges in his blog that that info sharing is going on.
That said, I do not see your specific claim about the NSA in the document that I linked, which is well cited. Which paragraph number are you referring to?
There’s a big difference between them sharing data with the NSA when required, and them being and NSA honeypot. Look through the repository you linked, it’s in there. Not my job to do critical thinking for you.
Indeed there is a big difference between warranted sharing and unwarranted sharing. The Snowden leaks are not about warranted sharing. There is no controversy over warranted sharing. You only muddy the waters to bring that up. It’s wholly irrelevant unless you are still actually claiming that the only sharing going on is warranted, which again is severely out of touch. You’ve not been paying attention to the Schneiere blogs. You should read them before discussing this topic. There are dozens of ways the unwarranted sharing occurs between intel agencies and tech giants, from simply buying the data commercially to backroom deals to inteligence insiders to outright malicious hacking exfiltration (which sometimes includes paying or pursuading the tech giant to simply neglect to fix a bug that the exfiltration relies on) to intelligence agencies handing a box over to the tech giant saying “here, just plug this box in on your LAN and pretend it’s not there - ask no questions”. All of those methods have been detected and exposed. It’s all there; inform yourself; I’m not going to do your homework for you. The HOW is irrelevant to the mere point that the data sharing happens without a warrant.
Look through the repository you linked, it’s in there.
I cited a specific article, not a repository.
So you’re suggesting they remove or tag 99% of projects from the directory because you don’t like where they put their source code? Seriously?
If you really don’t like it, use the git command line to access it… It’s just the server where the code is hosted…
And no, you don’t need an access token to clone a repo.
Yes these sites are bad, no it doesn’t warrant tarring the projects hosted on them.
