An organisation must enforce licence compliance on incoming dependencies. Their counsel has approved permissive licences but forbids any code under the GNU General Public License. The team configures the "dependency-review-action" and asks how to make a pull request that introduces a GPL-licensed dependency fail the pre-merge check while continuing to permit MIT and Apache-2.0 dependencies. Which configuration meets this requirement most directly?
- uses: actions/dependency-review-action@v4
with:
# licence policy goes here- ASet "deny-licenses" to the GPL SPDX identifiers, because the action then fails the check when an introduced dependency declares a licence on that deny list while permitting others. Correct
- BSet "fail-on-severity: low" so that the action treats a disallowed licence as a low-severity vulnerability and fails the check accordingly.
- CAdd "allow-dependencies-licenses" listing only the SPDX identifiers your security team has audited, leaving GPL absent so it is implicitly skipped without failing the run.
- DEnable both "deny-licenses" with the GPL identifiers and "allow-licenses" with MIT and Apache-2.0, because the action requires both lists to be present for licence enforcement to activate.
Why A is correct: The "deny-licenses" input takes a list of SPDX licence identifiers, and the action fails the pull request check when an introduced dependency declares any listed licence. Listing the GPL identifiers blocks GPL dependencies while MIT and Apache-2.0 are unaffected, which matches the policy exactly. An "allow-licenses" input is the inverse approach for an allowlist.
Why B is wrong: The "fail-on-severity" input governs vulnerability advisories, not licences, so lowering it does not make a GPL dependency fail on licence grounds. Licence findings are handled by separate allow or deny inputs rather than by the severity threshold.
Why C is wrong: The "allow-dependencies-licenses" input names individual dependencies to exempt from scanning, not an allowed-licence list, so it does not express a licence allowlist. The wording is tempting because it contains "allow" and "licenses", but it solves a different problem and would not fail the GPL dependency.
Why D is wrong: The "allow-licenses" and "deny-licenses" inputs are mutually exclusive and you configure one or the other, not both; supplying both is an invalid configuration. The claim that both are mandatory for enforcement is incorrect, which makes this option fail rather than satisfy the requirement.