Remove licensing headers in go files #5597

Closed
opened 2025-11-02 06:30:20 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @silverwind on GitHub (Jun 20, 2020).

I think having these headers is an archaic practice that has no real benefit. We're not consistent with having that header in every file and the copyright year is never updated. I think it's sufficient to have the root LICENSE file only.

Originally created by @silverwind on GitHub (Jun 20, 2020). I think having these headers is an archaic practice that has no real benefit. We're not consistent with having that header in every file and the copyright year is never updated. I think it's sufficient to have the root `LICENSE` file only.
GiteaMirror added the issue/stale label 2025-11-02 06:30:20 -06:00
Author
Owner

@lunny commented on GitHub (Jun 20, 2020):

@silverwind, I don't think so. The copyright headers should be kept because some copyright from other projects. i.e. Gogs. And for new files from Gitea, it will be provided by other forked or referenced projects. They should keep the copyright headers in their files to follow the MIT license.

@lunny commented on GitHub (Jun 20, 2020): @silverwind, I don't think so. The copyright headers should be kept because some copyright from other projects. i.e. Gogs. And for new files from Gitea, it will be provided by other forked or referenced projects. They should keep the copyright headers in their files to follow the MIT license.
Author
Owner

@silverwind commented on GitHub (Jun 20, 2020):

some copyright from other projects

We already have a gogs copyright in the LICENSE, that ought to be enough?

And for new files from Gitea, it will be provided by other forked or referenced projects

Git blame/history already lets one already determine when/how a file was introduced and it gives much better information than those loosely maintained headers.

@silverwind commented on GitHub (Jun 20, 2020): > some copyright from other projects We already have a gogs copyright in the `LICENSE`, that ought to be enough? > And for new files from Gitea, it will be provided by other forked or referenced projects Git blame/history already lets one already determine when/how a file was introduced and it gives much better information than those loosely maintained headers.
Author
Owner

@codestation commented on GitHub (Jun 23, 2020):

We're not consistent with having that header in every file and the copyright year is never updated.

There is no reason to update the copyright year unless you have made a significant change to the code that requires a renewal. In my opinion, if a year update is needed then the year must be appended rather than replaced (to don't lose the starting year).

An quote from the FSF about this (related to GPL but it can apply to other licenses):

The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn't post it until 1999, use 1998). You should add the proper year for each past release; for example, “Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names.

For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage.

Note that the GPL licenses recommends to add the license header to every file, so this is probably where the practice comes from:

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.

IMO the copyright notices should be kept. If the files are used in other projects outside Gitea then it becomes easier to see where it comes from and the license of the file. In this case the git history wouldn't be present (isn't present either in the release source tarballs).

@codestation commented on GitHub (Jun 23, 2020): > We're not consistent with having that header in every file and the copyright year is never updated. There is no reason to update the copyright year unless you have made a significant change to the code that requires a renewal. In my opinion, if a year update is needed then the year must be appended rather than replaced (to don't lose the starting year). An quote from the [FSF](https://www.gnu.org/licenses/gpl-howto.en.html) about this (related to GPL but it can apply to other licenses): > The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn't post it until 1999, use 1998). You should add the proper year for each past release; for example, “Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names. > > For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage. Note that the GPL licenses recommends to add the license header [to every file](http://www.gnu.org/licenses/gpl-3.0.html), so this is probably where the practice comes from: > To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. IMO the copyright notices should be kept. If the files are used in other projects outside Gitea then it becomes easier to see where it comes from and the license of the file. In this case the git history wouldn't be present (isn't present either in the release source tarballs).
Author
Owner

@stale[bot] commented on GitHub (Aug 22, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Aug 22, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#5597