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 license exceptions additive #398

Merged
merged 2 commits into from
Jan 31, 2022
Merged

Make license exceptions additive #398

merged 2 commits into from
Jan 31, 2022

Conversation

Jake-Shadle
Copy link
Member

This closes #276, I let it linger way too long, this just reimplements it.

Resolves: #135

@Jake-Shadle Jake-Shadle merged commit 1cd0951 into main Jan 31, 2022
@Jake-Shadle Jake-Shadle deleted the additive-exceptions branch January 31, 2022 09:24
@kim
Copy link

kim commented Feb 11, 2022

Unfortunately, this seems to have broken my build. I have an exception for ring to allow the OpenSSL license (it does not technically apply to the Rust code), like so:

exceptions = [
    { allow = ["ISC", "MIT", "OpenSSL"], name = "ring" }
]

Since cargo-deny also doesn't know how to interpret ring's license, I also have a clarify:

[[licenses.clarify]]
name = "ring"
expression = "ISC AND MIT AND OpenSSL"
license-file = [{ path = "LICENSE", hash = 0xbd0eed23 }]

This used to work, but since the latest release gives an error:

    │ expression = "ISC AND MIT AND OpenSSL"
    │               ^^^-----^^^-----^^^^^^^
    │               │       │       │
    │               │       │       rejected: explicitly denied
    │               │       accepted: license is explicitly allowed
    │               license expression retrieved via user override
    │               accepted: license is explicitly allowed via an exception

I understand that "make additive" means "in addition to the allow / deny lists", and indeed I can make the check pass if I remove "OpenSSL" from deny. I find this confusing though: I really don't want OpenSSL-licensed dependencies, so I should be able to express that, no?

What's the recommended way to deal with this? Invent a license identifier which only matches ring, and allow that? EDIT: sorry scap that, it needs to be a known SPDX identifier

@Jake-Shadle
Copy link
Member Author

Oh, we never specifically deny licenses so I didn't see this issue, I'll just have to change the order licenses are checked tomorrow.

@kim
Copy link

kim commented Feb 11, 2022

Ah, so anything not explicitly allowed is denied? Somehow I didn't realise this, working from someone else's template. I guess that'd work for me, too.

kim added a commit to kim/radicle-link that referenced this pull request Feb 14, 2022
The latest `cargo-deny` breaks our build evaluating the custom licensing
rules for `ring`. Until fixed upstream, remove the OpenSSL license from
the deny list (but also not allow it).

See: EmbarkStudios/cargo-deny#398

Signed-off-by: Kim Altintop <kim@eagain.st>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make license exceptions additive
2 participants