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
