# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
# 2000, 2001, 2002 Free Software Foundation, Inc.
-timestamp='2002-11-13'
+timestamp='2002-11-30'
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
;;
esac
# The OS release
- release=`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
+ # Debian GNU/NetBSD machines have a different userland, and
+ # thus, need a distinct triplet. However, they do not need
+ # kernel version information, so it can be replaced with a
+ # suitable tag, in the style of linux-gnu.
+ case "${UNAME_VERSION}" in
+ Debian*)
+ release='-gnu'
+ ;;
+ *)
+ release=`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
+ ;;
+ esac
# Since CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM:
# contains redundant information, the shorter form:
# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
echo ${UNAME_MACHINE}-pc-pw32
exit 0 ;;
x86:Interix*:3*)
- echo i386-pc-interix3
+ echo i586-pc-interix3
exit 0 ;;
[345]86:Windows_95:* | [345]86:Windows_98:* | [345]86:Windows_NT:*)
echo i${UNAME_MACHINE}-pc-mks
# How do we know it's Interix rather than the generic POSIX subsystem?
# It also conflicts with pre-2.0 versions of AT&T UWIN. Should we
# UNAME_MACHINE based on the output of uname instead of i386?
- echo i386-pc-interix
+ echo i586-pc-interix
exit 0 ;;
i*:UWIN*:*)
echo ${UNAME_MACHINE}-pc-uwin
EOF
eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^CPU=`
rm -f $dummy.c && rmdir $tmpdir
- test x"${CPU}" != x && echo "${CPU}-pc-linux-gnu" && exit 0
+ test x"${CPU}" != x && echo "${CPU}-unknown-linux-gnu" && exit 0
+ ;;
+ mips64:Linux:*:*)
+ eval $set_cc_for_build
+ sed 's/^ //' << EOF >$dummy.c
+ #undef CPU
+ #undef mips64
+ #undef mips64el
+ #if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL)
+ CPU=mips64el
+ #else
+ #if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB)
+ CPU=mips64
+ #else
+ CPU=
+ #endif
+ #endif
+EOF
+ eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^CPU=`
+ rm -f $dummy.c && rmdir $tmpdir
+ test x"${CPU}" != x && echo "${CPU}-unknown-linux-gnu" && exit 0
;;
ppc:Linux:*:*)
echo powerpc-unknown-linux-gnu
# Use sysv4.2uw... so that sysv4* matches it.
echo ${UNAME_MACHINE}-pc-sysv4.2uw${UNAME_VERSION}
exit 0 ;;
+ i*86:OS/2:*:*)
+ # If we were able to find `uname', then EMX Unix compatibility
+ # is probably installed.
+ echo ${UNAME_MACHINE}-pc-os2-emx
+ exit 0 ;;
+ i*86:XTS-300:*:STOP)
+ echo ${UNAME_MACHINE}-unknown-stop
+ exit 0 ;;
+ i*86:atheos:*:*)
+ echo ${UNAME_MACHINE}-unknown-atheos
+ exit 0 ;;
+ i*86:LynxOS:2.*:* | i*86:LynxOS:3.[01]*:* | i*86:LynxOS:4.0*:*)
+ echo i386-unknown-lynxos${UNAME_RELEASE}
+ exit 0 ;;
+ i*86:*DOS:*:*)
+ echo ${UNAME_MACHINE}-pc-msdosdjgpp
+ exit 0 ;;
i*86:*:4.*:* | i*86:SYSTEM_V:4.*:*)
UNAME_REL=`echo ${UNAME_RELEASE} | sed 's/\/MP$//'`
if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then
echo ${UNAME_MACHINE}-pc-sysv32
fi
exit 0 ;;
- i*86:*DOS:*:*)
- echo ${UNAME_MACHINE}-pc-msdosdjgpp
- exit 0 ;;
pc:*:*:*)
# Left here for compatibility:
# uname -m prints for DJGPP always 'pc', but it prints nothing about
exit 0 ;;
M68*:*:R3V[567]*:*)
test -r /sysV68 && echo 'm68k-motorola-sysv' && exit 0 ;;
- 3[34]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0)
+ 3[34]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0 | SDS2:*:4.0:3.0)
OS_REL=''
test -r /etc/.relid \
&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
mc68030:UNIX_System_V:4.*:*)
echo m68k-atari-sysv4
exit 0 ;;
- i*86:LynxOS:2.*:* | i*86:LynxOS:3.[01]*:* | i*86:LynxOS:4.0*:*)
- echo i386-unknown-lynxos${UNAME_RELEASE}
- exit 0 ;;
TSUNAMI:LynxOS:2.*:*)
echo sparc-unknown-lynxos${UNAME_RELEASE}
exit 0 ;;
fi
echo ${UNAME_MACHINE}-unknown-plan9
exit 0 ;;
- i*86:OS/2:*:*)
- # If we were able to find `uname', then EMX Unix compatibility
- # is probably installed.
- echo ${UNAME_MACHINE}-pc-os2-emx
- exit 0 ;;
*:TOPS-10:*:*)
echo pdp10-unknown-tops10
exit 0 ;;
*:ITS:*:*)
echo pdp10-unknown-its
exit 0 ;;
- i*86:XTS-300:*:STOP)
- echo ${UNAME_MACHINE}-unknown-stop
- exit 0 ;;
- i*86:atheos:*:*)
- echo ${UNAME_MACHINE}-unknown-atheos
- exit 0 ;;
esac
#echo '(No uname command or uname output not recognized.)' 1>&2
files and libraries. It is much cleaner to make other data files
architecture-independent, and it is generally not hard.
-Therefore, here are the variables Makefiles should use to specify
-directories:
+Here are the variables Makefiles should use to specify directories
+to put these various kinds of files in:
@table @samp
+@item datarootdir
+The root of the directory tree for read-only architecture-independent
+data files. This should normally be @file{/usr/local/share}, but
+write it as @file{$(prefix)/share}. @samp{datadir}'s default value is
+based on this variable; so are @samp{infodir}, @samp{mandir}, and others.
+
@item datadir
-The directory for installing read-only architecture independent data
-files. This should normally be @file{/usr/local/share}, but write it as
-@file{$(prefix)/share}.
-(If you are using Autoconf, write it as @samp{@@datadir@@}.)
-As a special exception, see @file{$(infodir)}
-and @file{$(includedir)} below.
+The directory for installing ideosyncratic read-only
+architecture-independent data files for this program. This is usually
+the same place as @samp{datarootdir}, but we use the two separate
+variables so that you can move these ideosyncratic files without
+altering the location for Info files, man pages, etc.
+
+The default definition of @samp{datadir} should be
+@file{$(datarootdir)}. (If you are using Autoconf, write it as
+@samp{@@datadir@@}.)
@item sysconfdir
The directory for installing read-only data files that pertain to a
should normally be @file{/usr/local/var}, but write it as
@file{$(prefix)/var}.
(If you are using Autoconf, write it as @samp{@@localstatedir@@}.)
+@end table
-@item libdir
-The directory for object files and libraries of object code. Do not
-install executables here, they probably ought to go in @file{$(libexecdir)}
-instead. The value of @code{libdir} should normally be
-@file{/usr/local/lib}, but write it as @file{$(exec_prefix)/lib}.
-(If you are using Autoconf, write it as @samp{@@libdir@@}.)
-
-@item infodir
-The directory for installing the Info files for this package. By
-default, it should be @file{/usr/local/info}, but it should be written
-as @file{$(prefix)/info}.
-(If you are using Autoconf, write it as @samp{@@infodir@@}.)
-
-@item lispdir
-The directory for installing any Emacs Lisp files in this package. By
-default, it should be @file{/usr/local/share/emacs/site-lisp}, but it
-should be written as @file{$(prefix)/share/emacs/site-lisp}.
-
-If you are using Autoconf, write the default as @samp{@@lispdir@@}.
-In order to make @samp{@@lispdir@@} work, you need the following lines
-in your @file{configure.in} file:
-
-@example
-lispdir='$@{datadir@}/emacs/site-lisp'
-AC_SUBST(lispdir)
-@end example
+These variables specify the directory for installing certain specific
+types of files, if your program has them. Every GNU package should
+have Info files, so every program needs @samp{infodir}, but not all
+need @samp{libdir} or @samp{lispdir}.
+@table @samp
@item includedir
@c rewritten to avoid overfull hbox --roland
The directory for installing header files to be included by user
To tell whether @file{foo.h} came from the Foo package, put a magic
string in the file---part of a comment---and @code{grep} for that string.
+
+@item infodir
+The directory for installing the Info files for this package. By
+default, it should be @file{/usr/local/share/info}, but it should be
+written as @file{$(datarootdir)/info}. (If you are using Autoconf,
+write it as @samp{@@infodir@@}.)
+
+@item libdir
+The directory for object files and libraries of object code. Do not
+install executables here, they probably ought to go in @file{$(libexecdir)}
+instead. The value of @code{libdir} should normally be
+@file{/usr/local/lib}, but write it as @file{$(exec_prefix)/lib}.
+(If you are using Autoconf, write it as @samp{@@libdir@@}.)
+
+@item lispdir
+The directory for installing any Emacs Lisp files in this package. By
+default, it should be @file{/usr/local/share/emacs/site-lisp}, but it
+should be written as @file{$(datarootdir)/emacs/site-lisp}.
+
+If you are using Autoconf, write the default as @samp{@@lispdir@@}.
+In order to make @samp{@@lispdir@@} work, you need the following lines
+in your @file{configure.in} file:
+
+@example
+lispdir='$@{datarootdir@}/emacs/site-lisp'
+AC_SUBST(lispdir)
+@end example
+
+@item localedir
+The directory for installing locale-specific message catalogs for this
+package. By default, it should be @file{/usr/local/share/locale}, but
+it should be written as @file{$(datarootdir)/locale}. (If you are
+using Autoconf, write it as @samp{@@localedir@@}.)
@end table
Unix-style man pages are installed in one of the following:
@table @samp
@item mandir
The top-level directory for installing the man pages (if any) for this
-package. It will normally be @file{/usr/local/man}, but you should
-write it as @file{$(prefix)/man}.
-(If you are using Autoconf, write it as @samp{@@mandir@@}.)
+package. It will normally be @file{/usr/local/share/man}, but you
+should write it as @file{$(datarootdir)/man}. (If you are using
+Autoconf, write it as @samp{@@mandir@@}.)
@item man1dir
The directory for installing section 1 man pages. Write it as
# Common prefix for installation directories.
# NOTE: This directory must exist when you start the install.
prefix = /usr/local
+datarootdir = $(prefix)/share
+datadir = $(datarootdir)
exec_prefix = $(prefix)
# Where to put the executable for the command `gcc'.
bindir = $(exec_prefix)/bin
# Where to put the directories used by the compiler.
libexecdir = $(exec_prefix)/libexec
# Where to put the Info files.
-infodir = $(prefix)/info
+infodir = $(datarootdir)/info
@end smallexample
If your program installs a large number of files into one of the
@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate October 19, 2001
+@set lastupdate November 23, 2002
@c %**end of header
-@ifinfo
-@format
-START-INFO-DIR-ENTRY
+@dircategory GNU organization
+@direntry
* Standards: (standards). GNU coding standards.
-END-INFO-DIR-ENTRY
-@end format
-@end ifinfo
+@end direntry
@c @setchapternewpage odd
@setchapternewpage off
@set CHAPTER node
@end ifinfo
-@ifinfo
-GNU Coding Standards
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+@copying
+The GNU coding standards, last updated @value{lastupdate}.
+
+Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
+2001, 2002 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
Front-Cover Texts, and with no Back-Cover Texts.
A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
-@end ifinfo
+@end copying
@titlepage
@title GNU Coding Standards
@author Richard Stallman, et al.
@author last updated @value{lastupdate}
@page
-
@vskip 0pt plus 1filll
-Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
-
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.1
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no
-Front-Cover Texts, and with no Back-Cover Texts.
-A copy of the license is included in the section entitled ``GNU
-Free Documentation License''.
+@insertcopying
@end titlepage
-@ifinfo
+@contents
+
+@ifnottex
@node Top, Preface, (dir), (dir)
@top Version
-Last updated @value{lastupdate}.
-@end ifinfo
+@insertcopying
+@end ifnottex
@menu
* Preface:: About the GNU Coding Standards
@cindex where to obtain @code{standards.texi}
@cindex downloading this manual
If you did not obtain this file directly from the GNU project and
-recently, please check for a newer version. You can ftp the GNU
-Coding Standards from any GNU FTP host in the directory
-@file{/pub/gnu/standards/}. The GNU Coding Standards are available
-there in several different formats: @file{standards.text},
-@file{standards.info}, and @file{standards.dvi}, as well as the
+recently, please check for a newer version. You can get the GNU
+Coding Standards from the GNU World Wide Web server host in several
+different formats: @uref{http://www.gnu.org/prep/standards.text},
+@uref{http://www.gnu.org/prep/standards.info}, and
+@uref{http://www.gnu.org/prep/standards.dvi}, as well as the
Texinfo ``source'' which is divided in two files:
-@file{standards.texi} and @file{make-stds.texi}. The GNU Coding
-Standards are also available on the GNU World Wide Web server:
+@uref{http://www.gnu.org/prep/standards.texi} and
+@uref{http://www.gnu.org/prep/make-stds.texi}. The GNU Coding
+Standards are also available in HTML format starting at
@uref{http://www.gnu.org/prep/standards_toc.html}.
Corrections or suggestions for this document should be sent to
to document them as much as possible. That way, your program will be
more maintainable by others.
+The GNU Hello program serves as an example of how to follow the GNU
+coding standards for a trivial program which prints @samp{Hello,
+world!}. @uref{http://www.gnu.org/software/hello/hello.html}.
+
@node Legal Issues
@chapter Keeping Free Software Free
@cindex legal aspects
@end example
@noindent
-If you want to mention the column number, use this format:
+If you want to mention the column number, use one of these formats:
@example
@var{source-file-name}:@var{lineno}:@var{column}: @var{message}
+@var{source-file-name}:@var{lineno}.@var{column}: @var{message}
+
@end example
@noindent
numbers assuming that space and all ASCII printing characters have
equal width, and assuming tab stops every 8 columns.
+The error message can also give both the starting and ending positions
+of the erroneous text. There are several formats so that you can
+avoid redundant information such as a duplicate line number.
+Here are the possible formats:
+
+@example
+@var{source-file-name}:@var{lineno-1}.@var{column-1}-@var{lineno-2}.@var{column-2}: @var{message}
+@var{source-file-name}:@var{lineno-1}.@var{column-1}-@var{column-2}: @var{message}
+@var{source-file-name}:@var{lineno-1}-@var{lineno-2}: @var{message}
+@end example
+
+@noindent
+When an error is spread over several files, you can use this format:
+
+@example
+@var{file-1}:@var{lineno-1}.@var{column-1}-@var{file-2}:@var{lineno-2}.@var{column-2}: @var{message}
+@end example
+
Error messages from other noninteractive programs should look like this:
@example
@item no-sort
@samp{-p} in @code{nm}.
+@item no-splash
+Don't print a startup splash screen.
+
@item no-split
Used in @code{makeinfo}.
The manual which discusses a program should certainly document all of
the program's command-line options and all of its commands. It should
-give examples of their use. But don't organize the manual as a list of
-features. Instead, organize it logically, by subtopics. Address the
-questions that a user will ask when thinking about the job that the
-program does.
+give examples of their use. But don't organize the manual as a list
+of features. Instead, organize it logically, by subtopics. Address
+the questions that a user will ask when thinking about the job that
+the program does. Don't just tell the reader what each feature can
+do---say what jobs it is good for, and show how to use it for those
+jobs. Explain what is recommended usage, and what kinds of usage
+users should avoid.
In general, a GNU manual should serve both as tutorial and reference.
It should be set up for convenient access to each topic through Info,
different from what we use in GNU manuals.
Please include an email address in the manual for where to report
-bugs @emph{in the manual}.
+bugs @emph{in the text of the manual}.
Please do not use the term ``pathname'' that is used in Unix
documentation; use ``file name'' (two words) instead. We use the term
``path'' only for search paths, which are lists of directory names.
-Please do not use the term ``illegal'' to refer to erroneous input to a
-computer program. Please use ``invalid'' for this, and reserve the term
-``illegal'' for activities punishable by law.
+Please do not use the term ``illegal'' to refer to erroneous input to
+a computer program. Please use ``invalid'' for this, and reserve the
+term ``illegal'' for activities prohibited by law.
@node Doc Strings and Manuals
@section Doc Strings and Manuals
@var{cpu}-@var{company}-@var{system}
@end example
-For example, a Sun 3 might be @samp{m68k-sun-sunos4.1}.
+For example, an Athlon-based GNU/Linux system might be
+@samp{i686-pc-linux-gnu}.
The @code{configure} script needs to be able to decode all plausible
-alternatives for how to describe a machine. Thus, @samp{sun3-sunos4.1}
-would be a valid alias. For many programs, @samp{vax-dec-ultrix} would
-be an alias for @samp{vax-dec-bsd}, simply because the differences
-between Ultrix and @sc{bsd} are rarely noticeable, but a few programs
-might need to distinguish them.
-@c Real 4.4BSD now runs on some Suns.
-
-There is a shell script called @file{config.sub} that you can use
+alternatives for how to describe a machine. Thus,
+@samp{athlon-pc-gnu/linux} would be a valid alias.
+There is a shell script called
+@uref{ftp://ftp.gnu.org/gnu/config/config.sub, @file{config.sub}}
+that you can use
as a subroutine to validate system types and canonicalize aliases.
+The @code{configure} script should also take the option
+@option{--build=@var{buildtype}}, which should be equivalent to a
+plain @var{buildtype} argument. For example, @samp{configure
+--build=i686-pc-linux-gnu} is equivalent to @samp{configure
+i686-pc-linux-gnu}. When the build type is not specified by an option
+or argument, the @code{configure} script should normally guess it
+using the shell script
+@uref{ftp://ftp.gnu.org/gnu/config/config.guess, @file{config.guess}}.
+
@cindex optional features, configure-time
Other options are permitted to specify in more detail the software
or hardware present on the machine, and include or exclude optional
system as both the host and the target, thus producing a program which
works for the same type of machine that it runs on.
+To compile a program to run on a host type that differs from the build
+type, use the configure option @option{--host=@var{hosttype}}, where
+@var{hosttype} uses the same syntax as @var{buildtype}. The host type
+normally defaults to the build type.
+
To configure a cross-compiler, cross-assembler, or what have you, you
should specify a target different from the host, using the configure
option @samp{--target=@var{targettype}}. The syntax for
look like this:
@example
-./configure @var{hosttype} --target=@var{targettype}
+./configure --host=@var{hosttype} --target=@var{targettype}
@end example
+The target type normally defaults to the host type.
Programs for which cross-operation is not meaningful need not accept the
@samp{--target} option, because configuring an entire operating system for
cross-operation is not a meaningful operation.
-Bootstrapping a cross-compiler requires compiling it on a machine other
-than the host it will run on. Compilation packages accept a
-configuration option @samp{--build=@var{buildtype}} for specifying the
-configuration on which you will compile them, but the configure script
-should normally guess the build machine type (using
-@file{config.guess}), so this option is probably not necessary. The
-host and target types normally default from the build type, so in
-bootstrapping a cross-compiler you must specify them both explicitly.
-
Some programs have ways of configuring themselves automatically. If
your program is set up to do this, your @code{configure} script can simply
ignore most of its arguments.
@cindex references to non-free material
A GNU program should not recommend use of any non-free program. We
-can't stop some people from writing proprietary programs, or stop other
-people from using them. But we can and should avoid helping to
-advertise them to new customers.
-
-Sometimes it is important to mention how to build your package on top of
-some non-free operating system or other non-free base package. In such
-cases, please mention the name of the non-free package or system in the
-briefest possible way. Don't include any references for where to find
-more information about the proprietary program. The goal should be that
-people already using the proprietary program will get the advice they
-need about how to use your free program, while people who don't already
-use the proprietary program will not see anything to encourage them to
-take an interest in it.
-
-Likewise, a GNU package should not refer the user to any non-free
-documentation for free software. The need for free documentation to go
-with free software is now a major focus of the GNU project; to show that
-we are serious about the need for free documentation, we must not
-undermine our position by recommending use of documentation that isn't
-free.
+can't stop some people from writing proprietary programs, or stop
+other people from using them, but we can and should refuse to
+advertise them to new potential customers. Proprietary software is a
+social and ethical problem, and the point of GNU is to solve that
+problem.
+
+The GNU definition of free software is found in
+@url{http://www.gnu.org/philosophy/free-sw.html}, with a list of
+important licenses and whether they qualify as free in
+@url{http://www.gnu.org/licenses/license-list.html}. The terms
+``free'' and ``non-free'', used in this document, refer to that
+definition. If it is not clear whether a license qualifies as free
+under this definition, please ask the GNU Project by writing to
+@email{licensing@@gnu.org}. We will answer, and if the license is an
+important one, we will add it to the list.
+
+When a non-free program or system is well known, you can mention it in
+passing---that is harmless, since users who might want to use it
+probably already know about it. For instance, it is fine to explain
+how to build your package on top of some widely used non-free
+operating system, or how to use it together with some widely used
+non-free program.
+
+However, you should give only the necessary information to help those
+who already use the non-free program to use your program with
+it---don't give, or refer to, any further information about the
+proprietary program, and don't imply that the proprietary program
+enhances your program, or that its existence is in any way a good
+thing. The goal should be that people already using the proprietary
+program will get the advice they need about how to use your free
+program with it, while people who don't already use the proprietary
+program will not see anything to lead them to take an interest in it.
+
+If a non-free program or system is obscure in your program's domain,
+your program should not mention or support it at all, since doing so
+would tend to popularize the non-free program more than it popularizes
+your program. (You cannot hope to find many additional users among
+the users of Foobar if the users of Foobar are few.)
+
+Sometimes a program is free software in itself but depends on a
+non-free platform in order to run. For instance, many Java programs
+depend on Sun's Java implementation, and won't run on the GNU Java
+Compiler (which does not yet have all the features) or won't run with
+the GNU Java libraries. To recommend that program is inherently to
+recommend the non-free platform as well; if you should not do the
+latter, then don't do the former.
+
+A GNU package should not refer the user to any non-free documentation
+for free software. Free documentation that can be included in free
+operating systems is essential for completing the GNU system, or any
+free operating system, so it is a major focus of the GNU Project; to
+recommend use of documentation that we are not allowed to use in GNU
+would weaken the impetus for the community to produce documentation
+that we can include. So GNU packages should never recommend non-free
+documentation.
+
+By contrast, it is ok to refer to journal articles and textbooks in
+the comments of a program for explanation of how it functions, even
+though they be non-free. This is because we don't include such things
+in the GNU system even if we are allowed to--they are outside the
+scope of an operating system project.
+
+Referring to a web site that describes or recommends a non-free
+program is in effect promoting that software, so please do not make
+links (or mention by name) web sites that contain such material. This
+policy is relevant particulary for the web pages for a GNU package.
+
+Following links from nearly any web site can lead to non-free
+software; this is an inescapable aspect of the nature of the web, and
+in itself is no objection to linking to a site. As long as the site
+does not itself recommend a non-free program, there is no need be
+concerned about the sites it links to for other reasons.
+
+Thus, for example, you should not make a link to AT&T's web site,
+because that recommends AT&T's non-free software packages; you should
+not make a link to a site that links to AT&T's site saying it is a
+place to get a non-free program; but if a site you want to link to
+refers to AT&T's web site in some other context (such as long-distance
+telephone service), that is not a problem.
@node Copying This Manual
@appendix Copying This Manual
@unnumbered Index
@printindex cp
-@contents
-
@bye
-@c Local variables:
-@c eval: (add-hook 'write-file-hooks 'time-stamp)
-@c time-stamp-start: "@set lastupdate "
-@c time-stamp-end: "$"
-@c time-stamp-format: "%:b %:d, %:y"
-@c compile-command: "make just-standards"
-@c End:
+
+Local variables:
+eval: (add-hook 'write-file-hooks 'time-stamp)
+time-stamp-start: "@set lastupdate "
+time-stamp-end: "$"
+time-stamp-format: "%:b %:d, %:y"
+compile-command: "make just-standards"
+End:
projects / thirdparty / autoconf.git / commitdiff
