We'd thought that the syntax in #974 would avoid auto-linking
but didn't check closely enough, and now the deprecation issue
it links to cannot be loaded due to having too many references.
This updates the text to point to a new issue in a way that...
I hope... will not be auto-linked.
When the dependency review summary exceeds GitHub's size limit (1024k), upload it as an artifact and provide a link in the comment. This ensures users can still access the full review details even when the summary is too large to display directly.
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
When using the `allow-dependencies-licenses` option, the packages listed
there should be allowed even if they have no license. This wasn't
working because the filtering for allowed dependencies was done
specifically on the list of packages that had licenses, leaving a
separate list (unfiltered) for packages with no licenses. With this
change, we filter out any changes for packages that have been allowed
_before_ we retrieve licenses.
Fixes#889
ClearlyDefined uses the string `OTHER` for the declared license when
a human has reviewed `NOASSERTION` text and found it to be a valid
license, but one without an SPDX identifier. `OTHER`, unlike
`NOASSERTION`, is not valid. With this change, when `OTHER` appears
in a license string, we'll replace it with
`LicenseRef-clearlydefined-OTHER`, which _is_ valid and will allow
the expressions to parse.
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.
