http://www.gnu.org/prep/maintain_7.html
Copyright Notices
You should maintain a legally valid copyright notice and a license notice in each nontrivial file in the package.
(Any file more than ten lines long is nontrivial for this purpose.) This includes header files and interface
definitions, makefiles, scripts, other data files used in building or running the program,do
cumentation files,
and any supporting files. If a file has been explicitly placed in the publicdo
main, then
instead of a copyright
notice, it should have a notice saying explicitly that it is in the publicdo
main.
Even image files and sound files should contain copyright notices and license notices, if they can. Some formats
do not have room for textual annotations;
for these files, state the copyright and copying permissions in a README
file in the same directory.
Change log files should have a copyright notice and license notice at the end, since new material is added at the
begin
ning but the end remains the end.
When a file is automatically generated from some other file in the distribution, it is useful to copy the copyright
notice and permission notice of the file it is generated from, if you can. Alternatively, put a notice at the
begin
ning saying which file it is generated from.
A copyright notice looks like this:
Copyright year1, year2, year3 copyright-holder
The copyright-holder may be the Free Software Foundation, Inc., or someone else
;
you should know who is the copyright
holder for your package.
The list of year numbers should include each year in which you finished preparing a version which was actually
released, and which was an ancestor of the current version.
Please reread the paragraph above, slowly and carefully. It is important to understand that rule precisely, much
as you would understand a complicated C statement in order to hand-simulate it.
This list is not a list of years in which versions were released. It is a list of years in which versions, later
released, were completed. So if you finish a version on Dec 31, 1994 and release it on Jan 1, 1995, this version
requires the inclusion of 1994, butdo
esn't require the inclusion of 1995.
Do not abbreviate the year list using a range;
for instance,do
not write `1996--1998';
instead, write `1996, 1997, 1998'.
The versions that matter, for purposes of this list, are versions that were ancestors of the current version.
So if you made a temporary branch in maintenance, and worked on branches A and B in parallel, then
each branch
would have its own list of years, which is based on the versions released in that branch. A version in branch
A need not be reflected in the list of years for branch B, and vice versa.
However, if you copy code from branch A into branch B, the years for branch A (or at least, for the parts that
you copied into branch B)do
need to appear in the list in branch B, because now they are ancestors of branch B.
This rule is complicated. If we were in charge of copyright law, we would probably change this (as well as many
other aspects).
For an FSF-copyrighted package, if you have followed the procedures to obtain legal papers, each file should
have just one copyright holder: the Free Software Foundation, Inc. So the copyright notice should give that
name.
But if contributors are not all assigning their copyrights to a single copyright holder,
it can easily happen that one file has several copyright holders. Each contributor of nontrivial amounts is
a copyright holder.
In that case, you should always include a copyright notice in the name of main copyright holder of the file.
You can also include copyright notices for other copyright holders as well, and this is a good idea for those
who have contributed a large amount and for those who specifically ask for notices in their names. But you
don't have to include a notice for everyone who contributed to the file, and that would be rather inconvenient.
OK?
