repo-criteria-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

What does it matter, gitlab.com does not meet C-level for a long time (w


From: Dmitry Alexandrov
Subject: What does it matter, gitlab.com does not meet C-level for a long time (was: Updated review of GitLab)
Date: Wed, 30 Oct 2019 13:57:56 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Tristan Miller <address@hidden> wrote:
> A few days ago I received the message below from GitLab.  To summarize, their 
> managed source hosting service at Gitlab.com will be serving proprietary 
> JavaScript code that may be used to report "telemetry" to a third-party 
> service.
>
> I imagine that GitLab will continue to work when this proprietary JavaScript 
> code is blocked (though I haven't tested this myself).  So probably GitLab 
> still meets Criterion C0.

Criterion C0 reads:

| * 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)
|
| ** Regarding sending code that runs on the JavaScript platform, any such code 
used by an important site function either (1) is free software, and labeled 
properly for LibreJS to recognize as free, or (2) isn't necessary, so that the 
function works properly even if JavaScript is disabled in the browser.
|
|    See The JavaScript Trap for more explanation.
|
|    Note that free software must come with the real source code. Minified 
JavaScript code, and code generated by translation from some other language, 
are not source code. They are a kind of object code. (C0.0)
|
| ** <...>

How does gitlab.com meets it?  Its web-frontend is absolutely unusable without 
running ad-hoc scripts, which are, of course, not marked as free in a way 
recognizable by LibreJS or in any other consistent way, and actually, they are 
_not_ free: sourcemaps are bogus.

It worth noting, that besides being unusable, itʼs also delusive: while some 
sites [https://code.gov] are honest with their visitors: they show a screen, 
that clearly demonstrates, that they were unable to write a pure web-interface, 
gitlab.com¹ may present them an _incomplete_ page without any warning.  This is 
mostly harmful on discussion pages: please, clear the JS exception for 
gitlab.com and open, for instance, that page [1] — what is your impression?  
Mine would be: there is no any replies posted.  Now add the exception back.

[1] https://gitlab.com/fdroid/fdroiddata/issues/1611

IIRC, it indeed was usable without running JS few years ago, but thatʼs in the 
past: now both github.com and sf.net are more freedom-respecting that 
gitlab.com.

Plus, we have to keep in mind, that besides everyday features, there is an 
‘important functionality’, that perhaps would never drawn our attention since 
we were registered somewhere — thatʼs a registration process itself.  So, such 
are the state of affairs: to sign up on gitlab.com one have to pass Googleʼs 
reCAPTCHA, which is obviously nonfree.

-
¹ The same applies to any GitLab-running website.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]