2. フリーソフトウェアを自由に保つ

この節では、 GNUソフトウェアを邪魔されないように保つための方法について議論している。

2.1 独占的プログラムの参照

どんなところでも、GNUに関する作業のためや、作業中に、Unixのソースコー ドを参照してはいけない！ (他の独占的プログラムについても。)

もしUnixプログラムの内部の曖昧な記憶を持っているなら、このことは、その イミテーションを書くことができない、とは言っていないが、そのイミテー ションを内部的に違った行で構成するようにしなさい。なぜなら、こうするこ とで、Unixバージョンの細部とあなたの結果とを、無関係で似ていないものに する傾向があるからだ。

例えば、Unixユーティリティは普通、メモリ使用量を最小化するように最適化 されている。もしあなたが代わりにスピードを追い求めれば、あなたのプログ ラムはかなり異なるものになるだろう。stdioを使わずに、入力ファイル全体 をコアに置き、それを検査してよい。Unixプログラムより最近に見付かった、 より賢いアルゴリズムを使いなさい。一時ファイルの利用を省きなさい。 二度やらず一回のパスでやりなさい (我々はこれをアセンブラで行った)。

あるいは、逆に、スピードではなく単純さを強めなさい。アプリケーションに よっては、今日のコンピュータのスピードでは、より単純なアルゴリズムが適 切である。

あるいは一般性を求めなさい。例えば、Unixプログラムはよく静的なテーブル や固定長の文字列を使っているが、それは制限を課していることになる。代わ りに動的な確保を行いなさい。あなたのプログラムを入力ファイルのNULや他 の変な文字を扱えるようにしなさい。拡張性のためにプログラミング言語を加 え、その言語でプログラムの一部を記述しなさい。

あるいは、プログラムのいくらかを独立して利用できるライブラリにしなさい。 あるいは、いつメモリを解放するか正確にトラッキングせずに、簡単なガーベ ージ・コレクタを使うか、obstacksのような新しいGNUの機能を利用しなさい。

2.2 貢献の受け取り

もしあなたが作業しているプログラムが、Free Software Foundationによる著 作権を持っているなら、誰か他の人がそのプログラムに加えるコードを送って きたとき、我々はそれを使うのに法的な文書を必要とする。ちょうど、我々が 初めにあなたに文書に署名するよう頼むときのように。プログラムに明解で ない寄与をする人は、我々がそのプログラムにはっきりした所有権を付ける ために、誰でもみな何らかの類いの法的な文書に署名しなければならない。 中心となった作者だけでは十分ではないのだ。

だから、他の人からの貢献を加える前に、我々に訊いてほしい。そうすると、 我々はその文書を手に入れられるよう計らうことができる。そして、その貢献 を実際に使う前に、署名された文書を受け取ったことをあなたに伝えるまで 待ちなさい。

これはプログラムをリリースする前と後の両方に当てはまる。もしバグを潰す ための差分を受け取り、それが顕著な変更を行うなら、我々はその変更のため の法的な文書を必要とする。

これはコメントや解説ファイルにも当てはまる。著作権法のため、コメントと コードは単なるテキストである。著作権はあらゆる種類のテキストに適用され るので、我々は全ての種類に対して法的な文書を必要とする。

法的な文書を請求するのが面倒だということは知っている。それは我々にとっ ても面倒なことなのだ。しかし、もしあなたが待たなければ、不利な立場に向 かっていることになる。例えば、その貢献者が雇った人間が著作権放棄の文書 に署名したがらなかったとしたら？あなたはそのコードを再び取り除かなくて はならないかもしれない！

あちこちの数行の変更には対しては、文書を必要としない。それらは著作権の目 的からは重要でないからだ。また、もし受け取った提案が発想であって、使用 する本当のコードでないなら、文書を必要としない。例えば、誰かがある実装 を送ったが、あなたが同じ発想の異なる実装を書いたなら、文書を受け取る必 要はない。

まさしく最悪なのは、他の貢献者を我々に伝えるのを忘れた場合だ。我々は、 結果として、いつか法廷で非常に決まり悪い思いをするかもしれない。

我々はプログラムの管理者にもっと詳細な情報を持っている。もし、GNUのた めのプログラムを(リリースされているかどうかに拘らず)実際に管理する段階 に達したら、コピーを請求していただきたい。