Achieve at least a "C" on GNU ethical repository criteria

[lofidevops]

• Gitea version (or commit ref): 1.1.0
• Can you reproduce the bug at https://try.gitea.io: Yes (homepage)
• Log gist: N/A

Description

The GNU ethical repository criteria are used to evaluate whether a code host is suitable for hosting free software (aka open source). This mainly means making sure the host itself doesn't require or host proprietary software. At the time of writing Savannah and GitLab have passing grades, while SourceForge and GitHub do not.

At the moment Gitea fails because it uses JavaScript that is not labelled as free software. See #1484 for details.

Checklist

• All important site functionality works correctly in free browsers, including IceCat, without running any nonfree software sent by the site. (C0) Passed (C0.0)

• Any JavaScript 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. (C0.0) Passed. See https://try.gitea.io/vendor/librejs.html

• Regarding sending code that executes based on a platform other than JavaScript, those conditions apply, mutatis mutandis. (C0.1) Not applicable.

• No other nonfree software is required to use the site (thus, no Flash). (C1) Passed.

• Does not discriminate against classes of users, or against any country. (C2) Passed.

• Permits access via Tor (we consider this an important site function). (C3) Passed

• The site's terms of service contain no odious conditions. (C4) Not applicable. No default/built-in TOS. Would be determined by a concrete instance.

• Recommends and encourages GPL 3-or-later licensing at least as much as any other kind of licensing. (C5) Passed. No explicit recommendation, but offers to add the full license text to a new repository.

• Support HTTPS properly and securely, including the site's certificates. (C6) Passed. Tested with https://www.ssllabs.com/ssltest/analyze.html?d=try.gitea.io

Next steps

1. Resolve JavaScript issues
   1.1. Complete Unsourced/undocumented libraries; missing license files; and other issues #1484
   1.2. Generate new LibreJS report Yes: results in Unsourced/undocumented libraries; missing license files; and other issues #1484
   1.3. Confirm librejs.html exists Yes: https://try.gitea.io/vendor/librejs.html
2. Check other "C" grade criteria, summarised above. Full details at https://www.gnu.org/software/repo-criteria.html#C
3. Resolve any other issues
   • C5. License picker selects blank by default. This is not preferred since this means copyright-restricted-by-default. But this is a "B" grade issue, not "C" grade.
   • C5. License picker effectively lists GPL-3.0-only but not GPL-3.0-or-later. Gitea does not "recommend" license, it provides a simple, optional mechanism for adding license text to a new repo, and lists GPL-3.0 with equal measure. The license text on it's own cannot make a distinction between 3-only and 3-or-later, that's up to the developer. See Explicitly add GPLv3-or-later to license list #2842 and https://lists.gnu.org/archive/html/repo-criteria-discuss/2017-11/msg00000.html and https://lists.gnu.org/archive/html/repo-criteria-discuss/2017-11/msg00001.html
4. Submit news to https://lists.gnu.org/archive/html/repo-criteria-discuss/ mailing list.

[strk]

The LibreJS issue is already reported in #1484

Beside that, GNU ethical repository hosting criteria are for services, not software.

[lofidevops]

Apologies for the duplication on the LibreJS issue. I've moved those details to the relevant ticket.

There is interest on the ethical repository mailing list in evaluating options for self-hosting, although there is no formal procedure as yet. I picked https://try.gitea.io as a test-case. I'll update with any feedback from the mailing list.

[bkcsoft]

C0: All important site functionality works correctly in free browsers, including IceCat, without running any nonfree software sent by the site.
C0.0: Any JavaScript used by an important site function (2) isn't necessary, so that the function works properly even if JavaScript is disabled in the browser.

Depends on what you define as "important site functionality". But most features work w/o JavaScript. Sans a few AJAX-triggers...

C2: Don't be a dick

We don't 🙂

C3: Works with Tor

Should work AFAIK

C4: No fucky ToS

try.gitea.io doesn't have a ToS

C5: Recommends GPL-3 equally to OR more than the others

We don't recommend any license at all. We do have a list of 'em all, and AFAIK GPL-3 is fairly high up the list.

C6: Support HTTPS properly

A-grade https://www.ssllabs.com/ssltest/analyze.html?d=try.gitea.io&s=159.203.182.191&latest

[lofidevops]

Updated as follows:

• C2, C4. Pass/not applicable.
• C6. Pass (added relevant link).

Remaining issues:

• C0.0. No-JavaScript option. Is the Gitea team prepared to fix bugs for users running without JavaScript? i.e. are such bugs in-scope? With-JavaScript option. Requires resolution of Unsourced/undocumented libraries; missing license files; and other issues #1484
• C3. Requires a quick note confirming someone has actually done this (I'll see if I can find some time). I assume this only means gitea-via-Tor-browser, not git-over-Tor, or Gitea-over-Tor-to-remote-git-repo.
• C5. Added a note (needs feedback from mailing list I think).

[MTecknology]

C0. Covered
C.0.0. There are some things that break without javascript enabled. There are places where javascript template items like ${ repo.stars_count } and ${ repo.full_name } show up, and things like drop-down menus don't work. I doubt you'd find the man-power interested in making the site functional without javascript, but it's really not that far off.

C3. I believe you can check Tor access off the list. There's nothing in the application that breaks by being accessed via the tor network or the tor browser. Depending on the tor exit node, it's also possible to run git+ssh:// over the network as well.

CX. There are some vendor'ed dependencies in vendor/ that weren't properly licensed. Some technically couldn't legally be part of any project, but every library (non-)maintainer--except tidb--was happy to license/copyright their work so that'll be cleaned up whenever gitea refreshes downstream modules.

CY. There is a similar problem in public/, documented in #1484. I believe this just requires somebody taking the time to restructure and document the directory and clean up anything referencing the data.

C5. AFAICT, there's no bias against GPLv3, which means equal to or greater than. Requiring it be above all others wouldn't be in the spirit of freedom. There's already a prompt to select a license. What's missing is reading PREFERRED_LICENSES from the config and sticking those values up top in bold (ideally order maintained). Then, by including GPLv3 in that default list, you can check off C5.

[lofidevops]

Updated as follows:

• C3. Pass. Confirmed by @MTecknology

Remaining issues:

• As before. (Thanks for the extra details.)

[mxmehl]

Can we close a few more points here? E.g. #1484 is closed as far as I can see.

[lofidevops]

Updated as follows:

• Marked Unsourced/undocumented libraries; missing license files; and other issues #1484 as complete
• Noted we still need a new LibreJS report to confirm the issue is resolved for this ticket. I tried generating one now, but it is taking a really long time. I'll try again when I can leave my browser for a while, unless someone else gets there first. Maybe the LibreJS HTML page can be optimized somehow?
• Just to highlight, anyone can drop a query about C5 to the repo-criteria-discuss mailing list.

[MTecknology]

I believe we can check off C5. The default is to provide no preference for any license above GPL-3.0+ and provide GPL-3.0+ is an available option. It is not weighted below any other option. FWIW- Alphabetical is organization, not preference.

I think it would be a great idea to set a default list of preferred licenses (GPL-3.0+, MIT, Apache-2.0, ) in the default configuration, but that's a preference (not requisite) of the C5 requirement. Requiring a license selection at repository creation would be a terrible idea but it's a part of the current workflow.

[lofidevops]

Posted queries to the repo-criteria-discuss mailing list about:

• C0.0 -- asking for someone else to do a LibreJS test
• C5 -- asking if "blank by default, GPL-3.0 option (not GPL-3.0+)" is suitable

[lofidevops]

Skipped LibreJS test (my plugin/browser is bust and no-one seems to be volunteering). Passed C0.0 on the basis that https://try.gitea.io/vendor/librejs.html exists and any errors would be logged as bugs.

[lofidevops]

Performed LibreJS test (success). Linked to results in #1484

[sapk]

So we could close this one ?

[lofidevops]

I'm afraid I'm still waiting on an answer on C5. If someone can find a reference to it being ok for Savannah or GitLab, that would work.

[lofidevops]

Also, please point me to where this should be documented for the eventual merge request.

[lofidevops]

Feedback from the repo mailing list:

• Blank-by-default is not preferred, but this is a "B" grade issue, not a "C" grade issue.
• Must explicitly list "GPL-3.0-or-later". I've created Explicitly add GPLv3-or-later to license list #2842 for this. This is the only outstanding issue.

[lofidevops]

Passed C5 based on discussion. Next steps:

1. Announce on to mailing list for confirmation
2. Add suitable text to Gitea documentation. something like "Based on a self-evaluation, your Gitea instance can achieve at least a 'C' grade using the GNU ethical repository criteria. If you want to add your specific instance to the list of GNU evaluations, it will need independent evaluation. [insert checklist results from the top of this ticket]"
3. Close this ticket 🍾

[MTecknology]

And then create a new one for grade 'B'? :)

[bkcsoft]

@MTecknology Seems like these might be problematic:

Does not encourage bad licensing practices (no license, unclear licensing, GPL N only). (B2)

Since we don't enforce licenses, and the default is "no license". Though I'd argue that "not enforcing" is not the same as "encourage".

Does not recommend nonfree licenses for works of practical use. (B3)

Again, depends on the definition of "recommend". I'd argue that we pass these, but they might not since we do list "nonfree" (according to FSF) licenses. And the wording is very iffy since what is "works of practical use"??

These should be okey though:

All code sent to the user's browser must be free software and labeled for LibreJS or other suitable free automatic license analyzer, regardless of whether the site functions when the user disables this code. (B0)

We do only use free software, and are labeled for LibreJS AFAIK. And the rule does not enforce the site to work if said code is disabled

Does not report visitors to other organizations; in particular, no tracking tags in the pages. This means the site must avoid most advertising networks. (B1)

We don't track or report anything to anyone, esp. not ad networks

[lofidevops]

Maybe the instance owner should be able to configure their instance in order to achieve higher levels of compliance? For example, a given instance owner decides they will force users to pick a license and restrict the list to FSF-approved licenses.

[lafriks]

@kwill instance owner can already add/remove licenses for his instance what he needs. I'm also not against adding option to require license when creating repository but that should not be enabled by default

[MTecknology]

I actually love the idea of being having the option to require a license selection, but I don't think that really matters for GNU criteria. I'd also agree with your assessment that not requiring a license is not the same as encouraging no license. There is an option to select a license and it's never hidden.

I think a very simple solution to assert a lack of ambiguity meeting the criteria is to simply take the existing PREFERRED_LICENSES option, stick those licenses at the top of the license-selection menu (perhaps in bold), and add a rule (<hr>) separating those licenses from the rest of the list. Then we just need to include a sane default list that includes GPL3+.

PREFERRED_LICENSES = Apache License 2.0,MIT License,GPL-3.0+

Pedantically, it might not be required, but doing so would let us confidently say the criteria has definitely been met.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.

[lesderid]

Shouldn't have been closed.