Support for packages with multiple licenses

[jcasner]

One of the packages we're importing has multiple licenses based on dependent projects. The Github dependency-graph API returns all 3 licenses. We have each of the 3 licenses in our allow-list, but because this is a single string response, it's failing the dependency review.

Response from the depency-graph API:

  {
    "change_type": "added",
    "manifest": "package-lock.json",
    "ecosystem": "npm",
    "name": "@fortawesome/fontawesome-free",
    "version": "5.15.4",
    "package_url": "pkg:npm/%40fortawesome/fontawesome-free@5.15.4",
    "license": "CC-BY-4.0 AND MIT AND OFL-1.1",
    "source_repository_url": "https://github.com/FortAwesome/Font-Awesome",
    "scope": "runtime",
    "vulnerabilities": []
  },

Proposal
For a situation like this, the action would parse the license field and use the operator (AND) to check that all 3 licenses are in our allow-list. I can see the possibility of a dual-licensed package including an OR (e.g.: CC-BY-4.0 OR MIT) and so we'd want to use the operator (AND or OR) to validate against the allow-list or deny-list appropriately.

Thanks for your consideration!

[febuiles]

@jcasner Thanks for the report. This is something originally reported in #131 that's actively being worked on using spdx-satisfies to evaluate these expressions. I'll update this issue once there are news to share!

[febuiles]

The latest release (v3) is fully SPDX-compliant and now has support for AND/OR expressions. Sadly, your specific example is a known bug in an upstream library, so I'm not confident the newest release will allow you to specific all three licenses as listed above. The OR expressions should work fine.

I'm leaving the bug report open until spdx-satisfies has been updated.

[JPLachance]

Hello!

I do have a very similar issue. We have a long allow-list and we are constantly facing issues like the one described here.

Do we have an ETA?

[febuiles]

@JPLachance we can't proceed until jslicense/spdx-satisfies.js#14 is fixed upstream. All ears if you have suggestions on how to improve the parsing of SPDX expressions!

[JPLachance]

GitHub created multiple tools to bring security into everyone's CI in the past few years. The Dependency Review action is part of the "Supply chain security" tool chain sold under the banner of GitHub Advanced Security.

https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review

GitHub is collecting hundreds of thousands of dollars per year selling GitHub Advanced Security.

So now, are you telling us that we are blocked by an almost year old issue in a repository that has only 4 contributors and for which the last commit was on May 9, 2021, 2 years ago?

I mean, fork it at this point 😅

I'll open yet another support case to GitHub if required to make things move.

[febuiles]

@JPLachance Your excitement regarding the project is very motivating, thank you for your comment!

It sounds like this issue is problematic for you as an Advanced Security customer (FOSS projects get GHAS for free), and in that case I think the best way to move forward is to open a support ticket, that'll help this type of work get prioritized.

[prakyathr]

Any updates on this issue? We are using many packages which uses multiple licenses. Since this is a paid service, can we expect any timeline to fix it?

[jonjanego]

We are using many packages which uses multiple packages

HI @prakyathr thank you for following up on this. Could you clarify, do you mean you're using packages that use multiple licenses?

[prakyathr]

Hi @jonjanego , you are right. I meant packages that uses multiple licenses. I fixed the typo in the comment above as well. Anyway, will it be fixed soon?

[jonjanego]

@prakyathr Thanks for clarifying! We're going to look into this and will share an update when we have more information on next steps.

[juxtin]

I just wanted to add a link to @elireisman comment here so it doesn't get lost: https://github.com/actions/dependency-review-action/pull/719/files#r1636935433

In short, #719 makes progress towards fixing this issue, but it doesn't quite get there. I have a test repo that confirms this.

[jtomkiew-mng]

Just putting a note here that since version 4.3.4 there is no workaround for packages with licence expressions (#792) and implementing this would be a welcome addition.

[wmmc88]

@juxtin So since version 4.3.4, is the only way to pass the pipeline when some dependencies use AND licenses is to add the package to allow-dependencies-licenses? Since expressions in allow-licenses are no longer allowed

[jaymevillafranca]

This is still an issue as of v4.3.4. I opened a support ticket recently and they pointed me to this issue. Why hasn't there been a fix yet after 2 years?

[jonjanego]

Thanks for the feedback. We don't have this in our immediate plans but it's on our radar.