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

Add an example for updating copyright and license header #934

Conversation

MikeOpenHWGroup
Copy link
Member

As per discussion in pull-request #931.

MikeOpenHWGroup and others added 29 commits June 26, 2023 09:33
[Skip CI] Version 2 RTD configuration file
Explicit build.os is now required by RTD.
@davideschiavone davideschiavone merged commit 48021ae into openhwgroup:dev Jan 8, 2024
3 of 5 checks passed
Copy link

@pascalgouedo pascalgouedo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending of the files, this is creating a sandwich of different layers which makes it awful to see !!!

All files have the same SHL license. If for each file we keep all previous information but restructured in a common way, I think this should not be a pb.

Some of them have Silabs, some of them ETH, others Bologna only.
I would propose ETH, Bologna, Silabs, Dolphin Design and OpenHW for all RTL files.
Plus keeping already listed contributors file per file.

@MikeOpenHWGroup
Copy link
Member Author

Depending of the files, this is creating a sandwich of different layers which makes it awful to see !!!

Yes, I agree. I have seen some truly ugly open-source license headers! This is why I suggest adding only two lines, one for the copyright and a second for the SPDX license. That adds only two lines per contributor, and if the license does not change then only one line.

@pascalgouedo
Copy link

Doesn't really answer to the original point of cleaning up...
But if we don't/can't change original header I will add our own layer as Arjan did ...

@MikeOpenHWGroup MikeOpenHWGroup deleted the MikeOpenHWGroup-how-to-update-license branch January 8, 2024 17:30
@MikeOpenHWGroup
Copy link
Member Author

Doesn't really answer to the original point of cleaning up...

I presume you mean this point:

None of the RTL files have OpenHW group license, only BHV ones have it.

Agree and understood. If we agree on the the method for updating copyright and license headers, the next step is to update all the RTL. I leave this to you, @davideschiavone and maybe @Silabs-ArjanB.

@pascalgouedo
Copy link

pascalgouedo commented Jan 8, 2024

I will propose what I have in mind through a specific PR for all RTL files.
I'll put @davideschiavone, @Silabs-ArjanB and yourself as reviewers.

@DBees
Copy link

DBees commented Jan 10, 2024

@MikeOpenHWGroup @pascalgouedo @davideschiavone the difficulty I have is that it is very hard to see who is contributing what with multiple authors presented in the same header. In other words, member A contributes something under License 1. Member B then contributes something additional under License 2. Not sure, but I think they should have separate headers with a description of what has been added. Otherwise it is impossible to see who is asserting what rights and granting what licenses to copyrights and patents. Let me check with Eclipse guys.

@MikeOpenHWGroup
Copy link
Member Author

Not sure, but I think they should have separate headers with a description of what has been added.

My proposal already adds a legal and complete license header (that this the comment line starting with SPDX). The description of what has been added is taken care of by the git/GitHub revision history and record of pull-request. No need to repeat that in a comment header.

@pascalgouedo
Copy link

I think that from a license point of view, files should be self-sufficient without relying on any file management history.
I have seen somewhere that for every file modification there should have some description additionally to your new copyright/contributors lines.
For sure not too detailed but maybe only related v1 and v2 differences in this present case?
I agree that differences between RI5CY and v1 would be missing.

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.

4 participants