Mercurial > hg > octave-lyh > gnulib-hg
changeset 6470:cfd1116d819e
Copyright Notices simplification
author | Karl Berry <karl@freefriends.org> |
---|---|
date | Tue, 06 Dec 2005 23:43:31 +0000 |
parents | 0528ec7cc2f9 |
children | 54a70822331f |
files | doc/maintain.texi |
diffstat | 1 files changed, 38 insertions(+), 52 deletions(-) [+] |
line wrap: on
line diff
--- a/doc/maintain.texi +++ b/doc/maintain.texi @@ -5,7 +5,7 @@ @c For double-sided printing, uncomment: @c @setchapternewpage odd @c This date is automagically updated when you save this file: -@set lastupdate May 10, 2005 +@set lastupdate December 6, 2005 @c %**end of header @dircategory GNU organization @@ -423,18 +423,19 @@ Please keep these records in a file named @file{AUTHORS} in the source directory for the program itself. + @node Copyright Notices @section Copyright Notices @cindex copyright notices in program files -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 -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. +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 @@ -446,9 +447,10 @@ 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. +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: @@ -468,42 +470,18 @@ translations may use C-in-a-circle in locales where that symbol is known to work. -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. +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.) -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 @emph{not} a list of years in which versions were -@emph{released}. It is a list of years in which versions, later -released, were @emph{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. +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}. Do -write each relevant year as a four-digit number. In the normal course -of maintenance, you may come across copyright notices which omit the -century, as in @samp{1996, 97, 98}---change these to include the -century. However, there is no need to systematically change the -notice in every old file. - -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). +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: @@ -512,16 +490,24 @@ 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. +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. But you don't have to include a notice -for everyone who contributed to the file, and that would be rather -inconvenient. +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 + @node License Notices @section License Notices