admin/notes/years

   1 How to Maintain Copyright Years for GNU Emacs
   2
   3
   4 "Our lawyer says it is ok if we add, to each file that has been in Emacs
   5  since Emacs 21 came out in 2001, all the subsequent years.  We don't
   6  need to check whether *that file* was changed in those years.
   7  It's sufficient that *Emacs* was changed in those years (and it was!).
   8
   9  For those files that have been added since then, we should add
  10  the year it was added to Emacs, and all subsequent years."
  11
  12  --RMS, 2005-07-13
  13
  14
  15 For the refcards under etc/, it's ok to simply use the latest year
  16 (typically in a `\def\year{YEAR}' expression) for the rendered copyright
  17 notice, while maintaining the full list of years in the copyright notice
  18 in the comments.
  19
  20
  21 ------------------------------------------------------------------------------
  22
  23
  24 Following is the policy that we tried to write down one time (mid 2005).
  25 Although it is incorrect, we keep it around to remind us how complicated
  26 things used to be (and may become in the future).
  27
  28
  29 Principle: Individual files need to have the year of the release
  30            in the copyright notice if there is significant change.
  31
  32
  33 Practice:
  34
  35 - individual files
  36   - each must be examined, along w/ its history, by a human
  37   - automated tools facilitate but can never replace this process
  38
  39 - year of the release
  40   - may be different from year of file introduction,
  41     or year of last significant change
  42   - sometimes the release year slips, leaving a file w/ prematurely
  43     marked release year => need update (e.g., s/2004/2005/ for Emacs 22)
  44   - intervening years (between releases) are not valid and may cause
  45     embarrassment later in case of dispute => remove (however, see next)
  46   - years for new files (merged, contributed) that have been separately
  47     published are valid even if between releases => leave alone
  48
  49 - significant change
  50   - insignificant
  51     - whitespace
  52     - copyright notice
  53     - version control tags
  54     - simple var/func renaming
  55     - in-file reorganization/reordering
  56     - typos
  57     - small bugfixes
  58     - small docfixes
  59     - filename renaming
  60   - most everything else is significant
  61     - change to interface
  62     - change in functionality
  63     - new file
  64   - many small changes may be significant in aggregate
  65
  66 - when in doubt, ask (and update these guidelines -- thanks!)
  67
  68 - sometimes people make mistakes
  69   - if they have not read these guidelines, point them here
  70   - if the guidelines are not helpful, improve the guidelines