Update copyright and license headers to SPDX compliant format

[HeikeGilg]

I recognized, that currently different copyright/license headers are used. And some files don't have a copyright/license header. To easily validate copyright and license information, I want to uniform the headers to be compliant with the SPDX specification. For automatic validation of the copyrights and licenses, I want to use REUSE. A tool which makes the information machine-readable and automatically validates the copyright /license headers of all files.

REUSE can be installed and executed via:

python3 -m pip install reuse # Install reuse
reuse lint # Validate copyright and license information

Some files that can't easily have a header, for example auto generated files, or certificate files, REUSE.toml is used.

I structured the commits as follows:

• Update headers:
  • Update single licensed headers to SPDX format -> easy to review
  • Update mixed licensed headers to SPDX format -> Feedback welcome: These files are originally from other projects and originally not licensed under BSD-3-Clause (Apache 2.0...). I only used the original licenses in the header and did not add the BSD-3-Clause. How do you want to have that?
• Add headers (which don't have a header yet) -> Feedback welcome: Is the BSD-3-Clause the license you want to use or alternatively the Creative Commons license (CC0 1.0)?:
  • Add SPDX compliant headers to CMakeLists.txt files
  • Add SPDX compliant headers to various files
• Add license files for all occurring licenses (into LICENSES directory) -> easy to review
• Add support for REUSE -> If you want, I can add REUSE to the CI in a subsequent pull request.
• Update check_copyright_date for SPDX format header -> line with current year changed from line 3 to line 2

[steven-bellock]

The format for source files was inherited from older DMTF open source projects, such as https://github.com/DMTF/Redfish-Interop-Validator/blob/396543b57961d6baa898afb54fd39aa0ddc1cb92/redfish_interop_validator/interop.py#L1-L4. The current document that covers this does not specify the license format in source files, so in theory this is OK. However this should be brought to the larger SPDM Working Group / DMTF technical committee. @HeikeGilg are you with a DMTF member company? If not then I can bring it to the wider audience.

[HeikeGilg]

Hi @steven-bellock, I am not with a DMTF member company. I would appreciate it, if you bring it to to the wider audience. If I can support regarding this topic, let me know.

[steven-bellock]

This was discussed at the SPDM Working Group today. @HeikeGilg is it OK if both DMTF and SPDX license text is at the top of the file, or do you want to see the DMTF text replaced by SPDX?

[HeikeGilg]

Thanks @steven-bellock for discussing that topic.

Using both license/copyright text formats (DMTF and SPDX) would mean redundant information and doubled maintenance effort. By only using SPDX license/copyright text format, the information would be unequivocal.

If both license text formats would be the only way to get SPDX license/copyright format, I would prefer that than having no SPDX license/copyright text.

But I would strongly recommend to use only the SPDX license/copyright text.

[HeikeGilg]

Hi @steven-bellock, are there any news on this topic here?

[steven-bellock]

Yes, the new template specifies both texts, with the SPDX first. So it would look like

/**
 * SPDX-FileCopyrightText: 2021-2024 DMTF
 * SPDX-License-Identifier: BSD-3-Clause
 * 
 * Copyright Notice:
 * Copyright 2021-2024 DMTF. All rights reserved.
 * License: BSD 3-Clause License. For full text see link: https://github.com/DMTF/libspdm/blob/main/LICENSE.md
 **/

If you'd like to continue I suggest

1. Close this pull request.
2. Make a new pull request that only targets files in libspdm/library and libspdm/include since that's straightforward to review.
3. File an issue to discuss the other files, including scripts and other licenses.

[HeikeGilg]

In my humble opinion, including the same licensing information in two different formats would be a change for the worse for the reasons I outlined above. Additionally, specifying the license for only a subset of files does not really ensure license completeness, either. If we are still unclear about the license of some files, we should clarify that first.

Unfortunately, I cannot contribute to any discussion regarding the license of utility files (some of which might not even reach the threshold of originality). This is the call of the maintainers. I opened issue #2845 to track this issue. Once this is clarified I'm open to work on the implementation of it. Feel free to close this PR it it does not align with the decision made by the maintainers.