Support SPDX expressions with operators in allow/deny license lists

[jebeaudet]

This change updates license validation to support full SPDX expressions (such as 'EPL-1.0 AND LGPL-2.1') in both allow-lists and deny-lists. This enables the action to correctly validate packages that declare multiple licenses using SPDX conjunctions like AND/OR, which are common in the field.

One concrete example is logback-core which is licensed as EPL-1.0 AND LGPL-2.1 AND LGPL-2.1-only source. With the latest version of this action, it is not possible to have a SPDX expression in the allow list which makes this license impossible to accept. Also, declaring the 3 licenses as allowed individually (allow: ['EPL-1.0', 'LGPL-2.1', 'LGPL-2.1-only']) does not work either because satisfiesAny does not consider it as valid.

The new logic uses spdx.satisfies() to evaluate whether a package’s declared license satisfies any expression in the allow/deny list, and comprehensive tests have been added to verify behavior for various SPDX
combinations.

This is a follow up of #915 after we upgraded our internal license check pipeline to the latest version which made me realize this bug/limitation.

fixes #897 #907

[Copilot]

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

[jebeaudet]

I added a small repository to highlight my problem https://github.com/jebeaudet/dep-review-bug-example.

You'll find there one PR that has the 3 licenses of logback-core individually so you can see the failure jebeaudet/dep-review-bug-example#1.

The other PR has the proper SPDX expression in the allow-list so you can see that the dependency-review-action does not allow SPDX expressions in the allow-list jebeaudet/dep-review-bug-example#2. Remember that we don't see the error because exceptions are swallowed by the action here. The exception message that would be printed can be found here.

[JPLachance]

From what I understand, this change brings us back to a working implementation and fixes the issues introduced in v4.3.4.

Thanks!!!

[ahpook]

@jebeaudet Hi, thank you so much for contributing this change! I'm working on validating it to see if we can make a new release that will hopefully address the problem for everyone.

To make sure I understand correctly: the goal is that an allow-licenses list that contains all three licenses as independent, comma-separated values A, B, C, should permit a package with an spdx expression of A AND B AND C.

I am still seeing a failure though, when using your test repo and running the workflow @ main to get the most recent code - check out:

ahpook/dep-review-bug-example#2

[jebeaudet]

@ahpook Thanks for reviewing this. It was not super clear in my description, but A AND B AND C can only be allowed by an entry in the allow-list A AND B AND C. It makes sense when you think about it since a dual/triple licensed project is a combination of many licenses so allowing each license individually is not entirely the same.

You can see how my patches allow this here : jebeaudet/dep-review-bug-example#4

GPT answer on dual MIT AND Apache-2.0 licensed project

From a license compliance perspective in a company, is accepting the licenses MIT and Apache-2.0 separately the same as allowing a dual licensed project that would have a spdx MIT AND Apache-2.0?

From a license compliance perspective, there is an important distinction between accepting projects licensed under MIT or Apache-2.0 individually, and accepting a project that is dual-licensed under MIT AND Apache-2.0.

Here’s the breakdown:

1. Accepting MIT or Apache-2.0 separately

This means:
• Projects licensed under just MIT are OK.
• Projects licensed under just Apache-2.0 are OK.
• You evaluate and approve each license independently.

2. Dual-licensed MIT AND Apache-2.0

This means:
• You must comply with both the MIT and Apache-2.0 licenses simultaneously.
• You do not get to choose one or the other; both apply.

This is different from:
• MIT OR Apache-2.0, where you choose either one license (more permissive)
• MIT AND Apache-2.0, where both sets of obligations must be met (more restrictive)

⸻

Compliance Implications:
• If your compliance policy only allows use of packages licensed under MIT or Apache-2.0 individually, it does not automatically allow a dual-licensed MIT AND Apache-2.0 project.
• For “AND” dual licenses, you have to ensure you can meet the conditions of both licenses:
• E.g., Apache-2.0 includes explicit patent grants and NOTICE file requirements, which MIT does not.
• So the combined license might have more obligations than either one alone.

⸻

Summary:

No, accepting MIT and Apache-2.0 separately is not the same as accepting a dual-licensed project with MIT AND Apache-2.0. You need to review and explicitly allow the combination.

[ahpook]

@jebeaudet i see, thanks for the explanation. i was basing my expectations on the comments from @jcasner in #263:

For a situation like this, the action would parse the license field and use the operator (AND) to check that all 3 licenses are in our allow-list.

But your (and ChatGPT's 😄 ) reasoning makes sense. I'll get back and do more testing on this.

[jebeaudet]

Yea, supporting MIT AND Apache-2.0 or MIT + Apache-2.0 individually is not the same, I believe the expectations in the OP of #263 are incorrect. I'll reach out to my legal team here just to confirm but it seems logical like this.

[jebeaudet]

I've confirmed with my legal team internally that my answer, and chatgpt's, is correct.