GNU Info
(maintain.info)Copyright Notices
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, documentation files, and any supporting
files. If a file has been explicitly placed in the public domain, then
instead of a copyright notice, it should have a notice saying explicitly
that it is in the public domain.
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 beginning 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 beginning 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,
but doesn'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.
automatically generated by info2www version 1.2.2.9