Update (c) in file headers and LICENSE

[dr-prodigy]

Proposed change

Hi guys!
As discussed, I provide this PR is to both update the code copyright to 2024, and to move authorship to the vacanza team (at last!).
For the sake of keeping the new code header as clean and tidy as it used to be, I chose to only add "vacanza team" as the new and current author, but also providing a direct link to the contributors page on github, so all your great work is still correctly attributed, and people can easily find you.
Open to any further suggestion / review, anyway.. KUTGW! 🥇

Type of change

• New country/market holidays support (thank you!)
• Supported country/market holidays update (calendar discrepancy fix, localization)
• Existing code/documentation/test/process quality improvement (best practice, cleanup, refactoring, optimization)
• Dependency update (version deprecation/upgrade)
• Bugfix (non-breaking change which fixes an issue)
• Breaking change (a code change causing existing functionality to break)
• New feature (new python-holidays functionality in general)

Checklist

• I've followed the contributing guidelines
• I've run make pre-commit, it didn't generate any changes
• I've run make test, all tests passed locally

[coveralls]

Pull Request Test Coverage Report for Build 8184095333

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 8181109558:	0.0%
Covered Lines:	10628
Relevant Lines:	10628

---

💛 - Coveralls

[arkid15r]

Hi @dr-prodigy, thanks for composing this!
I know it's once a year but still repetitive work involving a bunch of files.

I'm going to take some time to look into how other (big-ish) projects deal with balancing (c), license and contributor credits. Maybe we should create and populate some sort of AUTHORS file. Not sure how to backfill that file though.
Anyway, I'm going to look into options and get back to you with something.

In the meantime if anybody has ideas/suggestions -- don't be shy.

Thank you!

[arkid15r]

I looked into how Django (I guess the biggest Python project I've used) handles this.

Here is what we need to do for this scenario:

• remove each file headers (no need to update them every year) unless it's something non-standard
• we may still need to update LICENSE file depending on what's put there
• create AUTHORS or CREDITS file to keep track of all contributors (backfill the file with information from existing commits)

Any opinions on this?

[dr-prodigy]

I looked into how Django (I guess the biggest Python project I've used) handles this.

Here is what we need to do for this scenario:

• remove each file headers (no need to update them every year) unless it's something non-standard
• we may still need to update LICENSE file depending on what's put there
• create AUTHORS or CREDITS file to keep track of all contributors (backfill the file with information from existing commits)

Any opinions on this?

Hi @arkid15r !
I understand your point.. Though personally I still feel like it is beneficial to keep a complete header for each file to clearly identify their project and license attribution (not really about the single authors, but rather about our license model, ie: how this code can be used / re-used etc., according to the MIT model), even if spread / published separately.

Also, I feel like it is more "professional", anyway: source files without a header always look a bit.. shabby :-)

Definitely agreeing on a AUTHORS / CREDITS file to keep track of all the contributors, instead, if you feel comfortable to composing it now, and keeping it updated later (that is definitely a more expensive effort).

[arkid15r]

Hi @arkid15r ! I understand your point.. Though personally I still feel like it is beneficial to keep a complete header for each file to clearly identify their project and license attribution (not really about the single authors, but rather about our license model, ie: how this code can be used / re-used etc., according to the MIT model), even if spread / published separately.

Also, I feel like it is more "professional", anyway: source files without a header always look a bit.. shabby :-)

Definitely agreeing on a AUTHORS / CREDITS file to keep track of all the contributors, instead, if you feel comfortable to composing it now, and keeping it updated later (that is definitely a more expensive effort).

I'm not a lawyer and I've made my opinion based on the results I found online (see some of them listed below).
I see the suggested change beneficial due to couple of reasons:

• decrease the burden for maintainers
• keep the contribution authors sort of rewarded by putting their names into a special file
• make source files look cleaner and more professional (here my opinion is opposite of yours in terms of professionally looked files). I think that space would rather be suitable for listing the sources used for compiling the entity holidays list.

I believe the LICENSE file it the only one required to specify conditions for the code use, redistribution etc. As far as I know all PH files are under the same license.

Here is a quote from https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects

Copyright Notices – Community Best Practice

Most LF project communities do not require or recommend that every contributor include their copyright notice in contributed files. See below for more details on why not.

Instead, many LF project communities recommend using a more general statement in a form similar to the following (where XYZ is the project’s name):

    Copyright The XYZ Authors.
    Copyright The XYZ Contributors.
    Copyright Contributors to the XYZ project.

These statements are intended to communicate the following:

    the work is copyrighted;
    the contributors of the code licensed it, but retain ownership of their copyrights; and
    it was licensed for distribution as part of the named project.

By using a common format, the project avoids having to maintain lists of names of the authors or copyright holders, years or ranges of years, and variations on the (c) symbol. This aims to minimize the burden on developers and maintainers as well as redistributors of the code, particularly where compliance with the license requires that further distributions retain or reproduce copyright notices.

See Django Project license example.

Definitely agreeing on a AUTHORS / CREDITS file to keep track of all the contributors, instead, if you feel comfortable to composing it now, and keeping it updated later (that is definitely a more expensive effort).

I think this would be beneficial in order to attract more contributors. I believe this should be implemented as long as the process of keeping it up to date is automated and doesn't add additional burden to maintainers.

So the bottom line of my perspective on this:

• remove redundant file headers
• update LICENSE copyright to "Vacanza Team and individual contributors" instead
• create AUTHORS file (a separate PR) and CI/CD job to keep it up to date

Links:

• https://opensource.guide/legal/
• https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects
• https://ben.balter.com/2015/06/03/copyright-notices-for-websites-and-open-source-projects/
• https://opensource.com/article/20/10/copyright-notices-open-source-software

Again, it'd be great if other participants expressed their opinions on this.

[arkid15r]

A couple of updates:

• we've moved to the new branch names (dev, main) yesterday. I updated the PR's target to dev

• * create AUTHORS file (a separate PR) and CI/CD job to keep it up to date
  

  I've created an initial version of AUTHORS file and script to keep it up to date in Add AUTHORS file #1700 and Set up the update authors job #1701

[arkid15r]

The initial version of AUTHORS file has been added with #1700
We've decided all further changes will be done by contributors. I think we should update our contributions guide to reflect this.

[dr-prodigy]

Hi @arkid15r! Thank you for your explanation.
As I've explained directly per other channels, while I totally agree on the AUTHORS file addition (very fair towards all the present and past contributors of the library), and the change of copyright ownership towards vacanza team (which in fact I pushed here as first) I instead honestly don't agree on the removal of all existing headers, along with their current copyright information.
Easiest reasons are:

• compared to the whole library maintenance, their impact is absolutely negligible
• their removal, while requiring work, IMHO diminishes the software value rather than increasing it.

Moving to the reasons why those headers were included so far (since v.0.1, ie: even before I started working on the library):

• they allow any project source file to be clearly associated to python-holidays, even if taken apart
• it is very common among open source code and a huge number of projects do the same
• a number of open source licensing models (eg: GPL/LGPL) also explicitly require them, and our MIT license, while not enforcing, somehow suggests them, too

Another point: while I'm not a lawyer, just from a few searches I made on the internet, I can say with good certainty that existing copyright notices removal and / or tampering without permission is normally against the copyright laws.
This said, while I could even accept this change for what concerns "my part", this change should be accepted by the python-holidays former copyright owners too, prior to being applied.

Finally, I personally never had any legal nor commercial interest on this library, but as you may understand, I've always had and still have a quite strong paternity feeling towards it.
Not having time to develop the library as it deserves since quite a long time, I accepted to leave the whole project maintenance and direction in your hands @arkid15r and the Team, for the sake of it.. but I still would appreciate to be recognized for having maintained this whole project on my own for more than 5 years before you came.
Those headers are the largest part of that recognition (that goes not only for me, but for the former developers too, I guess), so I hope this is not perceived as unfair or pretentious.

I'm available for further discussion, thank you for your attention

[arkid15r]

Hey @dr-prodigy, thanks for the reply!

Hi @arkid15r! Thank you for your explanation. As I've explained directly per other channels, while I totally agree on the AUTHORS file addition (very fair towards all the present and past contributors of the library), and the change of copyright ownership towards vacanza team (which in fact I pushed here as first) I instead honestly don't agree on the removal of all existing headers, along with their current copyright information.

Right, as we figured out here and in Slack we have two strongly opposite opinions on this matter.

Easiest reasons are:

* compared to the whole library maintenance, their impact is absolutely negligible

My approach for such situations is simple -- I ask a question: "Is it necessary?"

* their removal, while requiring work, IMHO diminishes the software value rather than increasing it.

The PH value is in the precise holidays data it provides, not in the headers in my opinion.

Moving to the reasons why those headers were included so far (since v.0.1, ie: even before I started working on the library):

* they allow any project source file to be clearly associated to python-holidays, even if taken apart

* it is very common among open source code and a huge number of projects do the same

* a number of open source licensing models (eg: GPL/LGPL) also explicitly require them, and our MIT license, while not enforcing, somehow suggests them, too

Yeah, my reasons against can be found above.

Another point: while I'm not a lawyer, just from a few searches I made on the internet, I can say with good certainty that existing copyright notices removal and / or tampering without permission is normally against the copyright laws. This said, while I could even accept this change for what concerns "my part", this change should be accepted by the python-holidays former copyright owners too, prior to being applied.

You don't remove the copyright. Each contributor/author still holds their copyright. The LICENSE file is responsible for that.
The goal is to clean up the code and get rid of annual update for hundreds of files.

Finally, I personally never had any legal nor commercial interest on this library, but as you may understand, I've always had and still have a quite strong paternity feeling towards it. Not having time to develop the library as it deserves since quite a long time, I accepted to leave the whole project maintenance and direction in your hands @arkid15r and the Team, for the sake of it.. but I still would appreciate to be recognized for having maintained this whole project on my own for more than 5 years before you came. Those headers are the largest part of that recognition (that goes not only for me, but for the former developers too, I guess), so I hope this is not perceived as unfair or pretentious.

That's a real good one. I have nothing to argue against it. Let's keep the headers in order to have you recognized for your previous contributions to this project.
I respect your position and it's been a while this PR blocks us from starting PH v1 work.

Please find my questions regarding the PR contents below:

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[KJhellico]

LGTM!

[arkid15r]

Merging this in, thanks @dr-prodigy!