Include the list of all used licenses and dependencies

[AsamDiegoSanchez]

Describe the bug
The release of the v1.0.0 has been approved by the TSC but conditioned include all the licenses and dependencies used.

i.e the Python packages are missing

Expected behavior
Include all the necessary information in the appendix:
https://github.com/asam-ev/qc-framework/blob/main/licenses/readme.md

[ClemensLinnhoff]

I was wondering about the 3rd party licenses in the checker bundles. I am mainly asking for the future implementation of an OpenMATERIAL 3D checker bundle.
Naming the dependencies of course is important.
But what is the reasoning behind including all 3rd party licenses? I would understand, if the 3rd party packages would be shipped with the source code. But they are not, if I am not mistaken. They are separately installed by the user.
@AsamDiegoSanchez could you explain the reasoning from the TCP behind this?

[MatteoRagni]

First of all IANAL, reader discrection is advised...

There is no general rule about including and listing third party licenses for dependencies. The only license we are strictly bound to redistribute is the Xerces one (since there is C++ code generated by Xerces, which is licensed).

I'm not speaking directly for TSC, but since this is a project where the main audience are companies, keeping a list of required dependencies allows an easy evaluation of risk in using this codebase.

As a general discussion, even if a developer is not explicitly required to include licenses for required packages (I'm referring mainly at the python package), doing so does no harm.

[AsamDiegoSanchez]

Exactly what Matteo said, we wanted to be as transparent as possible, and one request was listing all licenses used. Since this was a no high-effort request and provided further valuable information we followed the request.

[ClemensLinnhoff]

One problem I see is that this is somewhat misleading, because it does not list the dependencies of the dependencies and their licenses. It is therefore incomplete and the "easy evaluation of risk" is simply wrong.
Another problem is, that as far as I see, the versions of these packages are not pinned. So if the license of a package changes in a newer version, the license information in this repository will be wrong.

[MatteoRagni]

I need to correct something I said in this comment. I was just informed that there is currently no Xerces generated code in the repository. I mistakenly considered some files as automatically generated while they are not.

Sorry

---

One problem I see is that this is somewhat misleading, because it does not list the dependencies of the dependencies and their licenses. It is therefore incomplete and the "easy evaluation of risk" is simply wrong.

Yeah more than easy, initial.

However, I expect to introduce more formal SBOM systems (also to track CVE in dependencies).