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

Standardize Copyright/License Headers #2845

Open
HeikeGilg opened this issue Sep 20, 2024 · 2 comments
Open

Standardize Copyright/License Headers #2845

HeikeGilg opened this issue Sep 20, 2024 · 2 comments

Comments

@HeikeGilg
Copy link

Problem
• Inconsistent Headers: Different copyright/license headers are currently used across the repository.
• Missing Headers: Some files do not contain any copyright/license headers.

Proposal for Improvement
I propose the following solutions to address these issues:

  1. Adopting the SPDX Header Format
    SPDX provides a standardized format for copyright and license headers. This format is widely recognized and makes it easier to understand, automate, and analyze the licensing information in the code.
  2. Utilizing the REUSE Tool
    The REUSE tool helps make copyright and license headers machine-readable. It also offers automatic validation to ensure that all files have appropriate and consistent headers.

Why Uniform Headers Are Necessary
• Maintainability: Using a single format simplifies the maintenance of the repository. It avoids the confusion and potential errors that can arise from having multiple header formats.
• Consistency: A uniform approach ensures that all files are treated equally, avoiding the complexity and potential issues of having different rules for different parts of the codebase.
• Accuracy: Having one consistent source of information minimizes the risk of discrepancies and errors in the copyright/license information.

Current Discussion State
The current discussion revolves around maintaining the existing copyright/license headers and adding new SPDX headers in addition. However, this approach is only proposed for a subset of files, with no clear plan for the remaining files in the repository. This partial solution risks increasing complexity and inconsistency, making the codebase harder to maintain and potentially leading to errors.

My Request
I recommend adopting a uniform approach to the copyright/license headers across the entire repository. Also I strongly recommend using SPDX header format.
This is a call of the maintainers to first clarify a strategy for all files in the repository before implementing a partial change.

Thank you for considering this proposal.

@steven-bellock
Copy link
Contributor

Inconsistent Headers: Different copyright/license headers are currently used across the repository.

@HeikeGilg can you give an example of this?

Missing Headers: Some files do not contain any copyright/license headers.

Adding copyright/license to scripts, configuration files, and build files is fine. I see Reuse advises that

The reason that these files must be licensed is because reasonable minds can differ about the threshold of originality. You may consider a file so insignificant that it does not merit licensing information, but downstream may disagree and believe that the file in question falls under copyright, effectively disallowing them from using it if there is no license.

Utilizing the REUSE Tool

REUSE would be added to CI/CD?

@HeikeGilg
Copy link
Author

The inconsistent headers occur in files, which are originally from other projects, like here: https://github.com/DMTF/libspdm/blob/main/os_stub/armbuild_lib/div64.c or here: https://github.com/DMTF/libspdm/blob/main/os_stub/mbedtlslib/include/mbedtls/libspdm_mbedtls_config.h
For the original headers SPDX is used and for the DMTF headers, the DMTF format is used.

It would be a possibility to add REUSE in the CI/CD to automatically verify the headers and that all occurring license files are added in the repository. This is up to you maintainers, if you want to use it in the CI or just provide the possibility to use REUSE manually.
I personally like using it in my CIs, because the automatic validation and reporting ensures consistency.

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

No branches or pull requests

2 participants