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