Description
I'll start with an opinion: a license deny list is a bad idea. A company using one would put copyleft licenses like GPL-2.0 in there, potentially missing other copyleft licenses like CC-BY-SA-4.0 or maybe they would forget to also add GPL-3.0. Additionally, it's easy to miss commercial licenses like Elastic which could be a problem for some users. This is even more an issue now that ClearlyDefined includes more license identifiers than ever before. A deny list provides very limited risk reduction.
Up until recently, DRA did not provide the tools necessary to remediate failures. The most important remediation is the ability to say "I've reviewed this package and it's fine", and DRA could do that, but only if the license was a valid license expression. Recent DRA releases check if a package is on the allow-dependencies-licenses list first, so it can pass even if there's an invalid license.
We should deprecate the deny list option in a 4.x release in preparation for an eventual 5.x release that removes it. It would be interesting to see if we have feedback that comes out in favor of deny lists and provides some justification as to why our product should support it.
Acceptance Criteria
- The README lists deny-licenses as deprecated
- The summary output from the action includes a very visible warning that deny-licenses is deprecated
- 4.x release is made with this behavior