Make the generated sys/stat.h more self-contained.
[gnulib.git] / doc / standards.texi
index 558746d..7414b05 100644 (file)
@@ -3,12 +3,12 @@
 @setfilename standards.info
 @settitle GNU Coding Standards
 @c This date is automagically updated when you save this file:
-@set lastupdate November 15, 2006
+@set lastupdate March 17, 2007
 @c %**end of header
 
 @dircategory GNU organization
 @direntry
-* Standards: (standards).        GNU coding standards.
+* Standards: (standards).         GNU coding standards.
 @end direntry
 
 @c @setchapternewpage odd
@@ -32,8 +32,9 @@
 @copying
 The GNU coding standards, last updated @value{lastupdate}.
 
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
+2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 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.2
@@ -105,7 +106,7 @@ diff to the @file{standards.texi} or @file{make-stds.texi} files, but if
 you don't have those files, please mail your suggestion anyway.
 
 These standards cover the minimum of what is important when writing a
-GNU package.  Likely, the needs for additional standards will come up.
+GNU package.  Likely, the need for additional standards will come up.
 Sometimes, you might suggest that such standards be added to this
 document.  If you think your standards would be generally useful, please
 do suggest them.
@@ -2201,10 +2202,14 @@ when writing GNU software.
 @cindex open brace
 @cindex braces, in C source
 It is important to put the open-brace that starts the body of a C
-function in column one, and avoid putting any other open-brace or
-open-parenthesis or open-bracket in column one.  Several tools look
-for open-braces in column one to find the beginnings of C functions.
-These tools will not work on code not formatted that way.
+function in column one, so that they will start a defun.  Several
+tools look for open-braces in column one to find the beginnings of C
+functions.  These tools will not work on code not formatted that way.
+
+Avoid putting open-brace, open-parenthesis or open-bracket in column
+one when they are inside a function, so that they won't start a defun.
+The open-brace that starts a @code{struct} body can go in column one
+if you find it useful to treat that definition as a defun.
 
 It is also important for function definitions to start the name of the
 function in column one.  This helps people to search for function
@@ -4010,11 +4015,25 @@ 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.
+depend on the parts of Sun's Java implementation which are not yet
+free software, 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.
+We hope this particular problem will be gone in a few months, when Sun
+makes the standard Java libraries free software, but of course the
+general principle remains: you should not recommend programs that
+depend on non-free software to run.
+
+Some free programs encourage the use of non-free software.  A typical
+example is @command{mplayer}.  It is free software in itself, and the
+free code can handle some kinds of files.  However, @command{mplayer}
+recommends use of non-free codecs for other kinds of files, and users
+that install @command{mplayer} are very likely to install those codecs
+along with it.  To recommend @command{mplayer} is, in effect, to
+recommend the non-free codecs.  We must not do that, so we cannot
+recommend @command{mplayer} either.
+
+In general, you should also not recommend programs that themselves
+strongly recommend the use of non-free software.
 
 A GNU package should not refer the user to any non-free documentation
 for free software.  Free documentation that can be included in free
@@ -4028,7 +4047,7 @@ 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
+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