64680
|
1 How to Maintain Copyright Years for GNU Emacs
|
75466
|
2 (see also file "copyright" in this directory)
|
62697
|
3
|
64680
|
4 "Our lawyer says it is ok if we add, to each file that has been in Emacs
|
75251
|
5 since Emacs 21 came out in 2001, all the subsequent years[1]. We don't
|
64680
|
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!).
|
62697
|
8
|
64680
|
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
|
62697
|
13
|
75251
|
14 [1] Note that this includes 2001 - see
|
|
15 <http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-12/msg00119.html>
|
|
16
|
62697
|
17
|
65217
|
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.
|
|
22
|
64680
|
23 ------------------------------------------------------------------------------
|
|
24
|
|
25
|
|
26 Following is the policy that we tried to write down one time (mid 2005).
|
|
27 Although it is incorrect, we keep it around to remind us how complicated
|
|
28 things used to be (and may become in the future).
|
62464
|
29
|
|
30
|
|
31 Principle: Individual files need to have the year of the release
|
|
32 in the copyright notice if there is significant change.
|
|
33
|
|
34
|
|
35 Practice:
|
|
36
|
|
37 - individual files
|
|
38 - each must be examined, along w/ its history, by a human
|
|
39 - automated tools facilitate but can never replace this process
|
|
40
|
|
41 - year of the release
|
|
42 - may be different from year of file introduction,
|
|
43 or year of last significant change
|
|
44 - sometimes the release year slips, leaving a file w/ prematurely
|
|
45 marked release year => need update (e.g., s/2004/2005/ for Emacs 22)
|
|
46 - intervening years (between releases) are not valid and may cause
|
|
47 embarrassment later in case of dispute => remove (however, see next)
|
|
48 - years for new files (merged, contributed) that have been separately
|
|
49 published are valid even if between releases => leave alone
|
|
50
|
|
51 - significant change
|
|
52 - insignificant
|
|
53 - whitespace
|
|
54 - copyright notice
|
|
55 - version control tags
|
|
56 - simple var/func renaming
|
|
57 - in-file reorganization/reordering
|
|
58 - typos
|
|
59 - small bugfixes
|
|
60 - small docfixes
|
|
61 - filename renaming
|
|
62 - most everything else is significant
|
|
63 - change to interface
|
|
64 - change in functionality
|
|
65 - new file
|
|
66 - many small changes may be significant in aggregate
|
|
67
|
|
68 - when in doubt, ask (and update these guidelines -- thanks!)
|
|
69
|
|
70 - sometimes people make mistakes
|
|
71 - if they have not read these guidelines, point them here
|
|
72 - if the guidelines are not helpful, improve the guidelines
|