Re: [PATCH] maint: fix copyright dates that were munged by a maintenance script

[Paul Eggert]

On 11/08/2010 05:27 PM, Karl Berry wrote:
> The whole point, as I understand it, is that it's *not fraudulent*.

Not having access to the earlier conversation about this, I can
only speculate that it was about a case where it was indeed not
fraudulent.  For example, if the copyright notice looked like this:

  This file is part of GNU Emacs.

  Copyright (C) 1983-2008 Free Software Foundation, Inc.
  ...

then the copyright notice wouldn't be fraudulent, as the preceding
sentence puts it into context that the notice is about GNU Emacs
as a whole, not just about the one file.  If my speculation is
correct, then the gunzip case is different, since the file gunzip
doesn't contain wording like that, and gunzip is intended to be
useful even when it is not part of the gzip package.

If my speculation is correct, then something like the following patch would
address the issue in a way that's both consistent with the earlier
conversation and with my concerns about misdating files.  Also, I
hope it reflects existing practice fairly well; it certainly does for
gnulib, where the dates are maintained individually.

--- maintain.texi
+++ maintain.texi
@@ -612,11 +612,17 @@ omitted entirely; the word @samp{Copyright} suffices.
 To update the list of year numbers, add each year in which you have
 made nontrivial changes to the package.  (Here we assume you're using
 a publicly accessible revision control server, so that every revision
-installed is also immediately and automatically published.)  When you
+installed is also immediately and automatically published; and we
+assume that the copyright notice is preceded by a phrase like ``This
+file is part of GNU FOO'' which makes it clear that the notice is for
+the entire package and not for just the file.)  When you
 add the new year, it is not required to keep track of which files have
 seen significant changes in the new year and which have not.  It is
 recommended and simpler to add the new year to all files in the
 package, and be done with it for the rest of the year.
+However, if a file is intended to be copied into another project or
+used standalone, its copyright years should be those of the file
+itself, not of the package containing the file.
 
 Don't delete old year numbers, though; they are significant since they
 indicate when older versions might theoretically go into the public