github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-11 17:46:29 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Exclude similar licences from license list #6975

New Issue
Closed
opened 2025-11-02 07:12:36 -06:00 by GiteaMirror · 7 comments
GiteaMirror commented 2025-11-02 07:12:36 -06:00
Owner
Copy Link

Originally created by @fnetX on GitHub (Mar 6, 2021).

  • Gitea version (or commit ref): 1.13.3 (Codeberg) and 1.14 (try.gitea.io)
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes

Description

A user on Codeberg told us in https://codeberg.org/Codeberg/Community/issues/407 that some licenses / licences like GPL-3.0-only are not available in the license chooser upon repository creation. This is not the case, since the licence variants usually contain the very same licence text and the user has to refer which variant it wants to use (so everything correct from Gitea's point).

Nevertheless, it would be nice to exclude those similar licences (= only include each individual licence text) to avoid confusion in the future and make sure users know that Gitea only includes the original licence text, and that selecting a variant upon creation of a repository is not enough to specify the correct version.

This would also result in a more clear and shorter licence list, if only "GPL-3.0" was available (the actual licence text) instead of the similar "-only" and "or-later" variants. I'm not sure what #2239 is about, but may be a non-redundant licence list would already help there.

Thank you.

This is a grouped list of licences that share a similar text 
options/license/LGPL-3.0-or-later       
options/license/LGPL-3.0-only

options/license/AGPL-1.0-or-later
options/license/AGPL-1.0-only

options/license/GPL-2.0-only
options/license/GPL-2.0-or-later

options/license/OFL-1.0-RFN
options/license/OFL-1.0-no-RFN
options/license/OFL-1.0

options/license/LGPL-2.0-or-later
options/license/LGPL-2.0-only

options/license/GFDL-1.2-invariants-only
options/license/GFDL-1.2-invariants-or-later
options/license/GFDL-1.2-only
options/license/GFDL-1.2-no-invariants-or-later
options/license/GFDL-1.2-no-invariants-only
options/license/GFDL-1.2-or-later

options/license/CAL-1.0-Combined-Work-Exception
options/license/CAL-1.0

options/license/MPL-2.0-no-copyleft-exception
options/license/MPL-2.0

options/license/LGPL-2.1-or-later
options/license/LGPL-2.1-only

options/license/GFDL-1.3-only
options/license/GFDL-1.3-invariants-only
options/license/GFDL-1.3-no-invariants-only
options/license/GFDL-1.3-invariants-or-later
options/license/GFDL-1.3-or-later
options/license/GFDL-1.3-no-invariants-or-later

options/license/GPL-3.0-or-later
options/license/GPL-3.0-only

options/license/OFL-1.1-no-RFN
options/license/OFL-1.1-RFN
options/license/OFL-1.1

options/license/GPL-1.0-or-later
options/license/GPL-1.0-only

options/license/AGPL-3.0-or-later
options/license/AGPL-3.0-only

options/license/GFDL-1.1-or-later
options/license/GFDL-1.1-invariants-or-later
options/license/GFDL-1.1-no-invariants-or-later
options/license/GFDL-1.1-no-invariants-only
options/license/GFDL-1.1-invariants-only
options/license/GFDL-1.1-only
Originally created by @fnetX on GitHub (Mar 6, 2021). - Gitea version (or commit ref): 1.13.3 (Codeberg) and 1.14 (try.gitea.io) - Can you reproduce the bug at https://try.gitea.io: - [x] Yes ## Description A user on [Codeberg](https://codeberg.org) told us in https://codeberg.org/Codeberg/Community/issues/407 that some licenses / licences like GPL-3.0-only are not available in the **license chooser upon repository creation**. This is not the case, since the licence variants usually contain the very same licence text and the user has to refer which variant it wants to use (so everything correct from Gitea's point). Nevertheless, it would be nice to **exclude those similar licences** (= only include each individual licence text) to avoid confusion in the future and make sure users know that Gitea only includes the original licence text, and that selecting a variant upon creation of a repository **is not enough** to specify the correct version. This would also result in a more clear and shorter licence list, if only "GPL-3.0" was available (the actual licence text) instead of the similar "-only" and "or-later" variants. I'm not sure what #2239 is about, but may be a non-redundant licence list would already help there. Thank you. <details><summary>This is a grouped list of licences that share a similar text</summary> ~~~ options/license/LGPL-3.0-or-later options/license/LGPL-3.0-only options/license/AGPL-1.0-or-later options/license/AGPL-1.0-only options/license/GPL-2.0-only options/license/GPL-2.0-or-later options/license/OFL-1.0-RFN options/license/OFL-1.0-no-RFN options/license/OFL-1.0 options/license/LGPL-2.0-or-later options/license/LGPL-2.0-only options/license/GFDL-1.2-invariants-only options/license/GFDL-1.2-invariants-or-later options/license/GFDL-1.2-only options/license/GFDL-1.2-no-invariants-or-later options/license/GFDL-1.2-no-invariants-only options/license/GFDL-1.2-or-later options/license/CAL-1.0-Combined-Work-Exception options/license/CAL-1.0 options/license/MPL-2.0-no-copyleft-exception options/license/MPL-2.0 options/license/LGPL-2.1-or-later options/license/LGPL-2.1-only options/license/GFDL-1.3-only options/license/GFDL-1.3-invariants-only options/license/GFDL-1.3-no-invariants-only options/license/GFDL-1.3-invariants-or-later options/license/GFDL-1.3-or-later options/license/GFDL-1.3-no-invariants-or-later options/license/GPL-3.0-or-later options/license/GPL-3.0-only options/license/OFL-1.1-no-RFN options/license/OFL-1.1-RFN options/license/OFL-1.1 options/license/GPL-1.0-or-later options/license/GPL-1.0-only options/license/AGPL-3.0-or-later options/license/AGPL-3.0-only options/license/GFDL-1.1-or-later options/license/GFDL-1.1-invariants-or-later options/license/GFDL-1.1-no-invariants-or-later options/license/GFDL-1.1-no-invariants-only options/license/GFDL-1.1-invariants-only options/license/GFDL-1.1-only ~~~ </details>
GiteaMirror added the type/proposal label 2025-11-02 07:12:36 -06:00
GiteaMirror commented 2025-11-02 07:12:37 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Mar 6, 2021):

License data is sourced from https://github.com/spdx/license-list-data. I guess deduplication can be attempted in the generation script but it's going to be tricky because the data has no clear indication on what a duplicate is. Maybe there is pre-vetted source available somewhere.

@silverwind commented on GitHub (Mar 6, 2021): License data is sourced from https://github.com/spdx/license-list-data. I guess deduplication can be attempted in the [generation script](https://github.com/go-gitea/gitea/blob/master/build/generate-licenses.go) but it's going to be tricky because the [data](https://github.com/spdx/license-list-data/blob/master/json/licenses.json) has no clear indication on what a duplicate is. Maybe there is pre-vetted source available somewhere.
GiteaMirror commented 2025-11-02 07:12:37 -06:00
Author
Owner
Copy Link

@fnetX commented on GitHub (Mar 7, 2021):

Well, looking at the licence list, I already wondered why SPDX publishes individual names for all those very similar licences. The point is, that they do have different proposed / default licence headers which are not part of the licence text but of their dataset.

Instead of the minimal solution of excluding the double licences, we could also improve Gitea's handling of this and either tell the user how to add the default licence header or include it somewhere:

 This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.

The latter one would bring up the legal question, if the default licence header in the README is enough to indicate which licence version is used here. It would surely suggest this to the user, but I'm not sure if it's still necessary to include this into every file.

If it's fine, it'd be a nice idea to make sure the default header for each licence finds their way into the repo, for example in the README.

@fnetX commented on GitHub (Mar 7, 2021): Well, looking at the licence list, I already wondered why SPDX publishes individual names for all those very similar licences. The point is, that they do have different proposed / default licence headers which are not part of the licence text but of their dataset. Instead of the minimal solution of excluding the double licences, we could also improve Gitea's handling of this and either tell the user how to add the default licence header or include it somewhere: ~~~ This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>. ~~~ The latter one would bring up the legal question, if the default licence header in the README is enough to indicate which licence version is used here. It would surely suggest this to the user, but I'm not sure if it's still necessary to include this into every file. If it's fine, it'd be a nice idea to make sure the default header for each licence finds their way into the repo, for example in the README.
GiteaMirror commented 2025-11-02 07:12:37 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Mar 7, 2021):

Why don't you use the [repository] PREFERRED_LICENSES option to just set your preferred variants to be at the top of the list?

@zeripath commented on GitHub (Mar 7, 2021): Why don't you use the `[repository]` `PREFERRED_LICENSES` option to just set your preferred variants to be at the top of the list?
GiteaMirror commented 2025-11-02 07:12:38 -06:00
Author
Owner
Copy Link

@fnetX commented on GitHub (Mar 7, 2021):

Why don't you use the [repository] PREFERRED_LICENSES option to just set your preferred variants to be at the top of the list?

Because that doesn't address the issue reported to Codeberg.org that the long list of similar licences implies that it's enough to select the correct variant there, although they only set the same licence text without further indicating any versions.

The SPDX details contain (JSON format used) the standardLicenseHeader field, it would be cool to add this to the README and keep the licence data as is. Sounds easier than filtering, I didn't find any cool way to do so.

@fnetX commented on GitHub (Mar 7, 2021): > Why don't you use the `[repository]` `PREFERRED_LICENSES` option to just set your preferred variants to be at the top of the list? Because that doesn't address the issue reported to Codeberg.org that the long list of similar licences implies that it's enough to select the correct variant there, although they only set the same licence text without further indicating any versions. The SPDX details contain (JSON format used) the `standardLicenseHeader` field, it would be cool to add this to the README and keep the licence data as is. Sounds easier than filtering, I didn't find any cool way to do so.
GiteaMirror commented 2025-11-02 07:12:38 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Mar 16, 2021):

Are you referring to this JSON? I don't see a standardLicenseHeader field in there.

@silverwind commented on GitHub (Mar 16, 2021): Are you referring to [this JSON](https://github.com/spdx/license-list-data/blob/master/json/licenses.json)? I don't see a `standardLicenseHeader` field in there.
GiteaMirror commented 2025-11-02 07:12:38 -06:00
Author
Owner
Copy Link

@fnetX commented on GitHub (Mar 17, 2021):

No, I was referring to the SPDX details which are in this folder.

I just noticed that some do not contain the standardLicenseHeader so we must make sure to check this :-)

My overall idea is to get the details for each license and automatically fill the template with the user data on repo creation as well as including the license header if it exists in the README. I told myself to have a look at this myself, but I won't get to this too soon.

@fnetX commented on GitHub (Mar 17, 2021): No, I was referring to the SPDX details which are in [this folder](https://github.com/spdx/license-list-data/tree/master/json/details). I just noticed that some do not contain the `standardLicenseHeader` so we must make sure to check this :-) My overall idea is to get the details for each license and automatically fill the template with the user data on repo creation as well as including the license header if it exists in the README. I told myself to have a look at this myself, but I won't get to this too soon.
GiteaMirror commented 2025-11-02 07:12:38 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Aug 9, 2022):

fixed

@6543 commented on GitHub (Aug 9, 2022): fixed
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/proposal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#6975
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?