Added license export

[DerBene]

Description

Add licence attestation report functionality

Addressed Issue

closes #651

Additional Details

Added it, even though we are not 100% sure if thats the right place to put it. Unit tests and documentation are missing and will be added once it's clear where the changes should be in.

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have added corresponding update logic
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[nscuro]

Thanks for the PR @DerBene!

I am torn on the export format. I think the format should be CycloneDX, matching the other export variants. The complete license text can be included there as well, refer to https://cyclonedx.org/use-cases/#license-compliance

I don't believe DT should export to non-standard formats, especially when they're not machine-readable.

CC @stevespringett; I attached an example export: 7169d274-0cbe-4933-899d-5a6a47c2d729-license-attestation.txt

[nscuro]

@troy256 Licenses are already part of the "Inventory" BOM export. Are you encountering situations where this is not the case?

[andife]

Maybe, I don't fully understand it. What is an "Inventory" BOM export? My status of knowledge is the the "license text" is not included in the export (#2018)

[nscuro]

I fear I am not entirely clear what the requested feature is here. License data (except the entire license text, as pointed out by @andife) is already included in the inventory export. This PR does not add anything beyond that, but instead adds a new non-standard export format.

We can offer a separate download option that includes inventory and complete license texts, to address #2018. But from what I understand so far, #651 is already implemented via inventory export.

Removing from the 4.10 milestone because it needs clarification.

[MarkusGeigerDev]

I fear I am not entirely clear what the requested feature is here. License data (except the entire license text, as pointed out by @andife) is already included in the inventory export. This PR does not add anything beyond that, but instead adds a new non-standard export format.

I'm just thinking out loud here, but I guess this is referring to licence obligations like the one in the MIT licence, which states

Permission is hereby granted, [...], subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

It's quite some work to collect all the licences that require such an attestation and compile a human (not machine !) readable document that contains all the copyright notices and licence texts for all components that require such attestation - so I see the benefit of a licence report targeted towards human readers and not, like the BOM export, towards machines.

I agree, however, that this needs some more discussion since such a document should only include components that require an attestation as of their licence agreement and furthermore could include some kind of to-do-list of what's needed on top of that, like, for example, a source code bundle for everything under EPL, etc.
All of that would require a bunch of new properties on all of DT's known licences, like need_to_ship_copyright_notice, need_to_ship_licences_text, need_to_ship_source_code, etc.

[DerBene]

I don't quite know on how to proceed now. Both options (CycloneDX formatted export and the current implementation) are viable for us. What is the preferred way?

[stevespringett]

Lawyers typically like to have a large text file, pdf, or similar of all basic information such as the component name and version, full license text, and copyright statements. Some additionally like to have evidence of other licenses and copyrights found in a component but may not be directly applied to a component. CycloneDX supports this, but I do not believe DT can import that yet.

Having a human readable format is fine IMO. It satisfies a typical legal use case. @MarkusGeigerDev brings up a valid point however in that there should ideally be a way to include and optionally filter on the components that have licenses that have obligations. This additional capability is captured in ticket #371.

I see this as a good MVP, but there should be a plan on implementing #371 shortly thereafter.