Fix allow list with multiple license

[kachick]

I have faced an issue to integrate stylelint. It depends meow, meow depends type-fest. Then type-fest has dual license.

Their license is written in SPDX 2.0, the syntax is recommended by npm.

GitHub REST API returns as below.

  {
    "change_type": "added",
    "manifest": "package-lock.json",
    "ecosystem": "npm",
    "name": "type-fest",
    "version": "0.18.1",
    "package_url": "pkg:npm/[email protected]",
    "license": "CC0-1.0 OR MIT OR (CC0-1.0 AND MIT)",
    "source_repository_url": "https://github.com/sindresorhus/type-fest",
    "vulnerabilities": [

    ]
  },
  {
    "change_type": "added",
    "manifest": "package-lock.json",
    "ecosystem": "npm",
    "name": "type-fest",
    "version": "0.8.1",
    "package_url": "pkg:npm/[email protected]",
    "license": "MIT OR (CC0-1.0 AND MIT)",
    "source_repository_url": "https://github.com/sindresorhus/type-fest",
    "vulnerabilities": [

    ]
  },
  {
    "change_type": "added",
    "manifest": "package-lock.json",
    "ecosystem": "npm",
    "name": "type-fest",
    "version": "0.6.0",
    "package_url": "pkg:npm/[email protected]",
    "license": "MIT OR (CC0-1.0 AND MIT)",
    "source_repository_url": "https://github.com/sindresorhus/type-fest",
    "vulnerabilities": [

    ]
  },

That is not simple to parse with current parsing logics.
So I have added the library of https://github.com/jslicense/spdx-satisfies.js.

Although, deny list looks hard to integrate to current spec. (And guessing hard to implement by me 🙇‍♂️ )
So I have added skipping test only for deny list. If it is not good, please remove.

[kachick]

Run eslint with existing config makes many non related alerts. I have updated them. However when the diff is needless, I'll revert them. (Looks CI is not checking them) 🙏

[kachick]

spdx-satisfies.js throw errors if given string is invalid in SPDX list.

That might make broken CI for users, however the spec is written in README.md 🤔

dependency-review-action/README.md

Lines 57 to 61 in 24ab96e

	# Possible values: Any `spdx_id` value(s) from https://docs.github.com/en/rest/licenses
	# allow-licenses: GPL-3.0, BSD-3-Clause, MIT
	#
	# Possible values: Any `spdx_id` value(s) from https://docs.github.com/en/rest/licenses
	# deny-licenses: LGPL-2.0, BSD-2-Clause

[kachick]

Added kind error into early stage 6738e7d

[brphelps]

@kachick -- I'm not super familiar with the licensing changes, but it looks like you've grouped together some unrelated changes like adding linting + linter integration. It seems like those changes warrant a PR split!

[kachick]

@brphelps Sure! I have updated this PR for focusing multiple license issue.

And extracted CI and lint in following PR kachick#1
I can send it after this PR closed.

[febuiles]

@kachick Thanks a ton for highlighting this issue! I need to find out how the licenses are being handled in the backend, and see if it's expected that they will include SPDX expressions going forward. I'll post an update when I have more info!

[febuiles]

@kachick Going forward the API will be using SPDX licenses. I have some ideas about augmenting our current license dataset, but for the time being I think using spdx-satisfies is the proper way to move forward. What conflicts did you encounter when dealing with the denylist?

[kachick]

I couldn’t imagine reasonable specs for a denying condition and a given combining condition. 🤔

For example, below patterns.

Allow License	Deny License	Given License	They should be…?
MIT	GPL-1.0-or-later	GPL-1.0-or-later AND MIT	False
MIT	GPL-1.0-or-later	GPL-1.0-or-later OR MIT	Validation error
(Empty list is given)	GPL-1.0-or-later	GPL-1.0-or-later OR MIT	True?

Personally I hope false-positive is the preferable way for this action. Or raising errors for some patterns might be robust even if making many alerts.

[febuiles]

Thanks for bringing up a good point! I will remove the example with an allow list since the action doesn't support both allow/deny: https://github.com/actions/dependency-review-action/#licenses. Using an example from an actual library:

Deny License	Given License	Result
MIT/X11 OR Apache-2.0	MIT/X11	Invalid license
MIT/X11	MIT/X11 OR Apache-2.0	Valid license

I've thought about this for a while, and the SPDX expression is valid, so we should not be biasing what happens here.

I was initially a bit concerned about SDPX expressions, but I've noticed that they are used more to express "This project uses license X AND Y" than "This project has uses X AND has used Y in the past".

I fetched a full list of unique licenses for all repos: https://gist.github.com/febuiles/985fb5215e72fd196cd9a7ea7fca1a2f. You can see there's a lot of funky stuff in there, but the actual number of repos with those long licenses is not significant.

@kachick what do you make out of all of this? Does it make sense to use spdx-satisfies to cover both allow/deny lists under this lens?

[kachick]

Sorry for my late response 🙇‍♂️

Looks updating this issue with #294. And this PR based on outdated code now. So please close this PR for now.