Make it more obvious what license a repo is using #10640

New Issue

GiteaMirror · 2025-11-02T09:13:58-06:00

GiteaMirror commented

2025-11-02 09:13:58 -06:00

Originally created by @RealFascinated on GitHub (Apr 12, 2023).

Feature Description

Adding a ui element to show what license the repo is using eg: MIT

Screenshots

No response

Originally created by @RealFascinated on GitHub (Apr 12, 2023). ### Feature Description Adding a ui element to show what license the repo is using eg: MIT ### Screenshots _No response_

GiteaMirror added the type/proposal type/feature labels 2025-11-02 09:13:58 -06:00

GiteaMirror closed this issue

2025-11-02 09:13:58 -06:00

GiteaMirror commented

2025-11-02 09:13:59 -06:00

@silverwind commented on GitHub (Apr 12, 2023):

License detection is complicated, requires heuristics and because of this, it'll never deliver perfect results unless the programming community as a whole standardizes on a format, which also won't happen.

GitHub does this via licensee, but we can't leverage easly it because it's Ruby. Maybe it can be ran as a subprocess.

@silverwind commented on GitHub (Apr 12, 2023): License detection is complicated, requires heuristics and because of this, it'll never deliver perfect results unless the programming community as a whole standardizes on a format, which also won't happen. GitHub does this via [licensee](https://github.com/licensee/licensee), but we can't leverage easly it because it's Ruby. Maybe it can be ran as a subprocess.

GiteaMirror commented

2025-11-02 09:13:59 -06:00

@jolheiser commented on GitHub (Apr 12, 2023):

In case someone is interested at looking in to this:

https://licensee.github.io/licensee/#the-solution
(and for that last part, https://github.com/adrg/strutil#sorensen-dice)

@jolheiser commented on GitHub (Apr 12, 2023): In case someone is interested at looking in to this: https://licensee.github.io/licensee/#the-solution (and for that last part, https://github.com/adrg/strutil#sorensen-dice)

GiteaMirror commented

2025-11-02 09:13:59 -06:00

@jellykells commented on GitHub (Apr 13, 2023):

As I suggested in #12905, license detection doesn't need to be implemented for this feature, even though it would be nice to have

@jellykells commented on GitHub (Apr 13, 2023): As I suggested in #12905, license detection doesn't need to be implemented for this feature, even though it would be nice to have

GiteaMirror commented

2025-11-02 09:14:00 -06:00

@delvh commented on GitHub (Apr 13, 2023):

Ah, you mean that a repo can set itself what license it uses, i.e. in the settings?

@delvh commented on GitHub (Apr 13, 2023): Ah, you mean that a repo can set itself what license it uses, i.e. in the settings?

GiteaMirror commented

2025-11-02 09:14:00 -06:00

@jellykells commented on GitHub (Apr 13, 2023):

Ah, you mean that a repo can set itself what license it uses, i.e. in the settings?

Yes exactly

@jellykells commented on GitHub (Apr 13, 2023): > Ah, you mean that a repo can set itself what license it uses, i.e. in the settings? Yes exactly

GiteaMirror commented

2025-11-02 09:14:00 -06:00

@silverwind commented on GitHub (Apr 13, 2023):

I don't see a manual license setting as a solution. Other forges do auto-detection, so we are kind of forced to do too. This also avoids a potential mismatch problem between a manually set license and a different one via LICENSE file (or other means like package.json).

@silverwind commented on GitHub (Apr 13, 2023): I don't see a manual license setting as a solution. Other forges do auto-detection, so we are kind of forced to do too. This also avoids a potential mismatch problem between a manually set license and a different one via `LICENSE` file (or other means like package.json).

GiteaMirror commented

2025-11-02 09:14:01 -06:00

@jellykells commented on GitHub (Apr 13, 2023):

I don't see a manual license setting as a solution. Other forges do auto-detection, so we are kind of forced to do too. This also avoids a potential mismatch problem between a manually set license and a different one via LICENSE file (or other means like package.json).

If auto-detection is ever enabled a manual override will almost certainly be necessary in cases of potential mismatch or misdetection anyway, so I think the manual selection might as well be implemented first since it does not rely on any new dependencies.

Also as an aside, I don't think what other code forges do should force Gitea to do anything. Gitea should forge (pun intentional) its own path and cater to its own users.

@jellykells commented on GitHub (Apr 13, 2023): > I don't see a manual license setting as a solution. Other forges do auto-detection, so we are kind of forced to do too. This also avoids a potential mismatch problem between a manually set license and a different one via `LICENSE` file (or other means like package.json). If auto-detection is ever enabled a manual override will almost certainly be necessary in cases of potential mismatch or misdetection anyway, so I think the manual selection might as well be implemented first since it does not rely on any new dependencies. Also as an aside, I don't think what other code forges do should force Gitea to do anything. Gitea should forge (pun intentional) its own path and cater to its own users.

GiteaMirror commented

2025-11-02 09:14:01 -06:00

@silverwind commented on GitHub (Apr 13, 2023):

Other forges are having automation so we have to have too. Imagine you have hundrets of repos to migrate between forges, you don't want to manually set their licenses on each of them. If such a topic is important to you, you might even end up not choosing gitea because of the lack of automatism.

@silverwind commented on GitHub (Apr 13, 2023): Other forges are having automation so we have to have too. Imagine you have hundrets of repos to migrate between forges, you don't want to manually set their licenses on each of them. If such a topic is important to you, you might even end up not choosing gitea because of the lack of automatism.

GiteaMirror commented

2025-11-02 09:14:01 -06:00

@silverwind commented on GitHub (Apr 13, 2023):

https://github.com/go-enry/go-license-detector looks like something that might work as a start, it seems to re-implement what licensee does.

@silverwind commented on GitHub (Apr 13, 2023): https://github.com/go-enry/go-license-detector looks like something that might work as a start, it seems to re-implement what licensee does.

GiteaMirror commented

2025-11-02 09:14:01 -06:00

@jellykells commented on GitHub (Apr 13, 2023):

Other forges are having automation so we have to have too. Imagine you have hundrets of repos to migrate between forges, you don't want to manually set their licenses on each of them. If such a topic is important to you, you might even end up not choosing gitea because of the lack of automatism.

Gitea has no license detection currently, meaning those users are out of luck anyway, but if adding a license detector is on someone's roadmap then great!

Another Github-specific option is to just use the existing API to retrieve the license for a repo during migration.

@jellykells commented on GitHub (Apr 13, 2023): > Other forges are having automation so we have to have too. Imagine you have hundrets of repos to migrate between forges, you don't want to manually set their licenses on each of them. If such a topic is important to you, you might even end up not choosing gitea because of the lack of automatism. Gitea has no license detection currently, meaning those users are out of luck anyway, but if adding a license detector is on someone's roadmap then great! Another Github-specific option is to just use the existing API to retrieve the license for a repo during migration.

GiteaMirror commented

2025-11-02 09:14:02 -06:00

@andreashaerter commented on GitHub (Dec 30, 2023):

License detection is complicated, requires heuristics and because of this, it'll never deliver perfect results unless the programming community as a whole standardizes on a format, which also won't happen.

Just as a side-note: https://reuse.software/ by the FSFE is a cool project to fix this and >70% of e.g. the Linux kernel is already on boat.

@andreashaerter commented on GitHub (Dec 30, 2023): > License detection is complicated, requires heuristics and because of this, it'll never deliver perfect results unless the programming community as a whole standardizes on a format, which also won't happen. Just as a side-note: https://reuse.software/ by the FSFE is a cool project to fix this and >70% of e.g. the Linux kernel is already on boat.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10640