Simpler rules for copyright notices

Simpler rules for copyright notices

[Richard M. Stallman]

After more discussions with Eben Moglen, we finalized the new
rules for years in copyright notices.  They are pretty simple.


@node Copyright Notices
@section Copyright Notices
@cindex copyright notices in program files

You should maintain a proper 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 for
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 for the automatic procedure to copy the
copyright notice and permission notice of the file it is generated
from, if possible.  Alternatively, put a notice at the beginning saying
which file it is generated from.

A copyright notice looks like this:

@example
Copyright (C) @var{year1}, @var{year2}, @var{year3}  @var{copyright-holder}
@end example

The @var{copyright-holder} may be the Free Software Foundation, Inc., or
someone else; you should know who is the copyright holder for your
package.

Replace the @samp{(C)} with a C-in-a-circle symbol if it is available.
For example, use @samp{@@copyright@{@}} in a Texinfo file.  However,
stick with parenthesized @samp{C} unless you know that C-in-a-circle
will work.  For example, a program's standard @option{--version}
message should use parenthesized @samp{C} by default, though message
translations may use C-in-a-circle in locales where that symbol is
known to work.

To update the list of year numbers, add each year in which you change
the package.  (Here we assume you're using a publicly accessible
revision control server, so that every revision installed is also
immediately and automatically published.)

Don't delete old year numbers, though; they can indicate when older
versions might theoretically go into the public domain.  If you copy a
file into the package from some other program, keep the copyright
years that come with the file.

Do not abbreviate the year list using a range; for instance, do not
write @samp{1996--1998}; instead, write @samp{1996, 1997, 1998}.

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.  You should edit the file's
copyright notice to list that name and only 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 text 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.  (Sometimes the license
on code that you copy in may require preserving certain copyright
notices.)  But you don't have to include a notice for everyone who
contributed to the file (which would be rather inconvenient).

Sometimes a program has an overall copyright notice that refers to the
whole program.  It might be in the @file{README} file, or it might be
displayed when the program starts up.  This copyright notice should
mention the year of completion of the most recent major version; it
can mention years of completion of previous major versions, but that
is optional.

Re: Simpler rules for copyright notices

[Glenn Morris]

"Richard M. Stallman" wrote:

> To update the list of year numbers, add each year in which you
> change the package. (Here we assume you're using a publicly
> accessible revision control server, so that every revision installed
> is also immediately and automatically published.)

It just says "change". Does this mean there is no concept of a
"significant" change any more (eg >= 10 lines, etc)?

Also, I'd find it a help if there was a more explicit statement about
the guidelines we were given for Emacs, ie something about:

  If a package contains multiple files, then when you release a new
  version of the package, you should update the copyright years in
  _all_ files (regardless of whether a given file has been changed
  since the last release).


I don't see that the question I asked on Nov 2 ("Finish updating
copyright years" thread), about whether we should add 2001 for Emacs
is explicitly answered. I think the spirit of it is that we should -
is this what you want us to do?


(I'm not trying to make mountains out of molehills for the sake of it.
IANAL, but it seems details are important, and I want to do it right!).

Re: Simpler rules for copyright notices

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

> To update the list of year numbers, add each year in which you change
> the package.

This is still unclear about whether it is ok to add a specific year in
individual files of a package even if those files have not been
changed in that specific year.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk