*** empty log message ***
[emacs.git] / admin / notes / years
bloba53a24bff18c64faa34da6b772c98a930e12d82e
1 How to Maintain Copyright Years for GNU Emacs
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[1].  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!).
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."
12  --RMS, 2005-07-13
14 [1] Note that this includes 2001 - see
15 <http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-12/msg00119.html>
18 For the refcards under etc/, it's ok to simply use the latest year
19 (typically in a `\def\year{YEAR}' expression) for the rendered copyright
20 notice, while maintaining the full list of years in the copyright notice
21 in the comments.
24 Please fix or report any non-trivial files that have "odd" copyright
25 notices.  This includes missing copyright notices, and copyright
26 holders other than FSF (or AIST in some cases).  In most cases,
27 individual authors should not appear in copyright statements.  Either
28 the copyright has been assigned (check copyright.list) to the FSF (in
29 which case the original author should be removed and the year(s)
30 transferred to the FSF); or else it is possible the file should not be
31 in Emacs at all (please report!).
33 When updating the copyright in a file (eg a .tex file) that generates
34 another file distributed with Emacs, don't forget to check in a
35 regenerated version of the target file.
37 ------------------------------------------------------------------------------
40 Following is the policy that we tried to write down one time (mid 2005).
41 Although it is incorrect, we keep it around to remind us how complicated
42 things used to be (and may become in the future).
45 Principle: Individual files need to have the year of the release
46            in the copyright notice if there is significant change.
49 Practice:
51 - individual files
52   - each must be examined, along w/ its history, by a human
53   - automated tools facilitate but can never replace this process
55 - year of the release
56   - may be different from year of file introduction,
57     or year of last significant change
58   - sometimes the release year slips, leaving a file w/ prematurely
59     marked release year => need update (e.g., s/2004/2005/ for Emacs 22)
60   - intervening years (between releases) are not valid and may cause
61     embarrassment later in case of dispute => remove (however, see next)
62   - years for new files (merged, contributed) that have been separately
63     published are valid even if between releases => leave alone
65 - significant change
66   - insignificant
67     - whitespace
68     - copyright notice
69     - version control tags
70     - simple var/func renaming
71     - in-file reorganization/reordering
72     - typos
73     - small bugfixes
74     - small docfixes
75     - filename renaming
76   - most everything else is significant
77     - change to interface
78     - change in functionality
79     - new file
80   - many small changes may be significant in aggregate
82 - when in doubt, ask (and update these guidelines -- thanks!)
84 - sometimes people make mistakes
85   - if they have not read these guidelines, point them here
86   - if the guidelines are not helpful, improve the guidelines