1 \input texinfo.tex @c -*-texinfo-*-
3 @setfilename maintain.info
4 @settitle Information For Maintainers of GNU Software
5 @c For double-sided printing, uncomment:
6 @c @setchapternewpage odd
7 @c This date is automagically updated when you save this file:
8 @set lastupdate April 4, 2004
11 @dircategory GNU organization
13 * Maintaining: (maintain). Maintaining GNU software.
16 @setchapternewpage off
18 @c Put everything in one index (arbitrarily chosen to be the concept index).
25 Information for maintainers of GNU software, last updated @value{lastupdate}.
27 Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
28 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
31 Permission is granted to make and distribute verbatim copies
32 of this entire document without royalty provided the
33 copyright notice and this permission notice are preserved.
38 @title Information For Maintainers of GNU Software
39 @author Richard Stallman
40 @author last updated @value{lastupdate}
42 @vskip 0pt plus 1filll
58 * Recruiting Developers::
66 * Ethical and Philosophical Consideration::
69 * Free Software Directory::
70 * Using the Proofreaders List::
75 @chapter About This Document
77 This file contains guidelines and advice for someone who is the
78 maintainer of a GNU program on behalf of the GNU Project. Everyone is
79 entitled to change and redistribute GNU software; you need not pay
80 attention to this file to get permission. But if you want to maintain a
81 version for widespread distribution, we suggest you follow these
82 guidelines; if you would like to be a GNU maintainer, then it is
83 essential to follow these guidelines.
85 Please send corrections or suggestions for this document to
86 @email{maintainers@@gnu.org}. If you make a suggestion, please include
87 a suggested new wording for it, to help us consider the suggestion
88 efficiently. We prefer a context diff to the @file{maintain.texi} file,
89 but if you don't have that file, you can make a context diff for some
90 other version of this document, or propose it in any way that makes it
93 This document uses the gender-neutral third-person pronouns ``person'',
94 ``per'', ``pers'' and ``perself'' which were promoted, and perhaps
95 invented, by Marge Piercy in @cite{Woman on the Edge of Time}. They are
96 used just like ``she'', ``her'', ``hers'' and ``herself'', except that
97 they apply equally to males and females. For example, ``Person placed
98 per new program under the GNU GPL, to let the public benefit from per
99 work, and to enable per to feel person has done the right thing.''
101 The directory @file{/gd/gnuorg} is found on the GNU file server,
102 currently @code{fencepost.gnu.org}; if you are the maintainer of a GNU
103 package, you should have an account there. Contact
104 @email{accounts@@gnu.org} if you don't have one. (You can also ask
105 for accounts for people who help you a large amount in working on the
106 package.) @file{/gd/gnuorg/maintain.tar.gz} is a tar file containing
107 all of these files in that directory which are mentioned in this file;
110 This release of the GNU Maintenance Instructions was last updated
114 @chapter Stepping Down
116 With good fortune, you will continue maintaining your package for many
117 decades. But sometimes for various reasons maintainers decide to step
120 If you're the official maintainer of a GNU package and you decide to
121 step down, please inform the GNU Project (@email{maintainers@@gnu.org}).
122 We need to know that the package no longer has a maintainer, so we can
123 look for and appoint a new maintainer.
125 If you have an idea for who should take over, please tell
126 @email{maintainers@@gnu.org} your suggestion. The appointment of a new
127 maintainer needs the GNU Project's confirmation, but your judgment that
128 a person is capable of doing the job will carry a lot of weight.
130 As your final act as maintainer, it would be helpful to set up the
131 package under @code{savannah.gnu.org} (@pxref{Old Versions}). This will
132 make it much easier for the new maintainer to pick up where you left off
133 and will ensure that the CVS tree is not misplaced if it takes us a
134 while to find a new maintainer.
136 @node Recruiting Developers
137 @chapter Recruiting Developers
139 Unless your package is a fairly small, you probably won't do all the
140 work on it yourself. Most maintainers recruit other developers to help.
142 Sometimes people will offer to help. Some of them will be capable,
143 while others will not. It's up to you to determine who provides useful
144 help, and encourage those people to participate more.
146 Some of the people who offer to help will support the GNU Project, while
147 others may be interested for other reasons. Some will support the goals
148 of the Free Software Movement, but some may not. They are all welcome
149 to help with the work---we don't ask people's views or motivations
150 before they contribute to GNU packages.
152 As a consequence, you cannot expect all contributors to support the GNU
153 Project, or to have a concern for its policies and standards. So part
154 of your job as maintainer is to exercise your authority on these points
155 when they arise. No matter how much of the work other people do, you
156 are in charge of what goes in the release. When a crucial point arises,
157 you should calmly state your decision and stick to it.
159 Sometimes a package has several co-maintainers who share the role of
160 maintainer. Unlike developers who help, co-maintainers have actually
161 been appointed jointly as the maintainers of the package, and they carry
162 out the maintainer's functions together. If you would like to propose
163 some of your developers as co-maintainers, please contact
164 @email{maintainers@@gnu.org}.
167 @chapter Legal Matters
168 @cindex legal matters
170 This chapter describes procedures you should follow for legal reasons
171 as you maintain the program, to avoid legal difficulties.
175 * Legally Significant::
176 * Recording Contributors::
177 * Copyright Notices::
179 * External Libraries::
182 @node Copyright Papers
183 @section Copyright Papers
184 @cindex copyright papers
186 If you maintain an FSF-copyrighted package
187 certain legal procedures when incorporating legally significant
188 changes written by other people. This ensures that the FSF has the
189 legal right to distribute the package, and the standing to defend its
190 GPL-covered status in court if necessary.
192 @strong{Before} incorporating significant changes, make sure that the
193 person who wrote the changes has signed copyright papers and that the
194 Free Software Foundation has received and signed them. We may also need
195 a disclaimer from the person's employer.
197 @cindex data base of GNU copyright assignments
198 To check whether papers have been received, look in
199 @file{/gd/gnuorg/copyright.list}. If you can't look there directly,
200 @email{fsf-records@@gnu.org} can check for you. Our clerk can also
201 check for papers that are waiting to be entered and inform you when
202 expected papers arrive.
204 @cindex @file{/gd/gnuorg} directory
205 @c This paragraph intentionally duplicates information given
206 @c near the beginning of the file--to make sure people don't miss it.
207 The directory @file{/gd/gnuorg} is found on the GNU machines; if you are
208 the maintainer of a GNU package, you should have an account on them.
209 Contact @email{accounts@@gnu.org} if you don't have one. (You can also
210 ask for accounts for people who help you a large amount in working on
213 In order for the contributor to know person should sign papers, you need
214 to ask for the necessary papers. If you don't know per well, and you
215 don't know that person is used to our ways of handling copyright papers,
216 then it might be a good idea to raise the subject with a message like
220 Would you be willing to assign the copyright to the Free Software
221 Foundation, so that we could install it in @var{program}?
228 Would you be willing to sign a copyright disclaimer to put this change
229 in the public domain, so that we can install it in @var{program}?
232 If the contributor wants more information, you can send per
233 @file{/gd/gnuorg/conditions.text}, which explains per options (assign
234 vs.@: disclaim) and their consequences.
236 Once the conversation is under way and the contributor is ready for
237 more details, you should send one of the templates that are found in
238 @file{/gd/gnuorg/Copyright}. This section explains which templates
239 you should use in which circumstances. @strong{Please don't use any
240 of the templates except for those listed here, and please don't change
243 Once the conversation is under way, you can send the contributor the
244 precise wording and instructions by email. Before you do this, make
245 sure to get the current version of the template you will use! We change
246 these templates occasionally---don't keep using an old version.
248 For large changes, ask the contributor for an assignment. Send per a
249 copy of the file @file{request-assign.changes}. (Like all the
250 @samp{request-} files, it is in @file{/gd/gnuorg/Copyright}.)
252 For medium to small changes, request a disclaimer by sending per the
253 file @file{request-disclaim.changes}.
255 If the contributor is likely to keep making changes, person might want
256 to sign an assignment for all per future changes to the program. So it
257 is useful to offer per that alternative. If person wants to do it that
258 way, send per the @file{request-assign.future}.
260 When you send a @file{request-} file, you don't need to fill in anything
261 before sending it. Just send the file verbatim to the contributor. The
262 file gives per instructions for how to ask the FSF to mail per the
263 papers to sign. The @file{request-} file also raises the issue of
264 getting a copyright disclaimer from the contributor's employer.
266 For less common cases, we have template files you should send to the
267 contributor. Be sure to fill in the name of the person and the name
268 of the program in these templates, where it says @samp{NAME OF PERSON}
269 and @samp{NAME OF PROGRAM}, before sending; otherwise person might
270 sign without noticing them, and the papers would be useless. Note
271 that in some templates there is more than one place to put the name of
272 the program or the name of the person; be sure to change all of them.
273 All the templates raise the issue of an employer's disclaimer as well.
275 @cindex legal papers for changes in manuals
276 You do not need to ask for separate papers for a manual that is
277 distributed only in the software package it describes. But if we
278 sometimes distribute the manual separately (for instance, if we publish
279 it as a book), then we need separate legal papers for changes in the
280 manual. For smaller changes, use
281 @file{disclaim.changes.manual}; for larger ones, use
282 @file{assign.changes.manual}. To cover both past and future
283 changes to a manual, you can use @file{assign.future.manual}.
284 For a translation of a manual, use @file{assign.translate.manual}.
286 If a contributor is reluctant to sign an assignment for a large change,
287 and is willing to sign a disclaimer instead, that is acceptable, so you
288 should offer this alternative if it helps you reach agreement. We
289 prefer an assignment for a larger change, so that we can enforce the GNU
290 GPL for the new text, but a disclaimer is enough to let us use the text.
292 If you maintain a collection of programs, occasionally someone will
293 contribute an entire separate program or manual that should be added to
294 the collection. Then you can use the files
295 @file{request-assign.program}, @file{disclaim.program},
296 @file{assign.manual}, and @file{disclaim.manual}. We very much prefer
297 an assignment for a new separate program or manual, unless it is quite
298 small, but a disclaimer is acceptable if the contributor insists on
299 handling the matter that way.
301 If a contributor wants the FSF to publish only a pseudonym, that is
302 ok. The contributor should say this, and state the desired pseudonym,
303 when answering the @file{request-} form. The actual legal papers will
304 use the real name, but the FSF will publish only the pseudonym. When
305 using one of the other forms, fill in the real name but ask the
306 contributor to discuss the use of a pseudonym with
307 @email{assign@@gnu.org} before sending back the signed form.
309 @strong{Although there are other templates besides the ones listed here,
310 they are for special circumstances; please do not use them without
311 getting advice from @email{assign@@gnu.org}.}
313 If you are not sure what to do, then please ask @email{assign@@gnu.org} for
314 advice; if the contributor asks you questions about the meaning and
315 consequences of the legal papers, and you don't know the answers, you
316 can forward them to @email{assign@@gnu.org} and we will answer.
318 @strong{Please do not try changing the wording of a template yourself.
319 If you think a change is needed, please talk with @email{assign@@gnu.org},
320 and we will work with a lawyer to decide what to do.}
322 @node Legally Significant
323 @section Legally Significant Changes
325 If a person contributes more than around 15 lines of code and/or text
326 that is legally significant for copyright purposes, which means we
327 need copyright papers for it as described above.
329 A change of just a few lines (less than 15 or so) is not legally
330 significant for copyright. A regular series of repeated changes, such
331 as renaming a symbol, is not legally significant even if the symbol
332 has to be renamed in many places. Keep in mind, however, that a
333 series of minor changes by the same person can add up to a significant
334 contribution. What counts is the total contribution of the person; it
335 is irrelevant which parts of it were contributed when.
337 Copyright does not cover ideas. If someone contributes ideas but no
338 text, these ideas may be morally significant as contributions, and
339 worth giving credit for, but they are not significant for copyright
340 purposes. Likewise, bug reports do not count for copyright purposes.
342 When giving credit to people whose contributions are not legally
343 significant for copyright purposes, be careful to make that fact
344 clear. The credit should clearly say they did not contribute
345 significant code or text.
347 When people's contributions are not legally significant because they
348 did not write code, do this by stating clearly what their contribution
349 was. For instance, you could write this:
354 * Richard Mlynarik <mly@@adoc.xerox.com> (1997)
355 * Masatake Yamato <masata-y@@is.aist-nara.ac.jp> (1999)
360 @code{Ideas by:} makes it clear that Mlynarik and Yamato here
361 contributed only ideas, not code. Without the @code{Ideas by:} note,
362 several years from now we would find it hard to be sure whether they
363 had contributed code, and we might have to track them down and ask
366 When you record a small patch in a change log file, first search for
367 previous changes by the same person, and see if his past
368 contributions, plus the new one, add up to something legally
369 significant. If so, you should get copyright papers for all his
370 changes before you install the new change.
372 If that is not so, you can install the small patch. Write @samp{(tiny
373 change)} after the patch author's name, like this:
376 2002-11-04 Robert Fenk <Robert.Fenk@@gmx.de> (tiny change)
379 @node Recording Contributors
380 @section Recording Contributors
381 @cindex recording contributors
383 @strong{Keep correct records of which portions were written by whom.}
384 This is very important. These records should say which files
385 parts of files, were written by each person, and which files or
386 portions were revised by each person. This should include
387 installation scripts as well as manuals and documentation
390 These records don't need to be as detailed as a change log. They
391 don't need to distinguish work done at different times, only different
392 people. They don't need describe changes in more detail than which
393 files or parts of a file were changed. And they don't need to say
394 anything about the function or purpose of a file or change--the
395 Register of Copyrights doesn't care what the text does, just who wrote
396 or contributed to which parts.
398 The list should also mention if certain files distributed in the same
399 package are really a separate program.
401 Only the contributions that are legally significant for copyright
402 purposes (@pxref{Legally Significant}) need to be listed. Small
403 contributions, ideas, etc., can be omitted.
405 For example, this would describe an early version of GAS:
408 Dean Elsner first version of all files except gdb-lines.c and m68k.c.
409 Jay Fenlason entire files gdb-lines.c and m68k.c, most of app.c,
410 plus extensive changes in messages.c, input-file.c, write.c
411 and revisions elsewhere.
413 Note: GAS is distributed with the files obstack.c and obstack.h, but
414 they are considered a separate package, not part of GAS proper.
417 @cindex @file{AUTHORS} file
418 Please keep these records in a file named @file{AUTHORS} in the source
419 directory for the program itself.
421 @node Copyright Notices
422 @section Copyright Notices
423 @cindex copyright notices in program files
425 You should maintain a legally valid copyright notice and a license
426 notice in each nontrivial file in the package. (Any file more than ten
427 lines long is nontrivial for this purpose.) This includes header files
428 and interface definitions
429 building or running the program, documentation files, and any supporting
430 files. If a file has been explicitly placed in the public domain, then
431 instead of a copyright notice, it should have a notice saying explicitly
432 that it is in the public domain.
434 Even image files and sound files should contain copyright notices and
435 license notices, if they can. Some formats do not have room for textual
436 annotations; for these files, state the copyright and copying
437 permissions in a README file in the same directory.
439 Change log files should have a copyright notice and license notice at
440 the end, since new material is added at the beginning but the end
443 When a file is automatically generated from some other file in the
444 distribution, it is useful to copy the copyright notice and permission
445 notice of the file it is generated from, if you can. Alternatively, put
446 a notice at the beginning saying which file it is generated from.
448 A copyright notice looks like this:
451 Copyright (C) @var{year1}, @var{year2}, @var{year3} @var{copyright-holder}
454 The @var{copyright-holder} may be the Free Software Foundation, Inc., or
455 someone else; you should know who is the copyright holder for your
458 Replace the @samp{(C)} with a C-in-a-circle symbol if it is available.
459 For example, use @samp{@@copyright@{@}} in a Texinfo file. However,
460 stick with parenthesized @samp{C} unless you know that C-in-a-circle
461 will work. For example, a program's standard @option{--version}
462 message should use parenthesized @samp{C} by default, though message
463 translations may use C-in-a-circle in locales where that symbol is
466 The list of year numbers should include each year in which you finished
467 preparing a version which was actually released, and which was an
468 ancestor of the current version.
470 Please reread the paragraph above, slowly and carefully. It is
471 important to understand that rule precisely, much as you would
472 understand a complicated C statement in order to hand-simulate it.
474 This list is @emph{not} a list of years in which versions were
475 @emph{released}. It is a list of years in which versions, later
476 released, were @emph{completed}. So if you finish a version on Dec 31,
477 1994 and release it on Jan 1, 1995, this version requires the inclusion
478 of 1994, but doesn't require the inclusion of 1995.
480 Do not abbreviate the year list using a range; for instance, do not
481 write @samp{1996--1998}; instead, write @samp{1996, 1997, 1998}.
483 The versions that matter, for purposes of this list, are versions that
484 were ancestors of the current version. So if you made a temporary
485 branch in maintenance, and worked on branches A and B in parallel, then
486 each branch would have its own list of years, which is based on the
487 versions released in that branch. A version in branch A need not be
488 reflected in the list of years for branch B, and vice versa.
490 However, if you copy code from branch A into branch B, the years for
491 branch A (or at least, for the parts that you copied into branch B) do
492 need to appear in the list in branch B, because now they are ancestors
495 This rule is complicated. If we were in charge of copyright law, we
496 would probably change this (as well as many other aspects).
498 For an FSF-copyrighted package, if you have followed the procedures to
499 obtain legal papers, each file should have just one copyright holder:
500 the Free Software Foundation, Inc. So the copyright notice should give
503 But if contributors are not all assigning their copyrights to a single
504 copyright holder, it can easily happen that one file has several
505 copyright holders. Each contributor of nontrivial amounts is a
508 In that case, you should always include a copyright notice in the name
509 of main copyright holder of the file. You can also include copyright
510 notices for other copyright holders as well, and this is a good idea for
511 those who have contributed a large amount and for those who specifically
512 ask for notices in their names. But you don't have to include a notice
513 for everyone who contributed to the file, and that would be rather
516 @node License Notices
517 @section License Notices
518 @cindex license notices in program files
520 Every nontrivial file needs a license notice as well as the copyright
521 notice. (Without a license notice giving permission to copy and change
523 would make the file non-free.)
525 The package itself should contain a full copy of GPL (conventionally in
526 a file named @file{COPYING}) and the GNU Free Documentation License
527 (included within your documentation). If the package contains any files
528 distributed under the Lesser GPL, it should contain a full copy of that
529 as well (conventionally in a file named @file{COPYING.LIB}).
531 You can get the official versions of these files from three places.
532 You can use whichever is the most convenient for you.
536 @uref{http://www.gnu.org/licenses/}.
539 The directory @file{/gd/gnuorg} on the host
540 @code{fencepost.gnu.org}. (You can ask @email{accounts@@gnu.org}
541 for an account there if you don't have one).
544 The @code{gnulib} project on @code{savannah.gnu.org}, which you
545 can access via anonymous CVS. See
546 @uref{http://savannah.gnu.org/projects/gnulib}.
550 The official Texinfo sources for the licenses are also available in
551 those same places, so you can include them in your documentation. A
552 GFDL-covered manual must include the GFDL in this way. @xref{GNU Sample
553 Texts,,,texinfo,Texinfo}, for a full example in a Texinfo manual.
555 Typically the license notice for program files (including build scripts,
556 configure files and makefiles) should cite the GPL, like this:
559 This file is part of GNU @var{program}
561 GNU @var{program} is free software; you can redistribute it and/or modify
562 it under the terms of the GNU General Public License as published by
563 the Free Software Foundation; either version 2, or (at your option)
566 GNU @var{program} is distributed in the hope that it will be useful,
567 but WITHOUT ANY WARRANTY; without even the implied warranty of
568 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
569 GNU General Public License for more details.
571 You should have received a copy of the GNU General Public License
572 along with @var{program}; see the file COPYING. If not, write to
573 the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
574 Boston, MA 02111-1307, USA.
577 But in a small program which is just a few files, you can use
581 This program is free software; you can redistribute it and/or modify
582 it under the terms of the GNU General Public License as published by
583 the Free Software Foundation; either version 2 of the License, or
584 (at your option) any later version.
586 This program is distributed in the hope that it will be useful,
587 but WITHOUT ANY WARRANTY; without even the implied warranty of
588 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
589 GNU General Public License for more details.
591 You should have received a copy of the GNU General Public License along
592 with this program; if not, write to the Free Software Foundation, Inc.,
593 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
596 Documentation files should have license notices also. Manuals should
597 use the GNU Free Documentation License. Here is an example of the
598 license notice to use after the copyright notice. Please adjust the
599 list of invariant sections as appropriate for your manual. (If there
600 are none, then say ``with no invariant sections''.) @xref{GNU Sample
601 Texts,,,texinfo,Texinfo}, for a full example in a Texinfo manual.
604 Permission is granted to copy, distribute and/or modify this document
605 under the terms of the GNU Free Documentation License, Version 1.1 or
606 any later version published by the Free Software Foundation; with the
607 Invariant Sections being "GNU General Public License", with the
608 Front-Cover Texts being ``A GNU Manual,'' and with the Back-Cover Texts
609 as in (a) below. A copy of the license is included in the section
610 entitled "GNU Free Documentation License".
612 (a) The FSF's Back-Cover Text is: ``You are free to copy and modify
613 this GNU Manual. Buying copies from GNU Press supports the FSF in
614 developing GNU and promoting software freedom.''
618 If the FSF does not publish this manual on paper, then omit the last
619 sentence in (b) that talks about copies from GNU Press. If the FSF is
620 not the copyright holder, then replace @samp{FSF} with the appropriate
623 See @url{http://www.gnu.org/licenses/fdl-howto.html} for more advice
624 about how to use the GNU FDL.
626 If the manual is over 400 pages, or if the FSF thinks it might be a good
627 choice for publishing on paper, then please include our standard
628 invariant section which explains the importance of free documentation.
629 Write to @email{assign@@gnu.org} to get a copy of this section.
631 Note that when you distribute several manuals together in one software
632 package, their on-line forms can share a single copy of the GFDL (see
633 section 6). However, the printed (@samp{.dvi}) forms should each
634 contain a copy of the GFDL, unless they are set up to be printed
635 and published only together. Therefore, it is usually simplest to
636 include the GFDL in each manual.
638 Small supporting files, short manuals (under 300 lines long) and rough
639 documentation (README files, INSTALL files, etc) can use a simple
640 all-permissive license like this one:
643 Copying and distribution of this file, with or without modification,
644 are permitted in any medium without royalty provided the copyright
645 notice and this notice are preserved.
648 If you would like help with license issues or with using the GFDL,
649 please contact @email{licensing@@gnu.org}.
651 @node External Libraries
652 @section External Libraries
654 When maintaining an FSF-copyrighted GNU package, you may occasionally
655 want to use a general-purpose free software module which offers a
656 useful functionality, as a ``library'' facility (though the module is
657 not always packaged technically as a library).
659 In a case like this, it would be unreasonable to ask the author of that
660 module to assign the copyright to the FSF. After all, person did not
661 write it specifically as a contribution to your package, so it would be
662 impertinent to ask per, out of the blue, ``Please give the FSF your
665 So the thing to do in this case is to make your program use the module,
666 but not consider it a part of your program. There are two reasonable
667 methods of doing this:
671 Assume the module is already installed on the system, and use it when
672 linking your program. This is only reasonable if the module really has
673 the form of a library.
676 Include the module in your package, putting the source in a separate
677 subdirectory whose @file{README} file says, ``This is not part of the
678 GNU FOO program, but is used with GNU FOO.'' Then set up your makefiles
679 to build this module and link it into the executable.
681 For this method, it is not necessary to treat the module as a library
682 and make a @samp{.a} file from it. You can link with the @samp{.o}
683 files directly in the usual manner.
686 Both of these methods create an irregularity, and our lawyers have told
687 us to minimize the amount of such irregularity. So consider using these
688 methods only for general-purpose modules that were written for other
689 programs and released separately for general use. For anything that was
690 written as a contribution to your package, please get papers signed.
693 @chapter Cleaning Up Changes
694 @cindex contributions, accepting
695 @cindex quality of changes suggested by others
697 Don't feel obligated to include every change that someone asks you to
698 include. You must judge which changes are improvements---partly based
699 on what you think the users will like, and partly based on your own
700 judgment of what is better. If you think a change is not good, you
703 If someone sends you changes which are useful, but written in an ugly
704 way or hard to understand and maintain in the future, don't hesitate to
705 ask per to clean up their changes before you merge them. Since the
706 amount of work we can do is limited, the more we convince others to help
707 us work efficiently, the faster GNU will advance.
709 If the contributor will not or can not make the changes clean enough,
710 then it is legitimate to say ``I can't install this in its present form;
711 I can only do so if you clean it up.'' Invite per to distribute per
712 changes another way, or to find other people to make them clean enough
713 for you to install and maintain.
715 The only reason to do these cleanups yourself is if (1) it is easy, less
716 work than telling the author what to clean up, or (2) the change is an
717 important one, important enough to be worth the work of cleaning it up.
719 The GNU Coding Standards are a good thing to send people when you ask
720 them to clean up changes (@pxref{Top, , Contents, standards, GNU Coding
721 Standards}). The Emacs Lisp manual contains an appendix that gives
722 coding standards for Emacs Lisp programs; it is good to urge authors to
723 read it (@pxref{Tips, , Tips and Standards, elisp, The GNU Emacs Lisp
727 @chapter Platforms to Support
729 Most GNU packages run on a wide range of platforms. These platforms are
730 not equally important.
732 The most important platforms for a GNU package to support are GNU and
733 GNU/Linux. Developing the GNU operating system is the whole point of
734 the GNU Project; a GNU package exists to make the whole GNU system more
735 powerful. So please keep that goal in mind and let it shape your work.
736 For instance, every new feature you add should work on GNU, and
737 GNU/Linux if possible too. If a new feature only runs on GNU and
738 GNU/Linux, it could still be acceptable. However, a feature that runs
739 only on other systems and not on GNU or GNU/Linux makes no sense in a
742 You will naturally want to keep the program running on all the platforms
743 it supports. But you personally will not have access to most of these
744 platforms--so how should you do it?
746 Don't worry about trying to get access to all of these platforms. Even
747 if you did have access to all the platforms, it would be inefficient for
748 you to test the program on each platform yourself. Instead, you should
749 test the program on a few platforms, including GNU or GNU/Linux, and let
750 the users test it on the other platforms. You can do this through a
751 pretest phase before the real release; when there is no reason to expect
752 problems, in a package that is mostly portable, you can just make a
753 release and let the users tell you if anything unportable was
756 It is important to test the program personally on GNU or GNU/Linux,
757 because these are the most important platforms for a GNU package. If
758 you don't have access to one of these platforms, please ask
759 @email{maintainers@@gnu.org} to help you out.
761 Supporting other platforms is optional---we do it when that seems like a
762 good idea, but we don't consider it obligatory. If the users don't take
763 care of a certain platform, you may have to desupport it unless and
764 until users come forward to help. Conversely, if a user offers changes
765 to support an additional platform, you will probably want to install
766 them, but you don't have to. If you feel the changes are complex and
767 ugly, if you think that they will increase the burden of future
768 maintenance, you can and should reject them. This includes both free
769 platforms such as NetBSD or FreeBSD and non-free platforms such as
773 @chapter Dealing With Mail
776 @cindex email, for receiving bug reports
777 @cindex mailing list for bug reports
778 Once a program is in use, you will get bug reports for it. Most GNU
779 programs have their own special lists for sending bug reports. The
780 advertised bug-reporting email address should always be
781 @samp{bug-@var{program}@@gnu.org}, to help show users that the program
782 is a GNU package, but it is ok to set up that list to forward to another
783 site for further forwarding. The package distribution should state the
784 name of the bug-reporting list in a prominent place, and ask users to
785 help us by reporting bugs there.
787 We also have a catch-all list, @email{bug-gnu-utils@@gnu.org}, which is
788 used for all GNU programs that don't have their own specific lists. But
789 nowadays we want to give each program its own bug-reporting list and
790 move away from using @email{bug-gnu-utils}.
792 If you are the maintainer of a GNU package, you should have an account
793 on the GNU servers; contact @email{accounts@@gnu.org} if you don't have
794 one. (You can also ask for accounts for people who help you a large
795 amount in working on the package.) With this account, you can edit
796 @file{/com/mailer/aliases} to create a new unmanaged list or add
797 yourself to an existing unmanaged list. A comment near the beginning of
798 that file explains how to create a Mailman-managed mailing list.
800 But if you don't want to learn how to do those things, you can
801 alternatively ask @email{alias-file@@gnu.org} to add you to the
802 bug-reporting list for your program. To set up a new list, contact
803 @email{new-mailing-list@@gnu.org}. You can subscribe to a list managed
804 by Mailman by sending mail to the corresponding @samp{-request} address.
806 @cindex responding to bug reports
807 When you receive bug reports, keep in mind that bug reports are crucial
808 for your work. If you don't know about problems, you cannot fix them.
809 So always thank each person who sends a bug report.
811 You don't have an obligation to give more response than that, though.
812 The main purpose of bug reports is to help you contribute to the
813 community by improving the next version of the program. Many of the
814 people who report bugs don't realize this---they think that the point is
815 for you to help them individually. Some will ask you to focus on that
816 @emph{instead of} on making the program better. If you comply with
817 their wishes, you will have been distracted from the job of maintaining
820 For example, people sometimes report a bug in a vague (and therefore
821 useless) way, and when you ask for more information, they say, ``I just
822 wanted to see if you already knew the solution'' (in which case the bug
823 report would do nothing to help improve the program). When this
824 happens, you should explain to them the real purpose of bug reports. (A
825 canned explanation will make this more efficient.)
827 When people ask you to put your time into helping them use the program,
828 it may seem ``helpful'' to do what they ask. But it is much @emph{less}
829 helpful than improving the program, which is the maintainer's real job.
831 By all means help individual users when you feel like it, if you feel
832 you have the time available. But be careful to limit the amount of time
833 you spend doing this---don't let it eat away the time you need to
834 maintain the program! Know how to say no; when you are pressed for
835 time, just ``thanks for the bug report---I will fix it'' is enough
838 Some GNU packages, such as Emacs and GCC, come with advice about how to
839 make bug reports useful. If you want to copy and adapt that, it could
840 be a very useful thing to do.
843 @chapter Recording Old Versions
844 @cindex version control
846 It is very important to keep backup files of all source files of GNU.
847 You can do this using RCS, CVS or PRCS if you like. The easiest way to
848 use RCS or CVS is via the Version Control library in Emacs;
849 @ref{VC Concepts,, Concepts of Version Control, emacs, The GNU Emacs
852 The history of previous revisions and log entries is very important for
853 future maintainers of the package, so even if you do not make it
854 publicly accessible, be careful not to put anything in the repository or
855 change log that you would not want to hand over to another maintainer
858 The GNU Project provides a CVS server that GNU software packages can
859 use: @code{subversions.gnu.org}. (The name refers to the multiple
860 versions and their subversions that are stored in a CVS repository.)
861 You don't have to use this repository, but if you plan to allow public
862 read-only access to your development sources, it is convenient for
863 people to be able to find various GNU packages in a central place. The
864 CVS Server is managed by @email{cvs-hackers@@gnu.org}.
866 The GNU project also provides additional developer resources on
867 @code{subversions.gnu.org} through its @code{savannah.gnu.org}
868 interface. All GNU maintainers are encouraged to take advantage of
869 these facilities, as @code{savannah} can serve to foster a sense of
870 community among all GNU developers and help in keeping up with project
874 @chapter Distributions
876 It is important to follow the GNU conventions when making GNU software
880 * Distribution tar Files::
881 * Distribution Patches::
882 * Distribution on ftp.gnu.org::
884 * Automated FTP Uploads::
888 @node Distribution tar Files
889 @section Distribution tar Files
890 @cindex distribution, tar files
892 The tar file for version @var{m}.@var{n} of program @code{foo} should be
893 named @file{foo-@var{m}.@var{n}.tar}. It should unpack into a
894 subdirectory named @file{foo-@var{m}.@var{n}}. Tar files should not
895 unpack into files in the current directory, because this is inconvenient
896 if the user happens to unpack into a directory with other files in it.
898 Here is how the @file{Makefile} for Bison creates the tar file.
899 This method is good for other programs.
903 echo bison-`sed -e '/version_string/!d' \
904 -e 's/[^0-9.]*\([0-9.]*\).*/\1/' -e q version.c` > .fname
907 dst=`cat .fname`; for f in $(DISTFILES); do \
908 ln $(srcdir)/$$f $$dst/$$f || @{ echo copying $$f; \
909 cp -p $(srcdir)/$$f $$dst/$$f ; @} \
911 tar --gzip -chf `cat .fname`.tar.gz `cat .fname`
912 -rm -rf `cat .fname` .fname
915 Source files that are symbolic links to other file systems cannot be
916 installed in the temporary directory using @code{ln}, so use @code{cp}
920 Using Automake is a good way to take care of writing the @code{dist}
923 @node Distribution Patches
924 @section Distribution Patches
925 @cindex patches, against previous releases
927 If the program is large, it is useful to make a set of diffs for each
928 release, against the previous important release.
930 At the front of the set of diffs, put a short explanation of which
931 version this is for and which previous version it is relative to.
932 Also explain what else people need to do to update the sources
933 properly (for example, delete or rename certain files before
934 installing the diffs).
936 The purpose of having diffs is that they are small. To keep them
937 small, exclude files that the user can easily update. For example,
938 exclude info files, DVI files, tags tables, output files of Bison or
939 Flex. In Emacs diffs, we exclude compiled Lisp files, leaving it up
940 to the installer to recompile the patched sources.
942 When you make the diffs, each version should be in a directory suitably
943 named---for example, @file{gcc-2.3.2} and @file{gcc-2.3.3}. This way,
944 it will be very clear from the diffs themselves which version is which.
948 @cindex time stamp in diffs
949 If you use GNU @code{diff} to make the patch, use the options
950 @samp{-rc2P}. That will put any new files into the output as ``entirely
951 different.'' Also, the patch's context diff headers should have dates
952 and times in Universal Time using traditional Unix format, so that patch
953 recipients can use GNU @code{patch}'s @samp{-Z} option. For example,
954 you could use the following Bourne shell command to create the patch:
957 LC_ALL=C TZ=UTC0 diff -rc2P gcc-2.3.2 gcc-2.3.3 | \
958 gzip -9 >gcc-2.3.2-2.3.3.patch.gz
961 If the distribution has subdirectories in it, then the diffs probably
962 include some files in the subdirectories. To help users install such
963 patches reliably, give them precise directions for how to run patch.
964 For example, say this:
967 To apply these patches, cd to the main directory of the program
968 and then use `patch -p1'. `-p1' avoids guesswork in choosing
969 which subdirectory to find each file in.
972 It's wise to test your patch by applying it to a copy of the old
973 version, and checking that the result exactly matches the new version.
975 @node Distribution on ftp.gnu.org
976 @section Distribution on @code{ftp.gnu.org}
978 @cindex @code{ftp.gnu.org}, the GNU ftp site
980 GNU packages are distributed through directory @file{/gnu} on
981 @code{ftp.gnu.org}. Each package should have a subdirectory
982 named after the package, and all the distribution files for the package
983 should go in that subdirectory.
985 @c If you have an interest in seeing the monthly download logs from the FTP
986 @c site at @code{ftp.gnu.org} for your program, that is something that
987 @c @email{ftp-upload@@gnu.org} can set up for you. Please contact them if
988 @c you are interested.
990 @xref{Automated FTP Uploads}, for procedural details of putting new
991 versions on @code{ftp.gnu.org}.
994 @section Test Releases
995 @cindex test releases
996 @cindex beta releases
997 @cindex pretest releases
999 @cindex @code{alpha.gnu.org}, ftp site for test releases
1000 When you release a greatly changed new major version of a program, you
1001 might want to do so as a pretest. This means that you make a tar file,
1002 but send it only to a group of volunteers that you have recruited. (Use
1003 a suitable GNU mailing list/newsgroup to recruit them.)
1005 We normally use the FTP server @code{alpha.gnu.org} for pretests and
1006 prerelease versions. @xref{Automated FTP Uploads}, for procedural details
1007 of putting new versions on @code{alpha.gnu.org}.
1009 Once a program gets to be widely used and people expect it to work
1010 solidly, it is a good idea to do pretest releases before each ``real''
1013 There are two ways of handling version numbers for pretest versions.
1014 One method is to treat them as versions preceding the release you are going
1017 In this method, if you are about to release version 4.6 but you want
1018 to do a pretest first, call it 4.5.90. If you need a second pretest,
1019 call it 4.5.91, and so on. If you are really unlucky and ten pretests
1020 are not enough, after 4.5.99 you could advance to 4.5.990 and so on.
1021 (You could also use 4.5.100, but 990 has the advantage of sorting in
1024 The other method is to attach a date to the release number that is
1025 coming. For a pretest for version 4.6, made on Dec 10, 2002, this
1026 would be 4.6.20021210. A second pretest made the same day could be
1029 For development snapshots that are not formal pretests, using just
1030 the date without the version numbers is ok too.
1032 One thing that you should never do is to release a pretest with the same
1033 version number as the planned real release. Many people will look only
1034 at the version number (in the tar file name, in the directory name that
1035 it unpacks into, or wherever they can find it) to determine whether a
1036 tar file is the latest version. People might look at the test release
1037 in this way and mistake it for the real release. Therefore, always
1038 change the number when you release changed code.
1041 @node Automated FTP Uploads
1042 @section Automated FTP Uploads
1044 @cindex ftp uploads, automated
1045 In order to upload new releases to @code{ftp.gnu.org} or
1046 @code{alpha.gnu.org}, you first need to register the necessary
1047 information. Then, you can perform uploads yourself, with no
1048 intervention needed by the system administrators.
1051 * Automated Upload Registration::
1052 * Automated Upload Procedure::
1056 @node Automated Upload Registration
1057 @subsection Automated Upload Registration
1059 @cindex registration
1060 @cindex uploads, registration for
1062 To register your information to perform automated uploads, send a
1063 message, preferably GPG-signed, to @email{ftp-upload@@gnu.org} with
1068 Name of package(s) that you are the maintainer for, and your
1069 preferred email address.
1072 An ASCII armored copy of your GnuPG key, as an attachment.
1073 (@samp{gpg --export -a YOUR_KEY_ID >mykey.asc} should give you this.)
1076 A list of names and preferred email addresses of other individuals you
1077 authorize to make releases for which packages, if any (in the case that you
1078 don't make all releases yourself).
1081 ASCII armored copies of GnuPG keys for any individuals listed in (3).
1084 The administrators will acknowledge your message when they have added
1085 the proper GPG keys as authorized to upload files for the
1086 corresponding packages.
1089 @node Automated Upload Procedure
1090 @subsection Automated Upload Procedure
1094 Once you have registered your information, as described in the
1095 previous section, you will be able to do unattended ftp uploads using
1096 the following procedure.
1098 For each upload destined for @code{ftp.gnu.org} or
1099 @code{alpha.gnu.org}, three files (a @dfn{triplet}) need to be
1100 uploaded via ftp to the host @code{ftp-upload.gnu.org}.
1104 File to distributed (e.g., @file{foo.tar.gz}).
1107 Detached GPG binary signature for (1), made using @samp{gpg -b}
1108 (for example, @file{foo.tar.gz.sig}).
1111 A clearsigned @dfn{directive file}, made using @samp{gpg --clearsign}
1112 (for example, @file{foo.tar.gz.directive.asc}).
1116 Upload the triplet via anonymous ftp to @code{ftp-upload.gnu.org}. If
1117 the upload is destined for @code{ftp.gnu.org}, then place the triplet
1118 in the @file{/incoming/ftp} directory. If the upload is destined for
1119 @code{alpha.gnu.org}, then place the triplet in the
1120 @file{/incoming/alpha} directory.
1122 Uploads are processed every five minutes. Uploads that are in
1123 progress when the upload processing script is running are handled
1124 properly, so do not worry about the timing of your upload.
1126 The directive file should contain one line, excluding the clearsigned
1127 data GPG that inserts, which specifies the final destination directory
1128 where items (1) and (2) to be placed.
1130 For example, the @file{foo.tar.gz.directive} file might contain the
1137 This directory line indicates that @file{foo.tar.gz} and
1138 @file{foo.tar.gz.sig} are part of package @code{bar}. If you were to
1139 upload the triplet to @file{/incoming/ftp}, and the system can
1140 positively authenticate the signatures, then the files
1141 @file{foo.tar.gz} and @file{foo.tar.gz.sig} will be placed in the
1142 directory @file{gnu/bar/v1} of the @code{ftp.gnu.org} site.
1144 The directive file can be used to create currently non-existent
1145 directory trees, as long as they are under the package directory for
1146 your package (in the example above, that is @code{bar}).
1148 Your designated upload email addresses (@pxref{Automated Upload
1149 Registration}) are sent a message if there are any problems processing
1150 an upload for your package.
1152 If you have difficulties processing an upload, email
1153 @email{ftp-upload@@gnu.org}.
1157 @section Announcing Releases
1159 When you have a new release, please make an announcement. You can
1160 maintain your own mailing list for announcements if you like, or you can
1161 use the moderated general GNU announcements list,
1162 @email{info-gnu@@gnu.org}.
1164 If you use your own list, you can decide as you see fit what events are
1165 worth announcing. If you use @email{info-gnu@@gnu.org}, please do not
1166 announce pretest releases, only real releases. But real releases do
1167 include releases made just to fix bugs.
1173 Please write pages about your package for installation on
1174 @code{www.gnu.org}. The pages should follow our usual standards for web
1175 pages (see @url{http://www.gnu.org/server}); we chose them in order to
1176 support a wide variety of browsers, to focus on information rather than
1177 flashy eye candy, and to keep the site simple and uniform.
1179 The simplest way to maintain the web pages for your project is to
1180 register the project on @code{savannah.gnu.org}. Then you can edit
1181 the pages using CVS. You can keep the source files there too, but if
1182 you want to use @code{savannah.gnu.org} only for the web pages, simply
1183 register a ``web-only'' project.
1185 If you don't want to use that method, please talk with
1186 @email{webmasters@@gnu.org} about other possible methods. For
1187 instance, you can mail them pages to install, if necessary. But that
1188 is more work for them, so please use CVS if you can.
1190 Some GNU packages have just simple web pages, but the more information
1191 you provide, the better. So please write as much as you usefully can,
1192 and put all of it on @code{www.gnu.org}. However, pages that access
1193 databases (including mail logs and bug tracking) are an exception; set
1194 them up on whatever site is convenient for you, and make the pages on
1195 @code{www.gnu.org} link to that site.
1197 Web pages for GNU packages should not include GIF images, since the GNU
1198 project avoids GIFs due to patent problems. @xref{Ethical and
1199 Philosophical Consideration}.
1201 The web pages for the package should include its manuals, in HTML,
1202 DVI, Info, PostScript, PDF, plain ASCII, and Texinfo format (source). (All
1203 of these can be generated automatically from the Texinfo source using
1204 Makeinfo and other programs.) When there is only one manual, put it
1205 in a subdirectory called @file{manual}; the file
1206 @file{manual/index.html} should have a link to the manual in each of
1209 If the package has more than one manual, put each one in a
1210 subdirectory of @file{manual}, set up @file{index.html} in each
1211 subdirectory to link to that manual in all its forms, and make
1212 @file{manual/index.html} link to each manual through its subdirectory.
1214 See the section below for details on a script to make the job of
1215 creating all these different formats and index pages easier.
1217 We would like to include links to all these manuals in the page
1218 @url{http://www.gnu.org/manual}. Just send mail to
1219 @code{webmasters@@gnu.org} telling them the name of your package and
1220 asking them to edit @url{http://www.gnu.org/manual}, and they will do
1221 so based on the contents of your @file{manual} directory.
1224 * Invoking gendocs.sh::
1227 @node Invoking gendocs.sh
1228 @section Invoking @command{gendocs.sh}
1230 @cindex generating documentation output
1232 The script @command{gendocs.sh} eases the task of generating the
1233 Texinfo documentation output for your web pages
1234 section above. It has a companion template file, used as the basis
1235 for the html index pages. Both are available from the Texinfo CVS
1238 @uref{http://savannah.gnu.org/cgi-bin/viewcvs/texinfo/texinfo/util/gendocs.sh}
1239 @uref{http://savannah.gnu.org/cgi-bin/viewcvs/texinfo/texinfo/util/gendocs_template}
1242 Invoke the script like this, in the directory containing the Texinfo
1245 gendocs.sh @var{yourmanual} "GNU @var{yourmanual} manual"
1248 @noindent where @var{yourmanual} is the short name for your package.
1249 The script processes the file @file{@var{yourmanual}.texinfo} (or
1250 @file{.texi} or @file{.txi}). For example:
1254 # download gendocs.sh and gendocs_template
1255 gendocs.sh emacs "GNU Emacs manual"
1258 @command{gendocs.sh} creates a subdirectory @file{manual/} containing
1259 the manual generated in all the standard output formats: Info, HTML,
1260 DVI, and so on, as well as the Texinfo source. You then need to move
1261 all those files, retaining the subdirectories, into the web pages for
1264 You can specify the option @option{-o @var{outdir}} to override the
1265 name @file{manual}. Any previous contents of @var{outdir} will be deleted.
1267 The second argument, with the description, is included as part of the
1268 HTML @code{<title>} of the overall @file{manual/index.html} file. It
1269 should include the name of the package being documented, as shown.
1270 @file{manual/index.html} is created by substitution from the file
1271 @file{gendocs_template}. (Feel free to modify the generic template
1272 for your own purposes.)
1274 If you have several manuals, you'll need to run this script several
1275 times with different arguments, specifying a different output
1276 directory with @option{-o} each time, and moving all the output to
1277 your web page. Then write (by hand) an overall index.html with links
1278 to them all. For example:
1281 gendocs.sh -o texinfo texinfo "GNU Texinfo manual"
1282 gendocs.sh -o info info "GNU Info manual"
1283 gendocs.sh -o info-stnd info-stnd "GNU info-stnd manual"
1286 You can set the environment variables @env{MAKEINFO}, @env{TEXI2DVI},
1287 and @env{DVIPS} to control the programs that get executed, and
1288 @env{GENDOCS_TEMPLATE_DIR} to control where the
1289 @file{gendocs_template} file is found.
1291 Please email bug reports, enhancement requests, or other
1292 correspondence to @email{bug-texinfo@@gnu.org}.
1295 @node Ethical and Philosophical Consideration
1296 @chapter Ethical and Philosophical Consideration
1300 The GNU project takes a strong stand for software freedom. Many times,
1301 this means you'll need to avoid certain technologies when such
1302 technologies conflict with our ethics of software freedom.
1304 Software patents threaten the advancement of free software and freedom
1305 to program. For our safety (which includes yours), we try to avoid
1306 using algorithms and techniques that we know are patented in the US or
1307 elsewhere, unless the patent looks so absurd that we doubt it will be
1308 enforced, or we have a suitable patent license allowing release of free
1311 Beyond that, sometimes the GNU project takes a strong stand against a
1312 particular patented technology in order to encourage everyone to reject
1315 For example, the GIF file format is covered by the LZW software patent
1316 in the USA. A patent holder has threatened lawsuits against not only
1317 developers of software to produce GIFs, but even web sites that
1320 For this reason, you should not include GIFs in the web pages for your
1321 package, nor in the distribution of the package itself. It is ok for
1322 a GNU package to support displaying GIFs which will come into play if
1323 a user asks it to operate on one. However, it is essential to provide
1324 equal or better support for the competing PNG and JPG
1325 formats---otherwise, the GNU package would be @emph{pressuring} users
1326 to use GIF format, and that it must not do. More about our stand on
1327 GIF is available at @uref{http://www.gnu.org/philosophy/gif.html}.
1329 Software patents are not the only matter for ethical concern. A GNU
1330 package should not recommend use of any non-free program, nor should it
1331 require a non-free program (such as a non-free compiler or IDE) to
1332 build. Thus, a GNU package cannot be written in a programming language
1333 that does not have a free software implementation. Now that GNU/Linux
1334 systems are widely available, all GNU packages should function
1335 completely with the GNU/Linux system and not require any non-free
1336 software to build or function.
1338 A GNU package should not refer the user to any non-free documentation
1339 for free software. The need for free documentation to come with free
1340 software is now a major focus of the GNU project; to show that we are
1341 serious about the need for free documentation, we must not contradict
1342 our position by recommending use of documentation that isn't free.
1344 Finally, new issues concerning the ethics of software freedom come up
1345 frequently. We ask that GNU maintainers, at least on matters that
1346 pertain specifically to their package, stand with the rest of the GNU
1347 project when such issues come up.
1350 @chapter Terminology Issues
1353 This chapter explains a couple of issues of terminology which are
1354 important for correcting two widespread and important misunderstandings
1358 * Free Software and Open Source::
1362 @node Free Software and Open Source
1363 @section Free Software and Open Source
1364 @cindex free software
1366 @cindex movements, Free Software and Open Source
1368 The terms ``free software'' and ``open source'' are the slogans of two
1369 different movements which differ in their basic philosophy. The Free
1370 Software Movement is idealistic, and raises issues of freedom, ethics,
1371 principle and what makes for a good society. The Open Source Movement,
1372 founded in 1998, studiously avoids such questions. For more explanation,
1373 see @url{http://www.gnu.org/philosophy/free-software-for-freedom.html}.
1375 The GNU Project is aligned with the Free Software Movement. This
1376 doesn't mean that all GNU contributors and maintainers have to agree;
1377 your views on these issues are up to you, and you're entitled to express
1378 them when speaking for yourself.
1380 However, due to the much greater publicity that the Open Source Movement
1381 receives, the GNU Project needs to overcome a widespread mistaken
1382 impression that GNU is @emph{and always was} an activity of the Open
1383 Source Movement. For this reason, please use the term ``free
1384 software,'' rather than ``open source,'' in GNU software releases, GNU
1385 documentation, and announcements and articles that you publish in your
1386 role as the maintainer of a GNU package. A reference to the URL given
1387 above, to explain the difference, is a useful thing to include as well.
1390 @section GNU and Linux
1394 The GNU Project was formed to develop a free Unix-like operating system,
1395 GNU. The existence of this system is our major accomplishment.
1396 However, the widely used version of the GNU system, in which Linux is
1397 used as the kernel, is often called simply ``Linux''. As a result, most
1398 users don't know about the GNU Project's major accomplishment---or more
1399 precisely, they know about it, but don't realize it is the GNU Project's
1400 accomplishment and reason for existence. Even people who believe they
1401 know the real history often believe that the goal of GNU was to develop
1402 ``tools'' or ``utilities.''
1404 To correct this confusion, we have made a years-long effort to
1405 distinguish between Linux, the kernel that Linus Torvalds wrote, and
1406 GNU/Linux, the operating system that is the combination of GNU and
1407 Linux. The resulting increased awareness of what the GNU Project has
1408 already done helps every activity of the GNU Project recruit more
1409 support and contributors.
1411 Please make this distinction consistently in GNU software releases, GNU
1412 documentation, and announcements and articles that you publish in your
1413 role as the maintainer of a GNU package. If you want to explain the
1414 terminology and its reasons, you can refer to the URL
1415 @url{http://www.gnu.org/gnu/linux-and-gnu.html}.
1417 Do contrast the GNU system properly speaking to GNU/Linux, you can
1418 call it ``GNU/Hurd'' or ``the GNU/Hurd system.'' However, when that
1419 contrast is not specifically the focus, please call it just ``GNU'' or
1422 When referring to the collection of servers that is the higher level
1423 of the GNU kernel, please call it ``the Hurd'' or ``the GNU Hurd.''
1424 Note that this uses a space, not a slash.
1428 @cindex CVS repository
1433 We would like to recommend using @code{subversions.gnu.org} as the CVS
1434 repository for your package, and using @code{ftp.gnu.org} as the
1435 standard FTP site. It is ok to use other machines if you wish. If you
1436 use a company's machine to hold the repository for your program, or as
1437 its ftp site, please put this statement in a prominent place on the
1438 site, so as to prevent people from getting the wrong idea about the
1439 relationship between the package and the company:
1442 The programs <list of them> hosted here are free software packages
1443 of the GNU Project, not products of <company name>. We call them
1444 "free software" because you are free to copy and redistribute them,
1445 following the rules stated in the license of each package. For more
1446 information, see http://www.gnu.org/philosophy/free-sw.html.
1448 If you are looking for service or support for GNU software, see
1449 http://www.gnu.org/help/gethelp.html for suggestions of where to ask.
1451 If you would like to contribute to the development of one of these
1452 packages, contact the package maintainer or the bug-reporting address
1453 of the package (which should be listed in the package itself), or look
1454 on www.gnu.org for more information on how to contribute.
1457 @node Free Software Directory
1458 @chapter Free Software Directory
1459 @cindex Free Software Directory
1461 The Free Software Directory aims to be a complete list of free software
1462 packages, within certain criteria. Every GNU package should be listed
1463 there, so please contact @email{bug-directory@@gnu.org} to ask for
1464 information on how to write an entry for your package.
1466 @node Using the Proofreaders List
1467 @chapter Using the Proofreaders List
1468 @cindex proofreading
1470 If you want help finding errors in documentation,
1471 or help improving the quality of writing,
1472 or if you are not a native speaker of English
1473 and want help producing good English documentation,
1474 you can use the GNU proofreaders mailing list:
1475 @email{proofreaders@@gnu.org}.
1477 But be careful when you use the list,
1478 because there are over 200 people on it.
1479 If you simply ask everyone on the list to read your work,
1480 there will probably be tremendous duplication of effort
1481 by the proofreaders,
1482 and you will probably get the same errors reported 100 times.
1483 This must be avoided.
1485 Also, the people on the list do not want to get
1486 a large amount of mail from it.
1487 So do not ever ask people on the list to send mail to the list!
1489 Here are a few methods that seem reasonable to use:
1493 For something small, mail it to the list,
1494 and ask people to pick a random number from 1 to 20,
1495 and read it if the number comes out as 10.
1496 This way, assuming 50% response, some 5 people will read the piece.
1499 For a larger work, divide your work into around 20 equal-sized parts,
1500 tell people where to get it,
1501 and ask each person to pick randomly which part to read.
1503 Be sure to specify the random choice procedure;
1504 otherwise people will probably use a mental procedure
1505 that is not really random,
1506 such as "pick a part near the middle",
1507 and you will not get even coverage.
1509 You can either divide up the work physically, into 20 separate files,
1510 or describe a virtual division, such as by sections
1511 (if your work has approximately 20 sections).
1512 If you do the latter, be sure to be precise about it---for example,
1513 do you want the material before the first section heading
1514 to count as a section, or not?
1517 For a job needing special skills, send an explanation of it,
1518 and ask people to send you mail if they volunteer for the job.
1519 When you get enough volunteers, send another message to the list saying
1520 "I have enough volunteers, no more please."
1530 eval: (add-hook 'write-file-hooks 'time-stamp)
1531 time-stamp-start: "@set lastupdate "
1532 time-stamp-start: "@set lastupdate "
1534 time-stamp-format: "%:b %:d, %:y"
1535 compile-command: "make just-maintain"