Simplify license expressions

[nicorikken]

Is your feature request related to a problem? Please describe.
We migrated to an allow-list. Our allow-licenses list is expanding rapidly to deal with complex license expressions.
Some examples:

  - LicenseRef-scancode-public-domain AND Unlicense  # pkg:npm/big-integer
  - Apache-2.0 AND LicenseRef-scancode-unknown-license-reference  # pkg:maven/org.apache.camel*
  - EPL-2.0 AND BSD-3-Clause AND Apache-1.1 AND EPL-2.0 AND EPL-1.0 AND Apache-1.1 AND Apache-2.0 AND BSD-2-Clause AND Apache-2.0 AND Apache-1.1 AND BSD-3-Clause  # pkg:maven/org.aspectj:aspectjweaver
  - Apache-1.1 AND Apache-2.0 AND BSD-3-Clause AND EPL-2.0 AND GPL-1.0-or-later AND LicenseRef-scancode-generic-export-compliance AND LicenseRef-scancode-public-domain AND MIT AND SAX-PD AND xpp. # pkg:maven/org.glassfish.jaxb:jaxb-runtime
  - Apache-2.0 AND BSD-3-Clause AND EPL-1.0 AND LicenseRef-scancode-other-copyleft. # pkg:maven/org.springframework:spring*

I would expect aspectjweaver to be simplified to EPL-2.0, just as it says in the repo.

The GPL-1.0-or-later in pkg:maven/org.glassfish.jaxb:jaxb-runtime is suspicious. I can't reproduce it looking at the source code.

For the Maven projects the advanced-security/maven-dependency-submission-action is used.

To me it feels as though the new license scan details is dumped to the users to sort out. The yaml file is not a great solution to handle all edge-cases. From this perspective I can see the need for #1046 but this will introduce even more complexity.

Describe the solution you'd like
That GitHub will make a larger effort to simplify licenses.

Describe alternatives you've considered
Giving up and stopping with this check altogether

Additional context
For the Maven projects the advanced-security/maven-dependency-submission-action is used.

[ahpook]

Hi @nicorikken thanks for the report - It seems like there are two pieces here, one about the list of expressions and one about license data accuracy.

For the first, I am surprised it is necessary to add these compound license strings to the allow list, because dependency-review-action will perform the boolean AND across the spdx expressions for you, so as long as each component of an expression is in the allow-licenses list once, the whole compound expression should pass. That should simplify the list and prevent needing to add the string for each package as a separate item.

Second, the source of the license data is ultimately from https://github.com/aboutcode-org/scancode-toolkit - could you try running scancode -l --license-diagnostics against the package locally and see what it says?

[nicorikken]

Ah, I was wondering about the AND. That does make sense. That wasn't clear to me. That puts things into perspective. Thanks. Perhaps I should have took more time to look into any changes on that part.

I'd have to see what licenses are missing. I know for sure that GPL-1.0-or-later is missing, because we normally would not allow it. We could also add LicenseRef-scancode-unknown-license-reference and LicenseRef-scancode-public-domain to solve some edge cases. So there will still be issues with packages misidentified through scancode-toolkit. The LicenseRef-scancode-other-copyleft doesn't seem actionable as it signifies an unknown risk. I'll add more licenses next working day and see what comes of it.