[groff] 06/30: FOR-RELEASE: Update copyright notice mgmt steps.

[G. Branden Robinson]

gbranden pushed a commit to branch master
in repository groff.

commit d48272b6c5bf1f9ac78982dcebfca7b0f0a7c0d3
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
AuthorDate: Tue Mar 26 20:59:50 2024 -0500

    FOR-RELEASE: Update copyright notice mgmt steps.
    
    * Specifically state how the copyright notice reported by groff(1)
      should be updated.
    * Drop instruction to run update-copyright.sh.  I disagree with its
      premises, and Bertrand didn't do it for the 1.23.0 release.  (We
      didn't discuss it.)
    
    In my opinion, somewhat informed from several years of working
    professionally in software licensing compliance (almost exclusively on
    copyright issues):
    
    1.  A _file_'s copyright notice should be updated only in a year when
        original work that would itself merit independent copyright
        protection is contributed to the file.  This is a subjective and
        arguable matter, so it's not necessarily offensive to apply an
        expansive interpretation, but "bumping" the copyright notice when
        _no_ change has been made, or when the alterations are trivial by
        another standard (code style changes that don't require regression
        testing; editorial changes to text that are _invisible_ to the lay
        reader without technological assistance--like trailing tab/space
        removal) abuse the principle.
    
    2.  It's okay to simply have a year range of XXXX-YYYY instead of a
        comma-separated list of years.  As far as I know there is no hard
        rule that such ranges are interpreted exhaustively, and unless
        someone has a chronolgical record of changes to the file, a broken
        sequence of copyright overage years makes little practical
        difference.  Copyright protection extends to those portions of the
        work fixed in a tangible medium in the years declared in the
        copyright notice, except for those portions whose copyright
        durations have elapsed.  However--as far as I know--no work of
        computer software or documentation has ever yet even _partially_
        aged into the public domain.
    
    3.  In contrast to the foregoing, I agree with the GNU guidance that the
        _package_ or work as a whole should get its copyright notice
        updated if any portion thereof saw an original contribution in the
        calendar year.
    
    4.  Don't be a jerk and release early in the year with no copyrightable
        changes made yet in that calendar year _and_ a copyright notice that
        is "bumped" to the current year.
    
    5.  Don't be a colossal jerk like major publishers and copyright a work
        with a date in the next calendar year when that year won't even
        arrive for several months.  The people who do this will not even be
        alive to pursue an infringment case that turns on the distinction.
        This veritably shouts, "Behold!  I am a rentier who shall never be
        held to account for abuse of my monopoly!  Choke on cake, proles!"
    
    If you see a file in the groff source distribution that appears to have
    too aggressive a range of copyright years, inform the development team
    at groff at gnu dot org.
    
    Ready to reform copyright law yet?
---
 FOR-RELEASE | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/FOR-RELEASE b/FOR-RELEASE
index 592a48fd7..53c3828db 100644
--- a/FOR-RELEASE
+++ b/FOR-RELEASE
@@ -47,9 +47,7 @@ This file describes how to prepare 'groff' for a new release.
   a historical ChangeLog file and add it to `EXTRA_DIST` in Makefile.am.
 
 * Update in 'src/roff/groff/groff.cpp' the 'printf' that displays the
-  copyright.
-
-* Update the copyright year with 'update-copyright.sh'.
+  copyright to include the current year if it is not present.
 
 * Increment the version number by tagging the release, beta, or release
   candidate.  groff requires an explicit three-part version,