| [Top] | [Contents] | [Index] | [ ? ] |
最終更新は November 15, 2001 になされました。
1. このドキュメントについて 2. 引退 3. 開発者の募集 4. 法的な問題 5. 変更の整理 6. サポートするプラットホーム 7. メールの処理 8. 過去のバージョンの記録 9. 配布物 10. リリースの発表 11. ウェブ・ページ 12. 用語の問題 13. ホスティング 14. フリー・ソフトウェア登録簿 15. 校正者リストの使用 Index
このファイルには、GNU プロジェクトのために、GNU のプログラムの管理者となっ ている人に対する指針や助言が書かれています。誰もが GNU ソフトウェアを変更 したり、再配布することのできる権利を持っています。つまり、許しを請うため にこのファイルに注意を払う必要はありません。でも、もし広く行き渡っている 配布物のあるバージョンを管理したいなら、これらの指針に従うことを提案しま す。もし GNU 管理者になりたいなら、これらの指針に従うことは必須です。
このドキュメントへの訂正や提案は maintainers@gnu.org に送ってくだ さい。もし提案を行うなら、その提案を効率的に考慮できるように、提案する、 新しい言葉遣いを含めてください。`maintain.texi' ファイルに対する context diff が望ましいですが、もしそのファイルを持ってなければ、このドキュ メントの少々古いバージョンに対する context diff でも良いですし、何かはっき り分かるやり方で提案しても構いません。
このドキュメントでは、Woman on the Edge of Time で Marge Piercy によって普及を促され、 多分発明された、 中性三人称代名詞「その人が」、 「その人の」、 「その人のもの」そして「その人自身」を使用します。 それらは、 男性と女性に対して等価に適用されることを除いて、 「彼女が」、 「彼女の」、 「彼女のもの」そして「彼女自身」とちょうど同じように使われます。 例えば、 「一般大衆がその人の業績から利益を得られるよう、 そして、 その人が 正しいことを行ったと感じられるように、その人はその人の新しいプログラムに GNU GPL を適用した。」 (1)
ディレクトリ `/gd/gnuorg' が GNU のマシン上で見付かります。もしあな たが GNU パッケージの管理者なら、そこにアカウントを持っているはずです。 もし持ってなければ、accounts@gnu.org に連絡してください (その パッケージの作業を多いに助けてくれている人々のためのアカウントを請求する こともできます)。 `/gd/gnu/maintain.tar.gz' はこのファイルで言及さ れている、そのディレクトリの全てのファイルを含んでいる tar ファイルです。 毎日更新されています。
GNU 管理説明書 (GNU Maintenance Instructions) のこのリリースは November 15, 2001 に最終更新されました。
幸運であれば、あなたのパッケージを何十年も管理し続けるでしょう。しかし、 管理者はときどき、様々な理由のために引退を決意します。
もしあなたが GNU パッケージの公式管理者で、引退を決めたなら、GNU プロジェ クトに知らせてください (maintainers@gnu.org)。我々はそのパッケー ジにはもはや管理者がいないことを知る必要があり、そうすれば我々は新しい管 理者を探して任命することができます。
もし誰が引き継ぐべきか、考えを持っているなら、 maintainers@gnu.org にあなたの提案を教えてください。新しい管理 者の任命には GNU プロジェクトの承認を必要としますが、ある人がその仕事を 行う能力を持っているという、あなたの判断は大きな意義を持つでしょう。
あなたのパッケージが割と小さいのでなければ、多分その仕事全てをあなた自身 で行うことはないでしょう。 ほとんどの管理者は助力をしてくれる開発者を募集します。
しばしば人々は助けを申し出ます。 そういう人々の一部は有能でしょうが、それ以外は駄目でしょう。誰が役 に立つ助力を差し延べるかを決め、それらの人々にもっと参加するよう奨励する のはあなたの責任です。
助力を申し出る人々の一部は GNU プロジェクトを支援するでしょうが、それ以 外は他の理由のために興味を持っているかもしれません。 一部はフリー・ソフトウェア運動の目標を支援するでしょうが、 一部はそうではないかもしれません。 その人々はみんなその仕事を助けることに歓迎されます--- 我々は人々が GNU パッケージに寄与する前に、 その人々の見方や動機を尋ねたりはしません。
それゆえ、全ての寄付者が GNU プロジェクトを支援するとか、その方針や標準 に関心を持っているとか、期待してはいけません。だから、管理者としてのあな たの仕事の一部は、そういう問題が持ち上がったときに、それらにあなたの権限 を行使することです。どれだけの仕事を他の人々がやろうとも、何がリリースに 加わるかに責任を持つのはあなたであって、 他の人々ではありません。 決定的な問題 が起きたら、あなたは冷静に判決を述べ、それを忠実に守るべきです。
ときどき、あるパッケージには管理者の役割を共有する、複数の共同管理者がい ます。 助力をしてくれる開発者とは違って、 共同管理者は現実にそのパッケージの管理者としてま とめて任命されており、 共同管理者たちは管理者の役割を一緒に実行します。 もしあなたの 開発者の一部を共同管理者として申し込みたければ、 maintainers@gnu.org に連絡してください。
この章では、プログラムを管理するとき、法律の困難を回避するため、法的な理 由のために従うべき手続きについて記述します。
4.1 寄付者の記録 4.2 著作権の書類 4.3 著作権告知 4.4 ライセンス告知 4.5 外部ライブラリ
どの部分が誰によって書かれたのか、正しい記録を管理せよ。 これは非常に重要です。
これらの記録にはどのファイル、あるいは、ファイルのどの部分が各人によって 書かれたか、どのファイルや部分が各人によって修正されたかが書かれているべ きです。
しかし、それらは変更履歴ほど詳細である必要はありません。それらは異なる時 期に行われた仕事を区別する必要はなく、異なる人々だけを区別する必要があり ます。それらはどのファイルやファイルの部分が変更されたか以上に詳しく変更 を記述する必要はありません。そして、それらはファイルや変更の機能や目的に ついて何も言及する必要はありません--著作権の記録簿はその文章が何をするか には関係がなく、ただ誰がどの部分を書いたり寄付したかだけに関係します。
数行の比較的重要でない変更 (15未満) だけを寄付したある人を列挙する必要は ありませんが、あまり重要でない変更の連続は列挙される必要がある、重要な寄 付へと足し合わされていくことを覚えておいてください。
その一覧はまた同じパッケージの中で配布される、ある特定のファイルが本当に 別個のプログラムであるかどうかも言及するべきです。
例えば、これは GAS のある初期のバージョンを記述します:
Dean Elsner first version of all files except gdb-lines.c and m68k.c.
Jay Fenlason entire files gdb-lines.c and m68k.c, most of app.c,
plus extensive changes in messages.c, input-file.c, write.c
and revisions elsewhere.
Note: GAS is distributed with the files obstack.c and obstack.h, but
they are considered a separate package, not part of GAS proper.
|
これらの記録をそのプログラム自身のソース・ディレクトリの中の `AUTHORS' と名付けられたファイルに保持してください。
もし FSF が著作権保護したパッケージを管理するなら、他の人々によって書か れた変更を組み込むとき、ある法的な手続きに従うべきです。これは FSF がそ のパッケージを配布する法的権限、そして、もし必要とあれば、法廷でその自由 な状態を弁護する権利を所有することを保証します。
重要な変更を組み込む前に、その変更を書いた人が著作権の書類に署 名しており、Free Software Foundation がそれらを受け取って署名しているこ とを確認してください。我々はその人の雇用者からの放棄声明書も必要とするか もしれません。
書類が受け取られたかどうかを点検するのに、 `/gd/gnuorg/copyright.list' をのぞいてください。 もしそこを直接見られな いなら、fsf-records@gnu.org があなたのために点検できます。我々 の職員は記入待ちの書類を確認し、いつ書類が届くと期待されているかを知らせ ることもできます。
ディレクトリ `/gd/gnuorg' が GNU のマシン上で見付かります。もし GNU パッケージの管理者なら、そこにアカウントを持っているはずです。もし持って なければ、 accounts@gnu.org に連絡してください (そのパッケージ の作業において大いに貢献している人々のためのアカウントを請求することもで きます)。
寄付者が書類に署名するべきだと分かるように、必要な書類を頼む必要がありま す。もしその人の意思を知らず、その人が著作権の書類を扱う我々のやり方に慣 れていると考えられないなら、このようなメッセージでその題目を提起すること は良い考えかもしれません:
Would you be willing to assign the copyright to the Free Software Foundation, so that we could install it in program?
あるいは、
Would you be willing to sign a copyright disclaimer to put this change in the public domain, so that we can install it in program?
もしその寄付者がもっと多くの情報を欲しがるなら、その人に `/gd/gnuorg/conditions.text' を送っても良く、それはその人の選択肢 (譲渡 vs. 放棄) やそれらの結果について説明しています。
その話し合いが始まり、その寄付者がもっと詳細を受ける準備ができたなら、 `/gd/gnuorg' に見付かる雛型のうちの一つを送るべきです。この節ではど の状況でどっちの雛型を使うべきかを説明します。 ここで挙げられて いる以外の雛型を使わないください、そして、その言葉遣いを変更しないでくだ さい。
その話し合いが始まったら、その寄付者に正確な言葉遣いや説明を電子メールで 送ることができます。 これをする前に、確実に使用する雛型の現行のバージョ ンを手に入れてください! 我々はこれらの雛型をために変更します---古いバー ジョンを使い続けないでください。
大きな変更に対しては、その寄付者に譲渡を求めてください。その人にファイル `/gd/gnuorg/request-assign.changes' のコピーを送ってください。
中ぐらいから小さい変更に対しては、その人にファイル `/gd/gnuorg/request-disclaim.changes' を送って、放棄を要求してくだ さい。
その寄付者が変更を行い続ける可能性が高いなら、その人はそのプログラムへの 将来の変更全てに対する譲渡に署名したがるかもしれません。だから、その人に この代案を提供すると役に立ちます。もしその人がそのようにしたければ、その 人に `/gd/gnuorg/request-assign.future' を送ってください。
`request-' ファイルを送るとき、送る前に何も空欄に記入する必要はあり ません。その寄付者に文字通りにそのファイルを送るだけです。そのファイルか ら、その人は署名する書類を FSF に郵送するよう頼む方法の指示を知ることが できます。`request-' ファイルはまたその寄付者の雇用者から著作権放棄 声明書を受け取る件についても取り挙げています。
あまり普通でない場合のために、我々は寄付者に送付するべき雛型ファイルを持っ ています。送る前に、これらの雛型にその人の名前とそのプログラムの名前を、 NAME OF PERSON と NAME OF PROGRAM と書かれているところに、記入するのを 忘れないでください。さもなければ、その人はそれらに気付かずに署名するかも しれず、その書類は無意味になってしまいます。いくつかの雛型ではそのプログ ラムの名前やその人の名前を入れるところが複数あることに注意してください。 それら全てを変更するよう気を付けてください。その雛型は全て、雇用者の放棄 声明書の問題も取り挙げています。
マニュアルが記しているソフトウェア・パッケージの中だけで配布される、その マニュアルに対しては別に書類を求める必要はありません。しかし、もし我々が ときどきそのマニュアルを別に配布するなら (例えば、もしそれを書籍として発 行するなら)、そのマニュアルの変更に対して、別個の法的な書類が必要です。 小規模な変更には、`/gd/gnuorg/disclaim.changes.manual' を使ってくだ さい。大規模なものには、`/gd/gnuorg/assign.changes.manual' を使って ください。あるマニュアルへの過去と将来の両方の変更をカバーするのに、 `/gd/gnuorg/assign.future.manual' を使って構いません。 マニュアルの翻訳には、 `/gd/gnuorg/assign.translate.manual' (2) を使ってください。
もしある寄付者が大きな変更に対する譲渡に署名したがらず、代わりに放棄に署 名する気があるなら、それは容認できるので、もしあなたがたが合意に達するの に役立つなら、この代替品を提供するべきです。その新しいテキストにも GNU GPL を強制できるように、比較的大きい変更には譲渡の方がより良いですが、放 棄はそのテキストを我々が使うには十分なものです。
もしプログラムの集まりを管理しているなら、時折誰かが、その集まりに加えら れるべき、別個のプログラムやマニュアル全体を寄付するでしょう。そのとき、 ファイル `request-assign.program'、`disclaim.program'、 `assign.manual'、そして、`disclaim.manual' を使えます。新しい 別個のプログラムやマニュアルには、それが極めて小さいのでなければ、譲渡の 方がずっと好ましいですが、その寄付者がどうしてもこの件をそうしたいと言う なら、放棄でも構いません。
ここで挙げられた以外にも他に雛型がありますが、それらは特別な状況 のためです。assign@gnu.org からの助言を受けずにそれらを使わない でください。
もし何をしたらいいかはっきりしなければ、助言を得るために assign@gnu.org に質問してください。もしその寄付者が法的な書類の 意味や結果についてあなたに質問し、あなたがその答えを知らないなら、 assign@gnu.org にそれを転送することができ、そうすると我々が答え るでしょう。
雛型の言葉遣いを自分で変更しようとしないください。もしある変更が 必要だと思うなら、assign@gnu.org に話してください、そうすれば、 我々はどうするべきかを決めるのに弁護士とともに取り組むでしょう。
パッケージ中の取るに足りないことはない (nontrivial) ファイルそれぞれに、 法的に有効な著作権告知とライセンス告知を管理しなければなりません (10行以上の長さのファイルはこの目的には取るには足りなくない ものです)。 これにはヘッダー・ファイル、インターフェース定義、 メークファイル、 スクリプト、 プログラムを構築したり動作させるのに使われる他のデータ・ファイル、 解説書のファイルや、 サポート用の全ファイルを含みます。 もしプログラムがあからさまにパブリック・ドメーンに置かれたのなら、 著作権告知の代わりに、 それがパブリック・ドメーンにあることを明示した告知があるべきです。
画像ファイルや音声ファイルにも、 もし可能であれば、 著作権告知やライセンス告知があるべきです。 一部の形式では文字の注釈を入れることができません。 そのようなファイルでは、 同じディレクトリーのREADMEファイルに著作権とコピー許可を明記してください。
変更履歴ファイルは、 新しい物件が先頭に追加されていき、 末尾は末尾のままなので、 末尾に著作権告知とライセンス告知があるべきです。
もしあるファイルが配布物の中にある他のファイルから自動的に生成されるとき、 もし可能であれば、 生成元のファイルから著作権告知や許可告知をコピーするのが便利です。 あるいは、 どのファイルから生成したのかという告知を先頭に置いてください。
著作権告知はこのようになります:
Copyright year1, year2, year3 copyright-holder |
copyright-holder は Free Software Foundation, Inc. や他の誰かにな るかもしれません。誰があなたのパッケージの著作権所有者なのかを知っている はずです。
年数の一覧には、実際にリリースされたバージョンの用意を終えた年、現在のバー ジョンの元になった年、それぞれが含められるべきです。
上の段落を、ゆっくりと、注意深く、読み直してください。この規則を正確に理 解することは、複雑な C の記述を手でまねる (hand-simulate) ために、それを 理解しようとするのと同じぐらいに重要です。
この一覧はバージョンが リリースされた 年の一覧では ありませ ん。それは、その後リリースされた、バージョンが 完成した 年の一覧 です。だから、もし Dec 31, 1994 にあるバージョンを仕上げ、それを Jan 1, 1995 にリリースすれば、このバージョンには 1994 を含めることが必要ですが、 1995 と含めることは必須ではありません。
範囲を使って、年の一覧を短縮しないでください。 たとえば、`1996--1998'などと書いてはいけません。 そうではなく、`1996, 1997, 1998'のように書いてください。
この一覧の目的には、問題になるバージョンは現在のバージョンの元になったバー ジョンです。だから、もし保守用に一時的なブランチを作って、ブランチ A と B に並行して取り組んだなら、各ブランチはそれ自身の年の一覧を持ち、それは このブランチがリリースされたバージョンに基きます。ブランチ A のあるバー ジョンがブランチ B の年の一覧に影響する必要はないし、逆もそうです。
しかしながら、もしブランチ A からブランチ B へコードをコピーすれば、ブラ ンチ A の (あるいは、少なくとも、ブランチ B にコピーした部分の) 年がブラ ンチ B の一覧に現れる必要があります。なぜなら、今やそれらはブランチ B の 元になっているからです。
この規則は分かりにくいです。もし我々が著作権法を担当していたならば、おそ らく (その他多くの面と同様) これを変更するでしょうね。
FSF に著作権保護されたパッケージでは、もし法的な書類を手に入れる手続きに 従っていたら、各ファイルにはたった一つの著作権所有者があるだけのはず: Free Software Foundation, Inc. です。 だから、 その著作権告知はこの名前だ けを示すべきです。
しかし、 もし寄付者みんなが単一の著作権所有者に寄付者たちの著作権を譲渡している のでなければ、容易に一つのファイルが何人もの著作権所有者を持ることが起き るでしょう。取るに足りなくはない量の寄付者のそれぞれが著作権所有者です。
この場合、 必ずそのファイルの主要な著作権所有者の名前を著作権告知に含めるべきです。 他の著作権所有者の著作権告知も含めることができ、 これは大量に寄付した人々や、 名前を告知に入れるように明確に求める人々には、 良い考えです。 しかし、 そのファイルに寄付したみんなに対する告知を含めなくても構わず、 そ れはむしろ迷惑でしょう。
取るに足りないことはない (nontrivial) 各ファイルには、 ライセンス告知と著作権告知が必要です (そのファイルをコピーしたり変更する承認を与えるライセンス情 報がないと、コピーや修正は法的に禁じられ、このためにそのファイルは自由で なくなってしまうでしょう)。
典型的には、 プログラム・ファイル (構築スクリプト、 configureファイル、 メークファイルを含みます) のライセンス告知はGPLを引き合いに出して、 次のようになるはずです:
This file is part of GNU programGNU program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.
GNU program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with program; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
しかし、数個のファイルしかない、小さなプログラムでは、これを代わりに使っ ても構いません:
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
解説書のファイルもライセンス告知を持つべきです。 マニュアルは GNU Free Documentation License を使用するべきです。 ここに著作権告知の後に使う、 ライセンス告知の例を挙げます。 あなたのマニュアルに都合が良いように、 不変部分 (invariant sections) を調節してください (もし全くないなら、 "with no invariant sections" と書いてください)。
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 the
Invariant Sections being "GNU General Public License", the Front-Cover
texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below). A copy of the license is included in the section entitled
"GNU Free Documentation License".
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.
You should have received a copy of the GNU Free Documentation License
along with program; see the file COPYING.DOC. If not, write to
the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston,
MA 02111-1307, USA.
|
もし FSF がこのマニュアルを製本して発行していないなら、FSF によって発行 されたコピーについて語っている (b) の最後の文を削ってください。 もしFSFが著作権所有者ではないなら、 `FSF'を適切な名前に置き換えてください。
一つのソフトウェア・パッケージ中にいくつ ものマニュアルを一緒に配布するとき、 オンライン形式でGFDLの単一のコピーを共有できるよう に注意してください (section 6 を参照) (3)。 しかし印刷された(`.dvi')形式では、 一緒にして発行するのでなければ、 それぞれにGFDLのコピーを入れておくべきです。
サポート用の小さなファイル、 (300行以下の) 短いマニュアルやおおざっぱな解説 (READMEファイル、 INSTALLファイルなど) では、 単純な、 全部許可のライセンスを使用して構いません。
もしライセンスの問題や GFDL の使用に援助が欲しいなら、 licensing@gnu.org に連絡してください。
FSF に著作権保護された GNU パッケージを管理するとき、 ときどき「ライブラリ」の能力として、 有用な機能を提供する、 汎用目的の自由なソフトウェア・ モジュールを利用したくなるでしょう (そのモジュールが必ずしも技術的にライ ブラリとしてパッケージされたいなくても)。
このような場合、このモジュールの作者に FSF へ著作権を譲渡するように頼む のは不合理でしょう。結局、その人は特にあなたのパッケージへの寄付として、 それを書いたわけではないのだから、 出し抜けに、 「FSF にあなたの著作権を渡してください」 とその人に頼むのは無作法でしょう。
だから、この場合にやるべきことは、あなたのプログラムがそのモジュールを使 うようするけど、それをあなたのプログラムの一部と考えないことです。こうす るのに理にかなった方法が二つあります。
この方法では、そのモジュールをライブラリとして扱い、`.a' ファイルを それから作る必要はありません。 通常のやり方で `.o' ファイルと直接リ ンクできます。
これらの方法は両方不規則さを生み出し、我々の弁護士はそのような不規則の量 を最小化するように教えています。 だから、他のプログラムのために書かれ、 一般利用のために別個にリリースされた、汎用目的のモジュールに対してのみ、 これらの方法を使用することを考慮してください。 あなたのパッケージへの寄 付として書かれたものなら何でも、書類に署名してもらってください。
ある人が含めるように求める、あらゆる変更を含める義務があると感じないでく ださい。 どの変更が改善であるかを判断しなければなりません---部分的にはそ のユーザが何を好むと思うかに基き、部分的には何が改善なのか、あなた自身の 判断に基いて。 もしある変更が良いとは思わないなら、それを却下するべきで す。
もしある人が役に立つ変更を送ってきたけれど、 それが見苦しいやり方で書かれていたり、 理解したり、 将来管理したりするのが困難なら、 それを合併する前に、 その人に変更を整理するように頼むことを躊躇しないでください。 我々が行える作 業量は有限なのだから、他の人々をもっと効率的に作業するのを助けてくれるよ うに説得すればするほど、より速く GNU は進歩するでしょう。
もしその寄付者が十分にその変更を整理しようとしない、あるいは、できな いなら、 「今のかたちでは、 私にはこれを取り入れられません。 もしあなたがこれを整理してくだされば、 そうできます」 と言うことは、 妥当 です。その人に変更を他のやり方で配布するように促すか、あなたが取り入れ、 管理できるように、それを整理してくれる他の人々を見付けてください。
自分でこれらの整理を行う唯一の理由は、 (1) その作者に何を整理するべき かを教えるより、簡単で、少しの作業で済むか、(2) その変更が重要なもので、 それを整理する作業に値するぐらいに重要な場合、です。
GNU Coding Standards は 変更を整理するように頼むとき、人々に送ると良 いものです (see section `Contents' in GNU Coding Standards)。 Emacs Lisp マニュアルには Emacs Lisp プログラム用のコーディング標準を示 す付録があります。作者たちにそれを読むように主張すると良いです (see section `Tips and Standards' in The GNU Emacs Lisp Reference Manual)。
たいていのGNUパッケージは、 いろいろなプラットホームでうごきます。 これらのプラットホームに皆、 同じ重要さがあるわけではありません。
GNUパッケージのサポートする一番大事なプラットホームは、 GNUとGNU/Linuxです。 GNUオペレーティング・システムの開発は、 GNUプロジェクトのかなめです。 GNUパッケージは、 全GNUシステムをより強力にするためにあります。 ですから、 その目標を念頭に置いて作業をすすめてください。 たとえば、 追加する新機能はすべてGNUでうごくべきですし、 もしできれば、GNU/Linuxでもそうです。 新機能がGNUやGNU/Linuxだけでうごくとしても、 それは許されます。 ですが、 他のシステムだけでうごき、 GNUやGNU/Linuxでうごかない機能は、 GNUパッケージでは無意味です。
あなたは当然、 サポートする全プラットホームプログラムがうごくようにしたいでしょう。 しかし、 個人的にはそういうプラットホームのほとんどにアクセスできないかもしれません。 --それでは、 どうすればいいのでしょう?
これら全プラットホームへアクセスしようとする必要はありません。 たとえこれら全プラットホームへのアクセスがあったとしても、 あなた自身が各プラットホームでプログラムの試験をするのは、 非効率的でしょう。 その代わり、 GNUやGNU/Linuxをふくむ2、 3のプラットホームでプログラムを試験し、 他のプラットホームでの試験は利用者にまかせるべきです。 これは、 実際のリリース前のプリテスト・フェーズでできます。 問題を予期すべき理由のないとき、 かなり移植性のあるパッケージでは、 単にリリースして、 なにか移植性のない点がもしあれば、 利用者に報告させるようにしてください。
GNUやGNU/Linuxでのプログラムの試験を自分ですることは、 重要です。 なぜならこれがGNUパッケージでもっとも重要なプラットホームだからです。 もしあなたにこれらのプラットホームへのアクセスがなければ、 maintainers@gnu.orgに聞いて援助を求めてください。
他のプラットホームサポートは、任意です。 ---そうするのがいい考えだと思われたときはそうしますが、 義務であるとは考えません。 もしあるプラットホームのめんどうを利用者がみてくれなくなったら、 援助してくれる利用者の現われるまでの間、 あなたはサポートをやめなければならないかもしれません。 逆に、 ある利用者が別なプラットホームをサポートする変更を提供してくれたとき、 あなたはそれをインストールしたいと思うかもしれませんが、 そうする必要はありません。 もしその変更が複雑で見苦しいと感じられたら、 もし将来の管理の重荷が増えると思われたら、 それを却下できますし、 そうすべきです。
あるプログラムが使われ始めたら、 それに対してバグ報告を受け取るでしょう。 ほとんどの GNU プログラムはバグ報告を送るためのそれら専用のリストを持っ ています。 そのプログラムが GNU パッケージであることをユーザに示すのを助 けるため、宣伝されるバグ報告の電子メールの宛先は常に `bug-program@gnu.org' であるべきですが、このリストをさらなる 転送のための他のサイトへ転送するように設定しても構いません。 パッケージ 配布物は目立つところにそのバグ報告リストの名前を述べ、ユーザにそこへバグ を報告することに助けてくれるように頼むべきです。
我々はまた、がらくた入れリスト、bug-gnu-utils@gnu.org を持って おり、それは特別のリストを持たない、全ての GNU プログラムのために使われ ています。 でも今日では、各プログラムにそれ自身のバグ報告リストを与え、 bug-gnu-utils を使わないようにしたいと考えています。
もし GNU パッケージの管理者なら、GNU サーバ上にアカウントを持っているは ずです。もし持っていなければ、accounts@gnu.org に連絡してくださ い (そのパッケージの作業に多大な助力を提供している人々のアカウントを頼むこともできます)。 このアカウントを使えば、 新しい未管理のリストを作成し たり、あなた自身をある存在している未管理のリストに加えるために、 `/com/mailer/aliases' を編集したりできます。 このファイルの始めの近くのコ メントが Mailman で管理されたメーリング・リストを作成する方法を説明して います。
しかし、もしこれらの事柄をどうやってやるのか暗記したくないなら、代わりに、 あなたのプログラム用のバグ報告リストへあなたを加えるように、 alias-file@gnu.org に頼むことができます。 新しいリストを立ち上 げるのに、new-mailing-list@gnu.org に連絡してください。 対応す る `-request' アドレスにメールを送ることで、Mailman によって管理さ れたリストに加入できます。
バグ報告を受け取るとき、バグ報告はあなたの作業に決定的なことを覚えておい てください。 もし問題を知らなければ、それを直すことはできません。だから、 常にバグ報告を送る人それぞれに感謝してください。
が、それ以上の反応を示す義務はありません。 バグ報告の主要な目的は、そのプロ グラムの次のバージョンを改良することによって、あなたがコミュニティに寄与 するのを助けることです。バグを報告する人々の多くはこのことに気付いていま せん--- 人々はその意味はあなたがその人々を個々に助けることだと思っています。 一部の人々はそのプログラムをより良くすることではなく、そのことに 集中するように求めるでしょう。 もしその人々の望みに応じれば、 そのプログラムを 管理するという仕事から逸脱してしまうでしょう。
例えば、人々はときどきバグを曖昧な (そして、それゆえに役に立たない) やり 方で報告し、 より多くの情報を求めると、 「その解決策をすでに知っているかどうかを見たかっただけだ」と言います (その場合、 そのバグ報告はプログラムを改善するのに何の役にも立ちません)。 こういうことが起きるとき、 報告者にバグ報告の真の目的を説明すべきです (説明を記録しておくと、 もっと効率的にこれを行えるでしょう)。
人々がそのプログラムの使用を助けるのに、あなたの時間を割くように頼むとき、 その人々が頼むことを行うのが「役立つ」ように見えるかもしれません。 でも、そ のプログラムを改善するより、ずっと役に立つことはなく、そっちが管 理者の本当の仕事です。
その時間が得られると感じるなら、そうしたいと思うとき、ぜひとも個々のユー ザを助けてください。 でも、これを行うのに費す時間を制限するように注意し てください---そのプログラムを管理するのに必要な時間を侵食させてはいけま せん! 否の言い方をおぼえてください。 時間に押されているとき、 「バグ報告をありがとうございます。 それは直すつもりです」 だけで十分な反応です。
Emacs や GCC のような、いくつかの GNU パッケージにはどのようにバグ報告を 有用にするべきかについて、助言が付いています。 もしこれをコピーして適合 させたいと思うなら、そうすることは非常に有用なことでしょう。
GNU の全てのソース・ファイルのバックアップ・ファイルを保守することが非常 に重要です。もしお気に召すなら、RCS や CVS、PRCS を使って、これを行うこ とができます。 RCS や CVS を使う一番簡単な方法は Emacs の Version Control ライブラリを使うことです。section `Concepts of Version Control' in The GNU Emacs Manual。
以前の改訂版やログ登録の履歴は、 そのパッケージの将来の管理者にとても重要なので、 たとえ公開アクセスさせない物件であっても、 いつか他の管理者に譲りたくないものは一切、 リポジトリや変更履歴に入れたりしないよう、 気を付けてください。
GNUプロジェクトでは、
GNUソフトウェアのパッケージの使用できるCVSサーバー
(subversions.gnu.org)
を提供しています
(この名前は、
CVSリポジトリーに格納される複数のバージョンや副バージョンをさします)。
必ずしもリポジトリーを使う必要はありません。
ですがもし開発中のソースへの読込み専用アクセスの公開を検討しているのなら、
色々なGNUパッケージが一括した場所にあると一般の人たちに便利です。
CVS Serverは、
cvs-hackers@gnu.orgが管理しています。
GNU ソフトウェアの配布物を作成するとき、GNU の慣習に従うことが重要です。
9.1 配布 tar ファイル 9.2 配布パッチ 9.3 ftp.gnu.org上での配布9.4 テスト・リリース
プログラム foo のバージョン m.n の tar ファイルは
`foo-m.n.tar' と名付けられるべきです。 それは
`foo-m.n' というサブディレクトリ配下に展開されるべきです。
tar ファイルは現在のディレクトリ中のファイルに展開されるべきで
はなく、なぜなら、もしそのユーザが他のファイルのあるディレクトリにたまた
ま展開してしまうと、
これでは不都合だからです。
ここにどのように Bison の `Makefile' が tar ファイルを作成するかを 示します。この手法は他のプログラムにも適しています。
dist: bison.info
echo bison-`sed -e '/version_string/!d' \
-e 's/[^0-9.]*\([0-9.]*\).*/\1/' -e q version.c` > .fname
-rm -rf `cat .fname`
mkdir `cat .fname`
dst=`cat .fname`; for f in $(DISTFILES); do \
ln $(srcdir)/$$f $$dst/$$f || { echo copying $$f; \
cp -p $(srcdir)/$$f $$dst/$$f ; } \
done
tar --gzip -chf `cat .fname`.tar.gz `cat .fname`
-rm -rf `cat .fname` .fname
|
他のファイル・システムへのシンボリック・リンクであるソース・ファイルは、
ln を使って一時ディレクトリに入れることはできないので、もし
ln が失敗すれば、cp を使ってください。
Automake を使うことは dist ターゲットを書く面倒を見るのに良い方法
です。
もしそのプログラムが大きいなら、以前の重要なリリースに対して、各リリース 用の差分の一式を作ると役に立ちます。
差分の一式の前に、 これがどのバージョン用であり、 どの以前のバージョンに対 応しているのか、簡潔な説明を置いてください。また、ソースを適切に更新する のに、人々がそれ以外のどんなことをする必要があるかを説明してください (例 えば、差分を適用する前に、あるファイルを削除、あるいは、改名せよ)。
差分を持つことの目的は、それらが小さいということです。 それらを小さく保 つために、そのユーザが容易に更新できるファイルを除いてください。 例えば、 info ファイルや、DVI ファイル、タグ・テーブル、Bison や Flex の出力ファ イルを除いてください。 Emacs の差分では、コンパイルされた Lisp ファイル を除いており、パッチを当てられたソースを再コンパイルするのは、そのインス トーラに任せています。
その差分を作るとき、各バージョンは適切に名付けられたディレクトリにあるべ きです---例えば、`gcc-2.3.2' と `gcc-2.3.3'。 こうして、その差 分がどのバージョンからどのバージョンに対するものか、それ自体で非常にはっ きりするでしょう。
もしそのパッチを作るのに、GNU diff を使うならば、オプション
`-rc2P' を使ってください。
これはどんな新しいファイルをも、
「全然違う」として、
その出力に入れるでしょう。
また、
そのパッチの context diff
のヘッダには、伝統的な Unix 形式を使って、協定世界時で日付と時間が含まれ
ているはずで、パッチを受け取った人々は GNU patch の `-Z' オ
プションを使用できます。 例えば、そのパッチを作成するのに、以下の Bourne
シェル・コマンドを使用します:
LC_ALL=C TZ=UTC0 diff -rc2P gcc-2.3.2 gcc-2.3.3 | \ gzip -9 >gcc-2.3.2-2.3.3.patch.gz |
もしその配布物にサブディレクトリがあるなら、 その差分はきっとサブディレ クトリのいくつかのファイルを含んでいます。 ユーザがそのようなパッチを信 頼性をもって組み込むのを助けるために、どうやって patch を走らせるか、正 確な手引きを与えてください。例えば、こう書きます:
To apply these patches, cd to the main directory of the program and then use `patch -p1'. `-p1' avoids guesswork in choosing which subdirectory to find each file in. |
あなたのパッチをその古いバージョンのコピーに適用し、その結果が厳密にその 新しいバージョンと一致することを点検することで、そのパッチを試験するのが 賢明です。
ftp.gnu.org 上での配布
GNU パッケージは ftp.gnu.org のディレクトリ `/gnu' によって
配布されます。 各パッケージはそのパッケージにちなんで名付けられたサブディ
レクトリを持つべきで、そのパッケージの配布ファイルは全て、このサブディレ
クトリに置かれるべきです。
どんなプログラムでも、最新のバージョンだけが ftp.gnu.org 上にある
必要があります。 過去のバージョンの保管所であることが ftp.gnu.org
の機能ではありません。
差分は別の問題です。 それらは配布ファイルよりずっと小さいので、 かなりの間、 その差分を置いておくと良いです。
ftp.gnu.org に新しいバージョンを置くことに関して、
ftp-upload@gnu.org と話してください。
もしあなたのプログラムに対して、ftp.gnu.org の FTP サイトからの毎
月のダウンロードの記録を見ることに興味があるなら、これは
ftp-upload@gnu.org があなたのために用意できることです。 興味が
あるなら、
そこに連絡してください。
あるプログラムの、大いに変更した新しいメジャー・バージョンをリリースする
とき、前試験として、そうしたいと思うかもしれません。これはつまり、tar ファ
イルを作るけど、
募集しておいた志願者の一団にだけ送るということです
(そんな人たちを募集するには、
適当な GNU のメーリング・リストやニュースグループを使ってください)。
我々は通常、
前試験や前リリースのバージョンのために、
FTP サー
バ、alpha.gnu.org を使います。 fencepost.gnu.org 上の
`~ftp/gnu' ディレクトリに置くことで、alpha.gnu.org 上に項目
を設置できます。
プログラムが広く使われるようになり、人々が満場一致で動作することを期待し たならば、 各「本当の」リリースの前に前試験のリリースを行うことは良い考 えです。
もしバージョン 4.6 をリリースするところだけど、まず前試験を行いたいなら、 それを 4.5.90 と呼んでください。 もし二つ目の前試験が必要ならば、それを 4.5.91 と呼び、以下同様です。 もし本当に不運で、10 の前試験が十分でない なら、4.5.99 の後、4.5.990 などなどに進めても構いません。
決してするべきでないことの一つは、計画されている本当のリリースと同じバー ジョン・ナンバーで前試験をリリースすることです。 多くの人々は、ある tar ファイルが最新バージョンであるかを決定するのに、そのバージョン・ナンバー (その tar ファイル名や、 解凍されるディレクトリ名、 あるいは、 その人々が見付け るところならどこでも) だけしか見ないでしょう。 人々はそのテスト・リリー スをこのように見て、それを本当のリリースと勘違いするかもしれません。 そ れゆえ、変更されたコードをリリースするとき、常にそのナンバーを変更してく ださい。
新しいリリースを行うとき、発表を行ってください。 もし好むなら、発表用の、 あなた自身メーリング・リストを管理しても良いし、司会付きの (moderated) 汎用 GNU 発表リスト、info-gnu@gnu.org を使っても構いません。
もしあなた自身のリストを使うなら、どんな出来事が発表に値するかを、あなた が考えた通りに決定できます。 もし info-gnu@gnu.org を使うなら、 前試験リリースを発表せず、本当のリリースだけに行ってください。 しかし、 本当のリリースには、バグを直すだけになされるリリースも含まれます。
www.gnu.org に格納(installation)するため、
あなたのパッケージについてのページを書い
てください。 そのページはウェブ・ページ用の、我々の通例の標準に従うべき
です
(http://www.gnu.org/server を参照)。
広範囲のブラウザをサポー
トし、一時の目の保養よりも情報に焦点を当て、そのサイトを単純で統一的に保
つために、それを決めました。
ページを組み込み、更新するための協定について、
webmasters@gnu.org と話してください。 これが行われ得る、さまざ
ま方法があります。
組み込むためのページをそこにメールしても良いし、
あなた
のためのアカウントを作っても良いし、subversions.gnu.org 上の CVS
でページを管理して、そのウェブ・サーバへ自動的にチェックアウトさせても良
いです。
いくつかの GNU パッケージはただ簡単なウェブ・ページを持っているだけです
が、よりたくさんの情報を提供すればするほど、より良いでしょう。 だから、
役に立つようにできる限りたくさん書いて、その全てを www.gnu.org 上
に置いてください。 しかし、(メールの記録やバグ追跡のような) データベース
にアクセスするページは例外です。あなたにとって便利なところならどこにでも、
それらを立ち上げ、そして、www.gnu.org 上のページをそれらにリンク
して構いません。
この章では、GNU に関する、二つの、広範囲に及び、そして、重大な誤解を正す ために重要な、用語の問題を二つ説明します。
12.1 フリー・ソフトウェアとオープン・ソース 12.2 GNU と Linux
用語「フリー・ソフトウェア (free software)」と 「オープン・ソース (open source)」は、 基本的な哲学において異なる、 二つの異なった運動の標語です。 フリー・ソフトウェア運動は理想主義的で、 自由、倫理、主義、そして、良い社会 に近付くあらゆることに関する問題を取り挙げます。 1998 年に設立されたオー プン・ソース運動は、慎重にそのような論題を回避します。 より多くの説明を 得るには、 http://www.gnu.org/philosophy/free-software-for-freedom.html を見 てください。
GNU プロジェクトはフリー・ソフトウェア運動と提携しています。 これは全ての GNU 寄付者や管理者が同意しなければならないことは意味しません。これらの問 題における、あなたの見方はあなた次第で、あなたには自分自身を語るときに、 それらを示す権利があります。
しかしながら、オープン・ソース運動ははるかに一般に知れ渡っているために、 GNU プロジェクトは GNU はオープン・ソース運動の活動であり、ずっと そうだったという、行き渡った誤印象を払拭する必要があります。 この理由の ために、GNU ソフトウェアのリリースや、GNU の解説書、そして、GNU パッケー ジの管理者としての役割で、 あなたが公表する発表や記事において、 「オープン・ソース」よりもむしろ、 「フリー・ソフトウェア」という用語を使ってください。 その差異を説明するのに、上で示した URL への参照も含めると役に立つもので す。
GNU プロジェクトは自由な Unix みたいなオペレーティング・システム、GNU を 開発するために結成されました。 このシステムの存在は我々の主要な業績です。 しかし、GNU システムの広く使われているバージョン、そこでは Linux がその カーネルとして使用されていますが、 しばしば単に「Linux」と呼ばれていま す。 結果として、ほとんどのユーザは GNU プロジェクトの主要な業績について 知りません--- あるいは、 もっと正確に、 ほとんどのユーザはそれを知っているけど、 それが GNU プロジェクトの業績であり、存在理由であることを認識していません。 本 当の歴史を知っていると信じている人々でさえ、 しばしば GNU の目標は「ツール」や「ユーティリティ」を開発することだった、 と信じています。
この混乱を訂正するために、Linux、Linus Torbalds が書いたカーネル、そして、 GNU/Linux、GNU と Linux の組み合わせであるオペレーティング・システムを区 別するために、何年もに渡る努力を続けました。GNU プロジェクトがすでに行っ たことに関する、結果として増大した関心のおかげで、GNU プロジェクトのあら ゆる活動がもっと多くの支援や寄付を募集することができます。
GNU ソフトウェアのリリースや、GNU の解説書、GNU パッケージの管理者として の役割で公表する、発表や記事において、一貫してこの区別を行ってください。 もしその用語やその理由を説明したければ、URL http://www.gnu.org/gnu/linux-and-gnu.html を参照できます。
あなたのパッケージの CVS リポジトリとして subversions.gnu.org を
使い、標準的な FTP サイトとして ftp.gnu.org を使うことを推奨した
いと思います。 もし望むなら、他のマシンを使っても構いません。 もしあなた
のプログラムのリポジトリを保持するのに、あるいは、その FTP サイトとして、
会社のマシンを使えば、人々がそのパッケージとその会社の関係について誤った
考えを持たないようにするため、そのサイトの目立つところに、この声明を置い
てください:
The programs <list of them> hosted here are free software packages of the GNU Project, not products of <company name>. We call them "free software" because you are free to copy and redistribute them, following the rules stated in the license of each package. For more information, see http://www.gnu.org/philosophy/free-sw.html. If you are looking for service or support for GNU software, see http://www.gnu.org/help/gethelp.html for suggestions of where to ask. If you would like to contribute to the development of one of these packages, contact the package maintainer or the bug-reporting address of the package (which should be listed in the package itself), or look on www.gnu.org for more information on how to contribute. |
フリー・ソフトウェア登録簿 (Free Software Directory) はある特定の判定基準内にある、 フリー・ソフトウェア・パッケージの完全な一覧であることを目指して います。 あらゆる GNU パッケージはそこに列挙されるべきなので、あなたのパッ ケージの項目の記載法に関する情報を求めるために、 bug-directory@gnu.org に連絡してください。
もし解説書における誤記を発見する助けや、執筆の質を向上させる助けが欲しかっ たり、あるいは、もしあなたが英語を母国語としておらず、優れた英語の解説書 を出版する助けが欲しいなら、 proofreaders@gnu.org GNU 校正者メーリング・リストを使うことができます。
しかし、そこには 200 人以上の人々がいるので、そのリストを使うときに注意 してください。 もしあなたの作成物を読むように、 単にそのリストのみんなにお願いすれば、 きっと校正者による骨折りには、 途方もない重複があることでしょうし、 おそらく同じ誤りを 100 回報告されるでしょう。 これは避けねばなりません。
また、そのリストの人々はそこから大量のメールを受け取りたくありません。だ から、そのリストの人々に、そのリストにメールを送るように頼まないでくださ い!
こちらに理に適っていると思われる使い方を 2、3 挙げます:
その乱数選択手法を指定するように気を付けてください。さもなければ、人々は きっと「真中ぐらいの部分を選ぶ」のような、 本当には無作為ではない、 精神的な手法を使用し、そうすると、全体をさえカバーできないでしょう。
その作成物を物理的に 20 の別個のファイルに分割しても良いし、 例えば (もしあなたの作品に大体 20 の項があるなら) 項ごとに、 論理的な分割を述べても良 いです。もし後者を行うなら、それが厳密になるように気を付けてください--- 例えば、最初の項の頭書きの前の題材を、一つの項と捉えてもらいたいのか、そ うではないのか?
| Jump to: | /
A B C D E F G H L M O P Q R T V W |
|---|
| Jump to: | /
A B C D E F G H L M O P Q R T V W |
|---|
| [Top] | [Contents] | [Index] | [ ? ] |
訳注: 日本語では何言ってるのか分かりま せんが、"person"と"she"のことです。(^^;
訳注: きっと`/gd/gnuorg/assign.translation.manual'でしょう。
少なくともfencepostには、もとのファイルはないです。
関係者には報告済みなのですが、なぜか原文はまだ訂正されていません。
訳注: 多分 GFDL の section 6 のことでしょう。
| [Top] | [Contents] | [Index] | [ ? ] |
ftp.gnu.org 上での配布
| [Top] | [Contents] | [Index] | [ ? ] |
1. このドキュメントについて
2. 引退
3. 開発者の募集
4. 法的な問題
5. 変更の整理
6. サポートするプラットホーム
7. メールの処理
8. 過去のバージョンの記録
9. 配布物
10. リリースの発表
11. ウェブ・ページ
12. 用語の問題
13. ホスティング
14. フリー・ソフトウェア登録簿
15. 校正者リストの使用
Index
| [Top] | [Contents] | [Index] | [ ? ] |
| Button | Name | Go to | From 1.2.3 go to |
|---|---|---|---|
| [ < ] | Back | previous section in reading order | 1.2.2 |
| [ > ] | Forward | next section in reading order | 1.2.4 |
| [ << ] | FastBack | previous or up-and-previous section | 1.1 |
| [ Up ] | Up | up section | 1.2 |
| [ >> ] | FastForward | next or up-and-next section | 1.3 |
| [Top] | Top | cover (top) of document | |
| [Contents] | Contents | table of contents | |
| [Index] | Index | concept index | |
| [ ? ] | About | this page |