『GNU Coding Standards』は、GNUプロジェクトのソフトウェアを書く際のスタイルと規約に関する文書です。この文書は、GNUプロジェクトのソフトウェアが一貫性を持ち、保守が容易になるようにするためのものです。

第1章「About the GNU Coding Standards」は、この文書が何であるか、その目的と目標について説明しています。この章では、GNUプロジェクトのプログラムのソースコードの書き方に関する規則が定められており、それらがどのように適用されるかについて説明されています。

第2.1節「Referring to Proprietary Programs」では、GNUプロジェクトのソフトウェアを書く際に、Unixや他のプロプライエタリなプログラムのソースコードを参照しないようにという指示があります。

第2.2節「Accepting Contributions」は、他の人からのコードの寄付について説明しています。Free Software Foundationによって著作権が保護されているプログラムについては、他の人がプログラムに追加するためのコードを送信した場合、その使用には法的な書類が必要です。これは、最初にあなたが署名した書類と同様です。

第2.3節「Trademarks」では、GNUソフトウェアパッケージやドキュメントにおける商標の扱いについて説明されています。この節では、商標の承認を含めないように求められています。商標の承認とは、そのようなものがそのような人の商標であるという声明のことです。GNUプロジェクトは、商標の基本的な考え方には異論はありませんが、これらの承認は屈辱的なものであり、法的に必要ではないため、使用していません。他人の商標に関して法的に求められることは、それらを読者が自分たちのプログラムや活動の名前やラベルとして理解する可能性がある方法で使用しないことです。例えば、「Objective C」が（少なくとも以前は）商標であるため、私たちは「Objective C言語用コンパイラ」を提供することを確実にしましたが、「Objective Cコンパイラ」とは言いませんでした。後者は前者を短く言い換えたものとして意図されましたが、それは関係を明確に述べていないため、コンパイラではなく言語のラベルとして「Objective C」を使用していると誤解される可能性があります。

また、GNUソフトウェアやドキュメントでは、「win」をMicrosoft Windowsの略称として使用しないでください。ハッカー用語では、「win」と呼ぶことは賞賛の形です。あなた自身がMicrosoft Windowsを賞賛したい場合は自由ですが、GNUパッケージではそうしないでください。代わりに、「Windows」とフルスペルするか、「w.」と略してください。

第3章「General Program Design」では、プログラムの設計に関する一般的なアドバイスが提供されています。この章では、使用する言語、他の実装との互換性、非標準機能の使用、標準Cおよび非標準C、条件付きコンパイルなどについて説明されています。

第3.1節「Which Languages to Use」については、残念ながら私の検索結果には詳細な情報がありません。ただし、この章は一般的なプログラム設計に関するものであり、使用する言語についてのガイドラインが含まれていると思われます。

第3.2節「Compatibility with Other Implementations」では、GNUプログラムとライブラリが他の実装との互換性について説明されています。この節では、GNUのユーティリティプログラムとライブラリは、Berkeley Unix、Standard C、およびPOSIXと上位互換性があるべきであると述べられています。ただし、例外もあります。

第3.3節「Using Non-standard Features」については、既存の多くのGNU機能が、比較可能なUnix機能よりも便利な拡張機能をサポートしていることが記載されています。プログラムの実装にこれらの拡張機能を使用するかどうかは難しい問題です。一方で、拡張機能を使用することで、よりクリーンなプログラムを作成できます。

第3.4節「Standard C and Pre-Standard C」では、C言語の標準と非標準について説明されています。この節では、1989年のStandard Cが広く普及しているため、その機能をプログラムで使用することができると述べられています。ただし、「trigraph」機能は使用しないでください。また、1999年および2011年の版についても言及されています。

第3.5節「Conditional Compilation」では、条件付きコンパイルについて説明されています。この節では、プログラムのビルド時に既知の設定オプションをサポートする場合、条件付きコンパイルよりもif文を使用することが推奨されています。これは、前者の場合、コンパイラがすべての可能なコードパスをより広範囲にチェックできるためです。例えば、if (HAS_FOO) ... else ...と書くことが推奨されており、#ifdef HAS_FOO ... #else ... #endifと書くことは推奨されていません。現代のコンパイラ（例えばGCC）は、両方の場合でまったく同じコードを生成します。

もちろん、この方法はすべての移植性問題を解決する銀の弾丸ではありませんし、常に適切ではありませんが、この方針に従うことで、GCC開発者は1年に多くの時間、あるいは数日を節約できるでしょう。

第4章「Program Behavior for All Programs」では、堅牢なソフトウェアの作成に関する規則が提供されています。この章では、エラーメッセージ、コマンドラインインターフェース、ライブラリの動作に関する一般的な規則が説明されています。

第4.1節「Non-GNU Standards」では、他の組織が発行した標準について説明されています。GNUプロジェクトは、他の組織が発行した標準を提案として扱い、命令としては扱いません。そのような標準を考慮しますが、「従う」わけではありません。GNUプログラムを開発する際には、それが客観的な意味でGNUシステム全体を改善する場合に、外部標準の仕様を実装するべきです。そうでない場合は、実装しないでください。

ほとんどの場合、公開された標準に従うことはユーザーにとって便利です。それは、彼らのプログラムやスクリプトがより移植性が高くなることを意味します。例えば、GCCはStandard Cのほぼすべての機能をその標準に従って実装しています。Cプログラム開発者は、そうでなければ不満を持つでしょう。また、GNUユーティリティは主にPOSIX.2の仕様に従っています。シェルスクリプト作成者やユーザーは、私たちのプログラムが互換性がなければ不満を持つでしょう。しかし、私たちはこれらの仕様を厳密には守っておらず、ユーザーにとってGNUシステムをより良くするために従わなかった特定のポイントがあります。

第4.2節「Writing Robust Programs」では、堅牢なプログラムの作成について説明されています。この節では、ファイル名、行、ファイル、シンボルなどのデータ構造の長さや数に任意の制限を設けず、すべてのデータ構造を動的に割り当てることが推奨されています。ほとんどのUnixユーティリティでは、「長い行は黙って切り捨てられる」ものですが、これはGNUユーティリティでは受け入れられません。

第4.3節「Library Behavior」では、ライブラリの動作について説明されています。この節では、ライブラリ関数を再入可能^[1]にするよう努力することが推奨されています。動的なストレージ割り当てが必要な場合でも、少なくともmalloc自体以外の非再入性^[1:1]を避けるようにしてください。また、名前の衝突を避けるためのライブラリの特定の名前規則があります。ライブラリの名前接頭辞を2文字以上で選択します。すべての外部関数および変数名は、この接頭辞で始まる必要があります。さらに、任意のライブラリメンバーには、これらのうち1つだけが存在する必要があります。これは通常、それぞれを別々のソースファイルに配置することを意味します。ただし、2つの外部シンボルが常に一緒に使用される場合（つまり、合理的なプログラムが一方を使用せずに他方を使用することができない場合）は、例外として両方を同じファイルに配置することができます。ユーザーのエントリポイントとして文書化されていない外部シンボルは、「 _ 」で始まる名前を持つ必要があります。「 _ 」の後には、ライブラリの選択された名前接頭辞が続く必要があります。これは他のライブラリとの衝突を防ぐためです。これらは、好きなようにユーザーエントリポイントと同じファイルに配置することができます。静的関数および変数は好きなように使用でき、命名規則に従う必要はありません。

第4.4節「Formatting Error Messages」については、エラーメッセージの書式についてのガイドラインが記載されています。コンパイラからのエラーメッセージは、次のような形式であるべきです: source-file-name: lineno: message。他の非対話型プログラムからのエラーメッセージは、適切なソースファイルがある場合は次のような形式であるべきです: program: source-file-name: lineno: message。適切なソースファイルがない場合は、次のような形式であるべきです: program: message。

対話型プログラム（端末からコマンドを読み取るもの）では、エラーメッセージにプログラム名を含めることは避けた方が良いでしょう。プログラム名を表示する場所は、プロンプトまたは画面レイアウトです。（同じプログラムが端末以外のソースから入力を受け取る場合、それは非対話型であり、非対話型スタイルを使用してエラーメッセージを出力することが最善です）。

message文字列は、プログラム名および/またはファイル名に続く場合、大文字で始まってはいけません。また、ピリオドで終わってはいけません。対話型プログラムからのエラーメッセージや使用方法メッセージなどの他のメッセージは、大文字で始まるべきです。ただし、ピリオドで終わってはいけません。

第4.5節「Standards for Interfaces Generally」については、残念ながら私の検索結果には詳細な情報がありません。ただし、この章は一般的なインターフェースに関するものであり、インターフェースの設計に関するガイドラインが含まれていると思われます。

第4.6節「Finding the Program’s Executable and Associated Files」では、プログラムが実行可能ファイルと関連ファイルを見つける方法について説明されています。プログラムは、同じプログラムを再起動するために、実行された実行可能ファイルを見つける必要があります。また、実行時に使用するソースファイルやビルドによって構築されたファイルなどの関連ファイルを見つける必要があります。それらを見つける方法は、argv[0]を見ることから始まります。その文字列にスラッシュが含まれている場合、それは実行可能ファイルのファイル名であり、そのディレクトリ部分は実行可能ファイルが含まれていたディレクトリです。これは、プログラムがPATHを介して見つからなかった場合（通常、ビルドされていないがインストールされていない場合）であり、ビルドディレクトリから実行されます。プログラムはargv[0]のファイル名を使用して自分自身を再起動し、そのディレクトリ部分で関連ファイルを探すことができます。そのファイル名が絶対的でない場合、それはプログラムが開始された作業ディレクトリに対して相対的です。argv[0]にスラッシュが含まれていない場合、それはPATH経由で実行可能なコマンド名です。プログラムはその名前をPATH内のディレクトリで検索し、.をプログラムが開始されたときの現在の作業ディレクトリとして解釈します。この手順で実行可能なものが見つかった場合、それが見つかったディレクトリを呼び出しディレクトリと呼びます。プログラムはそのディレクトリ内に必要な関連ファイルの存在を確認する必要があります。プログラムの実行可能ファイルが通常メインビルドディレクトリのサブディレクトリ内にビルドされ、メインビルドディレクトリに関連ファイル（サブディレクトリも含む）が含まれている場合、プログラムは呼び出しディレクトリの親を見て、メインビルドディレクトリに含まれるべき関連ファイルおよびサブディレクトリの存在を確認する必要があります。呼び出しディレクトリに必要なものが含まれていなくても、実行可能なファイル名がシンボリックリンクである場合、プログラムは呼び出しディレクトリとしてリンクターゲットの含むディレクトリを使用することもできます。この手順で有効な呼び出しディレクトリが得られなかった場合（通常PATH経由で見つかったインストール済みプログラムの場合）、プログラムはそのプログラムのmakefileがインストールするディレクトリ内で関連ファイルを探す必要があります。

argv[0]に有効な情報を提供することは、慣習であり、保証されていません。他のプログラムを起動するよく振る舞うプログラム（シェルなど）は、慣習に従います。あなたのコードも、他のプログラムを起動するときにそれに従うべきです。ただし、常にプログラムを起動してargv[0]に無意味な値を与えることができます。したがって、実行可能ファイルやその他の関連ファイルの場所を知る必要があるプログラムは、ユーザーがそれらの場所を明示的に指定するための環境変数を提供するべきです。そのような方法で呼び出されたときに関連ファイルや自身の実行可能ファイルを発見するプログラムに特別な権限（setuidビットなど）を与えないでください。その権限を、/usrや/etcなどのハードコーディングされたインストール済み場所で関連ファイルを見つけるプログラムに限定してください。

第4.7節「Standards for Graphical Interfaces」については、グラフィカルユーザーインターフェースを提供するプログラムを作成する場合、X Window Systemを使用し、GTK+ツールキットまたはGNUstepツールキットを使用してください。ただし、機能が特定の代替手段（たとえば、「コンソールモードでjpeg画像を表示する」）を必要とする場合は除きます。

第4.8節「Standards for Command Line Interfaces」では、プログラムのコマンドラインオプションについてのPOSIXガイドラインに従うことが推奨されています。これを実現する最も簡単な方法は、getoptを使用してパースすることです。ただし、GNU版のgetoptは、特別な引数「--」が使用されない限り、通常は引数の中でどこでもオプションを許可します。これはPOSIXが指定するものではありません。これはGNU拡張です。単一文字のUnixスタイルのオプションと同等の長い名前のオプションを定義してください。このようにして、GNUをよりユーザーフレンドリーにすることを期待しています。これは、GNU関数getopt_longを使用することで簡単に実現できます。長い名前のオプションの利点の1つは、プログラム間で一貫性があることです。たとえば、「verbose」オプションを持つ任意のGNUプログラムは、「--verbose」と正確に綴られることをユーザーが期待できるべきです。この一貫性を実現するために、プログラムのオプション名を選択するときに、共通の長いオプション名のテーブルを参照してください（Option Table参照）。通常、普通の引数として与えられたファイル名は入力ファイルだけであり、出力ファイルはオプション（できれば「-o」または「--output」）を使用して指定されるべきです。互換性のために普通の引数として出力ファイル名を許可する場合でも、別の方法としてオプションも提供しようとします。これにより、GNUユーティリティ間でより一貫性があり、ユーザーが覚える必要がある特殊性が少なくなります。すべてのプログラムは2つの標準オプション「--version」と「--help」をサポートする必要があります。CGIプログラムは、これらをコマンドラインオプションとして受け入れるべきですが、PATH_INFOとして与えられた場合も受け入れるべきです。たとえば、「http://example.org/p.cgi/--help」をブラウザで訪問すると、「p.cgi --help」をコマンドラインから起動した場合と同じ情報が出力されます。^[1]

第4.9節「Standards for Dynamic Plug-in Interfaces」では、フリープログラムをフリーに保つための別の側面として、フリープラグインの開発を促進し、プロプライエタリプラグインの開発を抑制することが説明されています。多くのGNUプログラムは、プラグインのようなものをまったく持たないでしょうが、持つものはこれらの実践に従うべきです。

第4.10節「Table of Long Options」には、GNUプログラムで使用される長いオプションの一覧があります。それは確実に不完全ですが、新しいプログラムが互換性を持つことを望むすべてのオプションをリストすることを目指しています。表にない名前を使用する場合は、その意味とともにリストを送信してください。そうすれば、表を更新できます。

例えば、after-dateはtarの-Nオプションに対応し、allはdu、ls、nm、stty、unameおよびunexpandの-aオプションに対応し、all-textはdiffの-aオプションに対応します。

第4.11節「OID Allocations」では、OID（オブジェクト識別子）1.3.6.1.4.1.11591がGNUプロジェクトに割り当てられていることが説明されています（Sergey Poznyakoffに感謝します）。これらは、SNMP、LDAP、X.509証明書などに使用されます。Webサイトhttps://www.alvestrand.no/objectidには、多くのOID割り当ての（自発的な）リストがあります。新しいスロットがGNUパッケージに必要な場合は、maintainers@gnu.orgに書いてください。現在割り当てられているアークのリストは次のとおりです。1.3.6.1.4.1.11591 GNU 1.3.6.1.4.1.11591.1 GNU Radius 1.3.6.1.4.1.11591.2 GnuPG 1.3.6.1.4.1.11591.2.1 notation 1.3.6.1.4.1.11591.2.1.1 pkaAddress 1^[1]

第4.12節「Memory Usage」では、プログラムが通常数メガバイトのメモリしか使用しない場合、メモリ使用量を減らすための努力をする必要はありません。例えば、他の理由で数メガバイト以上のファイルを操作することが実用的でない場合、入力ファイル全体をメモリに読み込んで操作することが妥当です。ただし、catやtailのような非常に大きなファイルを有用に操作できるプログラムでは、ファイルサイズを人為的に制限する技術を使用しないようにすることが重要です。プログラムが行単位で動作し、任意のユーザー提供の入力ファイルに適用される場合、メモリ内に1行だけ保持する必要があります。これは非常に難しくなく、ユーザーは一度にメモリ内に収まるより大きい入力ファイルを操作できるようにしたいからです。プログラムが複雑なデータ構造を作成する場合は、それらをメモリ内に作成し、mallocがNULLを返した場合は致命的なエラーを発生させます。valgrindなどのメモリ解析ツールは便利ですが、その偽警報を回避するためだけにプログラムを複雑化しないでください。例えば、メモリがプロセス終了直前まで使用される場合、そのようなツールを黙らせるためだけに解放しないでください。

第4.13節「File Usage」では、プログラムがファイルを使用する方法について説明されています。プログラムがファイルを作成する場合、それらはユーザーが指定した場所に作成されるべきです。

第5章「Making The Best Use of C」では、GNUソフトウェアを書く際にC言語を最適に使用する方法についてのアドバイスが提供されています。この章には、ソースコードのフォーマット、コメントの付け方、C言語の構文のクリーンな使用方法、変数・関数・ファイルの命名方法などが含まれています。

第5.1節「Formatting Your Source Code」では、ソースコードのフォーマットについての指示があります。この節では、ソース行の長さを79文字以下にすること、C関数の本体を開始するオープンブレースを1列目に配置することなどが指示されています。

第5.2節「Commenting Your Work」では、コメントの付け方についての指示があります。この節では、プログラムの冒頭にそのプログラムが何のためのものかを簡潔に説明するコメントを付けること、各ソースファイルの冒頭にそのファイル名とそのファイルの全体的な目的についての簡潔なコメントを付けることなどが指示されています。

第5.3節「Clean Use of C Constructs」では、C言語の構文をクリーンに使用する方法についての指示があります。この節では、すべてのオブジェクトの型を明示的に宣言すること、関数の引数をすべて明示的に宣言すること、関数がintを返す場合はintを省略せずに明示的に宣言することなどが指示されています。

第5.4節「Naming Variables, Functions, and Files」では、変数、関数、ファイルの命名方法についての指示があります。この節では、プログラム内のグローバル変数や関数の名前は、その変数や関数の意味について有用な情報を提供するような名前を選ぶこと、ローカル変数の名前は短くてもよいこと、記号名において略語の使用を控えることなどが指示されています。

第5.5節「Portability between System Types」では、異なるシステム間での移植性についての指示があります。この節では、GNUプログラムにとって、異なるUnixバージョンへの移植性は望ましいが最優先事項ではないこと、GNUプログラムの主な目的は、GNUカーネル上で、GNU Cコンパイラでコンパイルされ、さまざまな種類のCPUで実行されることであることが説明されています。

第5.6節「Portability between CPUs」では、異なるCPU間での移植性についての指示があります。この節では、GNUシステムでも、CPUの種類による違い（たとえば、バイト順序やアラインメント要件の違い）があるため、これらの違いを処理することが絶対に必要であることが説明されています。

第5.7節「Calling System Functions」では、システム関数の呼び出しについての指示があります。この節では、Cの実装が大きく異なり、多くのシステムがANSI/ISO C89の完全な実装を欠いていた歴史的背景が説明されています。しかし、現在では、すべての実用的なシステムにC89コンパイラがあり、GNU CはC99のほとんどとC11の一部をサポートしています。同様に、ほとんどのシステムはPOSIX.1-2001ライブラリとツールを実装しており、多くはPOSIX.1-2008を実装しています。そのため、古いCや非POSIXシステムをサポートする理由はほとんどありません。

第5.8節「Internationalization」では、プログラムのメッセージを様々な言語に翻訳することが容易になるように、GNU gettextと呼ばれるライブラリが紹介されています。このライブラリは、すべてのプログラムで使用することが推奨されています。プログラム内のメッセージは英語で記述し、gettextがそれらを他の言語に翻訳する方法を提供します。

第5.9節「Character Set」では、ソースコードのコメント、テキスト文書、その他の文脈でASCII文字セット（プレーンテキスト、7ビット文字）を使用することが推奨されています。ただし、アプリケーションドメインにより何か他のことをする理由がある場合は除きます。例えば、ソースコードがフランス革命暦を扱う場合、「Floréal」のような月名にアクセント付き文字が含まれるリテラル文字列は問題ありません。また、変更ログ（Change Logs）で貢献者の正式名称を表すために非ASCII文字を使用することもOKです（ただし必須ではありません）。

第5.10節「Quote Characters」では、ユーザーへのメッセージにおいて、引用符としてASCII文字セット（プレーンテキスト、7ビット文字）を使用することが推奨されています。開き引用符と閉じ引用符の両方に、0x22（「 " 」）または0x27（「 ' 」）が好ましいとされています。ただし、GNUプログラムは伝統的に0x60（「 ` 」）を開き引用符、0x27（「 ' 」）を閉じ引用符として使用していましたが、現在では「 `like this' 」のような引用符は通常非対称にレンダリングされるため、「 "like this" 」または「 'like this' 」のように引用する方が見栄えが良くなります。

第5.11節「Mmap」では、ファイルの読み書きにmmapを使用する場合、すべてのファイルで動作するとも、すべてのファイルで失敗するとも仮定しないようにという指示があります。mmapは、特定のファイルで使用しようとした場合にのみ動作するか失敗するかが決まります。mmapが動作しない場合は、readやwriteを使用して別の方法で処理を行うようにフォールバックする必要があります。この注意が必要な理由は、GNUカーネル（HURD）がユーザー拡張可能なファイルシステムを提供しており、「通常のファイル」の種類が多く存在するためです。多くのファイルはmmapをサポートしていますが、一部はサポートしていません。プログラムがこれらすべての種類のファイルを処理できるようにすることが重要です。

第6章「Documenting Programs」では、プログラムの文書化について説明されています。この章には、GNUマニュアル、ドック文字列とマニュアル、マニュアルの構造の詳細、マニュアルのライセンス、マニュアルのクレジット、印刷されたマニュアル、NEWSファイル、変更ログ、manページ、他のマニュアルの読み方などが含まれています。

第6.1節「GNU Manuals」では、GNUシステムの推奨文書形式としてTexinfo形式が紹介されています。すべてのGNUパッケージには、参照用および学習者用にTexinfoで文書化されたものが（理想的には）あるべきです。Texinfoを使用すると、TeXを使用して良質な書籍を作成し、Infoファイルを生成することができます。また、TexinfoソースからHTML出力を生成することもできます。

第6.2節「Doc Strings and Manuals」では、Emacsのようなプログラミングシステムが、各関数、コマンド、変数に対して文書文字列を提供することがあります。文書文字列をコンパイルして、それらの周りに少しの追加テキストを書いてリファレンスマニュアルを作成することに誘惑されるかもしれませんが、それは絶対にしてはいけません。そのアプローチは根本的な間違いです。よく書かれた文書文字列のテキストは、マニュアルには全く不適切です。文書文字列は単独で存在する必要があります。画面に表示されるとき、それを紹介または説明する他のテキストはありません。一方、スタイルはかなり非公式で構いません。マニュアル内の関数または変数の説明は単独で存在してはいけません。それはセクションまたはサブセクションの文脈内に表示されます。セクションの最初の他のテキストがいくつかの概念を説明し、複数の関数または変数に適用される一般的なポイントをしばしば述べるべきです。セクション内の関数および変数の以前の説明も、トピックに関する情報を提供します。単独で存在するように書かれた説明では、その情報の一部を繰り返します。この冗長性は悪い見え方をします。一方、文書文字列で許容される非公式さは、マニュアルでは完全に許容されません。文書文字列を使用して良質なマニュアルを作成する唯一の良い方法は、良質なテキストを作成するための情報源として使用することです。

第6.3節「Manual Structure Details」では、マニュアルの構造についての詳細が説明されています。マニュアルの表紙には、マニュアルで文書化されているプログラムまたはパッケージのバージョンが記載されるべきです。マニュアルのTopノードにもこの情報が含まれるべきです。マニュアルがプログラムとは独立して、またはより頻繁に変更される場合、両方の場所にマニュアルのバージョン番号も記載してください。マニュアル内の各プログラムには、「program Invocation」または「Invoking program」という名前のノードがあるべきです。このノード（およびそのサブノード（あれば））は、プログラムのコマンドライン引数と実行方法（manページで探すような情報）を説明するべきです。すべてのオプションと引数を使用するテンプレートを含む「@example」から始めます。代わりに、いずれかのメニューに上記パターンのいずれかに適合する項目名を持つメニュー項目を配置します。これは、その項目が指すノードを、そのノードの実際の名前に関係なく、この目的のためのノードとして識別します。Infoリーダーの「--usage」機能は、関連するテキストを見つけるためにこのようなノードまたはメニュー項目を探します。そのため、すべてのTexinfoファイルにはそれが必要です。1つのマニュアルが複数のプログラムを説明する場合、それぞれのプログラムに対してそのようなノードがあるべきです。

第6.4節「License for Manuals」では、GNU Free Documentation License（GNU FDL）が、数ページ以上のすべてのGNUマニュアルに使用することが推奨されています。同様に、短い文書のコレクションについても、コレクション全体に1つのGNU FDLのコピーだけが必要です。単一の短い文書については、長いライセンスでスペースを取らないように、非常に寛容な非コピーレフトライセンスを使用することができます。GFDLの使用方法についての詳しい説明は、https://www.gnu.org/copyleft/fdl-howto.html を参照してください。GPLまたはLGPLでもないライセンスを持つマニュアルにGNU GPLまたはGNU LGPLのコピーを含めることは義務ではありません。大型のマニュアルではプログラムのライセンスを含めることが良い考えです。プログラムのライセンスを含めることでサイズが大幅に増加する短いマニュアルでは、それを含めない方が良いでしょう。

第6.5節「Manual Credits」では、マニュアルの表紙に、マニュアルの主要な人間の著者として著者をクレジットするよう求められています。企業が作業をスポンサーした場合は、マニュアルの適切な場所で企業に感謝しますが、企業を著者として引用しないでください。

第6.6節「Printed Manuals」では、FSFがいくつかのGNUマニュアルを印刷形式で出版していることが説明されています。これらのマニュアルの販売を促進するために、マニュアルのオンライン版は、最初に印刷されたマニュアルが利用可能であることを言及し、それを入手するための情報を指すようにするべきです。例えば、https://www.gnu.org/order/order.html のページへのリンクがあります。ただし、印刷されたマニュアルには含めないでください。そこでは冗長です。また、オンライン形式のマニュアルで、ユーザーがソースからマニュアルを印刷する方法を説明することも有用です。

第6.7節「The NEWS File」では、パッケージには、言及する価値のあるユーザーが目に見える変更のリストを含む「NEWS」という名前のファイルがあるべきであることが説明されています。各新しいリリースで、ファイルの先頭に項目を追加し、それらが関連するバージョンを識別します。古い項目を破棄しないでください。新しい項目の後にそれらをファイルに残しておきます。このようにすると、以前のバージョンからアップグレードするユーザーは何が新しいかを確認できます。NEWSファイルが非常に長くなった場合は、古い項目の一部を「ONEWS」という名前のファイルに移動し、最後にそのファイルを参照するユーザーへの注意を入れます。

第6.8節「Change Logs」では、プログラムのソースファイルに対して行われたすべての変更を記述するために、変更ログを保持することが説明されています。これは、将来のバグを調査する人々が、そのバグを導入した可能性のある変更について知るためです。新しいバグは、最近変更されたものを見ることで見つけることができることがよくあります。さらに重要なことに、変更ログは、異なるプログラムの部分間の概念的な矛盾を排除するのに役立ちます。変更ログは、矛盾する概念がどのように生じ、それらが誰から来たか、矛盾する変更がなぜ行われたかといった歴史を提供することで、これを実現します。したがって、変更ログは、このようなソフトウェア法医学に一般的に必要な情報を提供するために、十分に詳細かつ正確であるべきです。具体的には、変更ログは次の質問に対する回答を簡単に見つけるようにするべきです：特定のソースファイルに影響した変更は何ですか？特定のソースファイルが名前が変更されたか移動された場合、それはどの変更の一部として行われましたか？特定の関数またはマクロまたはデータ構造の定義に影響した変更は何ですか？関数（またはマクロまたはデータ構造の定義）が別のファイルから名前が変更されたか移動された場合、それはどの変更の一部として行われましたか？関数（またはマクロまたはデータ構造）が削除された場合、その変更は何ですか？特定の変更の根拠とその主要なアイデアは何ですか？その変更に関する追加情報がある場合、それはどこで見つけることができますか？歴史的に見て、変更ログは特別な形式のファイルで保持されていました。現在では、プロジェクトは一般的にソースファイルをGit、Subversion、Mercurialなどのバージョン管理システム（VCS）で保持しています。VCSリポジトリが公開されており、変更が個別にコミットされ（1つのコミットで1つの論理的なchangeset）、各変更の著者を記録している場合、VCSで記録された情報を使用してVCSログから変更ログを生成し、適切なVCSコマンドを使用して上記の質問に回答することができます。（ただし、VCSログメッセージでも下記で説明するようなサポート情報を提供する必要があります。）このようなVCSリポジトリを保持するプロジェクトでは、別々の変更ログファイルを保持しないでVCSに依存して変更ログを保持することができます。別々の変更ログファイルを保持しないことに決定した場合でも、プロジェクトのVCSリポジトリにアクセスせずに変更ログを確認したいユーザーの利益のために、リリースtarballにそれらを提供することを検討してください。VCSログからChangeLogファイルを生成するスクリプトが存在します。例えば、Gnulibの一部であるgitlog-to-changelogスクリプトは、Gitリポジトリ用にそれができます。Emacsでは、C-x v a（vc-update-change-log）コマンドがVCSログからChangeLogファイルをインクリメンタルに更新する仕事をします。別々の変更ログファイルが保持される場合、それらは通常ChangeLogと呼ばれ、各ファイルはディレクトリ全体をカバーします。各ディレクトリには独自の変更ログファイルがあるか、またはディレクトリが親ディレクトリの変更ログを使用することができます。あなた次第です。

第6.9節「Man Pages」では、GNUプロジェクトでは、manページは二次的であることが説明されています。すべてのGNUプログラムにmanページがあることが必要または期待されるわけではありませんが、いくつかのプログラムにはmanページがあります。プログラムにmanページを含めるかどうかはあなた次第です。この決定をするとき、プログラムが変更されるたびにmanページをサポートすることにより継続的な努力が必要であることを考慮してください。manページに費やす時間は、より有用な作業から取り除かれる時間です。変更が少ない単純なプログラムでは、manページの更新は小さな仕事です。その場合、manページがある場合はそれを含める理由はほとんどありません。大幅に変更される大型のプログラムでは、manページの更新は大きな負担になる可能性があります。ユーザーがmanページを寄付することを申し出た場合、この贈り物を受け入れることは高価になる可能性があります。同じ人がそれを維持する完全な責任を引き受けるまで、manページを拒否する方が良いでしょう。その後、あなたはそれを完全に手放すことができます。このボランティアが後で仕事をしなくなった場合、自分自身でそれを拾う義務はありません。誰か他の人がそれを更新することに同意するまで、配布からmanページを撤回する方が良いでしょう。プログラムが少ししか変更されない場合、不一致が小さくてもmanページは更新せずに依然として有用であると感じるかもしれません。その場合は、manページの冒頭近くに目立つ注意書きを入れて、Texinfoマニュアルがより権威的であることを伝え、Texinfo文書にアクセスする方法を説明してください。注意書きにはTexinfo文書へのアクセス方法が記載されている必要があります。 manページに著作権表示とフリーライセンスを含めてください。単純なすべて許容的なライセンスは単純なmanページに適しています（Information for GNU Maintainers の License Notices for Other Files を参照）。長いmanページ（十分な説明や文書化があり、真のマニュアルと見なされるもの）ではGFDL（License for Manuals を参照）を使用します。最後に、GNU help2manプログラム（https://www.gnu.org/software/help2man/）は、--help出力からmanページを自動生成する1つの方法です。これは多くの場合十分です。

第6.10節「Reading other Manuals」では、プログラムを文書化するために非フリーの書籍や文書ファイルがある場合があることが説明されています。これらの文書を参照することは構いません。新しい代数の教科書の著者が他の代数の本を読むようにです。非フィクションの本の大部分は、この場合、特定のプログラムがどのように機能するかについての事実で構成されており、これらの事実は、その主題について書くすべての人にとって必ず同じです。ただし、あなたのアウトライン構造、言葉遣い、表または例を既存の非フリー文書からコピーしないよう注意してください。フリー文書からコピーすることは大丈夫かもしれません。個々のケースについてFSFに確認してください。

第7章「The Release Process」については、残念ながら私の検索結果には詳細な情報がありません。ただし、この章はリリースプロセスに関するものであり、リリースプロセスに関するガイドラインが含まれていると思われます。

第7.1節「How Configuration Should Work」については、各GNU配布物には、configureという名前のシェルスクリプトが付属していることが記載されています。このスクリプトは、プログラムをコンパイルするためのマシンとシステムの種類を記述する引数が与えられます²。configureスクリプトは、設定オプションを記録して、それらがコンパイルに影響するようにしなければなりません。

第7.2節「Makefile Conventions」については、GNUプログラムのMakefileを作成するための規則が記載されています1。Automakeを使用すると、これらの規則に従ったMakefileを作成するのが簡単になります1。ポータブルなMakefileについての詳細は、AutoconfのPOSIXおよびPortable Make Programmingを参照してください1。

第7.2.1小節「General Conventions for Makefiles」については、残念ながら私の検索結果には詳細な情報がありません。ただし、この小節はMakefileの一般的な規則に関するものであり、Makefileの作成に関するガイドラインが含まれていると思われます。

第7.2.2小節「Utilities in Makefiles」については、Makefileのコマンド（およびconfigureなどのシェルスクリプト）は、sh（従来のBourneシェルとPOSIXシェルの両方）で実行するように記述する必要があります²。kshやbashの特殊な機能、または従来のBourne shで広くサポートされていないPOSIX機能を使用しないでください²。configureスクリプトとビルドおよびインストール用のMakefileルールは、次のユーティリティ以外は直接使用しないでください: awk, cat, cmp, cp, diff, echo, egrep, expr, false, grep, install-info, ln, ls, mkdir, mv, printf, pwd, rm, rmdir, sed, sleep, sort, tar, test, touch, tr,true。これらのプログラムの広くサポートされている（通常はPOSIXで指定されている）オプションと機能に限定して使用してください。

第7.2.3小節「Variables for Specifying Commands」については、Makefileは、特定のコマンド、オプションなどをオーバーライドするための変数を提供する必要があります。特に、ほとんどのユーティリティプログラムは変数を介して実行する必要があります。たとえば、Bisonを使用する場合、BISONという名前の変数を持ち、デフォルト値をBISON = bisonで設定し、Bisonを使用する必要があるたびに$ (BISON)で参照します。ln、rm、mvなどのファイル管理ユーティリティは、このような変数を介して参照する必要はありません。ユーザーが他のプログラムに置き換える必要がないためです。

各プログラム名変数には、プログラムにオプションを提供するためのオプション変数が付属しています。プログラム名変数名に「FLAGS」を追加して、オプション変数名を取得します（例：BISONFLAGS）。ただし、Cコンパイラ用のCFLAGS、yacc用のYFLAGS、lex用のLDFLAGSはこのルールの例外ですが、それらは標準であるため維持します。プリプロセッサを実行するすべてのコンパイルコマンドでCPPFLAGSを使用し、リンクも行うすべてのコンパイルコマンドおよびldの直接使用でLDFLAGSを使用します。特定のファイルの適切なコンパイルに必要なCコンパイラオプションがある場合は、それらをCFLAGSに含めないでください。ユーザーは自分自身でCFLAGSを自由に指定できると期待しています。代わりに、CFLAGSとは独立して必要なオプションをCコンパイラに渡すようにしてください。それらを明示的にコンパイルコマンドに記述するか、次のような暗黙的なルールを定義します: CFLAGS = -g ALL_CFLAGS = -I. $ (CFLAGS) .c.o: $ (CC) -c $ (CPPFLAGS) $ (ALL_CFLAGS) $<。

第7.2.4小節「DESTDIR: Support for Staged Installs」については、make installルールは、DESTDIR変数をサポートする必要があります。この変数は、インストール先のディレクトリの先頭に追加されます。たとえば、make install DESTDIR=/tmp/stageとすると、ファイルは/tmp/stage/usr/local/binなどにインストールされます。この機能は、パッケージ作成者がパッケージを作成する際に役立ちます。

第7.2.5小節「Variables for Installation Directories」については、残念ながら私の検索結果には詳細な情報がありません。ただし、この小節はインストールディレクトリ用の変数に関するものであり、インストールディレクトリを指定するための変数に関するガイドラインが含まれていると思われます。

第7.2.6小節「Standard Targets for Users」については、残念ながら私の検索結果には詳細な情報がありません。ただし、この小節はユーザー向けの標準ターゲットに関するものであり、ユーザー向けの標準ターゲットに関するガイドラインが含まれていると思われます

第7.2.7小節「Install Command Categories」については、installターゲットを作成する際に、すべてのコマンドを3つのカテゴリーに分類する必要があります: 通常のもの、事前インストールコマンド、および事後インストールコマンドです²。通常のコマンドは、ファイルを適切な場所に移動し、モードを設定します。それらは、それらが属するパッケージから完全に来るもの以外のファイルを変更してはいけません。事前インストールおよび事後インストールコマンドは、他のファイルを変更できます。特に、グローバルな設定ファイルやデータベースを編集できます。事前インストールコマンドは通常、通常のコマンドの前に実行され、事後インストールコマンドは通常、通常のコマンドの後に実行されます。事後インストールコマンドで最も一般的な使用方法は、install-infoを実行することです。これは通常のコマンドでは実行できません。なぜなら、それはパッケージが完全かつ唯一から来るものではないファイル（Infoディレクトリ）を変更するからです。それは事後インストールコマンドであるため、パッケージのInfoファイルをインストールする通常のコマンドの後に実行する必要があります。ほとんどのプログラムには事前インストールコマンドは必要ありませんが、必要な場合があるため機能があります。

これら3つのカテゴリーにコマンドを分類するために、カテゴリーラインをそれらの間に挿入します。カテゴリーラインは、その後に続くコマンドのカテゴリーを指定します。カテゴリーラインはタブと特殊なMake変数への参照から構成され、末尾にオプションコメントがあります。各カテゴリーに対して使用できる変数が1つあり、変数名がカテゴリーを指定します。カテゴリーラインは通常実行時にno-opです。これら3つのMake変数は通常未定義（makefileで定義しないでください）です。次が3つの可能なカテゴリーラインです（それぞれ意味を説明するコメント付き）:

$ (PRE_INSTALL) # 事前インストールコマンドが続きます。
$ (POST_INSTALL) # 事後インストールコマンドが続きます。
$ (NORMAL_INSTALL) # 通常のコマンドが続きます。

installルールの最初にカテゴリーラインを使用しない場合、最初のカテゴリーラインまですべてのコマンドが通常として分類されます。カテゴリーラインを使用しない場合、すべてのコマンドが通常として分類されます。

これらがuninstall用のカテゴリーラインです:

$ (PRE_UNINSTALL) # 事前アンインストールコマンドが続きます。
$ (POST_UNINSTALL) # 事後アンインストールコマンドが続きます。
$ (NORMAL_UNINSTALL) # 通常のコマンドが続きます。

典型的には、Infoディレ^[1]

第7.3節「Making Releases」については、リリースを作成することは、ソースファイルをtarファイルにまとめてFTPでアップロードするだけではありません。あなたのソフトウェアを様々なシステムで実行できるように設定する必要があります。あなたのMakefileは、以下で説明するGNUの標準に準拠し、ディレクトリレイアウトも以下で説明する標準に準拠する必要があります。そうすれば、あなたのパッケージをすべてのGNUソフトウェアの大きな枠組みに含めることが簡単になります。

第8章「References to Non-Free Software and Documentation」については、GNUプログラムは、非フリーなプログラムの使用を推奨、促進、または正当化するべきではありません。プロプライエタリソフトウェアは社会的かつ倫理的な問題であり、その問題を解決することが私たちの目標です。私たちは、プロプライエタリプログラムを書く人々やそれらを使用する人々を止めることはできませんが、それらを新しい潜在的な顧客に広告したり、その存在が正当であるという印象を一般に与えることは拒否できます。GNUのフリーソフトウェアの定義はGNUウェブサイトにあり、フリー文書の定義はこちらにあります。この文書で使用される「フリー」と「非フリー」という用語は、それらの定義を指します。重要なライセンスとそれらがフリーかどうかの一覧はこちらにあります。ライセンスがフリーかどうかが明確でない場合は、licensing@gnu.org宛てにGNUプロジェクトにお問い合わせください。私たちは回答し、ライセンスが重要なものであれば、それを一覧に追加します。

非フリーなプログラムまたはシステムがあなたのプログラムの領域でよく知られている場合、それを通過して言及することができます。それは無害です。なぜなら、それを使用する可能性があるユーザーは既にそれについて知っているからです。たとえば、広く使用されている非フリーなオペレーティングシステム上であなたのパッケージをビルドする方法や、広く使用されている非フリーなプログラムと一緒に使用する方法を説明することは問題ありません。ただし、既に非フリープログラムを使用している人々があなたのプログラムをそれと一緒に使用する方法について必要な情報だけ提供してください。プロプライエタリプログラムに関するその他の情報や参照情報を提供しないでください。また、プロプライエタリプログラムがあなたのプログラムを強化したり、その存在が何らかの形で良いものであるかのように示唆しないでください。目標は、既にプロプライエタリプログラムを使用している人々があなたのフリープログラムをそれと一緒に使用する方法について必要なアドバイスを受け取り、既にプロプライエタリプログラムを使用していない人々がそれに興味を持つ可能性があるものを何も見ないようにすることです。非フリーなアドオンは推奨しないでくださいが、あなたのプログラムと連携するために役立つフリーアドオンを言及し、非フリープログラムの実行が必要であってもフリーアドオンをインストールする方法を説明することは問題ありません。

非フリーなプログラムまたはシステムがあな^[1]