Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update copyright and license headers to SPDX compliant format #2790

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

HeikeGilg
Copy link

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

- Update copyright information to be compliant to SPDX
- Update to current year
- Update BSD license headers to be compliant to SPDX

Signed-off-by: Gilg Heike <[email protected]>
- Update license and copyright headers to SPDX which were originally
  licensed under Apache-2.0, Apache-2.0 with llvm-exception or
GPL-2.0-or-later
- Remove additionally added BSD-3-Clause license identifier

Signed-off-by: Gilg Heike <[email protected]>
- Put all CMakeLists.txt file under BSD-3-Clause license
- Add copyright date from 2021-2024 for all CMakeLists.txt files

Signed-off-by: Gilg Heike <[email protected]>
- scripts
- workflow files
- git files
- version files
- config files

Signed-off-by: Gilg Heike <[email protected]>
- REUSE can be used to verify license/copyright headers
- REUSE makes licenses/copyrights machine-radable
- Install REUSE via:
```bash
python3 -m pip install reuse # Install reuse
reuse lint # Validate copyright and license information
```
- With REUSE.toml files that cannot easily get a license/copyright headers (e.g. auto generated files) get also the license/copyright information for REUSE
- More information about REUSE: https://reuse.software/

Signed-off-by: Gilg Heike <[email protected]>
- Copyright date is now in the second line of each file

Signed-off-by: Gilg Heike <[email protected]>
@steven-bellock
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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

@steven-bellock
Copy link
Contributor

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants