8000 Add REUSE support in the GitHub licensee library · Issue #901 · fsfe/reuse-tool · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add REUSE support in the GitHub licensee library #901

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.

Sign up for GitHub

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

Jump to bottom
Open
ottok opened this issue Jan 26, 2024 · 7 comments
Open

Add REUSE support in the GitHub licensee library #901

ottok opened this issue Jan 26, 2024 · 7 comments
Labels
8000 stale upstream It's someone else's problem

Comments

@ottok
Copy link
ottok commented Jan 26, 2024

Currently it seems that the GitHub licensee Ruby library they use for detecting licenses does not read the path LICENSES/. People hosting their code on GitHub probably value having GitHub detect their license correctly. Thus it might help drive adoption if the licensee matchers at https://github.com/licensee/licensee/tree/main/lib/licensee/matchers were extended to read the places REUSE recommends developers to use.

I am posting this for visibility while I am fully aware that this is not a bug in the reuse-tool itself.
@Mikaela
Copy link
Contributor
Mikaela commented Jan 26, 2024

licensee/licensee#635 looks like a related issue on their side although it's only about SPDX identifiers rather than the LICENSES/ directory.

@ottok ottok mentioned this issue Jan 28, 2024
Open
@mxmehl mxmehl added the upstream It's someone else's problem label Jan 29, 2024
@mxmehl
Copy link
Member
mxmehl commented Jan 29, 2024

There have been a number of upstream issues about this already, and also discussions via Twitter IIRC. Mike Linksvayer has made it quite clear that they only implement this when a pull request is made by a third party.

The REUSE team doesn't currently plan to do that but we welcome any initiative!

@nicorikken nicorikken mentioned this issue Apr 17, 2024
Closed
@sdavids
Copy link
sdavids commented Apr 17, 2024 •
edited
Loading

Mike Linksvayer has made it quite clear that they only implement this when a pull request is made by a third party.

The PR should target which repo?

https://github.com/licensee/licensee ?

@nicorikken
Copy link
Member

Indeed, unless GitHub has changes libraries in the mean time, but I wouldn't think so. Regardless, it would be good to have it in this commonly used library.

@carmenbianca
Copy link
Member

Linking the relevant licensee issue here: licensee/licensee#490

@silverhook silverhook mentioned this issue May 13, 2024
Closed
@erickt erickt mentioned this issue Feb 20, 2025
Open
@github-actions GitHub Actions
Copy link

Thank you for your time and contributions! Unfortunately, this issue has been inactive for quite a while which means we probably can't manage the time to deal with it. That's why we're marking it as stale. We want to keep things tidy and focus on active discussions, but we’re always happy to revisit if this is still relevant!

If you’d like to keep this open, please add a comment to let us know and remove the label stale. Otherwise, this issue will most likely be automatically closed soon.

@github-actions github-actions bot added the stale label Apr 19, 2025
@ottok
Copy link
Author
ottok commented Apr 19, 2025

I see licensee/licensee#490 was marked stale and closed as "completed" even though it wasn't resolved. This issue isn't resolved either, so logically it should stay open until resolved. One would assume that closing issues that aren't actually fixed just leads to them being filed again as new issues?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
stale upstream It's someone else's problem
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@sdavids @ottok @Mikaela @mxmehl @nicorikken @carmenbianca
155F
0