Replace ORT's simple license mapping with LicenseLynx

[sschuberth]

LicenseLynx is a relatively new project by Siemens that does exactly what ORT's simple license mapping does, but with way more mapping (8546 currently).

In order to outsource maintenance of license mappings (which ORT did not do well; the last mapping was added in 2022), and to avoid our discussion about ambiguous vs unambiguous mappings (also see https://github.com/oss-review-toolkit/ort/pull/8139, even if that deals with declared license mappings), I propose to fully switch to LicenseLynx instead. With Siemens being a big company that's probably very conservative about license mappings, I do not see a risk there. In any case, of course we should first ensure that ORT's current (unambigious) mapping are covered by LicenseLynx, and eventually contribute any missing mappings.

[tsteenbe]

I reviewed a lot of entries within LicenseLynx https://github.com/licenselynx/licenselynx/tree/main/data and although it looks like they have more entries than ORT they just imported ScanCode license DB for the most part. The license mappings in ORT have not been updated in my opinion since we have most of the common ones captured. Moving this to an external dependency like LicenseLynx will make it harder for ORT users to set up ORT with their own set of license mappings.

Prefer not to rely on single company for license mappings but on a community approach (under a neutral home).

[sschuberth]

Moving this to an external dependency like LicenseLynx will make it harder for ORT users to set up ORT with their own set of license mappings.

Why? How? ORT's license mappings are currently now configurable for end users.

Prefer not to rely on single company for license mappings but on a community approach (under a neutral home).

While LicenseLynx was initiated by Siemens, it's hosted under the independent / neutral licenselync organization (just like ORT was initiated by HERE Technologies).

[fviernau]

I believe it makes sense to keep a mapping data set under the ORT Umbrella so that the ORT community owns:

1. Quality gate
2. Decision to merge

This way we have one critical path for adressing issues which does not involve third party dependencies. In addition to our own data set, I believe having the possibility to make use of other data sets is I nice addition. The following way would be canditdates:

1. Import third party data on a regular basis, like we do with scan code license texts. (Pro: ORT quality gate, con: effort)
2. Add means for configuring additional data sources, similar to how clearly defined curations are integrated, e.g. as provider.