Re: CodeBerg addition

[Aaron Wolf]

Somewhere this was mentioned in earlier discussion (I think somewhere at 
Codeberg) that it is common for people to *move* repos to Codeberg from 
elsewhere. When that happens, this dropdown doesn't show up at all. It 
only shows when making a fresh repo, and it's not actually clear how 
much that happens compared to the moving scenario. And in the moving 
scenario, there's no direct method to check for an appropriate license.


Because of the sort of community they are cultivating, I think it would 
be more common there than elsewhere that regular users notice licensing 
that is out of alignment with the terms.


On 2024-04-15 8:02, bill-auger wrote:

On Mon, 15 Apr 2024 19:45:21 -0700 Aaron wrote:

On 2024-04-15 7:09, bill-auger wrote:

can you link us to that ticket? - if the maintainers consider that to be a
bug, there has been ample time to correct it now
  

https://codeberg.org/Codeberg/Community/issues/1393  is one of the issues
I opened, and it is noisy with some other community members expressing
their opinions, but they do not represent the organization.

as i remember, a few years ago during the initial round of evaluations, there
were some codeberg maintainers participating on this list - it would be good to
get some feedback from them, at least stating that they are aware of the issue
and are willing to address it - without that, i would keep it as failing


On Mon, 15 Apr 2024 19:45:21 -0700 Aaron wrote:

   I really have every reason to think that Codeberg *does* enforce their
terms

i expect that they would also, IFF the offending repo is brought to their
attention; but how does that happen? - i doubt that the admins are reviewing
every repo as savannah does - i suppose that relies on some other user reporting
the offending repo to the admins

the point i am arguing about mainly, is that the interface seems to be leading
people to choose non-free licenses; and if it installs a license file
automatically, it is actively helping them to do so - regardless that the
site policy, people generally do not read those; but every user will be
presented with those license options - in terms of the FSDG, that would
constitute a failure


On Mon, 15 Apr 2024 19:45:21 -0700 Aaron wrote:

I *do* support noting this outstanding issue within a published GNU
evaluation so that it brings attention to the concern and puts pressure
on fixing it — even if they are granted a passing grade before it is fixed.

the only place to note that though, is the checklist - and the only way to
indicate it, is to mark the criteria as failing

Re: CodeBerg addition

[bill-auger]

On Mon, 15 Apr 2024 19:45:21 -0700 Aaron wrote:
> On 2024-04-15 7:09, bill-auger wrote:
> > can you link us to that ticket? - if the maintainers consider that to be a
> > bug, there has been ample time to correct it now
> >  
> https://codeberg.org/Codeberg/Community/issues/1393 is one of the issues 
> I opened, and it is noisy with some other community members expressing 
> their opinions, but they do not represent the organization.

as i remember, a few years ago during the initial round of evaluations, there
were some codeberg maintainers participating on this list - it would be good to
get some feedback from them, at least stating that they are aware of the issue
and are willing to address it - without that, i would keep it as failing


On Mon, 15 Apr 2024 19:45:21 -0700 Aaron wrote:
>   I really have every reason to think that Codeberg *does* enforce their 
> terms

i expect that they would also, IFF the offending repo is brought to their
attention; but how does that happen? - i doubt that the admins are reviewing
every repo as savannah does - i suppose that relies on some other user reporting
the offending repo to the admins

the point i am arguing about mainly, is that the interface seems to be leading
people to choose non-free licenses; and if it installs a license file
automatically, it is actively helping them to do so - regardless that the
site policy, people generally do not read those; but every user will be
presented with those license options - in terms of the FSDG, that would
constitute a failure


On Mon, 15 Apr 2024 19:45:21 -0700 Aaron wrote:
> I *do* support noting this outstanding issue within a published GNU 
> evaluation so that it brings attention to the concern and puts pressure 
> on fixing it — even if they are granted a passing grade before it is fixed.

the only place to note that though, is the checklist - and the only way to
indicate it, is to mark the criteria as failing

Re: CodeBerg addition

[Aaron Wolf]

On 2024-04-15 7:09, bill-auger wrote:

On Thu, 4 Jan 2024 20:46:59 -0800 Aaron wrote:

I'm suggesting that the UI having a dropdown in a form that shows an
enormous list of free and non-free licenses *is* something to want
fixed, but that because the docs specifically describe licenses in
alignment with the criteria and because the Terms and enforcement meet
the criteria as well, the incidental nature of the not-yet-fixed
dropdown need not cause Codeberg to fail on the above criteria.

i would not overlook that so easily - ive read the codeberg TOS and it is quite
adamant about permitting only libre licenses - but if the UI will offer and
install non-free licenses automatically, then some people will opt to do so -
despite the stated policy, the effect is to allow non-free licenses; because i
seriously doubt that the admins are actively policing that


On Wed, 3 Jan 2024 08:24:17 -0800 Aaron wrote:

I did open issues on this and mentioned the criterion specifically.

I vote for a pass despite this issue of the dropdown.

can you link us to that ticket? - if the maintainers consider that to be a
bug, there has been ample time to correct it now

https://codeberg.org/Codeberg/Community/issues/1393 is one of the issues 
I opened, and it is noisy with some other community members expressing 
their opinions, but they do not represent the organization.


 I really have every reason to think that Codeberg *does* enforce their 
terms, it's not just a site that is hands-off, whatever. If any repo 
there does not use the libre licensing specified in the terms and does 
not fix it when the issue is brought up, the refusal to fix it *will* 
lead to the repo being removed from the site.


I *do* support noting this outstanding issue within a published GNU 
evaluation so that it brings attention to the concern and puts pressure 
on fixing it — even if they are granted a passing grade before it is fixed.

Re: CodeBerg addition

[bill-auger]

On Thu, 4 Jan 2024 20:46:59 -0800 Aaron wrote:
> I'm suggesting that the UI having a dropdown in a form that shows an 
> enormous list of free and non-free licenses *is* something to want 
> fixed, but that because the docs specifically describe licenses in 
> alignment with the criteria and because the Terms and enforcement meet 
> the criteria as well, the incidental nature of the not-yet-fixed 
> dropdown need not cause Codeberg to fail on the above criteria.

i would not overlook that so easily - ive read the codeberg TOS and it is quite
adamant about permitting only libre licenses - but if the UI will offer and
install non-free licenses automatically, then some people will opt to do so -
despite the stated policy, the effect is to allow non-free licenses; because i
seriously doubt that the admins are actively policing that


On Wed, 3 Jan 2024 08:24:17 -0800 Aaron wrote:
> I did open issues on this and mentioned the criterion specifically.
> 
> I vote for a pass despite this issue of the dropdown.

can you link us to that ticket? - if the maintainers consider that to be a
bug, there has been ample time to correct it now

Re: CodeBerg addition

[bill-auger]

i see some new reviews lately; but i suppose this review is not yet completed? -
codeberg is not listed on the website yet; and the checklist has not been
updated since July 2021‎

if any of the new reviews has changed any of the existing information or
completed any missing information on the checklist, please update it

https://libreplanet.org/wiki/Codeberg

overall, codeberg appears to be among the most libre-minded options, at least
according to the documentation and TOS - codeberg is popular enough and libre
enough to recommend - keeping the checklist up-to-date is the best way to avoid
losing track of progress


On Sat, 30 Dec 2023 11:57:07 +0200 Yevhen wrote:
> Does any other repo from the list passes A+5? As I know even Savannah 
> can't do it. 

i commented on that a few years ago, on my notabug evaluation:

> as a side note: pagure is the only forge i know of which would pass A+5

Re: LibreJS (was Re: CodeBerg addition)

[Aaron Wolf]

On 2024-03-19 7:48, Richard Stallman wrote:

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > >> "Regarding sending code that runs on the JavaScript platform, any 
such
   > >> code used by an important site function either (1) is free software,
   > >> *either* labeled properly for LibreJS
   > >>   to recognize as free *or 
with a
   > >> human-verifiable reference that links to relevant source code and
   > >> license files*, or (2) isn't necessary, so that the function works
   > >> properly even if JavaScript is disabled in the browser.

If the proposed change consists of adding the text in asterisks,
that is a bad idea.  My decision is no.

Depending on a "human-verifiable" page means telling each user
to redo the work of verifying the code based on that page.
That is a substantial amount of work.  Instead of posting a
"human-verifiable" page, they should post LibreJS tags
or labeling, so that the verification can be done with LibreJS.

That avoids the need for various humans to "human-verify" it.





Richard, when you first replied to this same suggestion, you said it looked 
good and asked for anyone else to comment. The proposal is just a first-draft 
wording, but the point is not to remove the LibreJS criteria but to shift it to 
the next letter in the grading.

The context was to suggest that C could be granted to sites that get 
false-flags from LibreJS but which are truly known to be all free. Then, grade 
B would include the requirement to work correctly with LibreJS.

Working with LibreJS is preferable indeed, but saying that a site is 
unacceptable without it is quite extreme if we know the site to be 100% free.

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> "Regarding sending code that runs on the JavaScript platform, any 
such
  > >> code used by an important site function either (1) is free software,
  > >> *either* labeled properly for LibreJS
  > >>  to recognize as free *or 
with a
  > >> human-verifiable reference that links to relevant source code and
  > >> license files*, or (2) isn't necessary, so that the function works
  > >> properly even if JavaScript is disabled in the browser.

If the proposed change consists of adding the text in asterisks,
that is a bad idea.  My decision is no.

Depending on a "human-verifiable" page means telling each user
to redo the work of verifying the code based on that page.
That is a substantial amount of work.  Instead of posting a
"human-verifiable" page, they should post LibreJS tags
or labeling, so that the verification can be done with LibreJS.

That avoids the need for various humans to "human-verify" it.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There are proposals like this and the CodeBerg review in progress. How 
  > do we keep things progressing so they get completed?

For reviews of repo sites, we use the list repo-criteria-discuss@gnu.org.
I don't know of any other way, but it seems to be enough.  We're waiting
for people to finish the work of evaluating codeberg.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Aaron Wolf]

Just checking in, is there a process to keep track of loose ends like this?

There are proposals like this and the CodeBerg review in progress. How 
do we keep things progressing so they get completed?


On 2024-01-24 7:24, Richard Stallman wrote:

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > "Regarding sending code that runs on the JavaScript platform, any such
   > code used by an important site function either (1) is free software,
   > *either* labeled properly for LibreJS
   >  to recognize as free *or with a
   > human-verifiable reference that links to relevant source code and
   > license files*, or (2) isn't necessary, so that the function works
   > properly even if JavaScript is disabled in the browser.

I think this is a good change.  Does anyone argue against it?

How about if we copy the current C0.0 into level B?

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > "Regarding sending code that runs on the JavaScript platform, any such 
  > code used by an important site function either (1) is free software, 
  > *either* labeled properly for LibreJS 
  >  to recognize as free *or with a 
  > human-verifiable reference that links to relevant source code and 
  > license files*, or (2) isn't necessary, so that the function works 
  > properly even if JavaScript is disabled in the browser.

I think this is a good change.  Does anyone argue against it?

How about if we copy the current C0.0 into level B?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Aaron Wolf]

Making this a specific proposal for discussion/consideration:

I propose the wording of the first paragraph of C0.0 be modified from

"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."


To

"Regarding sending code that runs on the JavaScript platform, any such 
code used by an important site function either (1) is free software, 
*either* labeled properly for LibreJS 
 to recognize as free *or with a 
human-verifiable reference that links to relevant source code and 
license files*, or (2) isn't necessary, so that the function works 
properly even if JavaScript is disabled in the browser.


(as a concrete example, I added a comment at 
https://codeberg.org/Codeberg/Community/issues/64#issuecomment-1531719 
suggesting Codeberg could better direct people to the relevant source 
code and licenses even prior to getting LibreJS functioning)


Aaron

On 2024-01-15 7:32, Richard Stallman wrote:

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > What is the process to go ahead with this change? Splitting free JS
   > between "is free" (verified at the time of review) for level C and
   > satisfies-LibreJS for level B

Th enext step is to see what other people have to say about it.
I'm the one who makes the decision but other people's arguments will
affect my conclusions.

Re: LibreJS (was Re: CodeBerg addition)

[Jing Luo]

On 2024-01-16 12:32, Richard Stallman wrote:

[...]

  > Codeberg has now fixed the link and fixed the new-repo link to go 
to

  > Codeberg docs instead of the choosealicense website. Unfortunately,
  > these fixes did not resolve the LibreJS flagging.

Can someone figure out why not?


The maintainer says [1] it has been impossible to generate the correct 
rel="jslicense" on every page using the current tooling since 2020. The 
fix implemented this month only changes the URL of the license list file 
IIUC, it was not a fix to make it librejs-compliant.


I came to this mailing list to ask for help to make them 
librejs-compliant, but it looks like we are going around in circles :(


[1] 
https://codeberg.org/forgejo/forgejo/issues/1654#issuecomment-1410082


--
Jing Luo
About me: https://jing.rocks/about/
PGP Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC


signature.asc
Description: OpenPGP digital signature

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What is the process to go ahead with this change? Splitting free JS 
  > between "is free" (verified at the time of review) for level C and 
  > satisfies-LibreJS for level B

Th enext step is to see what other people have to say about it.
I'm the one who makes the decision but other people's arguments will
affect my conclusions.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Codeberg has now fixed the link and fixed the new-repo link to go to 
  > Codeberg docs instead of the choosealicense website. Unfortunately, 
  > these fixes did not resolve the LibreJS flagging.

Can someone figure out why not?
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Aaron Wolf]

On 2024-01-11 7:53, Richard Stallman wrote:

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > My vote is to move the LibreJS criteria to higher grades,

It's not a matter of voting, but that could be a good idea.
"Satisfies LibreJS" could go in level B, leaving "is free" in level C.


Yes, I meant voting as a metaphor, just a way of saying "my 
opinion/suggestion/preference".


What is the process to go ahead with this change? Splitting free JS 
between "is free" (verified at the time of review) for level C and 
satisfies-LibreJS for level B



   > Is there a chance that the simple fix to the licenses URL link will
   > address issues with LibreJS?

Try it and see!


Codeberg has now fixed the link and fixed the new-repo link to go to 
Codeberg docs instead of the choosealicense website. Unfortunately, 
these fixes did not resolve the LibreJS flagging.

Re: CodeBerg addition

[Fischers Fritz]

>   > If Codeberg puts the unacceptable license in the dropdown
>   > but makes it very clear that you violate your agreement by choosing
>   > them and enforces the agreement, I would consider it a pass.
>   > It is just a really bad user interface.
> 
> That is not the right approach for judging our evaluation criteria.
> We have these criteria for practical reasons -- to judge whether the
> site's actions and statements fit what we can recommend.  It is not a matter
> of whether the site's developers mean well, but whether they have
> done the job right.

In this case, the criterion becomes unclear to me. It is likely relevant
that I have not read discussion of how each criteria was created.
Is there documentation on that? I suspect that would make the intent
more clear to me. In case not, I explain my confusion below, and perhaps
somebody else can try clarifying.



The issue of the license options in the dropdown menu relates to
criteria B3, A2, and A4. In these cases I thought that one could
accomplish "encourage", "recommend" by having a policy of acceptable
licenses and making people change the licenses if they choose
an unacceptable license. It sounds like the intent is something
more specific, and I don't know specifically what.

When I read most criteria, it sounds to me that good user interface
is not part of the criterion. For example, it is clear that C0, C1, C4,
and A1 are concerned with the agreement between the hosting service and
the end user and that a terrible user interface is acceptable. It is clear
that A0 relates to user interface and not policy (unless policy said
something like you must use JavaScript) but that a confusing user
interface is acceptable if it works.

A7 is one of few where I interpret the criterion as clearly requiring
a good user interface; it is clear to me in A7 that the endorsement
of freedom must be shown prominently, rather than being a small part
of a long document, for example.

Considering the discussion on rights and the explicit mention of user
interface quality for certain criteria, I thought a confusing user
interface was generally acceptable, unless otherwise mentioned.
But now it seems this was not the intent.

There are cases where the criteria could have very different meaning
depending on the relevance of a friendly user interface.

For example, consider "Does not discriminate against classes of users,
or against any country", criterion C2. I assumed this was referring
to the policy. But any particular choice of user interface will
discriminate against some users; indeed, we already have criterion A+4
for discrimination based on disability related to user interface.
If the intend is that C2 refer to interface rather than just policy,
then A+4 is logically part of C2.

Similarly, I believed that any access through Tor would be enough
to satisfy criterion C3. But if the confusing license menu would
cause the site to fail criteria B3, A2, and A4, it could be that
the intent was that access through Tor must be of high quality,
(for example, as fast as access without Tor).

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My vote is to move the LibreJS criteria to higher grades,

It's not a matter of voting, but that could be a good idea.
"Satisfies LibreJS" could go in level B, leaving "is free" in level C.

  > Is there a chance that the simple fix to the licenses URL link will 
  > address issues with LibreJS?

Try it and see!

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: CodeBerg addition

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If Codeberg puts the unacceptable license in the dropdown
  > but makes it very clear that you violate your agreement by choosing
  > them and enforces the agreement, I would consider it a pass.
  > It is just a really bad user interface.

That is not the right approach for judging our evaluation criteria.
We have these criteria for practical reasons -- to judge whether the
site's actions and statements fit what we can recommend.  It is not a matter
of whether the site's developers mean well, but whether they have
done the job right.

That being so, if a site's UI is self-contradictory or unclear about a
point we consider crucial, such as this one, we should not "give them
credit for good intentions".

But it is good to give them helpful feedback and encouragement in
getting it right.  We should tell them we're eager for them to
properly implement those good intentions.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: CodeBerg addition

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Codeberg's new-repo form still shows that giant list. However, Codeberg 
  > does not actually *allow* non-free licensing, so anyone choosing 
  > non-free from that list is in violation of Codeberg's terms.

  > The reason for this situation is obviously not because Codeberg chose to 
  > show the list but because nobody fixed it yet.

I understand now.  Thanks.

  > I have opened issues at multiple levels in this stack to suggest that 
  > the situation be fixed.

I think it would be a better approach to use this bug, in a gentle
way, to urge them to fix the bug.  Something like, "We see that
Codeberg's intention is to allow only free licenses, which would earn
the answers of Yes for criterion B3.  We're only waiting for bug #69
to be fixed."

I've written that with a tone that is not demanding or impatient,
just waiting for this minor problem to be cleared away so we can
be more supportive,

Or, since they are working on this area, we could simply wait a few
weeks and see if they fix it.  There is no super rush about adding any
entry.  We want to add more, but no one entry is ever urgent
unless it is negative ;-{.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Fischers Fritz]

Dear Jing,

After we are ready with our evaluation, Codeberg is welcome
to implement our recommendations. Once they (or you) fix some
problems, we could evaluate again.

With great honor,
Fischers Fritz

Re: LibreJS (was Re: CodeBerg addition)

[Aaron Wolf]

My vote is to move the LibreJS criteria to higher grades, because I 
support LibreJS but do not like the idea that 100% free software failing 
LibreJS is the degree of downgrading that it is in the current criteria. 
I still think it is ideal, and Codeberg should work on it.


Anyway, two important fixes have already been made in the Codeberg code, 
they just haven't been deployed yet (update hasn't been made the live 
version yet). See 
https://codeberg.org/Codeberg/forgejo/commits/branch/codeberg-1.21


The link to choosealicense is already now fixed to be the Codeberg docs 
(which are currently excellent).


The link to licenses.txt was broken and is fixed in the code. 
https://codeberg.org/assets/js/licenses.txt was wrong, and 
https://codeberg.org/assets/licenses.txt is correct.


Is there a chance that the simple fix to the licenses URL link will 
address issues with LibreJS?


On 2024-01-09 8:30, Jing Luo wrote:

On 2024-01-07 13:31, Richard Stallman wrote:

[...]

  > Suggestions on how to improve librejs to make site administrators 
life

  > easier to comply are welcome :)

All else being equal, we would like to make it easier -- but not by
eviscerating the checking it is supposed to do.


In CodeBerg's case, I still think it could take years for it to be 
libreJS compliant. I expect upstream Gitea completely to ignore the 
libreJS issue, because not only that stale ticket [1] was opened in 
2020, Gitea was taken over by a company and gone very commercial in 
2022. IMHO Gitea cannot be trusted to free our software, so that's why 
we have Forgejo->Codeberg.


The dropdown list of many licences with some nonfree, and the 
problematic "choose license" link, together with libreJS issue have 
bothered me. For my self-hosted forgejo instance, I'm considering a 
fork, to patch all of these, to insert correct licensing info into all 
js files, but it could take months, and I will have to learn Go 
language and deb packaging. Then if I submit my patch to Codeberg, 
they may accept it, so the whole process could take a year or so. What 
does it mean for your repo evaluation? Or, do you make exception for 
Codeberg for C0.0 and B0? Or, do you consider changing C0.0?


Thu,  4 Jan 2024 18:51:17 +0900 (JST) From: Jing Luo 

[...] changing the criteria C0.0 to something like "the javascript 
should be free but it doesn't have to be librejs compliant"?



[1] https://github.com/go-gitea/gitea/issues/13393

Re: LibreJS (was Re: CodeBerg addition)

[Jing Luo]

On 2024-01-07 13:31, Richard Stallman wrote:

[...]

  > Suggestions on how to improve librejs to make site administrators 
life

  > easier to comply are welcome :)

All else being equal, we would like to make it easier -- but not by
eviscerating the checking it is supposed to do.


In CodeBerg's case, I still think it could take years for it to be 
libreJS compliant. I expect upstream Gitea completely to ignore the 
libreJS issue, because not only that stale ticket [1] was opened in 
2020, Gitea was taken over by a company and gone very commercial in 
2022. IMHO Gitea cannot be trusted to free our software, so that's why 
we have Forgejo->Codeberg.


The dropdown list of many licences with some nonfree, and the 
problematic "choose license" link, together with libreJS issue have 
bothered me. For my self-hosted forgejo instance, I'm considering a 
fork, to patch all of these, to insert correct licensing info into all 
js files, but it could take months, and I will have to learn Go language 
and deb packaging. Then if I submit my patch to Codeberg, they may 
accept it, so the whole process could take a year or so. What does it 
mean for your repo evaluation? Or, do you make exception for Codeberg 
for C0.0 and B0? Or, do you consider changing C0.0?


Thu,  4 Jan 2024 18:51:17 +0900 (JST) From: Jing Luo 

[...] changing the criteria C0.0 to something like "the javascript 
should be free but it doesn't have to be librejs compliant"?



[1] https://github.com/go-gitea/gitea/issues/13393

--
Jing Luo
About me: https://jing.rocks/about/
PGP Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC


signature.asc
Description: OpenPGP digital signature

Re: LibreJS (was Re: CodeBerg addition)

[Yuchen Pei]

On Sat 2024-01-06 23:31:33 -0500, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>   > Suggestions on how to improve librejs to make site administrators life
>   > easier to comply are welcome :)
> All else being equal, we would like to make it easier -- but not by
> eviscerating the checking it is supposed to do.

Absolutely. Any change should not reduce the coverage/recall which is
targeted at 100%. There may be false positives, but there should be no
false negatives.

Best,
Yuchen

--
Dr Yuchen Pei | https://ypei.org | Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
https://ypei.org/assets/ypei-pubkey.txt

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Suggestions on how to improve librejs to make site administrators life
  > easier to comply are welcome :)

All else being equal, we would like to make it easier -- but not by
eviscerating the checking it is supposed to do.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

LibreJS already has a facility to recognize particular files that we
know are free.  We use this for libraries that (1) many sites use
and (2) we have checked to make sure they are free.

It would not be wise to use this for files specific to particular
sites, and which may be difficult for us to verify as free.

Why would they be difficult?  Whatever makes it difficult for the site
to describe what is the source code for each file of JS code would
make it difficult for us to check too.

If we offered to do this for lots of sites, we would be pressured
to spend a lot of time on it, requiring a few very skilled people to
do tis in some other thing.

It would work if thehre were only one site that needed this, but it is
does not scale to handling thousands of sites.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Fischers Fritz]

The need for machine-readable licenses
--
For a program that I rarely change on my computer,
it is fine that the license be written in a place where
a program can't automatically check the license,
since I need to review the license rarely.

On the web, it is easy and common to change JavaScript,
and I can't practically review the license every time I reload
a webpage. Thus it is important to specify the license
in a way we can check automatically.

Implementation of machine-readable licenses
--
The LibreJS format looks easy to me. I think it is
reasonable to require sites to follow this to achieve
higher grades in ethical hosting criteria.
https://www.gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html#License-tags

It is common these days that all JavaScript for a page
is compiled in a single file. It should be easy to add a step
after compilation that adds the appropriate comment before
and after the compilation result.

On an authoritative list of free JavaScript
--
Another common practice is to link to popular libraries
on other peoples' servers. For these cases it would work,
for example, to maintain a list of hashes of freely licensed
libraries that don't follow LibreJS's format, such as jQuery
(https://code.jquery.com/jquery-3.7.1.min.js). Is this what
you meant by maintaining a list of free JavaScript libraries?

While a list would work in that case, I think it should also be
easy to require that the library just have the LibreJS license
annotation. Is it common that websites are free software
but fail LibreJS checks only because they use popular libraries
like jQuery that don't annotate the license in LibreJS's format?
If this is the case, perhaps we could evaluate JavaScript libraries
for compliance with the format and submit patches for adding
the annotation.

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In practice, if sites that are 100% free software are not being 
  > recognized by LibreJS, and the way modern sites are put together makes 
  > doing this non-trivial,

What does that mean, concretely?  That argyment, as stated, is too vague to
prove anything.  That doesn't mean you're necessarily wrong, but I ask
you to state the argument clearly enough that we can judge it.

then the problem is LibreJS's approach, not the 
  > site.

That does not follow.  There might be something that can be improved
in LibreJS's approach, but "It's hard so give up" is not a good
reason.  In order to consider an improvement we need a specific idea
for what improvement.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

To verify that a web site's JS code is free is difficult if it doesn't
indicate licenses and source code.  The lack of that also makes changing
the Javascript code difficult in practice.

Thus, passing LibreJS is important for users' freedom.  It is the
necessary follow-through for making the JS code free.

What is the difficulty in making Codeberg's JS code clearly licensed?
Could we halp do that?  It is much better to do work to make the code
clearly licensed than to do work to avoid saying whether it is clearly
licensed.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Aaron Wolf]

Just my first impressions, I could imagine any FSF- or GNU-hosted spot 
for an authoritative list could work.

I can see how the Directory could tie in maybe.

It seems sensible enough that some process of recognition by GNU 
evaluators is acceptable, and combine that with a hash could possibly be 
enough such that *all* Forgejo (for example) instances (known in advance 
or not) would pass if they use the same js file with the same hash. And 
thus LibreJS would indicate that the hash has changed as soon as that is 
detected, and that would prompt a process of checking that the change 
doesn't change the licensing etc.


I can't speak to the technical issues, but the human work on maintaining 
the list would be feasible though not totally trivial. I could imagine a 
project like Forgejo having a script that automatically alerts FSF of 
changes to the JS, and I could imagine a Forgejo maintainer serving as 
the trusted adjudicator.


In practice, would allowing Forgejo to attest to its own freedom in such 
a list be any different than the status quo where the project attests to 
the freedom by marking licensing?


On 2024-01-05 3:53, Yuchen Pei wrote:

On Fri 2024-01-05 08:24:53 -0800, Aaron Wolf wrote:


The one thought on LibreJS improvement I was imagining so far:
Some sort of crowdsourced list of recognized free JS, like the way
that adblocking lists are put together to block ads. I imagine a
whitelist that just knows that Codeberg's JS is free, so it is
whitelisted not by individual local users of LibreJS but by a
collected list everyone gets by default.

For such a list to be authoritative enough to be used for forge
evaluation, it needs to be maintained and vetted. What would be the best
way to do that? A natural idea would be to draw from the Free Software
Directory, which FSF staff maintains by evaluating and approving entries
on weekly meetings. Does this process already evaluate javascript
libraries and applications? Are there already js projects in the FSD? I
see a submission of forgejo[1], but that may not be sufficient because
presumably codeberg has its own url under its own domain for the js
files, so naively either there needs to be a correspondence between
forgejo (possibly minified) js files and codeberg js urls. Technically
there should be hashes to the files also in case they get updated.

[1]https://directory.fsf.org/wiki/Forgejo


On 2024-01-05 4:08, Yuchen Pei wrote:

On Thu 2024-01-04 13:49:00 -0800, Aaron Wolf wrote:

Note that there's also this issue at Gitea:
https://github.com/go-gitea/gitea/issues/13393
Anyway, I think it is not okay to downgrade Codeberg for not
functioning with LibreJS when it is 100% free software anyway.
Insisting on this particular tooling needs to not be such a strong
requirement.
I think LibreJS needs some improved options for operating and should
not be a blocker to Codeberg getting a higher grade.
In practice, if sites that are 100% free software are not being
recognized by LibreJS, and the way modern sites are put together makes
doing this non-trivial, then the problem is LibreJS's approach, not
the site.

Suggestions on how to improve librejs to make site administrators life
easier to comply are welcome :)

[... 33 lines elided]

Best,
Yuchen
--
Dr Yuchen Pei |https://ypei.org   | Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
https://ypei.org/assets/ypei-pubkey.txt


Best,
Yuchen

--
Dr Yuchen Pei |https://ypei.org  | Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
https://ypei.org/assets/ypei-pubkey.txt

Re: LibreJS (was Re: CodeBerg addition)

[Yuchen Pei]

On Fri 2024-01-05 08:24:53 -0800, Aaron Wolf wrote:

> The one thought on LibreJS improvement I was imagining so far:

> Some sort of crowdsourced list of recognized free JS, like the way
> that adblocking lists are put together to block ads. I imagine a
> whitelist that just knows that Codeberg's JS is free, so it is
> whitelisted not by individual local users of LibreJS but by a
> collected list everyone gets by default.

For such a list to be authoritative enough to be used for forge
evaluation, it needs to be maintained and vetted. What would be the best
way to do that? A natural idea would be to draw from the Free Software
Directory, which FSF staff maintains by evaluating and approving entries
on weekly meetings. Does this process already evaluate javascript
libraries and applications? Are there already js projects in the FSD? I
see a submission of forgejo[1], but that may not be sufficient because
presumably codeberg has its own url under its own domain for the js
files, so naively either there needs to be a correspondence between
forgejo (possibly minified) js files and codeberg js urls. Technically
there should be hashes to the files also in case they get updated.

[1] https://directory.fsf.org/wiki/Forgejo

> On 2024-01-05 4:08, Yuchen Pei wrote:
>> On Thu 2024-01-04 13:49:00 -0800, Aaron Wolf wrote:

>>> Note that there's also this issue at Gitea:
>>> https://github.com/go-gitea/gitea/issues/13393
>>> Anyway, I think it is not okay to downgrade Codeberg for not
>>> functioning with LibreJS when it is 100% free software anyway.
>>> Insisting on this particular tooling needs to not be such a strong
>>> requirement.
>>> I think LibreJS needs some improved options for operating and should
>>> not be a blocker to Codeberg getting a higher grade.
>>> In practice, if sites that are 100% free software are not being
>>> recognized by LibreJS, and the way modern sites are put together makes
>>> doing this non-trivial, then the problem is LibreJS's approach, not
>>> the site.
>> Suggestions on how to improve librejs to make site administrators life
>> easier to comply are welcome :)

>>> [... 33 lines elided]
>> Best,
>> Yuchen
>> --
>> Dr Yuchen Pei |https://ypei.org  | Timezone: UTC+11
>> PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
>> https://ypei.org/assets/ypei-pubkey.txt


Best,
Yuchen

--
Dr Yuchen Pei | https://ypei.org | Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
https://ypei.org/assets/ypei-pubkey.txt

Re: LibreJS (was Re: CodeBerg addition)

[Aaron Wolf]

The one thought on LibreJS improvement I was imagining so far:

Some sort of crowdsourced list of recognized free JS, like the way that 
adblocking lists are put together to block ads. I imagine a whitelist 
that just knows that Codeberg's JS is free, so it is whitelisted not by 
individual local users of LibreJS but by a collected list everyone gets 
by default.



On 2024-01-05 4:08, Yuchen Pei wrote:

On Thu 2024-01-04 13:49:00 -0800, Aaron Wolf wrote:


Note that there's also this issue at Gitea:
https://github.com/go-gitea/gitea/issues/13393
Anyway, I think it is not okay to downgrade Codeberg for not
functioning with LibreJS when it is 100% free software anyway.
Insisting on this particular tooling needs to not be such a strong
requirement.
I think LibreJS needs some improved options for operating and should
not be a blocker to Codeberg getting a higher grade.
In practice, if sites that are 100% free software are not being
recognized by LibreJS, and the way modern sites are put together makes
doing this non-trivial, then the problem is LibreJS's approach, not
the site.

Suggestions on how to improve librejs to make site administrators life
easier to comply are welcome :)


[... 33 lines elided]

Best,
Yuchen

--
Dr Yuchen Pei |https://ypei.org  | Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
https://ypei.org/assets/ypei-pubkey.txt

Re: LibreJS (was Re: CodeBerg addition)

[Yuchen Pei]

On Thu 2024-01-04 13:49:00 -0800, Aaron Wolf wrote:

> Note that there's also this issue at Gitea:
> https://github.com/go-gitea/gitea/issues/13393

> Anyway, I think it is not okay to downgrade Codeberg for not
> functioning with LibreJS when it is 100% free software anyway.
> Insisting on this particular tooling needs to not be such a strong
> requirement.

> I think LibreJS needs some improved options for operating and should
> not be a blocker to Codeberg getting a higher grade.

> In practice, if sites that are 100% free software are not being
> recognized by LibreJS, and the way modern sites are put together makes
> doing this non-trivial, then the problem is LibreJS's approach, not
> the site.

Suggestions on how to improve librejs to make site administrators life
easier to comply are welcome :)

> [... 33 lines elided]

Best,
Yuchen

--
Dr Yuchen Pei | https://ypei.org | Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
https://ypei.org/assets/ypei-pubkey.txt

Re: CodeBerg addition

[Aaron Wolf]

I'm proposing that we judge Codeberg as passing C5, B2, B3, and A4.

I'm suggesting that the UI having a dropdown in a form that shows an 
enormous list of free and non-free licenses *is* something to want 
fixed, but that because the docs specifically describe licenses in 
alignment with the criteria and because the Terms and enforcement meet 
the criteria as well, the incidental nature of the not-yet-fixed 
dropdown need not cause Codeberg to fail on the above criteria.


On 2024-01-04 8:23, Richard Stallman wrote:

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > I vote for a pass despite this issue of the dropdown.

Those words are not clear to me.  What exactly
are you proposing we do?  And why?

Re: CodeBerg addition

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I vote for a pass despite this issue of the dropdown.

Those words are not clear to me.  What exactly
are you proposing we do?  And why?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: LibreJS (was Re: CodeBerg addition)

[Aaron Wolf]

Note that there's also this issue at Gitea:
https://github.com/go-gitea/gitea/issues/13393

Anyway, I think it is not okay to downgrade Codeberg for not functioning 
with LibreJS when it is 100% free software anyway. Insisting on this 
particular tooling needs to not be such a strong requirement.


I think LibreJS needs some improved options for operating and should not 
be a blocker to Codeberg getting a higher grade.


In practice, if sites that are 100% free software are not being 
recognized by LibreJS, and the way modern sites are put together makes 
doing this non-trivial, then the problem is LibreJS's approach, not the 
site.


I think the criteria should be updated. Imagine if the criteria for GNU 
distros included something like zero flags with the vrms program *and* 
maintaining that was challenging. We shouldn't penalize services so much 
when this is not an issue for software freedom but an incidental tooling 
issue that has no ramifications for software freedom in practice.


Aaron

On 2024-01-04 12:43, Jing Luo wrote:

Hello,

I'm glad to see CodeBerg passes so many criteria, but on the other 
hand, the libreJS issue [1] may not be resolved for the foreseeable 
future because of the technical difficulty originated from upstream 
("Gitea"): the lead maintainer says it's not possible for Forgejo to 
generate the tags for librejs to recognize them, which means Codeberg 
would not satisfy criteria C0.0 and B0 for a long time. Is there 
anyone on this list who can help with this issue? I see on 
software/repo-criteria.html it says "contact Mike Gerwitz at 
 for help", is this info up to date?


I myself plan to use Forgejo to host a website for free software, 
that's why I'm eager to see this resolved (although I'm not a good 
programmer...)


Or, do you (the people on this list) consider changing the criteria 
C0.0 to something like "the javascript should be free but it doesn't 
have to be librejs compliant"? As you can see it's a challenge for 
some senario...


[1] https://codeberg.org/forgejo/forgejo/issues/1654

LibreJS (was Re: CodeBerg addition)

[Jing Luo]

Hello,

I'm glad to see CodeBerg passes so many criteria, but on the other hand, 
the libreJS issue [1] may not be resolved for the foreseeable future 
because of the technical difficulty originated from upstream ("Gitea"): 
the lead maintainer says it's not possible for Forgejo to generate the 
tags for librejs to recognize them, which means Codeberg would not 
satisfy criteria C0.0 and B0 for a long time. Is there anyone on this 
list who can help with this issue? I see on software/repo-criteria.html 
it says "contact Mike Gerwitz at  for help", is this info up 
to date?


I myself plan to use Forgejo to host a website for free software, that's 
why I'm eager to see this resolved (although I'm not a good 
programmer...)


Or, do you (the people on this list) consider changing the criteria C0.0 
to something like "the javascript should be free but it doesn't have to 
be librejs compliant"? As you can see it's a challenge for some 
senario...


[1] https://codeberg.org/forgejo/forgejo/issues/1654

--
Jing Luo
About me: https://jing.rocks/about/
PGP Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC


signature.asc
Description: OpenPGP digital signature

Re: CodeBerg addition

[Aaron Wolf]

I did open issues on this and mentioned the criterion specifically.

I vote for a pass despite this issue of the dropdown.

On 2024-01-03 3:50, Fischers Fritz wrote:

Dear colleagues,

If Codeberg puts the unacceptable license in the dropdown
but makes it very clear that you violate your agreement by choosing
them and enforces the agreement, I would consider it a pass.
It is just a really bad user interface.

In general, though, another option is to tell Codeberg that
we will give a higher rating if it fixes problems like this.
Many such problems could be quick to fix, and Codeberg
might appreciate such feedback, given that they seem
to agree with our position.

With great honor,
Fischers Fritz

Re: CodeBerg addition

[Fischers Fritz]

Dear colleagues,

If Codeberg puts the unacceptable license in the dropdown
but makes it very clear that you violate your agreement by choosing
them and enforces the agreement, I would consider it a pass.
It is just a really bad user interface.

In general, though, another option is to tell Codeberg that
we will give a higher rating if it fixes problems like this.
Many such problems could be quick to fix, and Codeberg
might appreciate such feedback, given that they seem
to agree with our position.

With great honor,
Fischers Fritz

Re: CodeBerg addition

[Aaron Wolf]

Sorry for the lack of specificity.

By "inherited software", I meant this:

- Codeberg is running an instance of Forgejo
- Forgejo is a soft fork of Gitea
- Gitea has a new-repo form that includes a license field which shows 
all the licenses from a giant list of licenses, free and non-free, 
common and obscure, old and new.


Codeberg's new-repo form still shows that giant list. However, Codeberg 
does not actually *allow* non-free licensing, so anyone choosing 
non-free from that list is in violation of Codeberg's terms.


The reason for this situation is obviously not because Codeberg chose to 
show the list but because nobody fixed it yet.


I have opened issues at multiple levels in this stack to suggest that 
the situation be fixed.


I am now of the opinion that this is incidental enough and that we 
should consider giving it a PASS due to both the Terms and the docs at 
https://docs.codeberg.org/getting-started/licensing/


Also, just in the days since I started reviewing, they already updated 
the code so that the docs link will be highlighted right at the spot in 
the form where the big list of licenses shows up. So, even the new-repo 
form will be saying what licenses are suggested and required even though 
the dropdown list is still the giant list for now.



On 2024-01-02 8:11, Richard Stallman wrote:

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks very much for working on this evaluation.

   >https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage  
   > *requires* free software licensing (with a very few reasonable

   > exceptions). However, the inherited software interface has some issues.

It looks like that is the blocking issue, but what does it mean?
What is the "inherited software interface"?
Those words can be parsed in multiple ways.
What is inherited from what?

When we are ready to post the evaluation, it could be useful
for one of us (you?) to show them the draft we will post.
They might decide to fix B2 right away so that they will get a B.

Re: CodeBerg addition

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks very much for working on this evaluation.

  > 
https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage
 
  > *requires* free software licensing (with a very few reasonable 
  > exceptions). However, the inherited software interface has some issues. 

It looks like that is the blocking issue, but what does it mean?
What is the "inherited software interface"?
Those words can be parsed in multiple ways.
What is inherited from what?

When we are ready to post the evaluation, it could be useful
for one of us (you?) to show them the draft we will post.
They might decide to fix B2 right away so that they will get a B.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: CodeBerg addition

[Aaron Wolf]

Update:

I think we should say B2 passes actually.
Codeberg's official documents are excellent: 
https://docs.codeberg.org/getting-started/licensing/
They are already moving to link to that instead of choosealicense 
https://codeberg.org/Codeberg/Community/issues/1214
And I opened issues to resolve the messy giant-license-list pull-down, 
which is unintended and not reflective of the Terms or the values of the 
service. We could wait for these fixes, but I think it's clear overall 
that Codeberg as a service adequately prefers good licensing.


On 2023-12-29 10:08, Aaron Wolf wrote:


Great, thanks for the update! I've done what I could for today, here's 
my updates:


C6: https seems fine to me, LE cert and everything checks out in my 
browser, is there anything more to review?


B0 LibreJS: https://codeberg.org/assets/js/index.js gets blocked as 
not marked in a way LibreJS understands, but there is a license 
mention somewhere in the file which links to the MIT license file for 
https://github.com/zloirock/core-js which seems to be the upstream JS 
used. There are also some accepted trivial in-line scripts. This seems 
a LibreJS issue perhaps, the JS is indeed freely licensed. There is 
already an issue tracking this at 
https://codeberg.org/forgejo/forgejo/issues/1654


It is clear to me that this is a technical detail and not a matter of 
whether the JS is free or not.


B1: pass, I have never seen a tracking-tag or any third-party 
requests, there's no advertising, no indication of any issue here


B2: I think fail for now unfortunately. 
https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage 
*requires* free software licensing (with a very few reasonable 
exceptions). However, the inherited software interface has some 
issues. The new-repository settings prompt license choices, links to 
https://choosealicense.com/ for license consideration, and that is 
neutral on the topic of GLP-N-only. The selection pull-down has an 
enormous list which includes the -only licenses as well as all CC 
licenses (including non-free) and even outdated old versions. It also 
has strange non-free discriminatory licenses like BSD-3-No-Military.


There is already an issue here: 
https://codeberg.org/forgejo/forgejo/issues/1404 and I commented there 
about the scope of what I think would resolve this. I already got a 
response, and it indicates this should be easy enough to fix, so we 
could see this pass soon. Alternatively, I'd also say this would pass 
if the Terms were clearer on the N-only issue.


Note: this criterion B2 could be fleshed out to list more bad 
practices such as adding non-free clauses to licenses and using 
outdated versions of licenses (though I would not prefer to see sites 
fail this criterion just because they decide to include GPL-2-or-later 
for compatibility with existing GPL-2 projects).


A0: I lean toward voting for pass, despite not being perfect. The text 
shows up "This website requires JavaScript." The site loads still, and 
all content is visible and downloading files works without JS. 
Interactions are not quite as smooth though. When I tested posting a 
comment, I got a rate-limit notice. That notice does offer to do some 
intervention by contacting them. Perhaps they could whitelist a user 
account and/or IP in order to bypass rate-limiting. When I returned to 
the page in question with JS enabled, my original post did actually go 
through. So, it appears that much (if not all) of the functions are 
doable without JS if not for the rate-limiting.


A1: I've not further checked, but I'm pretty sure this passes

A2: could be fixed with the items I mentioned above under B2

A4: PASS

"for practical use" is Richard's excuse for using ND (No-Derivatives) 
licensing on his political opinion publications. He insists that works 
of opinion are distinct from "practical use" and do not have the 
issues of freedom that software has. I and many others disagree and 
believe that cultural freedom fits all the same issues. We need not 
debate this again here, Richard's views are encoded in the criteria in 
this case.


The fact is for Codeberg, 
https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage 
makes it clear that all repos must use free licensing, no matter what 
type of work it is, "practical" or otherwise.


A5: PASS, pretty sure, there's no service recommendations at all

A6: I vote for passing here actually. Look at 
https://docs.codeberg.org/getting-started/what-is-codeberg/ and see 
that they mostly use the term "free software" and *not* "open source". 
They sometimes say "Free and Open Source Software" but most of the 
references are like "On Codeberg you can develop your own Free 
Software projects". Overall, Codeberg embraces the term "free 
software" and prioritizes it over "open source". I don't think this 
criterion should be interpreted as a prohibition on the term "open 
source". It's more that this isn't one 

Re: CodeBerg addition

[Fischers Fritz]

Wonderful

It would be good if others could review Aaron's and my assessments.

Also, if I read correctly, the only criterion that neither of us has
checked is A+4: Follows the Web Accessibility Initiative - Accessible
Rich Internet Applications 1.0 (WAI-ARIA 1.0) standard. Does somebody
want to review that one?

With great honor,
Fischers Fritz

Re: CodeBerg addition

[Aaron Wolf]

Great, thanks for the update! I've done what I could for today, here's 
my updates:


C6: https seems fine to me, LE cert and everything checks out in my 
browser, is there anything more to review?


B0 LibreJS: https://codeberg.org/assets/js/index.js gets blocked as not 
marked in a way LibreJS understands, but there is a license mention 
somewhere in the file which links to the MIT license file for 
https://github.com/zloirock/core-js which seems to be the upstream JS 
used. There are also some accepted trivial in-line scripts. This seems a 
LibreJS issue perhaps, the JS is indeed freely licensed. There is 
already an issue tracking this at 
https://codeberg.org/forgejo/forgejo/issues/1654


It is clear to me that this is a technical detail and not a matter of 
whether the JS is free or not.


B1: pass, I have never seen a tracking-tag or any third-party requests, 
there's no advertising, no indication of any issue here


B2: I think fail for now unfortunately. 
https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage 
*requires* free software licensing (with a very few reasonable 
exceptions). However, the inherited software interface has some issues. 
The new-repository settings prompt license choices, links to 
https://choosealicense.com/ for license consideration, and that is 
neutral on the topic of GLP-N-only. The selection pull-down has an 
enormous list which includes the -only licenses as well as all CC 
licenses (including non-free) and even outdated old versions. It also 
has strange non-free discriminatory licenses like BSD-3-No-Military.


There is already an issue here: 
https://codeberg.org/forgejo/forgejo/issues/1404 and I commented there 
about the scope of what I think would resolve this. I already got a 
response, and it indicates this should be easy enough to fix, so we 
could see this pass soon. Alternatively, I'd also say this would pass if 
the Terms were clearer on the N-only issue.


Note: this criterion B2 could be fleshed out to list more bad practices 
such as adding non-free clauses to licenses and using outdated versions 
of licenses (though I would not prefer to see sites fail this criterion 
just because they decide to include GPL-2-or-later for compatibility 
with existing GPL-2 projects).


A0: I lean toward voting for pass, despite not being perfect. The text 
shows up "This website requires JavaScript." The site loads still, and 
all content is visible and downloading files works without JS. 
Interactions are not quite as smooth though. When I tested posting a 
comment, I got a rate-limit notice. That notice does offer to do some 
intervention by contacting them. Perhaps they could whitelist a user 
account and/or IP in order to bypass rate-limiting. When I returned to 
the page in question with JS enabled, my original post did actually go 
through. So, it appears that much (if not all) of the functions are 
doable without JS if not for the rate-limiting.


A1: I've not further checked, but I'm pretty sure this passes

A2: could be fixed with the items I mentioned above under B2

A4: PASS

"for practical use" is Richard's excuse for using ND (No-Derivatives) 
licensing on his political opinion publications. He insists that works 
of opinion are distinct from "practical use" and do not have the issues 
of freedom that software has. I and many others disagree and believe 
that cultural freedom fits all the same issues. We need not debate this 
again here, Richard's views are encoded in the criteria in this case.


The fact is for Codeberg, 
https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage 
makes it clear that all repos must use free licensing, no matter what 
type of work it is, "practical" or otherwise.


A5: PASS, pretty sure, there's no service recommendations at all

A6: I vote for passing here actually. Look at 
https://docs.codeberg.org/getting-started/what-is-codeberg/ and see that 
they mostly use the term "free software" and *not* "open source". They 
sometimes say "Free and Open Source Software" but most of the references 
are like "On Codeberg you can develop your own Free Software projects". 
Overall, Codeberg embraces the term "free software" and prioritizes it 
over "open source". I don't think this criterion should be interpreted 
as a prohibition on the term "open source". It's more that this isn't 
one of those common places that uses "open source" as their default 
term. Codeberg is clearly "free software" focused.


A7: I vote PASS. I see zero space between the FSF's definitions and 
Codeberg's understanding. There are some people pushing against the 
FSF/GNU understanding, and some opened this issue 
https://codeberg.org/Codeberg/Community/issues/385 which I just now 
commented on. But the organization has not supported these directions, 
though they didn't block or close the discussion.


A9: Fail, though I personally worry that this criterion is out of 
alignment with today's 

Re: CodeBerg addition

[Fischers Fritz]

Dear associates,

I have begun the review and was pleased with the signup process.
However, I have not received the account yet. Aaron, since you
already have the account, would you like to handle some
of the remaining points? Below are my conclusions so far.

With great honor,
Fischers Fritz



C0: Pass

  I registered with w3m.

C1: Pass

  I registered with w3m.

C2: Pass

  Codeberg bylaws section § 3.1 says.

  > Mitglied kann jede natürliche oder juristische Person oder rechtsfähige
  > Personengesellschaft werden.

  https://codeberg.org/Codeberg/org/src/branch/main/Satzung.md

  In English this is

  > Every natural person, legal person or legal partnership can become a member.

  https://codeberg.org/Codeberg/org/src/branch/main/en/bylaws.md

C3: TODO

C4: Pass

  https://codeberg.org/assets/js/licenses.txt
  https://codeberg.org/Codeberg/org/src/branch/main/PrivacyPolicy.md
  https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md

C5: Pass

  Recommends and encourages GPL 3-or-later licensing at least as much as any 
other kind of licensing. (C5)

  > Repository content shall be licensed under an open-source license approved 
by
  > the Free Software Foundation (see list of the FSF) or the Open Source 
Initiative
  > (see list of the OSI).
  > Reasonable exceptions are to a very limited extent considered acceptable. 
For
  > example, releasing single logo image files of a FLOSS project under no 
licence
  > or a separate non-free licence that requires derivative works to use their 
own
  > logo that is clearly distinguishable from the original work even in absence 
of
  > trademark registration.

C6: TODO

  Support HTTPS properly and securely, including the site's certificates. (C6)

B0: TODO

  Review https://codeberg.org/assets/js/licenses.txt
  and test with LibreJS.

B1: TODO

B2: TODO

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

B3: Pass

  (See C5.)

A0: TODO

  Signup worked fine with w3m.
  However, I have not received the account, so I have not tested
  other functions.

A1: TODO

  I think it passes, but I have not checked thoroughly.

A2: Fail

  (See C5.)

A3: Pass

  (See C5.)

A4: TODO

  I believe Codeberg to fail A4, but I am not sure, because I do not understand
  the phrase "for practical use". (See C5.) Does somebody know what this means?

A5: Todo
Does not recommend services that are SaaSS. (A5)

A6: FAIL

  (See C5.)

A7: TODO

  I say pass, but I would like another opinion.

A8: Pass

  I didn't notice references to GNU/Linux, GNU, nor Linux.

A9: TODO

A+0: Pass

A+1: TODO

A+2: TODO

A+3: TODO

A+4: TODO

A+5: TODO

  Codeberg claims to pass this criterion by being a Forgejo instance.
  According to Codeberg, "[b]y choosing a Forgejo instance, you can
  easily migrate away from Codeberg in case you don't like it." We can
  test the claim by exporting a Codeberg account's data and importing it
  to another Forgejo instance.

Re: CodeBerg addition

[Aaron Wolf]

Absolutely, seconding this suggestion to review Codeberg ASAP. I forgot 
that it wasn't already there. I think Codeberg is today far-and-away the 
most robust and popular service that has an explicit software-freedom 
dedicated focus. If there are any concerns (there may be very few), I am 
almost certain they would actively engage with us in discussing and 
working to resolve them.


I am myself using Codeberg now as the repository service for my 
projects. In fact, after way too much delay, Snowdrift.coop (project I 
co-founded and am still working on) is now moving to Codeberg and 
finally escaping GitLab (having initially, though uncomfortably, moved 
to GitLab back when it was at least acceptable).


I would like to see the GNU evaluation of Codeberg done before publicly 
announcing the Snowdrift move.


I did notice that Codeberg is criticized at 
https://git.sdf.org/humanacollaborator/humanacollabora/src/branch/master/forge_comparison.md 
for an event in which they were inadequately supportive of some critic 
of Cloudflare. However, without going deeply into it, this seems like 
just the the sort of imperfect decision-making that organizations can 
have. The service is not directly using cloudflare itself nor any other 
authentication-wall, and I do not think this is a sign of bigger 
problems or a slippery-slope scenario. I bring it up for others to 
consider though.


Who will lead the Codeberg review? I am willing to help, especially if 
someone can take the lead and delegate specific items. I do have other 
pressing priorities that make it hard to focus on this right now.


Aaron

On 2023-11-05 9:07, Yevhen Babiichuk wrote:

Hello!

I think that Code Berg [1] is enough popular to be in the list [2]. If 
it is bad, it would be good to have it in the list to show people they 
shouldn't use it. If it is good, they idea will be the same but opposite.


[1] https://codeberg.org/
[2] https://www.gnu.org/software/repo-criteria-evaluation.html


--
Aaron Wolf
co-founder, Snowdrift.coop
music teacher, wolftune.com

Re: CodeBerg addition

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It is good to evaluate more sites, as long as they are well known
enoug to merit that.  We simply need people to do the evaluation
and figure out the answers.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: CodeBerg addition

[Aaron Wolf]

Absolutely, seconding this suggestion. I forgot that it wasn't already 
there. I think Codeberg is today far-and-away the most robust and 
popular service that has an explicit software-freedom dedicated focus. 
If there are any concerns (there may be very few), I am almost certain 
they would actively engage with us in discussing and working to resolve 
them.


I am myself using Codeberg now as the repository service for my projects.

Aaron

On 2023-11-05 9:07, Yevhen Babiichuk wrote:

Hello!

I think that Code Berg [1] is enough popular to be in the list [2]. If 
it is bad, it would be good to have it in the list to show people they 
shouldn't use it. If it is good, they idea will be the same but opposite.


[1] https://codeberg.org/
[2] https://www.gnu.org/software/repo-criteria-evaluation.html