@c For double-sided printing, uncomment:
@c @setchapternewpage odd
@c This date is automagically updated when you save this file:
-@set lastupdate November 12, 2010
+@set lastupdate October 12, 2011
@c %**end of header
@dircategory GNU organization
Information for maintainers of GNU software, last updated @value{lastupdate}.
Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
-Foundation, Inc.
+2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
+2010, 2011 Free Software Foundation, Inc.
@quotation
Permission is granted to copy, distribute and/or modify this document
Standards (@pxref{Top, , Contents, standards, GNU Coding Standards}).
@cindex @code{bug-standards@@gnu.org} email address
-@cindex Savannah repository for gnustandards
-@cindex gnustandards project repository
+@cindex Savannah repository for @code{gnustandards}
+@cindex @code{gnustandards} project repository
Please send corrections or suggestions for this document to
@email{bug-standards@@gnu.org}. If you make a suggestion, please
include suggested new wording if you can. We prefer a context diff to
@cindex help, getting
@cindex @code{mentors@@gnu.org} mailing list
-If you have general questions or encounter a situation where it isn't
-clear what to do, you can ask @email{mentors@@gnu.org}, which is a
-list of a few experienced GNU contributors who have offered to answer
-questions for new maintainers.
+If you have any general questions or encounter a situation where it
+isn't clear how to get something done or who to ask, you (as a GNU
+contributor) can always write to @email{mentors@@gnu.org}, which is a
+list of a few experienced GNU folks who have volunteered to answer
+questions. Any GNU-related question is fair game for the
+@code{mentors} list.
@cindex advisory committee
The GNU Advisory Committee helps to coordinate activities in the GNU
committee members. Additional information is in
@file{/gd/gnuorg/advisory}.
+@cindex down, when GNU machines are
+@cindex outage, of GNU machines
+@cindex @url{http://identi.ca/group/fsfstatus}
+If you find that any GNU computer systems (@code{fencepost.gnu.org},
+@code{ftp.gnu.org}, @code{www.gnu.org}, @code{savannah.gnu.org},
+@dots{}) seem to be down, you can check the current status at
+@url{http://identi.ca/group/fsfstatus}. Most likely the problem, if
+it can be alleviated at the FSF end, is already being worked on.
+
+@cindex sysadmin, FSF
+@cindex FSF system administrators
+@cindex GNU system administrators
+The FSF system administrators are responsible for the network and GNU
+hardware. You can email them at @email{sysadmin@@fsf.org}, but please
+try not to burden them unnecessarily.
@node Getting a GNU Account
@gdgnuorgtext{}
-@cindex down, when GNU machines are
-@cindex outage, of GNU machines
-@cindex @url{http://identi.ca/group/fsfstatus}
-If you find that any GNU computer systems (@code{fencepost.gnu.org},
-@code{ftp.gnu.org}, @code{www.gnu.org}, @code{savannah.gnu.org},
-@dots{}) seem to be down, you can check the current status at
-@url{http://identi.ca/group/fsfstatus}. Most likely the problem, if
-it can be alleviated at the FSF end, is already being worked on.
-
@node Stepping Down
@chapter Stepping Down
maintainer needs the GNU Project's confirmation, but your judgment that
a person is capable of doing the job will carry a lot of weight.
-As your final act as maintainer, it would be helpful to set up the
-package under @code{savannah.gnu.org} if it is not there already
-(@pxref{Old Versions}). This will make it much easier for the new
-maintainer to pick up where you left off and will ensure that the
-source tree is not misplaced if it takes us a while to find a new
-maintainer.
+As your final act as maintainer, it would be helpful to set up or
+update the package under @code{savannah.gnu.org} (@pxref{Old
+Versions}). This will make it much easier for the new maintainer to
+pick up where you left off and will ensure that the source tree is not
+misplaced if it takes us a while to find a new maintainer.
@node Recruiting Developers
@quotation
Would you be willing to assign the copyright to the Free Software
-Foundation, so that we could install it in @var{program}?
+Foundation, so that we could install it in @var{package}?
@end quotation
@noindent
@quotation
Would you be willing to sign a copyright disclaimer to put this change
-in the public domain, so that we can install it in @var{program}?
+in the public domain, so that we can install it in @var{package}?
@end quotation
If the contributor then wants more information, you can send per the file
papers to sign. The @file{request-} file also raises the issue of
getting an employer's 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 a couple of weeks---mostly waiting for letters to go back and
-forth.
+When the contributor emails the form to the FSF, the FSF sends per an
+electronic (usually PDF) copy of the assignment. All contributors
+then print the assignment and sign it. Contributors residing outside
+the U.S. must mail the signed form to the FSF via the post.
+Contributors located in the U.S. can then email or fax a scanned copy
+back to the FSF (or use postal mail, if they prefer). (To emphasize,
+the necessary distinction is between US residents and non-residents,
+citizenship does not matter.)
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
For a translation of a manual, use @file{assign.translation.manual}.
For translations of program strings (as used by GNU Gettext, for
-example; @pxref{Internationalization,,,standards,GNU Coding
+example; @pxref{Internationalization,,, standards, GNU Coding
Standards}), use @file{disclaim.translation}. If you make use of the
Translation Project (@url{http://translationproject.org}) facilities,
please check with the TP coordinators that they have sent the
copy of its plain text version also (conventionally in a file named
@file{COPYING.LESSER}).
-If you have questions about license issues for your GNU package,
+If you have questions about licensing issues for your GNU package,
please write @email{licensing@@gnu.org}.
@menu
-* Source: Canonical License Sources.
-* Code: License Notices for Code.
+* Which: Licensing of GNU Packages.
+* Canonical: Canonical License Sources.
+* Code: License Notices for Code.
* Documentation: License Notices for Documentation.
-* Other: License Notices for Other Files.
+* Other: License Notices for Other Files.
@end menu
+@node Licensing of GNU Packages
+@subsection Licensing of GNU Packages
+
+Normally, GNU packages should use the latest version of the GNU GPL,
+with the ``or any later version'' formulation. @xref{License Notices
+for Code}, for the exact wording of the license notice.
+
+Occasionally, a GNU library may provide functionality which is already
+widely available to proprietary programs through alternative
+implementations; for example, the GNU C Library. In such cases, the
+Lesser GPL should be used (again, for the notice wording,
+@pxref{License Notices for Code}). If a GNU library provides unique
+functionality, however, the GNU GPL should be used.
+@url{http://www.gnu.org/licenses/why-not-lgpl.html} discusses this
+strategic choice.
+
+Some of these libraries need to work with programs released under
+GPLv2-only; that is, which allow the GNU GPL version 2 but not later
+versions. In this case, the GNU package should be released under a
+dual license: GNU GPL version 2 (or any later version) and the GNU
+Lesser GPL version 3 (or any later version). Here is the notice for
+that case:
+
+@smallexample
+This file is part of GNU @var{package}.
+
+GNU @var{package} is free software: you can redistribute it and/or
+modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+or both in parallel, as here.
+
+GNU @var{package} is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received copies of the GNU General Public License and
+the GNU Lesser General Public License along with this program. If
+not, see @url{http://www.gnu.org/licenses/}.
+@end smallexample
+
+For small packages, you can use ``This program'' instead of ``GNU
+@var{package}''.
+
+
@node Canonical License Sources
@subsection Canonical License Sources
The official Texinfo sources for the licenses are also available in
those same places, so you can include them in your documentation. A
GFDL-covered manual should include the GFDL in this way. @xref{GNU
-Sample Texts,,,texinfo,Texinfo}, for a full example in a Texinfo
+Sample Texts,,, texinfo, Texinfo}, for a full example in a Texinfo
manual.
configure files and makefiles) should cite the GPL, like this:
@quotation
-This file is part of GNU @var{program}.
+This file is part of GNU @var{package}.
-GNU @var{program} is free software: you can redistribute it and/or
+GNU @var{package} is free software: you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
-GNU @var{program} is distributed in the hope that it will be useful,
+GNU @var{package} is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
along with this program. If not, see @url{http://www.gnu.org/licenses/}.
@end quotation
+In either case, for those few packages which use the Lesser GPL
+(@pxref{Licensing of GNU Packages}), insert the word ``Lesser'' before
+``General'' in @emph{all three} places.
+@url{http://@/www.gnu.org/@/licenses/@/gpl-howto.html} discusses application
+the GPL in more detail.
+
@node License Notices for Documentation
@subsection License Notices for Documentation
If your manual is not published by the FSF, and under 400 pages, you
can omit both cover texts.
-@xref{GNU Sample Texts,,,texinfo,Texinfo}, for a full example in a
+@xref{GNU Sample Texts,,, texinfo, Texinfo}, for a full example in a
Texinfo manual, and see
@url{http://www.gnu.org/licenses/fdl-howto.html} for more advice about
how to use the GNU FDL.
Once a program is in use, you will get bug reports for it. Most GNU
programs have their own special lists for sending bug reports. The
advertised bug-reporting email address should always be
-@samp{bug-@var{program}@@gnu.org}, to help show users that the program
+@samp{bug-@var{package}@@gnu.org}, to help show users that the program
is a GNU package, but it is ok to set up that list to forward to another
site if you prefer. The package distribution should state the
name of the bug-reporting list in a prominent place, and ask users to
nowadays we want to give each program its own bug-reporting list and
move away from using @email{bug-gnu-utils}.
+@xref{Replying to Mail}, for more about handling and tracking bug
+reports.
+
@cindex help for users, mailing list for
Some GNU programs with many users have another mailing list,
-@samp{help-@var{program}.org}, for people to ask other users for help.
+@samp{help-@var{package}.org}, for people to ask other users for help.
If your program has many users, you should create such a list for it.
For a fairly new program, which doesn't have a large user base yet, it
is better not to bother with this.
@cindex announcements, mailing list for
If you wish, you can also have a mailing list
-@samp{info-@var{program}} for announcements (@pxref{Announcements}),
-and any others you find useful.
+@samp{info-@var{package}} for announcements (@pxref{Announcements}).
+Any other mailing lists you find useful can also be created.
@node Creating Mailing Lists
to make bug reports useful. Copying and adapting that could be very
useful for your package.
+@cindex @url{http://bugs.gnu.org}
+@cindex bug reports, email tracker for
+@cindex bug reports, web tracker for
+If you would like to use an email-based bug tracking system, see
+@url{http://bugs.gnu.org}; this can be connected with the regular
+bug-reporting address. Alternatively, if you would like to use a
+web-based bug tracking system, Savannah supports this (@pxref{Old
+Versions}), but please don't fail to accept bugs by regular email as
+well---we don't want to put up unnecessary barriers against users
+submitting reports.
+
@node Old Versions
@chapter Recording Old Versions
@cindex version control
It is very important to keep backup files of all source files of GNU.
-You can do this using a source control system (such as RCS, CVS, Git,
-@dots{}) if you like. The easiest way to use RCS or CVS is via the
-Version Control library in Emacs (@pxref{VC Concepts,, Concepts of
-Version Control, emacs, The GNU Emacs Manual}).
+You can do this using a source control system (such as Bazaar, RCS,
+CVS, Git, Subversion, @dots{}) if you like. An easy way to use
+many such systems is via the Version Control library in Emacs
+(@pxref{Introduction to VC,, Introduction to Version Control, emacs,
+The GNU Emacs Manual}).
The history of previous revisions and log entries is very important for
future maintainers of the package, so even if you do not make it
some day.
@cindex @code{savannah-hackers@@gnu.org}
-The GNU Project provides a server that GNU software packages can use
+The GNU Project provides a server that GNU packages can use
for source control and other package needs: @code{savannah.gnu.org}.
-You don't have to use this repository, but if you plan to allow public
-read-only access to your development sources, it is convenient for
-people to be able to find various GNU packages in a central place.
-Savannah is managed by @email{savannah-hackers@@gnu.org}.
+Savannah is managed by @email{savannah-hackers@@gnu.org}. For more
+details on using and contributing to Savannah, see
+@url{http://savannah.gnu.org/maintenance}.
-All GNU maintainers are strongly encouraged to take advantage of
-Savannah, as sharing such a central point can serve to foster a sense
-of community among GNU developers and help in keeping up with project
-management.
+It's not an absolute requirement, but all GNU maintainers are strongly
+encouraged to take advantage of Savannah, as sharing such a central
+point can serve to foster a sense of community among GNU developers as
+well as help in keeping up with project management. Please don't mark
+Savannah projects for GNU packages as private; that defeats a large
+part of the purpose of using Savannah in the first place.
@cindex @code{savannah-announce@@gnu.org} mailing list
If you do use Savannah, please subscribe to the
@cindex time stamp in diffs
If you use GNU @code{diff} to make the patch, use the options
@samp{-rc2P}. That will put any new files into the output as ``entirely
-different.'' Also, the patch's context diff headers should have dates
+different''. Also, the patch's context diff headers should have dates
and times in Universal Time using traditional Unix format, so that patch
recipients can use GNU @code{patch}'s @samp{-Z} option. For example,
you could use the following Bourne shell command to create the patch:
subdirectory named after the package, and all the distribution files
for the package should go in that subdirectory.
-@c If you have an interest in seeing the monthly download logs from the FTP
-@c site at @code{ftp.gnu.org} for your program, that is something that
-@c @email{ftp-upload@@gnu.org} can set up for you. Please contact them if
-@c you are interested.
-
@xref{Automated FTP Uploads}, for procedural details of putting new
versions on @code{ftp.gnu.org}.
@item
In the @samp{My Account Conf} page on @code{savannah}, upload the GPG
-key you will use to sign your packages.
+key you will use to sign your packages. If you haven't created one
+before, you can do so with the command @code{gpg --gen-key} (you can
+accept all the default answers to its questions).
-You can create a key with the command @code{gpg --gen-key}. It is
-good to also send your key to the GPG public key server: @code{gpg
---keyserver keys.gnupg.net --send-keys @var{keyid}}, where @var{keyid}
-is the eight hex digits reported by @code{gpg --list-public-keys} on
-the @code{pub} line before the date. For full information about GPG,
-see @url{http://www.gnu.org/software/gpg})
+Optional but recommended: Send your key to a GPG public key server:
+@code{gpg --keyserver keys.gnupg.net --send-keys @var{keyid}}, where
+@var{keyid} is the eight hex digits reported by @code{gpg
+--list-public-keys} on the @code{pub} line before the date. For full
+information about GPG, see @url{http://www.gnu.org/software/gpg}.
@item
Compose a message with the following items in some @var{msgfile}.
Then GPG-sign it by running @code{gpg --clearsign @var{msgfile}}, and
-finally email the resulting @file{@var{msgfile}.asc}), to
+finally email the resulting @file{@var{msgfile}.asc} to
@email{ftp-upload@@gnu.org}.
@enumerate
@item
-Name of package(s) that you are the maintainer for, and your
-preferred email address.
+Name of package(s) that you are the maintainer for, your
+preferred email address, and your Savannah username.
@item
-An ASCII armored copy of your GnuPG key, as an attachment. (@samp{gpg
+An ASCII armored copy of your GPG key, as an attachment. (@samp{gpg
--export -a @var{your_key_id} >mykey.asc} should give you this.)
@item
don't make all releases yourself).
@item
-ASCII armored copies of GnuPG keys for any individuals listed in (3).
+ASCII armored copies of GPG keys for any individuals listed in (3).
@end enumerate
@end enumerate
command line @code{ftp}.
If you have difficulties with an upload, email
-@email{ftp-upload@@gnu.org}.
+@email{ftp-upload@@gnu.org}. You can check the archive of uploads
+processed at
+@url{https://lists.gnu.org/archive/html/ftp-upload-report}.
@node FTP Upload Directive File - v1.1
@cindex announcement mailing list, project-specific
You can maintain your own mailing list (typically
-@email{info-@var{program}@@gnu.org}) for announcements as well if you
+@email{info-@var{package}@@gnu.org}) for announcements as well if you
like. For your own list, of course you decide as you see fit what
events are worth announcing. (@xref{Mail}, for setting this up, and
more suggestions on handling mail for your package.)
redirect to a nearby mirror.
@item
-The NEWS (@pxref{NEWS File,,, standards, GNU Coding Standards}) for
+The @t{NEWS} (@pxref{NEWS File,,, standards, GNU Coding Standards}) for
the present release.
@end itemize
@end smallexample
@noindent where @var{yourmanual} is the short name for your package
-and @var{yourbuglist} is the email address for bug reports (typically
-@code{bug-@var{package}@@gnu.org}). The script processes the file
-@file{@var{yourmanual}.texinfo} (or @file{.texi} or @file{.txi}). For
-example:
+and @var{yourbuglist} is the email address for bug reports (which
+should be @code{bug-@var{package}@@gnu.org}). The script processes
+the file @file{@var{yourmanual}.texinfo} (or @file{.texi} or
+@file{.txi}). For example:
@smallexample
-cd .../emacs/man
+cd .../texinfo/doc
# download gendocs.sh and gendocs_template
-gendocs.sh --email bug-gnu-emacs@@gnu.org emacs "GNU Emacs manual"
+gendocs.sh --email bug-texinfo@@gnu.org texinfo "GNU Texinfo manual"
@end smallexample
@command{gendocs.sh} creates a subdirectory @file{manual/} containing
@node Free Software and Open Source
@section Free Software and Open Source
-@cindex free software
+@cindex free software movement
@cindex open source
-@cindex movements, Free Software and Open Source
-
-The terms ``free software'' and ``open source'' are the slogans of two
-different movements which differ in their basic philosophy. The Free
-Software Movement is idealistic, and raises issues of freedom, ethics,
-principle and what makes for a good society. The Open Source Movement,
-founded in 1998, studiously avoids such questions. For more explanation,
-see @url{http://www.gnu.org/philosophy/open-source-misses-the-point.html}.
-
-The GNU Project is aligned with the Free Software Movement. This
+@cindex movement, free software
+@cindex development method, open source
+
+The terms ``free software'' and ``open source'', while describing
+almost the same category of software, stand for views based on
+fundamentally different values. The free software movement is
+idealistic, and raises issues of freedom, ethics, principle and what
+makes for a good society. The term open source, initiated in 1998, is
+associated with a philosophy which studiously avoids such questions.
+For a detailed explanation, see
+@url{http://www.gnu.org/philosophy/open-source-misses-the-point.html}.
+
+The GNU Project is aligned with the free software movement. This
doesn't mean that all GNU contributors and maintainers have to agree;
your views on these issues are up to you, and you're entitled to express
them when speaking for yourself.
-However, due to the much greater publicity that the Open Source
-Movement receives, the GNU Project needs to overcome a widespread
-mistaken impression that GNU is @emph{and always was} an activity of
-the Open Source Movement. For this reason, please use the term ``free
+However, due to the much greater publicity that the term ``open source''
+receives, the GNU Project needs to overcome a widespread
+mistaken impression that GNU is @emph{and always was} an ``open
+source'' activity. For this reason, please use the term ``free
software'', not ``open source'', in GNU software releases, GNU
documentation, and announcements and articles that you publish in your
role as the maintainer of a GNU package. A reference to the URL given
above, to explain the difference, is a useful thing to include as
well.
+
@node GNU and Linux
@section GNU and Linux
@cindex Linux
precisely, they know about it, but don't realize it is the GNU Project's
accomplishment and reason for existence. Even people who believe they
know the real history often believe that the goal of GNU was to develop
-``tools'' or ``utilities.''
+``tools'' or ``utilities''.
To correct this confusion, we have made a years-long effort to
distinguish between Linux, the kernel that Linus Torvalds wrote, and
@url{http://www.gnu.org/gnu/linux-and-gnu.html}.
To contrast the GNU system properly with respect to GNU/Linux, you can
-call it ``GNU/Hurd'' or ``the GNU/Hurd system.'' However, when that
+call it ``GNU/Hurd'' or ``the GNU/Hurd system''. However, when that
contrast is not specifically the focus, please call it just ``GNU'' or
-``the GNU system.''
+``the GNU system''.
When referring to the collection of servers that is the higher level
-of the GNU kernel, please call it ``the Hurd'' or ``the GNU Hurd.''
+of the GNU kernel, please call it ``the Hurd'' or ``the GNU Hurd''.
Note that this uses a space, not a slash.
Versions}, for more information about Savannah.
We strongly urge you to use @code{ftp.gnu.org} as the standard
-distribution site. Doing so makes it easier for developers and users
-to find the latest GNU releases. However, it is ok to use another
-server if you wish, provided it allows access from the general public
-without limitation (for instance, without excluding any country).
+distribution site for releases. Doing so makes it easier for
+developers and users to find the latest GNU releases. However, it is
+ok to use another server if you wish, provided it allows access from
+the general public without limitation (for instance, without excluding
+any country).
If you use a company's machine to hold the repository for your
-program, or as its ftp site, please put this statement in a prominent
-place on the site, so as to prevent people from getting the wrong idea
-about the relationship between the package and the company:
+program, or as its release distribution site, please put this
+statement in a prominent place on the site, so as to prevent people
+from getting the wrong idea about the relationship between the package
+and the company:
@smallexample
The programs <list of them> hosted here are free software packages
As a maintainer, you might want to accept donations for your work,
especially if you pay for any of your own hosting/development
-infrastructure. Following is some text you can adapt for your
-package's web site, @file{README}, or wherever you find it useful:
+infrastructure. Following is some text you can adapt to your own
+situation, and use on your package's web site, @file{README}, or
+in wherever way you find it useful:
@smallexample
We appreciate contributions of any size -- donations enable us to spend
more time working on the project, and help cover our infrastructure
expenses.
-If you'd like to make a small donation, please visit @var{url} and do
-it through PayPal. Since our project isn't a tax-exempt organization,
-we can't offer you a tax deduction, but for all donations over
-@var{amount}, we'd be happy to recognize your contribution on
-@var{another-url}.
+If you'd like to make a small donation, please visit @var{url1} and do
+it through @var{payment-service}. Since our project isn't a
+tax-exempt organization, we can't offer you a tax deduction, but for
+all donations over @var{amount1}, we'd be happy to recognize your
+contribution on @var{url2}.
-If you can make a donation large enough to entirely fund a substantial
-change, such as $1000, then we could discuss with you what change we
-should do with your funds, and we could give you a certain amount of
-specific help in exchange. Write to us about this at @var{address}.
+We are also happy to consider making particular improvements or
+changes, or giving specific technical assistance, in return for a
+substantial donation over @var{amount2}. If you would like to discuss
+this possibility, write to us at @var{address}.
+
+Another possibility is to pay a software maintenance fee. Again,
+write to us about this at @var{address} to discuss how much you want
+to pay and how much maintenance we can offer in return. If you pay
+more than @var{amount1}, we can give you a document for your records.
Thanks for your support!
@end smallexample
+We don't recommend any specific payment service. However, GNU
+developers should not use a service that requires them to sign a
+proprietary software license, such as Google's payment service.
+
+Of course, it is also good to encourage people to join or contribute
+to the FSF (@url{http://www.fsf.org}), either instead of or as well as
+package-specific donations.
+
@node Free Software Directory
@chapter Free Software Directory
projects / gnulib.git / blobdiff