X-Git-Url: http://erislabs.net/gitweb/?a=blobdiff_plain;f=doc%2Fmaintain.texi;h=6f6716f4c25186d7079516f2a295ae1f471f5cc7;hb=b2892d7fdc1ccddc18263320f389f5c06bff45a5;hp=623067a9b9f09c82379089575d9ad0f3df47d72a;hpb=512eca76f67448338221e99237a3e392f111be40;p=gnulib.git diff --git a/doc/maintain.texi b/doc/maintain.texi index 623067a9b..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 May 15, 2004 +@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 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 @@ -184,7 +184,7 @@ as you maintain the program, to avoid legal difficulties. @cindex copyright papers If you maintain an FSF-copyrighted package -certain legal procedures when incorporating legally significant +certain legal procedures are required when incorporating legally significant changes written by other people. This ensures that the FSF has the legal right to distribute the package, and the standing to defend its GPL-covered status in court if necessary. @@ -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 -@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}. @@ -263,6 +267,11 @@ file gives per instructions for how to ask the FSF to mail per the papers to sign. The @file{request-} file also raises the issue of getting a copyright disclaimer from the contributor's employer. +When the contributor emails the form to the FSF, the FSF sends per +papers to sign. If person signs them right away, the whole process +takes about two weeks--mostly waiting for letters to go back and +forth. + For less common cases, we have template files you should send to the contributor. Be sure to fill in the name of the person and the name of the program in these templates, where it says @samp{NAME OF PERSON} @@ -281,7 +290,7 @@ manual. For smaller changes, use @file{disclaim.changes.manual}; for larger ones, use @file{assign.changes.manual}. To cover both past and future changes to a manual, you can use @file{assign.future.manual}. -For a translation of a manual, use @file{assign.translate.manual}. +For a translation of a manual, use @file{assign.translation.manual}. If a contributor is reluctant to sign an assignment for a large change, and is willing to sign a disclaimer instead, that is acceptable, so you @@ -418,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 @@ -441,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: @@ -463,60 +474,58 @@ 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: -the Free Software Foundation, Inc. So the copyright notice should give -that name. +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 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 @@ -542,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 @@ -575,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 @@ -595,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 @@ -607,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 @@ -621,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. @@ -650,6 +659,11 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. @end smallexample +If your package distributes Autoconf macros that are intended to be +used (hence distributed) by third-party packages under possibly +incompatible licenses, you may also use the above all-permissive +license for these macros. + If you would like help with license issues or with using the GFDL, please contact @email{licensing@@gnu.org}. @@ -808,6 +822,14 @@ bug-reporting list for your program. To set up a new list, contact @email{new-mailing-list@@gnu.org}. You can subscribe to a list managed by Mailman by sending mail to the corresponding @samp{-request} address. +You should moderate postings from non-subscribed addresses on your +mailing lists, to prevent propagation of unwanted messages (``spam'') +to subscribers and to the list archives. For lists controlled by +Mailman, you can do this by setting @code{Privacy Options - Sender +Filter - generic_nonmember_action} to @code{Hold}, and then +periodically (daily is best) reviewing the held messages, accepting +the real ones and discarding the junk. + @cindex responding to bug reports When you receive bug reports, keep in mind that bug reports are crucial for your work. If you don't know about problems, you cannot fix them. @@ -882,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 @@ -1152,7 +1174,8 @@ your package (in the example above, that is @code{bar}). Your designated upload email addresses (@pxref{Automated Upload Registration}) are sent a message if there are any problems processing -an upload for your package. +an upload for your package. You also receive a message when your ++upload has been successfully processed. If you have difficulties processing an upload, email @email{ftp-upload@@gnu.org}. @@ -1402,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