[BUG] Excluded from license check and SPDX validation not working correctly

[ES00660463]

Describe the bug I have several repositories in the organization that are having problems with some packages, especially from NPM.

For example, in the @primeng/themes library (https://github.com/primefaces/primeng/blob/master/packages/themes/package.json), the value "SEE LICENSE IN LICENSE.md" is detected, which is an accepted value by NPM (https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#license), but Dependency Review does not mark it as unknown as it does with those it does not detect; instead, it marks it as an invalid value and blocks the flow.

In addition, even if we put that library in the 'allow-dependencies-licenses' field, Dependency Review ignores or does not apply that configuration and continues to block the flow.

It does not seem like good behavior to mark unknown packages as warnings and yet, packages with a manageable value block the flow and additionally block it even though they are on the whitelist.

To Reproduce

1. Create or have a repository with a package.json that includes the @primeng/themes library.
2. Disponer de un workflow para ejecutar Dependency Review cuyo paso principal sea similar a este:

      - name: 'Dependency Review'
        uses: actions/dependency-review-action@v4
        with:
          deny-licenses: GPL-2.0, GPL-3.0, AGPL-3.0, MPL-2.0-no-copyleft-exception, EPL-1.0
          allow-dependencies-licenses: 'pkg:npm/@primeng/themes'
          show-openssf-scorecard: false

3. View the execution results and check that the lock occurs.

Expected behavior Regardless of whether the tool should manage the value "SEE LICENSE IN LICENSE.md" (which from our perspective it should at least manage because it is an accepted value in the package.json file), at the very least, if the library is on the list of accepted ones, it should allow the flow to proceed and not block it.

Screenshots

Action version v4 (that points to the latest version v4.7.1)

[muawiakh]

We are facing a similar issue, where we exclude some packages via:

allow-dependencies-licenses: pkg:npm/%40n8n/typescript-config,pkg:npm/%40n8n_io/ai-assistant-sdk,pkg:npm/n8n,pkg:npm/n8n-workflow

and we see:

pnpm-lock.yaml » @n8n/[email protected] – License: SEE LICENSE IN LICENSE.md
pnpm-lock.yaml » @n8n_io/[email protected] – License: UNLICENSED

Interestingly the packages pkg:npm/n8n,pkg:npm/n8n-workflow do not error out even though they have SEE LICENSE IN LICENSE.md on npm:

https://www.npmjs.com/package/n8n https://www.npmjs.com/package/n8n-workflow

[dangoor]

Hello, @ES00660463! I believe the license allow list is more tolerant of the interaction of poorly formed licenses and the allow-dependencies-licenses option. We're planning to deprecate deny-licenses (see #938).

@muawiakh Does your configuration also use deny-licenses?

[ES00660463]

Yes, we use deny-licenses, but I don't quite understand the point of doing it the way you suggest.

What the tool offers is to detect licenses in libraries and then have a list of allowed ones even if they have a license from the list.

In addition to the "deny-licenses" field, we use the "allow-dependencies-licenses" field. The former is used to detect disallowed licenses, and the latter is used to allow licenses that we believe may be used for other reasons, even though they do not have an allowed license.

The "allow-dependencies-licenses" field alone is meaningless if a license has not been blocked before, and removing the deny-licenses field implies that of the two existing blocking reasons, license or vulnerability, we would lose the license reason.

We're interested in this tool for its two features: vulnerability blocking and license blocking. Will it stop blocking by license? Will we lose functionality?

You'll have to lower the price of GHAS if you remove features, right?

[dangoor]

@ES00660463 We're still doing blocking by license, but through an allow list instead of a deny list. (See #938 for discussion about that.) Now that "allow-dependencies-licenses" is working properly and invalid SPDX IDs don't cause everything to stop working, it's easier to have a successful experience with an allow list. So, relevant to this issue, migrating to an allow list and using allow-dependencies-licenses for packages that are known to be good should address the issues you've seen here.

[ES00660463]

Hello @dangoor

I understand what you are saying, but the SPDX license list is huge (https://spdx.org/licenses/).

It seems crazy to me to have to include the entire list just to then remove licenses.

In addition to having to stay alert for new licenses to include them in the list.

If the action, from the start, already allows the pass of all licenses, it seems to me an outdated approach to have to include the entire list when what I want is to use the original functionality and block licenses.