The allow-licenses list is expected (and documented) to be a list of
SPDX license IDs (LicenseRefs are also valid). If someone puts an
expression in the list (e.g. "GPL-3.0-only OR MIT"), it should be
discarded so that the whole list does not become invalid.
Fixes#907
There are many packages that are dual-licensed, offering a choice
of licenses (e.g. `MIT OR Apache-2.0`). There are some that include
code from multiple sources and require multiple licenses
(e.g. `MIT AND Apache-2.0`). There are also complex combinations that
can exist for a variety of reasons, such as
`MIT AND (Apache-2.0 OR BSD-3-Clause)`.
The most straightforward approach to handle these is to have an
allow list. As long as the licenses on the allow list can satisfy
the license expression of the package in question, it should pass.
To implement this, I the newest release of spdx-satisfies
which changed the interface to be exactly as described
`satisfies(license, allowList)` (see
https://github.com/jslicense/spdx-satisfies.js/pull/17).
Fixes https://github.com/actions/dependency-review-action/issues/263
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 complex
open-source projects.
Previously, only simple license identifiers were supported, which caused
multi-licensed packages to be improperly flagged as invalid even when
they matched the intent of the allow-list.
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 improves compatibility with projects using compound SPDX license
expressions and ensures more accurate license policy enforcement.
