Fix and optimize license check workflow logic

[rauljzortega]

Fix logic in check_licenses.yml to prevent errors in merge/push events.

[ocaisa]

I'm looking at some of the results from the licenses check and wondering why the CI is not failing for them:

...
Underworld:
  2.16.4:
    License: not found
    Permission to redistribute: false
    Retrieved from: not found
aiohttp:
  3.9.5:
    License: not found
    Permission to redistribute: false
    Retrieved from: not found
debugpy:
  1.8.1:
    License: not found
    Permission to redistribute: false
    Retrieved from: https://aka.ms/microsoft/debugpy/blob/main/LICENSE
deprecation:
  2.1.0:
    License: not found
    Permission to redistribute: false
    Retrieved from: not found
ipywidgets:
  8.1.2:
    License: Other
    Permission to redistribute: false
    Retrieved from: https://jupyter.org/
jupyter-server:
  2.14.0:
    License: Other
    Permission to redistribute: false
    Retrieved from: https://jupyter.org/
...

all of these are clearly a problem, but the CI is not flagging them at all.

[ocaisa]

Ah, I see it generates a patch file...but perhaps it should actually fail when we do not have permission to redistribute and provide advice about what to do? The current CI will never fail, so no-one will pay attention to problems being introduced.

[ocaisa]

Also, ipywidgets is BSD 3-Clause which is the common licence for Jupyter, why is it picking up Other?

[hvelab]

Ah, I see it generates a patch file...but perhaps it should actually fail when we do not have permission to redistribute and provide advice about what to do? The current CI will never fail, so no-one will pay attention to problems being introduced.

This is the idea for when the results are more stable to not have now a failing CI all the time.

Also, ipywidgets is BSD 3-Clause which is the common licence for Jupyter, why is it picking up Other?

I suspect on the way to parse the packages, as it's not the same for a repository than for a package, and Underworld is a repository but all the dependencies are Python packages, so the way to go fetch the license can results in mistmatches like this. Good news though, while checking how to solve it I found out that ecosyste.ms released a new API for license fetching!: https://licenses.ecosyste.ms/docs/index.html

We will give it a try and update the pipeline, it could solve this particular issue