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

この ノード では, GNU ソフトウェアで法律的な問題や,その他 関係する問題を回避するにはどうしたら良いかを議論します.

2.1 排他的権利を持つプログラムの参照
2.2 寄贈の受取
2.3 商標

2.1 排他的権利を持つプログラムの参照

GNU ソフトウェアに関係する作業をしている間は, Unix のソースコード （あるいは他の排他的権利を有するプログラム）を見ないように努めてください.

とはいっても,なにかの Unix プログラムの内部を見たことがあり, それを ぼんやりとでも憶えていたからといって,そのプログラムの別バージョンを 書くのはいけないかというと,そんなことはないので安心してください. ただし, そういうプログラムを書く機会があるなら, 元のプログラムとは異なった 方針で内部仕様を設計してください. そうすれば元の Unix 版のプログラムとは細かな点では無関係で 似ていないものになります.

内部構造を Unix 版のプログラムと違うものにするためにはどうすれば良いか, 少し考えてみましょう.例えば, Unix のコマンドはメモリ使用量が 少なくなるような作りのものが多いのですが, 代わりに速度を重視するように すれば,かなり違ったプログラムになるはずです. ファイルを全部メモリ中に取り込めば, 標準入出力ライブラリを使わずとも ファイルの中身を走査することもできます. Unix のプログラムで使われているアルゴリズムよりも新しくて賢い アルゴリズムがあればそっちを使いましょう. 一時ファイルを使わないようにしましょう. ２パスはやめ, （GNU アセンブラのように)１パスにしましょう.

あるいは逆に, 速度よりも単純さを重視することも考えられます. 最近の計算機は速くなってきているので, アプリケーションによっては 単純なアルゴリズムの方が適している場合もあります.

あるいは一般性を追及しましょう. Unix のプログラムでは静的な配列や固定長の文字列をよく使っていますが, こういう制限は困りものです. 代わりにメモリを動的に獲得するようにしましょう. 自分のプログラムが入力ファイル中の NUL 文字やその他の制御文字等を きちんと扱えるかどうか確かめてみてください. 拡張性を持たせるには, 拡張機能を記述するためのプログラミング言語を 作って, プログラムの一部をその言語で書いてください.

あるいは, プログラムの一部を,独立に使えるライブラリに転用しましょう. また, いつメモリを解放すべきかを正確に追跡するのはやめて, 代わりに単純なガベージコレクタを使うか, obstack のような GNU の新しい 機能を使いましょう.

2.2 寄贈の受取

読者が作業中のプログラムの著作権が Free Software Foundation にあるものなら, そのプログラムに追加できるようなコードを誰かが送って きたとしても, 我々がそれを使うには法的な文書が必要です. この文書は, 我々が最初に読者に要求したものと同様の文書です. プログラムの所有権をはっきりさせるため, プログラムに簡単ではない貢献をした人全員が文書にサインしなければな りません. 主となる著者のサインだけでは不十分です.

そういう理由があるので, 他人から寄贈されたコードを自分のコードに加えるまえに 知らせてくれれば文書の準備をします. そして, 我々がサイン入りの文書を受けとったという連絡があるまで, 実際に寄贈された部分を使うのは待ってください.

このことは, プログラムをリリースする前, それにリリース以後についても 適用されます. バグを修正した差分を受けとって,そのために重要な変更が 生じたときも法的な文書が必要です.

これは, コメントやドキュメントのファイルについても当てはまります. 著作権法の観点からみれば, コメントもコードも単なるテキストです. 著作権はあらゆる種類のテキストに適用されますので, 我々もあらゆる種類の テキストについて書類が必要なのです.

法的な文書が必要だなんて煩わしいことなのはわかっています. 我々にとっても煩わしいことなのです. しかし, 法的文書を待たないと孤立無援になります. 例えば,寄与者の雇主が 権利放棄書にサインしなかったらどうなるでしょうか? そのコードを再び 取り除かなければならなくなるでしょう.

ほんの数行程度の変更なら文書の必要はありません. 著作権の意図するところにとっては, 重要でないからです. また, 受け取ったものが実際に使えるコードではなく, 何かのアイデアである場合も 文書はいりません. 例えば, 誰かが読者に何かの実装を 送ってきたものの, 読者が同じアイデアをそれとは別に実装した場合も はまります.

一番まずいのは, 他にも寄与者がいることを忘れ, 我々に知らせないことです. その結果として,いつか,我々は法廷において非常に困った事態にあうかも しれません.

プログラムの保守担当者にはもっと細かいアドバイスがあります. もし, GNU のプログラムを実際に保守する段階に達したら(それが リリースされるかどうかは別です), 我々に覚書のコピーを要求してください.

2.3 商標

GNU ソフトウェアのパッケージや文書で商標についての謝辞は一切含めないで ください.

商標の謝辞とはこれこれはなになにの商標であるという形の文です. GNU プロジェクトは商標の基本的な考え方に異義はないが,しかしこういう 謝辞はいたずらにへつらっているようであり,我々は使用しない.こういうものに ついて法律的な要請はないのである.

他人の商標について法的に要求されているのは,読んだ人が, 我々自身のプログラムや活動に名前を付けたり,ラベルを貼ったりしていると 思わせるような使い方をしないということである. 例えば,"Objective C" というのは商標なので(あるいは,少なくとも 昔は商標であったので),我々は「Objective C コンパイラ」ではなく 「Objectvie C 言語用コンパイラ」を提供しているというように気をつけて いた.前者は後者の短縮形であるが,関係を明示的に述べていないので, "Objecvitve C" を言語を表すものでなく,コンパイラにラベルを貼るものと して使っていると誤解される可能性があったのである.