[FEAT] use PREFERRED_LICENSES when creating a repository #1404

New Issue

Open

opened 2023-09-10 14:00:14 +00:00 by earl-warren · 10 comments

earl-warren commented

2023-09-10 14:00:14 +00:00

Owner

Needs and benefits

When creating a repository it is common to associate it with a license. Although there are hundreds of licenses, a dozen are most commonly used and should be presented first so the user does not need to search for the license name.

Feature Description

When creating a repository, a list of licenses is presented alphabetically sorted in a menu.

They originate from the license directory, extracted from https://github.com/spdx/license-list-data/ with make generate-license. The licenses listed in PREFERRED_LICENSES should be displayed first.

### Needs and benefits When creating a repository it is common to associate it with a license. Although there are hundreds of licenses, a dozen are most commonly used and should be presented first so the user does not need to search for the license name. ### Feature Description When creating a repository, a list of licenses is presented alphabetically sorted in a menu. ![image](/attachments/00854888-79ea-4d31-8d2b-fe7ef3868cdc) They originate from the [license directory](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/options/license), extracted from https://github.com/spdx/license-list-data/ with `make generate-license`. The licenses listed in `PREFERRED_LICENSES` should be displayed first.

image.png

70 KiB

👍 2

earl-warren added the

enhancement/feature

label 2023-09-10 14:00:16 +00:00

caesar commented

2023-09-10 15:27:25 +00:00

Owner

Is PREFERRED_LICENSES an existing setting which is used elsewhere, or one that should be added specifically for this purpose?

Is `PREFERRED_LICENSES` an existing setting which is used elsewhere, or one that should be added specifically for this purpose?

earl-warren commented

2023-09-10 16:03:45 +00:00

Author

Owner

Is PREFERRED_LICENSES an existing setting which is used elsewhere, or one that should be added specifically for this purpose?

It exists:

PREFERRED_LICENSES: Apache License 2.0,MIT License: Preferred Licenses to place at the top of the list. Name must match file name in options/license or custom/options/license.

> Is `PREFERRED_LICENSES` an existing setting which is used elsewhere, or one that should be added specifically for this purpose? It [exists](https://forgejo.org/docs/v1.20/admin/config-cheat-sheet/#repository-repository): > PREFERRED_LICENSES: Apache License 2.0,MIT License: Preferred Licenses to place at the top of the list. Name must match file name in options/license or custom/options/license.

👍 1

dachary added the

User Research - feature

label 2023-10-27 18:52:44 +00:00

wolftune commented

2023-12-29 23:37:26 +00:00

FYI, I am reviewing Codeberg specifically (and by extension Forgejo) for official GNU endorsement at https://www.gnu.org/software/repo-criteria-evaluation.html

Resolving this issue would make it clearer in passing criterion B2. That criterion is generally about whether the system encourages "bad licensing practices", and it calls out specifically no-license and unclear license which are not a problem for Forgejo. However, it also calls out as "bad" the use of GPL-N-only because "good" practice is to use GPL-N-or-later. Although the GNU criterion should be updated to add non-free licenses and outdated-versions as also bad practice.

On PREFERRED_LICENSES:

PREFERRED_LICENSES: Apache License 2.0,MIT License: Preferred Licenses to place at the top of the list. Name must match file name in options/license or custom/options/license.

That is itself a problem. Forgejo should not prefer Apache2 and MIT over other well-respected licenses. That list should be expanded to include at least the full GPL family (with the -or-later tags specifically) and the free-culture variants of CC (i.e. without the ND or NC limitations) licenses (using v4). Perhaps some others are also appropriate to add.

The limited Apache and MIT preference is inherited from Gitea, which I think is a project and community that cares less about software freedom for the world compared to Forgejo and Codeberg.

While Forgejo does not itself have the limitations of licensing that Codeberg specifies at https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage perhaps it makes sense to also have a separate list of approved Free/Libre/Open licenses so that there is a medium between the enormous-everything list and the preferred list?

FYI, I am reviewing Codeberg specifically (and by extension Forgejo) for official GNU endorsement at https://www.gnu.org/software/repo-criteria-evaluation.html Resolving this issue would make it clearer in passing criterion B2. That criterion is generally about whether the system encourages "bad licensing practices", and it calls out specifically no-license and unclear license which are not a problem for Forgejo. However, it also calls out as "bad" the use of GPL-N-only because "good" practice is to use GPL-N-or-later. Although the GNU criterion should be updated to add non-free licenses and outdated-versions as also bad practice. On PREFERRED_LICENSES: > PREFERRED_LICENSES: Apache License 2.0,MIT License: Preferred Licenses to place at the top of the list. Name must match file name in options/license or custom/options/license. That is itself a problem. **Forgejo should not prefer Apache2 and MIT over other well-respected licenses**. That list should be expanded to include at least the full GPL family (with the -or-later tags specifically) and the free-culture variants of CC (i.e. without the ND or NC limitations) licenses (using v4). Perhaps some others are also appropriate to add. The limited Apache and MIT preference is inherited from Gitea, which I think is a project and community that cares less about software freedom for the world compared to Forgejo and Codeberg. While Forgejo does not itself have the limitations of licensing that Codeberg specifies at https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md#2-allowed-content-usage perhaps it makes sense to also have a separate list of approved Free/Libre/Open licenses so that there is a medium between the enormous-everything list and the preferred list?

👍 1

algernon commented

2023-12-29 23:52:34 +00:00

Member

I'm not sure I understand the issue... on my instance running Forgejo 1.21.3-0, I have [repository].PREFERRED_LICENSES = GPL-3.0-only,GPL-3.0-or-later,BSD-3-Clause,CC-BY-SA-4.0,MIT in my config, and when creating a repo, they are listed at the top of the list:

As far as GNU endorsement is concerned, I suppose all that would take is changing the default for this for Forgejo.

I can submit a PR to do that, but to clarify, @wolftune, would the following preference list be fine? AGPL-3.0-or-later,GPL-3.0-or-later,LGPL-3.0-or-later,CC-BY-SA-4.0,CC0-1.0,MIT

I did not include CC-BY-4.0, to limit the list of default licenses, but included MIT, because that's the Gitea/Forgejo license. It might make sense to drop CC0-1.0, and add Apache-2.0 instead, because the latter is likely more practical. The list would still prefer the GPL family over the others.

I'm not sure I understand the issue... on my instance running Forgejo 1.21.3-0, I have `[repository].PREFERRED_LICENSES = GPL-3.0-only,GPL-3.0-or-later,BSD-3-Clause,CC-BY-SA-4.0,MIT` in my config, and when creating a repo, they are listed at the top of the list: ![Screenshot from 2023-12-30 00-44-45.png](/attachments/9b7de134-0ab3-44dd-8b5b-256948fb29ab) As far as [GNU endorsement](https://codeberg.org/forgejo/forgejo/issues/1404#issuecomment-1409321) is concerned, I suppose all that would take is changing the default for this for Forgejo. I can submit a PR to do that, but to clarify, @wolftune, would the following preference list be fine? `AGPL-3.0-or-later,GPL-3.0-or-later,LGPL-3.0-or-later,CC-BY-SA-4.0,CC0-1.0,MIT` I did not include `CC-BY-4.0`, to limit the list of default licenses, but included MIT, because that's the Gitea/Forgejo license. It might make sense to drop `CC0-1.0`, and add `Apache-2.0` instead, because the latter is likely more practical. The list would still prefer the GPL family over the others.

Screenshot from 2023-12-30 00-44-45.png

52 KiB

👍 1

algernon referenced this issue from algernon/codeberg-worklog

2023-12-29 23:57:46 +00:00

preferred licenses #14

wolftune commented

2023-12-30 05:14:19 +00:00

@algernon thanks for clarifying. I guess I haven't investigated fully. Could it be that Forgejo already uses PREFERRED_LICENSES in the repo-creation form while Codeberg's instance specifically does not? I assumed by this issue being open that it was a Forgejo unresolved issue.

Your screenshot looks much better. If appropriate, I'm happy to open a Codeberg issue about Codeberg setting preferred licenses.

For the GNU endorsement, the list you gave would technically qualify (get a passing grade on the relevant items). Though I would suggest the variant of AGPL-3.0-or-later,GPL-3.0-or-later,LGPL-3.0-or-later,Apache-2.0,MIT,CC-BY-SA-4.0,CC-BY-4.0,CC0-1.0 because all those are compatible, the whole set. My suggested order is software-first, non-code (CC) licenses later; most-copyleft to most-permissive. A collection of repos under a mix of all those licenses would all be allowed to be combined into a single AGPL-3.0-or-later derivative (even the CC ones, as those have been declared GPL-compatible). And while it gives preference to GNU licenses, it includes the full range of permissiveness for both software and non-software repos. I think BSD-3-Clause could be included as well, next to MIT.

If this were set correctly for Codeberg, it would pass the GNU criteria for license-suggestions with no question. It seems still preferable as well for Forgejo in general at any instance to default to to the same short list, which individual hosts could change as they wish.

ADDENDUM: to be explicit about GNU criteria (which really is for Codeberg, not Forgejo): Grade C level requires that no other license be promoted or favored more than GPL-3.0-or-later. Grade B requires that GPL-N-only not be encouraged. Grade A requires that GPL-3.0-or-later be actively encouraged as well as AGPL-3.0-or-later being offered and supported (and for the service to prohibit non-free licensing).

@algernon thanks for clarifying. I guess I haven't investigated fully. Could it be that Forgejo already uses `PREFERRED_LICENSES` in the repo-creation form while Codeberg's instance specifically does not? I assumed by this issue being open that it was a Forgejo unresolved issue. Your screenshot looks much better. If appropriate, I'm happy to open a Codeberg issue about Codeberg setting preferred licenses. For the GNU endorsement, the list you gave would technically qualify (get a passing grade on the relevant items). Though I would suggest the variant of `AGPL-3.0-or-later,GPL-3.0-or-later,LGPL-3.0-or-later,Apache-2.0,MIT,CC-BY-SA-4.0,CC-BY-4.0,CC0-1.0` because all those are compatible, the whole set. My suggested order is software-first, non-code (CC) licenses later; most-copyleft to most-permissive. A collection of repos under a mix of *all* those licenses would *all* be allowed to be combined into a single AGPL-3.0-or-later derivative (even the CC ones, as those have been declared GPL-compatible). And while it gives preference to GNU licenses, it includes the full range of permissiveness for both software and non-software repos. I think BSD-3-Clause could be included as well, next to MIT. If this were set correctly for Codeberg, it would pass the GNU criteria for license-suggestions with no question. It seems still preferable as well for Forgejo in general at any instance to default to to the same short list, which individual hosts could change as they wish. ADDENDUM: to be explicit about GNU criteria (which really is for Codeberg, not Forgejo): Grade C level requires that no other license be promoted or favored *more* than GPL-3.0-or-later. Grade B requires that GPL-N-only not be encouraged. Grade A requires that GPL-3.0-or-later be actively *encouraged* as well as AGPL-3.0-or-later being offered and supported (and for the service to prohibit non-free licensing).

algernon commented

2023-12-30 09:54:10 +00:00

Member

@algernon thanks for clarifying. I guess I haven't investigated fully. Could it be that Forgejo already uses PREFERRED_LICENSES in the repo-creation form while Codeberg's instance specifically does not? I assumed by this issue being open that it was a Forgejo unresolved issue.

By "I don't understand the issue", I meant the original issue, which in my reading meant that PREFERRED_LICENSES should be taken into account when sorting the licenses in the selector, and it is, so that problem seems to be gone now. (For both Forgejo and Codeberg; Codeberg lists Apache-2.0 and MIT on top, the PREFERRED_LICENSES default)

Your screenshot looks much better. If appropriate, I'm happy to open a Codeberg issue about Codeberg setting preferred licenses.

I think that would be the best, because as you said, the endorsement criteria is for Codeberg, not Forgejo, so Forgejo is fine with sticking with the Gitea default. Nevertheless, if Forgejo wants to change their defaults, I'm happy to submit a PR against Forgejo too. =)

Though I would suggest the variant of AGPL-3.0-or-later,GPL-3.0-or-later,LGPL-3.0-or-later,Apache-2.0,MIT,CC-BY-SA-4.0,CC-BY-4.0,CC0-1.0 because all those are compatible, the whole set. My suggested order is software-first, non-code (CC) licenses later; most-copyleft to most-permissive.

That ordering makes sense, and including BSD-3-Clause - as you said - would be great, too.

> @algernon thanks for clarifying. I guess I haven't investigated fully. Could it be that Forgejo already uses `PREFERRED_LICENSES` in the repo-creation form while Codeberg's instance specifically does not? I assumed by this issue being open that it was a Forgejo unresolved issue. By "I don't understand the issue", I meant the original issue, which in my reading meant that `PREFERRED_LICENSES` should be taken into account when sorting the licenses in the selector, and it is, so that problem seems to be gone now. (For both Forgejo and Codeberg; Codeberg lists Apache-2.0 and MIT on top, the `PREFERRED_LICENSES` default) > Your screenshot looks much better. If appropriate, I'm happy to open a Codeberg issue about Codeberg setting preferred licenses. I think that would be the best, because as you said, the endorsement criteria is for Codeberg, not Forgejo, so Forgejo is fine with sticking with the Gitea default. Nevertheless, if Forgejo wants to change their defaults, I'm happy to submit a PR against Forgejo too. =) > Though I would suggest the variant of `AGPL-3.0-or-later,GPL-3.0-or-later,LGPL-3.0-or-later,Apache-2.0,MIT,CC-BY-SA-4.0,CC-BY-4.0,CC0-1.0` because all those are compatible, the whole set. My suggested order is software-first, non-code (CC) licenses later; most-copyleft to most-permissive. That ordering makes sense, and including BSD-3-Clause - as you said - would be great, too.

👍 2

wolftune commented

2023-12-30 16:15:39 +00:00

Okay, I think this issue as-is might be partly fixed. It looks like PREFERRED_LICENSES is used indeed, but it is used just to put those licenses at the top and then still show the rest of the enormous list. The outstanding questions seem to be:

Should the drop-down default to showing only the preferred licenses (anyone can still add a LICENSE file for anything if there's some reason not to use preferred licenses)
- Upstream issue: https://github.com/go-gitea/gitea/issues/2239
What should Forgejo have as a default in the preferred licenses (I really think it should not be just Apache-2.0 and MIT)
- I opened an upstream Gitea issue: https://github.com/go-gitea/gitea/issues/28661
- I support Forgejo doing this if Gitea will not

I did go ahead and open a Codeberg-specific issue now: Codeberg/Community#1393

Okay, I think this issue as-is might be partly fixed. It looks like `PREFERRED_LICENSES` is used indeed, but it is used just to put those licenses at the top and then still show the rest of the enormous list. The outstanding questions seem to be: - Should the drop-down default to showing *only* the preferred licenses (anyone can still add a LICENSE file for anything if there's some reason not to use preferred licenses) - Upstream issue: https://github.com/go-gitea/gitea/issues/2239 - What should Forgejo have as a default in the preferred licenses (I really think it should not be just Apache-2.0 and MIT) - I opened an upstream Gitea issue: https://github.com/go-gitea/gitea/issues/28661 - I support Forgejo doing this if Gitea will not I did go ahead and open a Codeberg-specific issue now: https://codeberg.org/Codeberg/Community/issues/1393

algernon commented

2023-12-30 16:22:51 +00:00

Member

I think PREFERRED_LICENSES should work as it does now, and put those on the top, while also showing the long list after. If we want to trim the list, a separate setting, say, ALLOWED_LICENSES (or simply LICENSES, because using an unlisted license is still fine and supported) could be used instead - but that should probably be a separate issue.

So should the question of whether to change the PREFERRED_LICENSES default for Forgejo/Codeberg, just so that we can track different issues separately, even if they're somewhat related.

I think `PREFERRED_LICENSES` should work as it does now, and put those on the top, while also showing the long list after. If we want to trim the list, a separate setting, say, `ALLOWED_LICENSES` (or simply `LICENSES`, because using an unlisted license is still fine and supported) could be used instead - but that should probably be a separate issue. So should the question of whether to change the `PREFERRED_LICENSES` default for Forgejo/Codeberg, just so that we can track different issues separately, even if they're somewhat related.

👍 2

wolftune referenced this issue from Codeberg/Community

2023-12-30 16:29:19 +00:00

Update PREFERRED_LICENSES and full license list to match Codeberg's Terms and Docs #1393

Gusted commented

2023-12-30 16:29:55 +00:00

Owner

There has been a previous related discussion about this: #1409

There has been a previous related discussion about this: https://codeberg.org/forgejo/forgejo/pulls/1409

👍 1

wolftune commented

2023-12-30 16:37:54 +00:00

Sounds like this specific issue should be closed because the top-level (initial) concern is resolved.

I support @algernon 's suggestion of having a LICENSES list that instances can easily customize which amounts to what additional licenses are shown beyond the preferred ones.

Regarding that other discussion on the PR about ethical-licenses, I saw nobody suggesting that it is good to show an extensive list of obscure and outdated licenses. The debate seems only about whether or not to include newer licenses that FSF and OSI do not support. Everyone seems to support the set that FSF and OSI supports also, it's only a question of whether or not to limit to that.

Sounds like this specific issue should be closed because the top-level (initial) concern is resolved. I support @algernon 's suggestion of having a `LICENSES` list that instances can easily customize which amounts to what *additional* licenses are shown beyond the preferred ones. Regarding that other discussion on the PR about ethical-licenses, I saw nobody suggesting that it is good to show an extensive list of obscure and outdated licenses. The debate seems only about whether or not to include newer licenses that FSF and OSI do not support. Everyone seems to support the set that FSF and OSI supports also, it's only a question of whether or not to limit to that.

👍 1

No Label