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

REUSE 3.0 Specification Support? #490

Closed
echohack opened this issue Apr 7, 2021 · 7 comments
Closed

REUSE 3.0 Specification Support? #490

echohack opened this issue Apr 7, 2021 · 7 comments
Labels

Comments

@echohack
Copy link

echohack commented Apr 7, 2021

Hello, I am opening a new issue in the same spirit as #413

I think it would be really handy if licensee could detect a license if the REUSE 3.0 Specification is in use. Specifically, REUSE dictates that all license files are located in the LICENSES/ directory at the root of a project, even if there is only one license.

I personally think there's a simple implementation to detect if there's only one file in this directory, and if there is, declare it to be the project's license. If not, then it's clear something more complicated is happening with the project's license, and it's worth it to declare the project license as unknown. A human likely has to intervene anyway in these more complex cases, even if licensee could semantically detect a multiple license scenario correctly.

Thank you for all the work you've done on licensee, and please feel free to close this issue out if this feature request continues to be a wontfix. Thank you!

@mlinksva
Copy link
Contributor

I don't have any plans to work on this. If someone would like to propose an implementation here and then after discussion make a PR, I'd be happy to take a look. A start would be some pointers to use in the wild, that could be used to inform tests.

@mlinksva
Copy link
Contributor

a simple implementation to detect if there's only one file in this directory, and if there is, declare it to be the project's license

That would be fine with me. Presumably the filename of the license would also need to match the detected license, per the spec.

@stale
Copy link

stale bot commented Jun 16, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jun 16, 2021
@mxmehl
Copy link

mxmehl commented Jun 21, 2021

I would like to second this request. REUSE has been adopted by a lot of projects already, and using the LICENSES/ is also recmmended by the CII best practices, and implemented by the Linux Kernel.

It's not uncommon that a project has code and assets under more than one license.

@stale stale bot removed the wontfix label Jun 21, 2021
@stale
Copy link

stale bot commented Aug 22, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Aug 22, 2021
@stale stale bot closed this as completed Sep 19, 2021
@ghost91-
Copy link

I also second this request. REUSE seems like the best available solution for properly handling licensing information, in particular if more than one license is involved. And it's already adopted pretty widely, as mentioned by @mxmehl last year.

What's the best way to move forward with this?

@nicorikken
Copy link

I looked into the Licensee code to see what needs to be done. My conclusion thus far:

  • Include LICENSES/ directory in file scan in lib/licensee/projects/. Probably requires forwarding this context of the subdirectory for further processing.
  • Also index files in LICENSES/ as LicenseFile in lib/licensee/project_files/license_file.rb.
  • Perhaps also check if the detected license matches the filename in LICENSES/, as suggested by @mlinksva to strictly implement the spec.

It certainly seems doable, but requires some care to avoid restructuring the matching process. I hope to find the time to create a PR in the near future.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants