mirror of
https://git.savannah.gnu.org/git/emacs.git
synced 2024-12-24 10:38:38 +00:00
71 lines
2.4 KiB
Plaintext
71 lines
2.4 KiB
Plaintext
How to Maintain Copyright Years for GNU Emacs
|
|
|
|
|
|
"Our lawyer says it is ok if we add, to each file that has been in Emacs
|
|
since Emacs 21 came out in 2001, all the subsequent years. We don't
|
|
need to check whether *that file* was changed in those years.
|
|
It's sufficient that *Emacs* was changed in those years (and it was!).
|
|
|
|
For those files that have been added since then, we should add
|
|
the year it was added to Emacs, and all subsequent years."
|
|
|
|
--RMS, 2005-07-13
|
|
|
|
|
|
For the refcards under etc/, it's ok to simply use the latest year
|
|
(typically in a `\def\year{YEAR}' expression) for the rendered copyright
|
|
notice, while maintaining the full list of years in the copyright notice
|
|
in the comments.
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
|
|
Following is the policy that we tried to write down one time (mid 2005).
|
|
Although it is incorrect, we keep it around to remind us how complicated
|
|
things used to be (and may become in the future).
|
|
|
|
|
|
Principle: Individual files need to have the year of the release
|
|
in the copyright notice if there is significant change.
|
|
|
|
|
|
Practice:
|
|
|
|
- individual files
|
|
- each must be examined, along w/ its history, by a human
|
|
- automated tools facilitate but can never replace this process
|
|
|
|
- year of the release
|
|
- may be different from year of file introduction,
|
|
or year of last significant change
|
|
- sometimes the release year slips, leaving a file w/ prematurely
|
|
marked release year => need update (e.g., s/2004/2005/ for Emacs 22)
|
|
- intervening years (between releases) are not valid and may cause
|
|
embarrassment later in case of dispute => remove (however, see next)
|
|
- years for new files (merged, contributed) that have been separately
|
|
published are valid even if between releases => leave alone
|
|
|
|
- significant change
|
|
- insignificant
|
|
- whitespace
|
|
- copyright notice
|
|
- version control tags
|
|
- simple var/func renaming
|
|
- in-file reorganization/reordering
|
|
- typos
|
|
- small bugfixes
|
|
- small docfixes
|
|
- filename renaming
|
|
- most everything else is significant
|
|
- change to interface
|
|
- change in functionality
|
|
- new file
|
|
- many small changes may be significant in aggregate
|
|
|
|
- when in doubt, ask (and update these guidelines -- thanks!)
|
|
|
|
- sometimes people make mistakes
|
|
- if they have not read these guidelines, point them here
|
|
- if the guidelines are not helpful, improve the guidelines
|