Re: Gitlab's "C" rating is overrated; add netneutrality; evaluate Playstore & F-Droid (repo-criteria-discus: message 1 of 3)

[bill-auger]

On Mon, 13 Jan 2020 11:48:20 -0500
address@hidden wrote:
> There is a trend for projects to move from MS Github to
> gitlab.com under the naive idea that gitlab.com is an ethical
> alternative.

On Mon, 13 Jan 2020 12:42:47 -0500
address@hidden wrote:
> "your product is unethical because of this poor rating from a
> credible organization".  Does FSF want to support that mission
> or not?

the FSF already says plenty about that concern - the mere use of
any SAAS service is a complete abandonment of software freedom -
these ratings are essentially a concession to those who will
choose to use SAAS services, despite the efforts of the FSF to
convince people that SAAS services offer zero computing freedom
to their users, regardless of which software it is running


On Mon, 13 Jan 2020 08:43:31 +0100 Hannes wrote:
> Fyi: It seems that Gitlab merged an alternative to recaptcha
> It is not yet enabled by default on gitlab.com though.

On Mon, 13 Jan 2020 11:48:20 -0500
address@hidden wrote:
> There is an opportunity here to downgrade Gitlab.com's rating,
> Waiting for gitlab.com to implement the non-Google
> CAPTCHA would defeat these opportunities.

On Mon, 13 Jan 2020 20:18:59 +0100 Hannes wrote:
> Imho this is important info for open source
> projects regardless of whether it is enabled on gitlab.com

exactly, and as soon as you decide to self-host, then the
decisions made by the admins of "someone else's service" become
a non-issue; because you are the admin of the service that you
will be inviting people to use

the captcha has been in place for years - if that would change
the standing, the evaluations should have reflected that long
ago - the suggestion to downgrade gitlab.com now, before they
have time to implement on their public service, what the freely
available gitlab software itself already supports for
self-hosting, is just exposing the fact that the current
examples are mainly criticizing the admins of a service, and not
reflecting the software itself - that is not an optimal way to
encourage people to exercise software freedom - the missed
opportunity there, is to encourage people to buy a little
beagle board and self-host - user-friendly tools such as
'freedombox' exist to make doing so, much less difficult than
most people probably realize


On Tue, 14 Jan 2020 00:59:20 +0000 address@hidden wrote:
> They would need different rating criteria.

regarding package repos, i agree with aaron there - there
probably would need to be a very different set of rating
criteria; and it would be confusing to present them in the same
context as source code forges

for one thing, most of those repos are not websites; but accessed
using specialized clients, of which most are themselves 100% free
software - neither the "javascript trap" nor the ethics of the
service admins are of much concern - also, the distinction
between binary and source packages is not really pertinent to
those - that domain would include every programming
language-specific package repo (python, ruby, javascript, and so
on) - the majority of those, host executable "source" code
exclusively; so licensing would be of a much higher importance
for third-party package repos

i looked into the licensing requirements of several of those,
and the "cabal" haskell repo was the only one i found, that
required all packages to be freely licensed - all others allowed
non-free and unlicensed software to be published on their
service; which is not even one of the criteria for the forges -
if licensing requirements were one of the criteria, notabug
would be the only public forge service that i know of besides
savannah, which requires all hosted software to be freely
licensed - perhaps there are more; but that seems to me like an
informative distinction to make, where credit is due

the current forge criteria is only whether or not the GPL is
recommended as much as any other license; but most of the
third-party package repos that i looked at, do not even suggest
that the hosted software should convey any license at all - IIRC
some do not even have a way to indicate the license of any of its
software - so strictly speaking, most of those would satisfy
criteria C5: "Recommends and encourages GPL 3-or-later licensing
at least as much as any other kind of licensing."; because they
do not recommend nor require any license at all - criteria C5
pretty much back-fires in that regard

not to dismiss the proposal of expanding the scope of the
repo-criteria project; but if there is any expansion to be done,
it would be more fruitful to begin by filling out a more
representative spectrum of forges, rather than the paltry few
samples that are represented - the forge software ecosystem is
quite diverse and expanding - we did a fairly thorough
evaluation of many of them, that could be used as a reference[1]
- from our evaluations, pagure, coding-team, and fusion-forge
would rank above gitlab on the true freedom spectrum; and there
are at least a dozen more that would fall into the 'C' range
with gitlab

i would also suggest moving the focus away from the how the
admins of one particular instance or another treat their users,
to focus on what the software itself can do for those who choose
to take advantage of software freedom, and to encourage people
to favor self-reliance over convenience - that would of course
push github off the list entirely; because its software is a
black box


[1]:
https://wiki.freephile.org/wiki/Comparison_of_git_hosting_options