Source Format Enforcement

[squidadm]

No description provided.

[rousskov]

Maintaining copyright does not require annual modification of ~2000 files. If this PR was a result of some automation, please adjust/disable it.

[yadij]

Maintaining copyright does not require annual modification of ~2000 files. If this PR was a result of some automation, please adjust/disable it.

The above statement is factually wrong.

• This blurb is the code-wide blurb for Squid. Indicating the copyright period and conditions of the complete published work called "squid".
• New code implementation has been added (i.e. "published") to Squid in the year 2025.
• New code was submitted by new authors not covered by previous copyrights assignment.

For all the above reasons (and possibly more) the correct copyright statement must indicate 2025 as a publication date for "squid" code. Without that change, new contributions are unfairly awarded at least one year less copyright protection for their works than previous contributors.

As I have already mentioned several times, the copyright period these dates indicate the beginning of varies around the world. We do not all enjoy the lifetime + 70 years protection that you have in the USA.

[rousskov]

Maintaining copyright does not require annual modification of ~2000 files.

The above statement is factually wrong.

• This blurb is the code-wide blurb for Squid. Indicating the copyright period and conditions of the complete published work called "squid".
• New code implementation has been added (i.e. "published") to Squid in the year 2025.
• New code was submitted by new authors not covered by previous copyrights assignment.

None of the above bullet points contradict my statement AFAICT.

For all the above reasons (and possibly more) the correct copyright statement must indicate 2025 as a publication date for "squid" code. Without that change, new contributions are unfairly awarded at least one year less copyright protection for their works than previous contributors. ... the copyright period these dates indicate the beginning of varies around the world.

I doubt these assertions are correct. My validity concerns have not been addressed when this was discussed during the previous iteration.

FWIW, I am (still) not against removing dates from boilerplate and/or updating a single file with new dates.

[kinkie]

For all the above reasons (and possibly more) the correct copyright statement must indicate 2025 as a publication date for "squid" code. Without that change, new contributions are unfairly awarded at least one year less copyright protection for their works than previous contributors. ... the copyright period these dates indicate the beginning of varies around the world.

I doubt these assertions are correct. My validity concerns have not been addressed when this was discussed during the previous iteration.

FWIW, I am (still) not against removing dates from boilerplate and/or updating a single file with new dates.

I am with Amos on this one, and I'm far from alone. In fact, the FSF recommends to do that in all GPL-licensed software.

In fact, given that our software is technically released continuously through github, we are breaking recommendations already.

So, my vote goes for updating the copyright blurb across all versions we release. As a second best option, I vote for mandatorily updating the copyright date every time a file is touched during development.

[rousskov]

For all the above reasons (and possibly more) the correct copyright statement must indicate 2025 as a publication date for "squid" code. Without that change, new contributions are unfairly awarded at least one year less copyright protection for their works than previous contributors. ... the copyright period these dates indicate the beginning of varies around the world.

I doubt these assertions are correct. My validity concerns have not been addressed when this was discussed during the previous iteration.
FWIW, I am (still) not against removing dates from boilerplate and/or updating a single file with new dates.

I am with Amos on this one, and I'm far from alone. In fact, the FSF recommends to do that in all GPL-licensed software.

Please note that those FSF recommendations do not contradict anything I have said. I bet we would have been a lot more productive if we were able to hear and base our decisions on a shared set of facts and carefully evaluated arguments.

N.B. Many well-known projects do not update or have recently removed the dates from individual file boilerplates. We should not make decisions by counting fresh prominent examples and recommendations, but if we were to do that, I bet the options I support would win in a fair count!

In fact, given that our software is technically released continuously through github, we are breaking recommendations already.

Technically, the world has moved on from maintaining individual "files" to VCS repositories long time ago, so parts of those old, unsubstantiated, one-size-fits-all FSF instructions become rather meaningless and wasteful if applied literally, but we do follow the essence of those recommendations well! The only deviation being discussed here is really minor (and has no effect on copyright). Our official git repository contains all the necessary information that does (unlike boilerplate!) affect copyright, including copyright expiration.

So, my vote goes for updating the copyright blurb across all versions we release. As a second best option, I vote for mandatorily updating the copyright date every time a file is touched during development.

Here is a rough summary of options being discussed so far:

1. Change the boilerplate date in all source files every year. Many (most?) dates become a lie. Long-term overheads for some developers.
2. Change the boilerplate date in modified source files every year. Fewer dates become a lie. Effectively the same overheads.
3. Change the boilerplate date whenever PR modifies a file (in a new year). Even fewer dates become a lie. Serious UX problems, especially for new/outside contributors. Similar long-term overheads for some developers plus significant additional overheads during every PR review.
4. Keep the last boilerplate date. Some dates become stale. No overheads.
5. Replace the date in individual file boilerplate with a 1996-present range. Less common? No overheads.
6. Remove the date from individual file boilerplate. No overheads.

The above summary ignores a bit of one-time development work that all items except item 1 imply. I am willing to cover that work for items 5 and 6.

None of the above options affect copyright (including copyright expiration).

I recommend option 6 and would be content with option 5 (for the reasons detailed earlier and summarized above).

[yadij]

So, my vote goes for updating the copyright blurb across all versions we release. As a second best option, I vote for mandatorily updating the copyright date every time a file is touched during development.

FTR; This is where the The Squid Software Foundation board of directors decision matters - to make Squid GPL copyrighted as a collection rather than keep a file-by-file copyright. Maintaining per-file copyright records imposes a large amount of additional documentation and management work - we chose to instead use the simpler collection method which can be automated (and has by the CI generating this PR).

I stand by that original board choice still being correct.

[rousskov]

So, my vote goes for updating the copyright blurb across all versions we release. As a second best option, I vote for mandatorily updating the copyright date every time a file is touched during development.

This is where the The Squid Software Foundation board of directors decision matters - to make Squid GPL copyrighted as a collection rather than keep a file-by-file copyright.

There was no such decision: The decision we actually made was about Squid Software Foundation copyright on the collection of individually copyrighted works. Foundation copyright (on the collection) does not replace or invalidate individual copyrights (on various parts of that collection). The term "file" is pretty much irrelevant to that decision and those concepts.

Maintaining per-file copyright records imposes a large amount of additional documentation and management work

I disagree. Git and GitHub pretty much do that for us.

I stand by that original board choice still being correct.

Yes, I also think it was the right call.

[yadij]

So, my vote goes for updating the copyright blurb across all versions we release. As a second best option, I vote for mandatorily updating the copyright date every time a file is touched during development.

This is where the The Squid Software Foundation board of directors decision matters - to make Squid GPL copyrighted as a collection rather than keep a file-by-file copyright.

There was no such decision: The decision we actually made was about Squid Software Foundation copyright on the collection of individually copyrighted works.

That is what I wrote. The decision to be a collection.

Our choice was between https://github.com/squid-cache/squid/blob/master/scripts/boilerplate.h on every file (maintained by the script creating this PR), vs every file in Squid being marked up like https://github.com/squid-cache/squid/blob/master/acinclude/ax_cxx_compile_stdcxx.m4#L35. Notice how neither alternative permits github to be managing the list.

Foundation copyright (on the collection) does not replace or invalidate individual copyrights (on various parts of that collection). The term "file" is pretty much irrelevant to that decision and those concepts.

Indeed. Though please be aware that "pretty much" is not a legally sound position when managing other peoples property.

A bit of history for those possibly blinded by that gaslighting:

• May 2012: The Squid Software Foundation board, being in the later stages of taking on Squid software management, discussed and decided to begin publishing the Squid code under a GPLv2+ license. http://www.squid-cache.org/Foundation/archive/2012/2012-05-17_board-meeting-3.html
• June 2012 - October 2013: Squid core mailing list discussed specifics of how to transfer all existing Squid code from existing copyrights into the Foundation collection.
  • most code was already GPLv2+, and random contributions had for some years been provided under GPLv2+
  • copyright holders of code under GPLv2-only were contacted explicitly and asked for permission to re-license. All accepted the request.
  • the CONTRIBUTORS file was dedicated as our legally binding list of all contributing copyright holders for the Squid software (since separation from Harvest, first public code under the "squid" name). Historic records were searched to extend and fill in the list as much as possible.
  • the CREDITS file was dedicated as our legally binding list of all license conditions applicable to the Squid code. With specific scope of rights delegations documented.
  • b1427da
• July 2017: @rousskov begins prohibiting code authored under non-GPL license being added to Squid.

• RFC 6750 OAuth 2.0 Authorization Framework: Bearer Token Usage #30 (comment)

• January 2020: @rouskov begins attempts to erase The Squid Software Foundation rights on Squid.
  • Source Format Enforcement #532 (review)
  • we have been cycling through this same discussion re-explaining how copyright laws require the copyright statement existence and correct text since then.

There are many other related decisions to this pattern, but I will not go into them here and now.

Maintaining per-file copyright records imposes a large amount of additional documentation and management work

I disagree. Git and GitHub pretty much do that for us.

1. they really do not.
2. "pretty much" legal is not good enough.

The information on license and rights holders legally MUST be available without the use of a tools like git, in the "downloaded" form of Squid sources - such as github generated tarballs and zip files. Without having to run ./bootstrap.sh, or ./scripts/source-maintenance.sh (i.e. with copyright update option enabled) or any other script.

This PR updates the collection copyright statement to document that changes have occurred to the Squid code in the years 2024 and 2025.

• Yes, it does have to state all these years.
• Yes, it does have to exist and be constantly updated on every file in the collection.
• No, we cannot remove it.

[yadij]

@rousskov, if you want to upskill yourself https://tind.wipo.int/record/47985?v=pdf page 73 advises our current way of managing the collective copyrights of Squid contributors as a viable solution to many issues seen with copyright over a collection of work with various authors.

[yadij]

I just went through and checked the latest list of Berne Convention countries. Those are the ones where copyright law is what you might call "reasonable" and is assumed and followed even when one is absent entirely from a file.

Several of our worst "problem" countries have signed up the Berne Convention since the 2013 analysis of the situation. However squid code has had contributions from at least Iraq and Taiwan[1] that I am personally aware of. Those are still problems, so I have not at this time delved into the code archaeology for additional issues.

[1] regardless of the political stance: "Taiwan as a country" is not a Berne signatory, "Taiwan as region of China" is not a Berne signatory. Only Mainland, Hong-Kong and Macao special regions are Berne signatories under the "China" hat AFAICT.

[rousskov]

At this time, I choose not to comment on personal attacks and FUD in #2042 (comment).

https://tind.wipo.int/record/47985?v=pdf page 73 advises our current way of managing the collective copyrights of Squid contributors as a viable solution to many issues seen with copyright over a collection of work with various authors.

I do not see any relevant information on page 73 of the document rendered on the above page. Perhaps more importantly, the current disagreement is not about viability of updating years in ~2000 files.

This PR updates the collection copyright statement to document that changes have occurred to the Squid code in the years 2024 and 2025.

• Yes, it does have to state all these years.
• Yes, it does have to exist and be constantly updated on every file in the collection.
• No, we cannot remove it.

AFAICT, the assertion that every source file has to state (all) years has not been proven; nothing in the previous comments proves (or even attempts to prove) that assertion.

Assertions about the need for copyright/licensing statements in every source file are irrelevant here because nobody is suggesting to remove those statements from source files.

[yadij]

At this time, I choose not to comment on personal attacks and FUD in #2042 (comment).

Sigh. I went to all the trouble of providing references showing your own words and still get called FUD.

https://tind.wipo.int/record/47985?v=pdf page 73 advises our current way of managing the collective copyrights of Squid contributors as a viable solution to many issues seen with copyright over a collection of work with various authors.

I do not see any relevant information on page 73 of the document rendered on the above page. Perhaps more importantly, the current disagreement is not about viability of updating years in ~2000 files.

Let me quote then. This regarding the problem of an publisher (The Squid Software Foundation) distributing a collection of texts (the Squid code) whose copyrights belong to others (the Contributors):

 Combining copyright licenses with content can be a viable solution, based
 on cooperation between RROs and publishers. Such services have been
 developed for both the educational sector and the corporate market.

This PR updates the collection copyright statement to document that changes have occurred to the Squid code in the years 2024 and 2025.

• Yes, it does have to state all these years.
• Yes, it does have to exist and be constantly updated on every file in the collection.
• No, we cannot remove it.

AFAICT, the assertion that every source file has to state (all) years has not been proven; nothing in the previous comments proves (or even attempts to prove) that assertion.

"not been proven" is disingenuous. You have rejected the written statements from FSF legal advisors that the years are required and in what format. You should know the only way to definitively (dis)prove those lawyers advice is to go to court and have a judge rule on it - in every country of this world.

Assertions about the need for copyright/licensing statements in every source file are irrelevant here because nobody is suggesting to remove those statements from source files.

Er, "we should remove this copyright line (or at least the copyright year) from the source files." - Alex Rousskov, Jan 3, 2020. yeah, nobody.

Need I remind you. The copyright statement in question is for the entire code base. Which has new additions yearly. So the collection copyright changes with those additions. The very definition of what is covered by this copyright is the files containing it (exactly them and no others). Ergo this and similar PR updates.

Sure, you don't like it. Fine. I/we hear you. Time to move on.

No legal grounds for extraditional change.

[yadij]

I have removed Alex's block because this is an automated update maintaining status-quo practice. The practice was started on advice from legal authorities. It is up to Alex to demonstrate that the change of that practice is legally valid, not me/us to prove his opinion wrong.

Clearing for merge since this has passed the 10-days criteria (sans the arguments).

[rousskov]

Amos: I have removed Alex's block because ...

@yadij, you have no right to remove my negative vote (regardless of what flaws you see in my arguments). You have violated a fundamental rule that Squid Project heavily relies upon.

Amos: Clearing for merge since this has passed the 10-days criteria (sans the arguments).

GitHub: yadij dismissed rousskov’s stale review at 3:48 am

GitHub: yadi removed the request for review from rousskov at 6:59 am

... and you did not even give me a chance to respond to that removal (all three of the above events occurred when I would be extremely unlikely to immediately notice them in my time zone).