-
Notifications
You must be signed in to change notification settings - Fork 75
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
Apply CNCF aligned copyright statement to all the files #79
Comments
@bpradipt is this issue still relevant or can be closed? |
add copyright for all files?
|
@bpradipt Is this something we want to enforce? Has there already been a discussion on how existing copyright statements should be handled? If this is still relevant, feel free to assign me. |
@katexochen this issue is still relevant. We are ensuring to add the following copyright statement when adding new code or modifying existing code
|
@katexochen I assigned the issue to you. |
Just to be clear @bpradipt, that means if a file now has the following copyright header: // (C) Copyright Foo Corp. 2022.
// SPDX-License-Identifier: Apache-2.0 Should it in future look like this: // (C) Copyright The Confidential Containers Contributors.
// (C) Copyright Foo Corp. 2022.
// SPDX-License-Identifier: Apache-2.0 or like this: // (C) Copyright The Confidential Containers Contributors.
// SPDX-License-Identifier: Apache-2.0 We would need explicit permissions to remove existing copy right statements. |
Hey Paul, we've had this discussion on a PR in the past and I don't think it is as straight forward. I know that IBM legal have insisted that we use the IBM Copyright on our contributions to open source and this seems to be a common pattern in kata-containers: e.g. https://github.com/kata-containers/kata-containers/blob/CCv0/src/agent/src/image_rpc.rs So is compatibly with the CNCF copyright rules: https://github.com/cncf/foundation/blob/main/copyright-notices.md#what-if-i-want-my-copyright-notice-included
I don't really want to open the can of worms over all of the times that we've not been consistent in using/updating IBM copyright though 😨. I can try and open a discussion with IBM Legal, but that might take a while to resolve I know it's not the same issue, but in my experience copyright isn't mandatory on files, but license files are https://github.com/cncf/foundation/blob/main/license-notices.md, so that is where kata-containers have chosen to focus their automation (https://github.com/kata-containers/tests/blob/9439ae1c9167ffd49bca6ad2dd3b5edf0841b4f4/.ci/static-checks.sh#L389) My opinion is that whilst we aren't in a consistent state with copyrights, they aren't required IIRC, and I don't think we should be applying copyright rules in cloud-api-adaptor in isolation of the rest of the CoCo org, so I think this is a TSC question of whether they have any project wide guidance. |
Thanks for your reply @stevenhorsman. I know that this isn't any easy topic (that's why I'm asking 😆). I think the situation is pretty clear here. As I understand it, the spdx identifier is required, and CNCF grants contributors the right to include their own copyright. So the only open question would be if we should/can add a line As other contributors are granted the same rights to add their copyright when editing files of a project, adding additional copyright shouldn't be a problem.
But it would for sure be good to get that confirmed from TSC. |
Tbh, we need to refer to existing CNCF projects for guidance and relying on any project external to CNCF may not be the best thing to do. Anyways I'll try to bring this as a topic in TSC meet and get back. |
I think we are already generally in compliance with CNCF guidelines for copyright notices. We can discuss further with TSC. |
So I think this was discussed in the TSC meeting, but I'm not sure what the exact result was regarding this specific issue? Aren't we adding a workflow at all? Should we implement my suggestion from #79 (comment)? |
@katexochen yes, we discussed this in TSC and documented it in the status doc. Reproducing the statement here
So the recommendation is to use the above copyright statement. We can collectively decide in the peer-pods community meeting whether to apply to only new files, or also include files where copyright is missing. And if at all we need to remove an existing copyright with approval or add to existing copyright |
I thought a bit about this lately, and I think I found a great solution to implement it reliably and so that all requirements can be met: We already use the
By using this fields, the header can be easily parsed by software. We can easily check and sort the header, and people can still add their copyright or contributor name to files in an organized manner. |
Based on the CNCF guideline we can use something like below:
The text was updated successfully, but these errors were encountered: