|
このページは大阪弁化フィルタによって翻訳生成されたんですわ。 |
オープンソースのコードをめぐっては、 どなたはんかがそれを移植し、使用し、開発に協力するっちうことを妨げることのあらへんようわ、 数ようけの伝統ある良き慣習が存在してるんや。 それらの慣例のいくつかは Unix および Linux の世界で 伝統的に受け継がれてきたもんや。 その他の慣例は、 World Wide Web のような特徴ある新しい技術やツールに関連して、 きょうびになって生み出されたもんや。
この文書は正しい慣習について知るための一助となるでっしゃろ。 各章の見出しには、 それぞれがチェックリストの項目となるように要旨をまとめたんや。 あんさんの配布物が旅に出る前の点検項目とお考えしておくんなはれ。
この文書は毎月 comp.os.linux.answers に投稿されはります。
また metalab.unc.edu の pub/Linux/docs/HOWTO を含め、
数ようけの Linux FTP サイトに保管されとりまんねん。
また、この HOWTO の最新の版を World Wide Web では http://metalab.unc.edu/LDP/HOWTO/Software-Release-Practice-HOWTO.html で読むことができまんねん。
この HOWTO に関する質問や意見は Eric S. Raymond, esr@snark.thyrsus.com 宛にお気軽にお寄せしておくんなはれ。
この HOWTO の祖国語版は http://www.linux.or.jp/JF/JFdocs/Software-Release-Practice-HOWTO.html で最新のもんを読むことができまんねん。 訳文に関する質問や意見は <JF@linux.or.jp> 宛にお寄せしておくんなはれ。
なお、翻訳文には JF Project の以下の方々の意見・校正が反映されとりまんねん。
Metalab や PSA ほんで CPAN のような アーカイヴサイトの管理者にかかる負担が増えるにつれて、 登録作業の一部せやなかったらみなをプログラムによって処理するゆう傾向に なってきとります (ゴチャゴチャゆうとる場合やあれへん、要は、人間によって行われるんとちゃうちうことや)。
これによって プロジェクトとアーカイヴファイルの名称が、 計算機のプログラムによって解析し理解されるようわ、 正しい形式で名前付けされとることの重要性が増しましたわ。
もしみなのアーカイヴのファイルに GNU のような名前付け -- ゴチャゴチャゆうとる場合やあれへん、要は小文字のアルファベットから成る基本名称を頭に付けて、 ダッシュ (-) を付加し、続けてバージョン数字列、拡張子、 その他の識別子を付けるやり方 -- がされとったら、 こらどなたはんの目にもわかりやすいもんになるんですわ。
仮に `foobar' ちう名前で呼ばれとるプロジェクトの、 バージョン 1、リリース 1、パッチレベル 3 があるとしまひょ。 もしそれが単一のアーカイヴとして成立してんやったら (ワイが思うにはは ソースコードでっしゃろ)、以下のような名前付けがええでっしゃろ:
ソースアーカイヴ
LSM ファイル (Metalab に登録する場合).
次のようなんは ダメ や:
こらようけのプログラムに `foobar123' ちう名の プロジェクトのバージョン番号のあらへんアーカイヴと見なされてしまいまんねん。
こらようけのプログラムに `foobar1' ちう名の プロジェクトのバージョン 2.3 のアーカイヴと見なされてしまいまんねん。
ようけのプログラムはこいつを `foobar-v1' ちう名のプロジェクトやと解釈されてしまいまんねん。
アンダースコアは人間が喋りにくいし、 入力しづらいし、覚えにくいや。
小賢しい利己主義者思われても 構へん やったらば。 おまけにこら喋りにくいし、入力しづらいし、覚えにくいや。
ファイル名によってソースとバイナリアーカイヴや、 異なる種類のバイナリを区別したり、 ビルドの時のオプションのたぐいを表現する必要があるやったら、 それらはバージョン番号の後に付加するファイル識別子として 取り扱うようにしておくんなはれ。ゴチャゴチャゆうとる場合やあれへん、要は、以下のような方法や:
ソースコード
バイナリ (タイプは不明)
ELF バイナリ
静的にリンクされた ELF バイナリ
SPARC 向けバイナリ
`foobar-ELF-1.2.3.tar.gz' みたいなんはやめまひょ。 こらプログラムが基本名称から内部識別子 (`-ELF' のような部分) を 導き出しにくなるからや。
よい名前の一般的形式は、以下のような部分から順番に成り立っとります:
-).)
プロジェクトやコミュニティによっては、 名前付けとバージョン番号についてようわかるように定義された慣習があり、 その場合は上記のアドバイスにやったらう必要はおまへん。 例あげたろか、たとえばやなあ Apache のモジュールには mod_foo のような名前が一般的に使われており、 それ自身のバージョン番号とそれが動作する Apache のバージョン番号の両方が 付加されとりまんねん。 同様に Perl のモジュールには浮動小数点として取り扱い可能なバージョン番号 が付けられてて (例あげたろか、たとえばやなあ 1.3.3 のような形式よりも 1.303 のような形式を 見ることが多いでっしゃろ)、Foo::Bar ちうモジュールのバージョン 1.303 の 配布物には、Foo-Bar-1.303.tar.gz ちう名称が付けられはることが一般的や。
コミュニティと開発集団に独自の慣習を調べ、それを大切にしておくんなはれ。
基本名称はプロジェクトのファイル全体を通して共通のもんとし、
そら読みやすく、入力しやすく、ほんで覚えやすいもんにすなあかんのです。
アンダースコア(_)を使うんはやめまひょ。
それと、格段の理由のあらへん限り、
全体せやなかったら一部にでも大文字を使うんはやめまひょ。
人間の目視による自然な検索順序を困惑させることになるんやし、
まるで小賢しく立ち振舞おうとする下衆な利己主義者みたいやないやろか。
ふたつの異なるプロジェクトが同じ基本名称を持つと、みんなが混乱しまっせ。 この世におぎゃあいうて生まれてはじめてのリリースの前には名前が衝突してへんかをチェックしまひょ。 このチェックには index file of Metalab が便器...おっとちゃうわ、便利や。
あんさんの選択するライセンスには、 共同開発者たちとユーザの間で合意したい 社会的な契約事項が定義されることになるんですわ。 また、ソフトウェアに授けた著作権は、 ソフトウェアとそこからの派生物に関するライセンス事項において、 主としてあんさんの権利を法的に主張するもんとして機能しまっせ。
パブリック・ドメインやないかぎり、みなの著作物には、 ひとないしは複数の著作権が存在してるんや。 ベルヌ条約 (1978 年からアメリカ合衆国でも有効な法律) の元では、 著作権は必ずしも明示されへんでもよいことになっとりまんねん。 したがちう、仮に著作権が明示されていないからいうても、 著作者は著作権を保持してんことになるんですわ。
どなたはんを著作者としてカウントするか、ちうことは、 特に多数の人の手が加わったソフトウェアの場合、エライ難問となり得まんねん。 ライセンス条項が重要である理由がここにおます。 協定の内容によっては、それを設定するっちうことによって、 著作権の保持者による独断的な行動から自身を守る権利を、 ユーザたちにも認めることができるようになるんですわ。
独占状態にあるソフトウェアでは、 ライセンス条項は専ら著作権を保護するもんとして設計されとりまんねん。 所有者 (著作権保持者) には法的分野における幅広い権利を認める一方で、 ユーザにはほんのわずかいな権利しか認めへん、ちうやり方や。 著作権保持者こそがいっちゃん重要なんやし、 またライセンスの論理における制限がごっつう厳しいために、 ライセンス条項そのもんの厳密な特記事項は 大抵の場合あんまり重要でへんかったりしまっせ。
オープン・ソース・ソフトウェアにおいては、状況はまるっきし正反対や。 著作権はライセンスを保護するために存在してるんや。 著作権保持者が常に維持できる唯一の権利は、 ライセンスをつよ主張するっちうことだけや。 その一方で、ほんのわずかいな権利を除く、ほとんどみなの選択権はユーザにおます。 とりわけ、著作権保持者はすでに人手に渡ったコピーに関する条項は変更でけしまへん。 それやから、オープン・ソース・ソフトウェアにおいては、 著作権保持者はほとんど無力や。 せやけどダンさん、ライセンス条項はどエライ重要な意味を持っとりまんねん。
通常、プロジェクトの著作権保持者はその時点でのプロジェクトリーダーか、 プロジェクトを援助してん組織や。 プロジェクトを新しいリーダーに引き継ぐことが、 著作権保持者が変わることによって示されることもようおます。 そやかて、こらぜぇぇぇったい的に堅固なルールちうわけやおまへん。 例あげたろか、たとえばやなあようけのオープン・ソース・プロジェクトには 複数の著作権保持者が存在してるんやが、 このことが法的な問題を引き起こしたゆう 実例は過去におまへん。
いくつかのプロジェクトは 著作権を Free Software Foundation に譲渡するっちうことを選択してるんや。 この組織はオープン・ソースを防御するっちうことに関心があり、 そのために法律家の力も借りることができる、ちう考えに基づくもんや。
実際のライセンス供与にあたり、 そのライセンスが誘引するいくつかの異なりよった種類の権利について、 区別して考えることができまんねん。 複製・再配布する権利、 使用する権利、 個人的な用途にあわせて改変する権利、ほんで 改変したもんの複製物を再配布する権利や。 どの権利においてもライセンスによって制限が加えられはる可能性がおます。
あるソフトウェアを ``オープン・ソース'' せやなかったら ``フリー'' (古くさかいの用語) と定義づける条件について、深く掘り下げて考察した結果が Open Source Initiative にまとめられとりまんねん。 ここではライセンスに関して以下のような制限事項が要求されとります :
このガイドラインでは 改変をほどこしたバイナリの再配布に関する制限も 禁止されとりまんねん。 こら、余計な負担を強いられはることなく、 オノレたちの作業したコードを提供したいゆう ソフトウェア・ディストビュータのニーズに合わせた結果や。 一方で改変したソース・コードは 改変前のソース・コードとそれに対するパッチの組合わせで再配布されるようわ、 作者が要求するっちうことを認めとりまんねん。 これによって当初の作者の意図と、 第三者による改変の様子を ``追跡調査'' する仕組みが確立できることになるんですわ。
OSD は `OSI Certified Open Source (OSI 公認オープン・ソース)' 認定マーク の法的な定義なんやし、 どないな人でも歩み寄れるように ``フリー・ソフトウェア'' を より良う定義したもんや。 みなの標準的なライセンス (MIT, BSD, Artistic, ほんで GPL/LGPL) がこれに合致します (せやけど、GPL のよないくつかのライセンスには、 それを選択する前に理解せなならへん別の制限事項も存在してるんや)。
非商用に限定して使用を許可するライセンスは、 たとえ ``GPL'' せやなかったら その他の標準ライセンスによる装飾がされとったとしたかて、 オープン・ソースのライセンス形態は 満たしておらへん ことに用心しておくんなはれ。 そら特定の職業、人間、集団を差別するもんなんやこれがホンマに。 ほんで、CD-ROM 配布業者や オープン・ソース・ソフトウェアをショーバイ的に普及させようとする人々にとっては、 どエライ悩ましい頭痛の種となるちうワケや。
これまでに説明してきた一般法則を実践に移す方法について説明しまっせ。
法律家を擁するスポンサー団体による支援がある場合、 その団体に著作権を渡したい、ちうケースもあるでっしゃろ。
Open Source Definition は、 この世界におけるライセンスの確固たる標準や。 OSD そのもんはライセンス条項やのうて、 あるライセンス条項がオープン・ソース・ライセンスとして 機能するっちうことを保証するための、 必要最小限の権利関係を定義づけるもんといえまんねん。 OSD とそれを補足するもんは Open Source Initiative のウェブ・サイトから入手できまんねん。
すでに普及してん OSD 準拠のライセンスには、 エライよう確立された伝統ある解釈が盛り込まれとりまんねん。 開発者は (その気さえあれば、ユーザも) それらが意図するもんを理解しとり、 納得できるんやったらリスクを引き受け、 ほんで自らの関与したもんを交換取引するんや。 やから、 可能な限り OSI のサイトにある標準的なライセンスのどれかを 利用するようにしまひょ。
もしオノレ自身でライセンス条項を書かなならへんやったら、 OSI によって認定を受けるようにしまひょ。 これによって際限のあらへん論争と無駄を回避するっちうことができるでっしゃろ。 ライセンスについての議論の応酬がいかに始末に負えへんもんになるか、 あんさんがそれを経験しておらへんやったら想像もつかいないやろけど、 ライセンスはオープン・ソース社会の真核部分に触れる ほとんど宗教がかった誓約に関するもんやから、 人々はつい激情に駆られやすくなってまうのや。
さらにいうたら、 もしあんさんのライセンス条項が法廷で審判を受けることになったら、 すでに確立された解釈体系の存在がいかに重要であるか、 証明されることになるでっしゃろ。 これを書いとる時点 (1999 年後半) では、 どのオープン・ソース・ライセンスに関したかて、 有効・チャラのどちらの判例もおまへん。 そやかて、こら起源となりよった共同体においては当然予期され、 また妥当な慣習に基づいたライセンス条項および契約事項であると 法廷で解釈されるはずの、法律的に有効な主張や (なんぼなんでもアメリカ合衆国では。 ほんでワイが思うにはイングランドとそれ以外のブリテン諸国やらなんやら、 他の慣習法に則った国々でも)。
ここで触れる話題のほとんどは、Linux 圏のみやったらへんし、 他の Unix も含めた移植性の確保に関係するもんや。 他の Unix へ移植可能であるちうことは、 プロフェッショナリズムとハッカー主義の美徳であるだけでなく、 将来において Linux 自体に変身が起きた場合にそなえた 貴重な保険ちうこともできまんねん。
結論から言うたら、どなたはんかがあんさんのコードを Linux 以外のシステムにおいて ビルドしたろとおもうんは明らかや。 移植性を高めておけば、あんさんが受け取る煩わしうて難儀な email の数を 減らすことができるでっしゃろ。
移植性と安定性のために、ANSI C もしくは可搬性の保証されとるスクリプト言語を 使いまひょ。 プラットフォームを越えて単一の実装が存在してんねんさかいや。
これに適合するスクリプト言語としては、 Python, Perl, Tcl, ほんで Emacs Lisp やらなんやらがおます。 プレインな古くさい shell は不合格や。 ビミョーな違いのあるんや、ようけの異なる実装が存在してるんやし、 エイリアスのようなユーザカスタマイズによって、 shell の実行環境が ごちゃごちゃになっとることも想定されるさかいや。
Java は可搬性の高い言語であることを約束してるんやが、 今のトコ Linux で利用できる実装は完全やのうて、 Linux との親和性も貧弱や。 Java は成熟するに連れてさらに人気を増していくように見えまっけど、 現時点ではまだ薄氷を踏むような選択と言えまんねん。
C 言語で開発してんやったら、ANSI で用意されたずぅぇえええぇぇええんぶの機能を 好きなように使うておくんなはれ。モジュール間の矛盾を洗い出すために 便利ええファンクション・プロトタイプもこれに含まれはります。 旧式の K&R コンパイラはすでに歴史の遺物や。
その一方で、例あげたろか、たとえばやなあ `-pipe' オプションやネストされた関数構造やらなんやら、 GCC 固有の機能が使えると仮定してはいけまへん。 どなたはんかが Linux 以外、GCC 以外のシステムに移植する際に、 この問題が付きまとい、困らせることになるんですわ。
C 言語で開発してんやったら、システムの環境設定を探査したり、 makefile を仕立てたりといった、可搬性にまつわる事柄を操作するために、 autoconf/automake/autoheader ユーティリティーを使いまひょ。 今日では、ソースからビルドする際に、 "configure; make" とタイプして、 きれいに、ほんで正しく作り上げられはることを人々は期待してまんねん。
C 言語で開発してん場合は、 リリースの前になんぼなんでも一回は -Wall オプションを付けてテストコンパイルを行い、 アヤマチが出ぇへんことを確認しまひょ。 こらどエライようけのアヤマチを検出しまっせ。 究極を目指すんやったら、-pedantic オプションを付けてコンパイルしてみまひょ。
Perl で書いとる場合は、コードに -c (場合によっては -T) オプションを付けて チェックしてみまひょ。信心深く行うんやったら perl -w と `use strict' やね (これについては Perl のドキュメントを参照しておくんなはれ)。
これから述べるガイドラインでは、どなたはんかが配布物をダウンロードし、中身を取り出して 展開した際に、配布物はどないな風に現れなあかんか、ちう事を説明しまっせ。
開発のどシロウトが冒しやすい誤りの中で、もっともわずらわしいもんは、 配布物中のファイルとディレクトリをカレントディレクトリにぶちまけ、 すでにそこにあるファイル群を上書きする可能性のある tarball を作ってまう、ゆうものや。 こうしてはぜぇぇぇったいにいけまへん！
これを避けるには、アーカイヴされたファイルをみなプロジェクト名で始まる 専用のディレクトリに入れれば、現在のディレクトリの直下 にあるんや、単一のトップ・ディレクトリの中に展開されるでっしゃろ。
これを完璧に行うための makefile の裏技がおます。 配布物のディレクトリが `foobar' ちう名前で、 SRC ちう変数には配布ファイルのリストが入っとるとしまっせ。 これには GNU tar 1.13 が必要や。
VERS=1.0
foobar-$(VERS).tar.gz:
tar --name-prefix='foobar-$(VERS)/' -czf foobar-$(VERS).tar.gz $(SRC)
もし古くさい tar を使うておる場合は、以下のようにしまっせ。
foobar-$(VERS).tar.gz:
@ls $(SRC) | sed s:^:foobar-$(VERS)/: >MANIFEST
@(cd ..; ln -s foobar foobar-$(VERS))
(cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz `cat foobar/MANIFEST`)
@(cd ..; rm foobar-$(VERS))
ソース配布物のロードマップとなる README もしくは READ.ME ちうファイルを 用意しまひょ。古来の言い伝えでは、こらソースを展開した勇敢なる探検者たちが 最初に目にして読むはずの書、ちうことになっとりまんねん。
README の中に書いておきたい項目は:
README ファイルを読むより先に、 勇敢なる探検者たちは展開した 配布物のトップディレクトリのファイル名を探索するやろな。 ファイルの名称は、それ自体が情報を含んでおりますわ。 標準的な名前付けの慣例を踏襲するっちうことによって、 次に何を見なあかんなんかちう重要な手がかりを、探検者たちに示すことができまんねん。
標準的なトップレベルのファイル名とそれが意味するもんについて説明しまひょ。 配布物にこれらぜええんぶひとつのこらずが必要やおまへん。
最初に読む案内書
設定・ビルド・インストール方法の解説
プロジェクトに対する貢献者のリスト
プロジェクトに関するきょうびのニュース
プロジェクトの履歴
プロジェクトのライセンス (GNU 流の慣習)
プロジェクトのライセンス
配布物に含まれるファイルの一覧
プロジェクトに関して、よう尋ねられはる質問とその回答を記したプレインテキストのドキュメント
Emacs や vi で利用するタグファイル
これらのファイル名がみな大文字で構成されとるちう慣習は、 それらがビルドの部品として使われるのやなく、 パッケージに関する一般的情報を含んや人間が読むべきもんやと 暗示してんことに用心しておくんなはれ。
インストールに使われるバイナリパッケージの事実上の標準フォーマットは、 Red Hat Package Manager, RPM や。 こらもっとも人気のある Linux ディストリビューションのええトコとなっており、 事実上他の Linux ディストリビューションでも サポートされとります (Debian と Slackware は除きまんねん。 せやけど Debian では RPM からインストールするっちうことも可能や)。
したがちう、ソースコードの tarball と同様に、 インストール可能な RPM 形式のファイルを プロジェクトのサイトで提供するんはええ考えや。
また、ソース・コードの tarball の中には RPM の spec ファイルを含め、 Makefile の中ではそこから RPM を生成する仕組みを提供するんもええ考えでっしゃろ。 spec ファイルには rpm の -t オプションで tarball から見つけられはるように、 `.spec' ちう拡張子を与えておきまひょ。
形式に関して点数を稼ぎたいやったら、 Makefile せやなかったら version.h を読み込んで正しいバージョン番号をなあんもせんとホッタラかしといても 返すような Shell スクリプトを利用し、spec ファイルを生成するようにしまひょ。
あんさんのソフトウェアは、 その存在を知られへん限り世界に貢献するっちうことはでけしまへん。 また、プロジェクトの存在をインターネット上で明らかにするっちうことは、 ユーザを増やしたり共同開発者を募んのに役立つでっしゃろ。 これについての標準的な手法に関して解説しまっせ。
comp.os.linux.announce で新たなリリースのお知らせをしまひょ。
それ自体がよう購読されとる Newsgroup である上に、 Freshmeat のような Web ベースで新着情報を扱うサイトへも転送されとりまんねん。
あんさんのアプリケーションに直接関連する USENET の Newsgroup を見つけて、 ほんでもアナウンスしまひょ。 慎みを持ちう、 ソフトウェアとしての機能が関係する Newsgroup にのみ投稿しておくんなはれ。
例あげたろか、たとえばやなあ IMAP サーバに問い合わせを行う Perl で書かれたプログラムを リリースしたろおもておるやったら、 間違いなく comp.mail.imap には投稿すなあかんでっしゃろ。 せやけどダンさんプログラムが Perl の先鋭的テクニックのお手本にもなるもんやないと、 ワイが思うには comp.lang.perl には投稿せん方がよいでっしゃろ。
アナウンスにはプロジェクトの Web サイトの URL も示しておきまひょ。
(訳注: 祖国語の Newsgroup では
fj.sources
でソフトウェア公開のアナウンスがされとりまんねん。
本来テキストエンコードされたソースコードのアーカイブを、
直接投稿する Newsgroup やったが、
きょうびはアナウンスのみを投稿するっちうことの方が増えとりまんねん。
投稿する記事には Followup-To: ヘッダで
fj.sources.d
を指定するっちうことがマナーとなっとりまんねん。)
プロジェクトのユーザせやなかったら開発者のコミュニティを しっかりと築くことを目指すんやったらば、 Web サイトを用意した方がよいでっしゃろ。 Web サイトに用意する標準的な内容は以下のようなもんや:
プロジェクトのサイトによっては、 一次ソースツリーへの匿名アクセスが可能な URL を用意するっちうこともおます。
開発の協力者が交流を行い、パッチを交換できるような非公開のメーリングリストを 用意するっちうことが一般によう行われとりまんねん。 プロジェクトの進歩状況を知らせて欲しい人々を対象とした、アナウンスのための メーリングリストがあってもよいでっしゃろ。
ここ数年の間、 Metalab archive は Linux のソフトウェアのための重要な拠点となってきましたのや。
それ以外に以下のような重要なサイトがおます:
関係者がみなボランティアである場合、 プロジェクトを上手に運用するゆうことは、 それ自体が特殊な課題となるんですわ。 このことは、この HOWTO で取り上げるには大きすぎる題材や。 幸いなことに、これに関する要点を理解するための助けとなる、 幾つかの文書が存在してるんや。
基礎となる開発集団と、 '早目にリリース、しょっちゅうリリース' の 'バザール・モデル' に関しては、 The Cathedral and the Bazaar (伽藍とバザール) を参照しておくんなはれ。
動機付けに関する考察、共同体の風習、衝突の解決といった話題については、 Homesteading the Noosphere (ノウアスフィアの開墾) をご覧しておくんなはれ。
経済的側面と適切なビジネス・モデルに関しては、 The Magic Cauldron (魔法のおなべ). を参照しておくんなはれ。
これらの文書はオープン・ソース開発に関する決定版ちうわけやおまへん。 せやけどダンさん、もっともはよに書かれた意義深い分析なんやし、 これに代わる文書は未だに出てきてへんねん。
(訳注: この節で取り上げた文書の翻訳が以下で参照できまんねん。