Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
RealFascinated opened this issue Apr 12, 2023 · 11 comments · Fixed by #24872
Closed

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

RealFascinated opened this issue Apr 12, 2023 · 11 comments · Fixed by #24872
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Milestone

Comments

@RealFascinated
Copy link

Feature Description

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

Screenshots

No response

@RealFascinated RealFascinated added type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Apr 12, 2023
@silverwind
Copy link
Member

silverwind commented 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.

@jolheiser
Copy link
Member

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)

@jellykells
Copy link

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

@delvh
Copy link
Member

delvh commented Apr 13, 2023

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

@jellykells
Copy link

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

Yes exactly

@silverwind
Copy link
Member

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

@jellykells
Copy link

jellykells commented 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.

@silverwind
Copy link
Member

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
Copy link
Member

silverwind commented 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.

@jellykells
Copy link

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.

@yp05327 yp05327 mentioned this issue May 23, 2023
10 tasks
@andreashaerter
Copy link

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.

@lunny lunny added this to the 1.23.0 milestone Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants