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

Allow simpler config for license checks #116

Closed
luser opened this issue Jan 24, 2020 · 3 comments · Fixed by #118
Closed

Allow simpler config for license checks #116

luser opened this issue Jan 24, 2020 · 3 comments · Fixed by #118
Labels
enhancement New feature or request

Comments

@luser
Copy link
Contributor

luser commented Jan 24, 2020

AFAICT currently the licenses check requires explicitly listing out allowed licenses since step 5 states that crates that don't match any other rules are implicitly rejected.

For our usage I would ideally like to be able to specify a list of denied licenses without having to spell out all of the allowed licenses. My initial thought was to simply use something like:

[licenses]
unlicensed = "deny"
copyleft = "deny"

This causes the license check to fail since I don't have an allow list. Perhaps being able to change the default behavior for step 5 would be the simplest fix? Something like:

[licenses]
unlicensed = "deny"
copyleft = "deny"
default = "allow"

If this is not something you'd consider, perhaps a "generate a valid configuration that allows all of the licenses for crates currently in use" command would be helpful.

@luser luser added the enhancement New feature or request label Jan 24, 2020
@Jake-Shadle
Copy link
Member

So just to be clear, the allow-osi-fsf-free field doesn't handle your use case? I will add a default field because it is useful to allow changing that default rejection behaviour, but just curious if you have an example of a license that you would still want to allow that doesn't match a license that is in the OSI or FSF categories.

@luser
Copy link
Contributor Author

luser commented Jan 25, 2020

That is a good question and I suspect it might but I found that option confusing to think about so I'm not sure!

@Jake-Shadle
Copy link
Member

Oh? Do you have any idea on how the option could be simpler and easier to understand?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants