Source Format Enforcement

[squidadm]

No description provided.

[squid-prbot]

Can one of the admins verify this patch?

[yadij]

OK to test

[rousskov]

I suggest removing the years from copyright statements instead of modifying 2000+ files every year. However, I will not block this PR on this ground.

As far as US (and, I bet, most other countries) copyright laws are concerned,

1. these years do not follow the required "first publication year" format of a formal copyright notice,
2. most years invalidate the formal notice by containing a year past the first publication year, and
3. the entire notice itself is not required for stuff created after 1989 A.D. In the 179 countries that signed the Berne Convention, creations are automatically copyrighted, with or without a valid notice.

[rousskov]

This change should not have been sneaked into the supposed-to-be-automated pull request.

[yadij]

I suggest removing the years from copyright statements instead of modifying 2000+ files every year. However, I will not block this PR on this ground.

As far as US (and, I bet, most other countries) copyright laws are concerned,

Squid is distributed and used in jurisdictions outside those areas covered by the Berne Convention. The understanding I gained during the copyright update project in 2014 is that to ensure best legal application we do need to explicitly use claim statements. Also that those statements use a syntax containing the historic copyright symbol, word and year indicators. Each has an explicit legal side effect in laws of countries outside the Berne Convention jurisdiction - as do omission and/or errors in those indicators.

1. these years do not follow the required "first publication year" format of a formal copyright notice,

The year value follows the format advised by FSF for range of years where GPL copyrights are claimed. Since we release files periodically they are important and mean that any code unique to eg Squid-3.5.1 expires into public domain N years after 2015. Versus code unique to Squid-4.1 expiring into public domain N years after 2020. Where N is the country-specific duration for validity of software copyright claims made by organizations.

2. most years _invalidate_ the formal notice by containing a year _past_ the first publication year, and

As discussed during the initial project planning circa 2013-2014;

• the statement being modified here is a "collective works" claim. It is claiming that our published files were written across all years between 1996 and current year.

• challenges or third-party violation legalities are left to the specific jurisdiction legal process to determine exact coverage of the lines relevant to the case.

• being a collection - subsections may exist under dual license. Any individual file may contain additional claims that dual-license that files content in whole or in part at the discretion of the originating author(s).

• being a collection - each file covered by the claim contains it. There are files in the tarball exempt from the GPL coverage. Those are not covered by this claim - either by their nature as non-source with omission of this line (eg icons), or by explicit use of only other copyright statements (eg translated texts).

3. the entire notice itself is [not required](https://copyright.uslegal.com/copyright-notice/omission-of-notice-or-error-in-notice/) for stuff created after 1989 A.D. In the 179 countries that signed the Berne Convention, creations are automatically copyrighted, with or without a valid notice.

No. The notice is designed and used explicitly to make our claim legally enforceable in maximum possible number of legal jurisdictions. As of this writing there are 20 countries and a number of non-country states and territories who are not Berne signatories.

[rousskov]

Squid is distributed and used in jurisdictions outside those areas covered by the Berne Convention.

That is a known fact, but you have not demonstrated its relevance. To become relevant, somebody will need to find a country or place where the removal of the year would make a serious negative impact. Ideally, somebody should also show that our handwaving about the year range and year values will not have a negative impact in the rest of those ~5-12 countries and territories that are not covered by Berne or TRIPS (the latter has the same provisions making explicit copyright notices obsolete as the Berne Convention).

The understanding I gained during the copyright update project in 2014 is that to ensure best legal application we do need to explicitly use claim statements.

To justify modifying 2000 files every year, I would like to see a lot more than a statement of understanding. I have substantiated my understanding (that those years are not helping) by references to specific laws and legal opinions. AFAICT, you pretty much have not, and some of your arguments have been invalid, further reducing my confidence in the correctness of unsubstantiated conclusions.

Alex: 1. these years do not follow the required "first publication year" format of a formal copyright notice,

Amos: The year value follows the format advised by FSF for range of years where GPL copyrights are claimed

First of all, those two statements do not contradict each other. Whether we are breaking the formal format by following FSF alleged recommendation or on our own volition is irrelevant here.

Second, we probably do not actually follow FSF suggestion because we do not satisfy its preconditions. See below for the FSF text quote.

Third, it is not a recommendation, but a permission AFAICT: FSF has recognized that listing all years has became impractical so they graciously let folks abbreviate. They do not recommend abbreviation; they just say it is "okay". This permission does not address other problems with (the literal interpretation of) their recommendations, but it is one problem that they could easily address. Their liberal attitude to the format of the formal copyright notice only underscores my argument that once we violate the legal format in one aspect, there is no point in trying to preserve some other aspects of that format regardless of the costs -- I bet FSF knows that the legal notice format is essentially irrelevant these days, and so they feel comfortable playing with it.

I will quote FSF text here to substantiate the above claims:

FSF: 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.

BTW, FSF is not an infallible entity -- some of their recommendations are bad for Squid -- but we can still follow their year-range suggestion in some single source file that summarizes Squid licensing policies. We do not need to modify 2000+ files every year to be in sync with that specific FSF suggestion.

Since we release files periodically they are important and mean that any code unique to eg Squid-3.5.1 expires into public domain N years after 2015. Versus code unique to Squid-4.1 expiring into public domain N years after 2020. Where N is the country-specific duration for validity of software copyright claims made by organizations.

True but irrelevant. The same would happen if we use a single/centralized notice with the range of years. Or no notice at all.

Alex: 2. most years invalidate the formal notice by containing a year past the first publication year, and

Amos: As discussed during the initial project planning circa 2013-2014; ...

All those facts are not related to my statement or its implications AFAICT:

• If we believe that the last year in the copyright notice in file X applies to that file X, then the fact I stated stands -- many of those notices are invalidated by our outomated "future dating" of files without fresh copyrightable modifications.
• If we believe that the year range in copyright notice in file X only applies to the whole collection of Squid files, then we are actually not specifying a year for each specific file and, hence, moving the range of years to a centralized location (referred to by the copyright statement in each file) is not going to harm any individual file (any more than it is already harmed by the essentially dateless statement now). In fact, such a move will only improve the clarity of our collection-scope claim!

Alex: 3. the entire notice itself is not required for stuff created after 1989 A.D. In the 179 countries that signed the Berne Convention, creations are automatically copyrighted, with or without a valid notice.

Amos: No. The notice is designed and used explicitly to make our claim legally enforceable in maximum possible number of legal jurisdictions. As of this writing there are 20 countries and a number of non-country states and territories who are not Berne signatories.

I have demonstrated that the notice is not required in all but ~5-12 places. You have not demonstrated that it is required in any single place! Just because there are places that have not signed the Berne Convention or joined TRIPS Agreement does not imply that our notice is required in those places (and certainly does not imply that removing the year range from that notice in individual files will harm Squid in those places!).

You could try to shift that burden of proof to me, but, IMO, the onus of proving the legal necessity of modifying 2000+ files every year is on the person insisting on that modification.

[yadij]

I have re-done this PR as two commits based on todays master branch. It drops the controversial change to scripts/source-maintenance.sh which is the key issue blocking merge (copyright discussions is a board@ policy issue).

• Commit 88a038a contains all code and format related changes.
• Commit df5cca8 should contain only the usual copyright line updates.

[rousskov]

Thank you for addressing my blocking concern. I did not review every changed file, but I trust that there are no manual changes in the current PR version.

I can only hope that we will remove the year range instead of modifying 2000+ files again next year.

My blocking change request was addressed.

[yadij]

Restored the PR diff to just the copyright and enforcement script changes. Not sure how the bunch of master commits got added.

[rousskov]

PR approval Pending — waiting for more votes

@yadij, I have not re-checked the PR changes, but please note that this PR has not been approved by any Core developer and, hence, Anubis bugs notwithstanding, will not be merged. If you are confident that the current PR changes are correct, then you may, of course, approve the PR to allow merging.

Somebody will also need to fix and/or retry Jenkins tests, as usual.