X-Git-Url: http://erislabs.net/gitweb/?a=blobdiff_plain;f=doc%2Fmaintain.texi;h=6f6716f4c25186d7079516f2a295ae1f471f5cc7;hb=ce23825440a0cdac92dce2a444dfbf3c20e81576;hp=f48f7c0e11728fd2a2aa2276e34ff750bb395213;hpb=f0b4806df7c50191879d90368f472bf9fccb5c9d;p=gnulib.git diff --git a/doc/maintain.texi b/doc/maintain.texi index f48f7c0e1..6f6716f4c 100644 --- 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 January 4, 2005 +@set lastupdate March 22, 2006 @c %**end of header @dircategory GNU organization @@ -25,7 +25,7 @@ Information for maintainers of GNU software, last updated @value{lastupdate}. Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, -2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. +2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. @quotation Permission is granted to make and distribute verbatim copies @@ -53,22 +53,22 @@ copyright notice and this permission notice are preserved. @end ifnottex @menu -* Preface:: -* Stepping Down:: -* Recruiting Developers:: -* Legal Matters:: -* Clean Ups:: -* Platforms:: -* Mail:: -* Old Versions:: -* Distributions:: -* Web Pages:: -* Ethical and Philosophical Consideration:: -* Terminology:: -* Hosting:: -* Free Software Directory:: -* Using the Proofreaders List:: -* Index:: +* Preface:: +* Stepping Down:: +* Recruiting Developers:: +* Legal Matters:: +* Clean Ups:: +* Platforms:: +* Mail:: +* Old Versions:: +* Distributions:: +* Web Pages:: +* Ethical and Philosophical Consideration:: +* Terminology:: +* Hosting:: +* Free Software Directory:: +* Using the Proofreaders List:: +* Index:: @end menu @node Preface @@ -171,12 +171,12 @@ This chapter describes procedures you should follow for legal reasons as you maintain the program, to avoid legal difficulties. @menu -* Copyright Papers:: +* Copyright Papers:: * Legally Significant:: -* Recording Contributors:: -* Copyright Notices:: -* License Notices:: -* External Libraries:: +* Recording Contributors:: +* Copyright Notices:: +* License Notices:: +* External Libraries:: @end menu @node Copyright Papers @@ -204,11 +204,12 @@ expected papers arrive. @cindex @file{/gd/gnuorg} directory @c This paragraph intentionally duplicates information given @c near the beginning of the file--to make sure people don't miss it. -The directory @file{/gd/gnuorg} is found on the GNU machines; if you are -the maintainer of a GNU package, you should have an account on them. -Contact @email{accounts@@gnu.org} if you don't have one. (You can also -ask for accounts for people who help you a large amount in working on -the package.) +The directory @file{/gd/gnuorg} is found on the GNU machines, +currently @code{fencepost.gnu.org}; if you are the maintainer of a GNU +package, you should have an account on them. Contact +@email{accounts@@gnu.org} if you don't have one. (You can also ask +for accounts for people who help you a large amount in working on the +package.) In order for the contributor to know person should sign papers, you need to ask for the necessary papers. If you don't know per well, and you @@ -235,10 +236,12 @@ vs.@: disclaim) and their consequences. Once the conversation is under way and the contributor is ready for more details, you should send one of the templates that are found in -the directory @file{/gd/gnuorg/Copyright/}. This section explains -which templates you should use in which circumstances. @strong{Please -don't use any of the templates except for those listed here, and -please don't change the wording.} +the directory @file{/gd/gnuorg/Copyright/}; they are also available +from the @file{doc/Copyright/} directory of the @code{gnulib} project +at @url{http://savannah.gnu.org/projects/gnulib}. This section +explains which templates you should use in which circumstances. +@strong{Please don't use any of the templates except for those listed +here, and please don't change the wording.} Once the conversation is under way, you can send the contributor the precise wording and instructions by email. Before you do this, make @@ -247,7 +250,8 @@ these templates occasionally---don't keep using an old version. For large changes, ask the contributor for an assignment. Send per a copy of the file @file{request-assign.changes}. (Like all the -@samp{request-} files, it is in @file{/gd/gnuorg/Copyright}.) +@samp{request-} files, it is in @file{/gd/gnuorg/Copyright} and in +@code{gnulib}.) For medium to small changes, request a disclaimer by sending per the file @file{request-disclaim.changes}. @@ -423,14 +427,15 @@ they are considered a separate package, not part of GAS proper. 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 +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 +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 @@ -446,9 +451,10 @@ 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. +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 +474,31 @@ 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. -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 have +made nontrivial changes to 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.) When you +add the new year, it is not required to keep track which files have +seen significant changes in the new year and which have not. It is +recommended and simpler to add the new year to all files in the +package, and be done with it for the rest of the year. -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. +For files which are regularly copied from another project (such as +@samp{gnulib}), the copyright notice should left as it is in the +original. -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}. + +The copyright statement may be split across multiple lines, both in +source files and in any generated output. This often happens for +files with a long history, having many different years of +publication. 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 +507,25 @@ 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 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 +is optional. + @node License Notices @section License Notices @@ -547,7 +551,7 @@ You can use whichever is the most convenient for you. @item The directory @file{/gd/gnuorg} on the host -@code{fencepost.gnu.org}. (You can ask @email{accounts@@gnu.org} +@code{fencepost.gnu.org}. (You can ask @email{accounts@@gnu.org} for an account there if you don't have one). @item @@ -580,8 +584,8 @@ GNU General Public License for more details. You should have received a copy of the GNU General Public License along with @var{program}; see the file COPYING. If not, write to -the Free Software Foundation, Inc., 59 Temple Place - Suite 330, -Boston, MA 02111-1307, USA. +the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, +Boston, MA 02110-1301 USA. @end quotation But in a small program which is just a few files, you can use @@ -600,7 +604,7 @@ GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., -59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA @end quotation Documentation files should have license notices also. Manuals should @@ -612,7 +616,7 @@ Texts,,,texinfo,Texinfo}, for a full example in a Texinfo manual. @smallexample Permission is granted to copy, distribute and/or modify this document -under the terms of the GNU Free Documentation License, Version 1.1 or +under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being "GNU General Public License", with the Front-Cover Texts being ``A GNU Manual,'' and with the Back-Cover Texts @@ -626,7 +630,7 @@ developing GNU and promoting software freedom.'' @end smallexample If the FSF does not publish this manual on paper, then omit the last -sentence in (b) that talks about copies from GNU Press. If the FSF is +sentence in (a) that talks about copies from GNU Press. If the FSF is not the copyright holder, then replace @samp{FSF} with the appropriate name. @@ -900,12 +904,12 @@ It is important to follow the GNU conventions when making GNU software distributions. @menu -* Distribution tar Files:: -* Distribution Patches:: -* Distribution on ftp.gnu.org:: -* Test Releases:: -* Automated FTP Uploads:: -* Announcements:: +* Distribution tar Files:: +* Distribution Patches:: +* Distribution on ftp.gnu.org:: +* Test Releases:: +* Automated FTP Uploads:: +* Announcements:: @end menu @node Distribution tar Files @@ -1421,8 +1425,8 @@ important for correcting two widespread and important misunderstandings about GNU. @menu -* Free Software and Open Source:: -* GNU and Linux:: +* Free Software and Open Source:: +* GNU and Linux:: @end menu @node Free Software and Open Source