<!doctype linuxdoctr system>

<article>

<title>Software Release Practice HOWTO
<author>Eric S. Raymond &lt;esr@thyrsus.com&gt;
<date>v2.0, 18 September 1999
<trans>福島於修 &lt;fuku@amorph.rim.or.jp&gt;
<tdate>v2.0j1, 08 October 1999

<abstract>
<!--
This HOWTO describes good release practices for Linux open-source projects.
By following these practices, you will make it as easy as possible for
users to build your code and use it, and for other developers to understand
your code and cooperate with you to improve it.

This document is a must-read for novice developers.  Experienced developers 
should review it when they are about to release a new project.  It will be
revised periodically to reflect the evolution of good-practice standards.
-->
この HOWTO では Linux でのオープンソース・プロジェクトの公開にかかわる
望ましい慣例について解説します。
これらの慣例を踏襲することによって、
ユーザがソースコードからビルドして使用することが大変容易になりますし、
他の開発者はコードの内容を理解し、
改良に協力することができます。

この文書は開発の初心者にとっては必読のものです。
経験をつんだ開発者にとっても、
新しいプロジェクトをリリースする前に再確認すべき点を含んでいます。
この文書は、標準的な望ましい慣例の実情を反映して、
定期的に改訂する予定です。
</abstract>

<toc>

<sect><!-- Introduction -->はじめに
<p>
<sect1><!-- Why this document? -->この文書が書かれた背景
<p>
<!--
There is a large body of good-practice traditions for open-source code that
helps other people port, use, and cooperate with developing it.  Some of these
conventions are traditional in the Unix world and predate Linux; others
have developed recently in response to particular new tools and technologies
such as the World Wide Web.

This document will help you learn good practice.  It is organized into
topic sections, each containing a series of checklist items.  Think of
these as a pre-flight checklist for your distribution.
-->
オープンソースのコードをめぐっては、
誰かがそれを移植し、使用し、開発に協力することを妨げることのないよう、
数多くの伝統ある良き慣習が存在しています。
それらの慣例のいくつかは Unix および Linux の世界で
伝統的に受け継がれてきたものです。
その他の慣例は、
World Wide Web のような特徴ある新しい技術やツールに関連して、
最近になって生み出されたものです。

この文書は正しい慣習について知るための一助となるでしょう。
各章の見出しには、
それぞれがチェックリストの項目となるように要旨をまとめました。
あなたの配布物が旅に出る前の点検項目とお考え下さい。

<sect1><!-- New versions of this document -->この文書の最新の版
<p>
<!--
This document will be posted monthly to the newsgroups
<tt>comp.os.linux.answers</tt> . The document is archived on a number
of Linux FTP sites, including <tt>metalab.unc.edu</tt> in 
<tt>pub/Linux/docs/HOWTO</tt>.

You can also view the latest version of this HOWTO on the World
Wide Web via the URL <url
url="http://metalab.unc.edu/LDP/HOWTO/Software-Release-Practice.html">.

Feel free to mail any questions or comments about this HOWTO to 
Eric S. Raymond, <url 
url="mailto:esr@snark.thyrsus.com" name="esr@snark.thyrsus.com">. 
-->

この文書は毎月 <tt>comp.os.linux.answers</tt> に投稿されます。
また <tt>metalab.unc.edu</tt> の <tt>pub/Linux/docs/HOWTO</tt> を含め、
数多くの Linux FTP サイトに保管されています。

また、この HOWTO の最新の版を World Wide Web では
<url url="http://metalab.unc.edu/LDP/HOWTO/Software-Release-Practice-HOWTO.html">
で読むことができます。

この HOWTO に関する質問や意見は
Eric S. Raymond, <url 
url="mailto:esr@snark.thyrsus.com" name="esr@snark.thyrsus.com">
宛にお気軽にお寄せ下さい。

<sect2>翻訳文に関して
<p>
この HOWTO の日本語版は <url
url="http://www.linux.or.jp/JF/JFdocs/Software-Release-Practice-HOWTO.html">
で最新のものを読むことができます。
訳文に関する質問や意見は &lt;JF@linux.or.jp&gt; 宛にお寄せ下さい。

なお、翻訳文には JF Project の以下の方々の意見・校正が反映されています。
<itemize>
<item>武井伸光さん &lt;takei@cc.kochi-u.ac.jp&gt;
</itemize>

<sect><!-- Good project- and archive- naming practice -->
正しいプロジェクトとアーカイヴの命名規則についての提案
<p>
<!--
As the load on maintainers of archives like Metalab, the PSA site and CPAN
increases, there is an increasing trend for submissions to be processed
partly or wholly by programs (rather than entirely by a human).

This makes it more important for project and archive-file names to fit
regular patterns that computer programs can parse and understand.
-->
Metalab や PSA そして CPAN のような
アーカイヴサイトの管理者にかかる負担が増えるにつれて、
登録作業の一部あるいは全てをプログラムによって処理するという傾向に
なってきています
(つまり、人間によって行われるのではないということです)。

これによって
プロジェクトとアーカイヴファイルの名称が、
計算機のプログラムによって解析し理解されるよう、
正しい形式で名前付けされていることの重要性が増しました。

<sect1><!-- Use GNU-style names with a stem and major.minor.patch numbering. -->基本名称 + major.minor.patch 番号という GNU スタイルを使いましょう
<p>
<!--
It's helpful to everybody if your archive files all have GNU-like
names - - all-lower-case alphanumeric stem prefix, followed by a dash,
followed by a version number, extension, and other suffixes.
-->
もし全てのアーカイヴのファイルに GNU のような名前付け --
つまり小文字のアルファベットから成る基本名称を頭に付けて、
ダッシュ (-) を付加し、続けてバージョン数字列、拡張子、
その他の識別子を付けるやり方 -- がされていたら、
これは誰の目にもわかりやすいものになります。

<!--
Let's suppose you have a project you call `foobar' at version 1,
release 2, level 3.  If it's got just one archive part (presumably the
sources), here's what its names should look
-->
仮に `foobar' という名前で呼ばれているプロジェクトの、
バージョン 1、リリース 1、パッチレベル 3 があるとしましょう。
もしそれが単一のアーカイヴとして成立しているなら (おそらくは
ソースコードでしょう)、以下のような名前付けがいいでしょう:

<descrip>
<tag>foobar-1.2.3.tar.gz</tag> ソースアーカイヴ

<tag>foobar.lsm</tag> LSM ファイル (Metalab に登録する場合).

</descrip>

<!--
Please <em>don't</em> use these:

<descrip>
<tag>foobar123.tar.gz</tag>This looks to many programs like an archive
for a project called`foobar123' with no version number.

<tag>foobar1.2.3.tar.gz</tag>This looks to many programs like an archive
for a project called `foobar1' at version 2.3.

<tag>foobar-v1.2.3.tar.gz</tag> Many programs think this goes with a
project called `foobar-v1'.

<tag>foo_bar-1.2.3.tar.gz</tag> The underscore is hard for people to speak,
type, and remember

<tag>FooBar-1.2.3.tar.gz</tag> Unless you <em>like</em> looking like a
marketing weenie.  This is also hard for people to speak, type, and remember.
</descrip>
-->
次のようなのは <em>ダメ</em> です:

<descrip>
<tag>foobar123.tar.gz</tag>これは多くのプログラムに `foobar123' という名の
プロジェクトのバージョン番号のないアーカイヴと見なされてしまいます。

<tag>foobar1.2.3.tar.gz</tag>これは多くのプログラムに `foobar1' という名の
プロジェクトのバージョン 2.3 のアーカイヴと見なされてしまいます。

<tag>foobar-v1.2.3.tar.gz</tag>多くのプログラムはこいつを `foobar-v1'
という名のプロジェクトだと解釈されてしまいます。

<tag>foo_bar-1.2.3.tar.gz</tag>アンダースコアは人間が喋りにくいし、
入力しづらいし、覚えにくいです。

<tag>FooBar-1.2.3.tar.gz</tag>小賢しい利己主義者と思われても
<em>構わない</em>
ならば。 おまけにこれは喋りにくいし、入力しづらいし、覚えにくいです。
</descrip>

<!--
If you have to differentiate between source and binary archives, or
between different kinds of binary, or express some kind of build
option in the file name, please treat that as a file extension to go
<em>after</em> the version number. That is, please do this:
-->
ファイル名によってソースとバイナリアーカイヴや、
異なる種類のバイナリを区別したり、
ビルドの時のオプションのたぐいを表現する必要があるなら、
それらはバージョン番号の<em>後に</em>付加するファイル識別子として
取り扱うようにしてください。つまり、以下のような方法です:

<!--
<descrip>
<tag>foobar-1.2.3.src.tar.gz            </tag> sources

<tag>foobar-1.2.3.bin.tar.gz            </tag> binaries, type not specified

<tag>foobar-1.2.3.bin.ELF.tar.gz        </tag> ELF binaries

<tag>foobar-1.2.3.bin.ELF.static.tar.gz </tag> ELF binaries statically linked 

<tag>foobar-1.2.3.bin.SPARC.tar.gz      </tag> SPARC binaries
</descrip>
-->
<descrip>
<tag>foobar-1.2.3.src.tar.gz            </tag> ソースコード

<tag>foobar-1.2.3.bin.tar.gz            </tag> バイナリ (タイプは不明)

<tag>foobar-1.2.3.bin.ELF.tar.gz        </tag> ELF バイナリ

<tag>foobar-1.2.3.bin.ELF.static.tar.gz </tag> 静的にリンクされた ELF バイナリ

<tag>foobar-1.2.3.bin.SPARC.tar.gz      </tag> SPARC 向けバイナリ
</descrip>

<!--
Please <em>don't</em> use names like `foobar-ELF-1.2.3.tar.gz', because
programs have a hard time telling type infixes (like `-ELF') from the
stem.
-->
`foobar-ELF-1.2.3.tar.gz' みたいなのは<em>やめましょう</em>。
これはプログラムが基本名称から内部識別子 (`-ELF' のような部分) を
導き出しにくくなるからです。

<!--
A good general form of name has these parts in order:

<enum>
<item>project prefix
<item>dash
<item>version number
<item>dot
<item>"src" or "bin" (optional)
<item>dot or dash (dot preferred)
<item>binary type and options (optional)
<item>archiving and compression extensions
</enum>
-->

よい名前の一般的形式は、以下のような部分から順番に成り立っています:

<enum>
<item>プロジェクトの基本名称
<item>ダッシュ (<tt>-</tt>)
<item>バージョン番号
<item>ドット (<tt>.</tt>)
<item>"src" または "bin" (任意)
<item>ドットまたはダッシュ (ドットが望ましい)
<item>バイナリタイプと付記事項 (任意)
<item>アーカイヴと圧縮手段の識別子
</enum>

<sect1><!-- But respect local conventions where appropriate -->
それでも「郷に入っては郷に従いましょう」
<p>
<!--
Some projects and communities have well-defined conventions for names and
version numbers that aren't necessarily compatible with the above advice.
For instance, Apache modules are generally named like mod_foo, and have
both their own version number and the version of Apache with which they
work.  Likewise, Perl modules have version numbers that can be treated as
floating point numbers (e.g., you might see 1.303 rather than 1.3.3), and
the distributions are generally named Foo-Bar-1.303.tar.gz for version
1.303 of module Foo::Bar.</p>

<p>Look for and respect the conventions of specialized
communities and developers; for general use, follow the above
guidelines.</p>
-->

プロジェクトやコミュニティによっては、
名前付けとバージョン番号について明確に定義された慣習があり、
その場合は上記のアドバイスにならう必要はありません。
たとえば Apache のモジュールには mod_foo のような名前が一般的に使われており、
それ自身のバージョン番号とそれが動作する Apache のバージョン番号の両方が
付加されています。
同様に Perl のモジュールには浮動小数点として取り扱い可能なバージョン番号
が付けられていて (たとえば 1.3.3 のような形式よりも 1.303 のような形式を
見ることが多いでしょう)、Foo::Bar というモジュールのバージョン 1.303 の
配布物には、Foo-Bar-1.303.tar.gz という名称が付けられることが一般的です。</p>

<p>
コミュニティと開発集団に独自の慣習を調べ、それを大切にしてください。
</p>

<sect1><!-- Try hard to choose a name prefix that is unique and easy to type-->
プロジェクトには特徴ある、入力しやすい基本名称を選びましょう
<p>
<!--
The stem prefix should be common to all a project's files, and it
should be easy to read, type, and remember.  So please don't use
underscores.  And don't capitalize or BiCapitalize without extremely
good reason - - it messes up the natural human-eyeball search order and
looks like some marketing weenie trying to be clever.

It confuses people when two different projects have the same stem name.
So try to check for collisions before your first release.  A good place
to check is the <url url="http://metalab.unc.edu/pub/Linux" name="index
file of Metalab">.
-->
基本名称はプロジェクトのファイル全体を通して共通のものとし、
それは読みやすく、入力しやすく、そして覚えやすいものにするべきです。
アンダースコア(<tt>_</tt>)を使うのはやめましょう。
それと、格段の理由のない限り、
全体あるいは一部にでも大文字を使うのはやめましょう。
人間の目視による自然な検索順序を困惑させることになりますし、
まるで小賢しく立ち振舞おうとする下衆な利己主義者みたいじゃないですか。

ふたつの異なるプロジェクトが同じ基本名称を持つと、みんなが混乱します。
はじめてのリリースの前には名前が衝突してないかをチェックしましょう。
このチェックには
<url url="http://metalab.unc.edu/pub/Linux" name="index
file of Metalab"> が便利です。

<sect><!-- Good licensing and copyright practice: the theory -->正しいライセンスと著作権に関する提案: 基礎篇
<p>
<!--
The license you choose defines the social contract you wish to set up
among your co-developers and users.  The copyright you put on the software
will function mainly as a legal assertion of your right to set license
terms on the software and derivative works of the software.
-->
あなたの選択するライセンスには、
共同開発者たちとユーザの間で合意したい
社会的な契約事項が定義されることになります。
また、ソフトウェアに授けた著作権は、
ソフトウェアとそこからの派生物に関するライセンス事項において、
主としてあなたの権利を法的に主張するものとして機能します。

<sect1><!-- Open source and copyrights -->オープン・ソースと著作権
<p>
<!-- 
Anything that is not public domain has a copyright, possibly more than
one.  Under the Berne Convention (which has been U.S. law since 1978),
the copyright does not have to be explicit.  That is, the authors of a
work hold copyright even if there is no copyright notice.<P>
-->
パブリック・ドメインでないかぎり、全ての著作物には、
ひとつないしは複数の著作権が存在しています。
ベルヌ条約 (1978 年からアメリカ合衆国でも有効な法律) の元では、
著作権は必ずしも明示されなくてもよいことになっています。
したがって、仮に著作権が明示されていなくても、
著作者は著作権を保持していることになります。

<!--
Who counts as an author can be very complicated, especially for software
that has been worked on by many hands.  This is why licenses are 
important.  By setting out the terms under which material can be used,
they grant rights to the users that protect them from arbitrary
actions by the copyright holders.<P>
-->
誰を著作者としてカウントするか、ということは、
特に多数の人の手が加わったソフトウェアの場合、大変な難問となり得ます。
ライセンス条項が重要である理由がここにあります。
協定の内容によっては、それを設定することによって、
著作権の保持者による独断的な行動から自身を守る権利を、
ユーザたちにも認めることができるようになります。

<!--
In proprietary software, the license terms are designed to protect the
copyright.  They're a way of granting a few rights to users while
reserving as much legal territory is possible for the owner (the
copyright holder).  The copyright holder is very important, and the
license logic so restrictive that the exact technicalities of the
license terms are usually unimportant.
-->
独占状態にあるソフトウェアでは、
ライセンス条項は専ら著作権を保護するものとして設計されています。
所有者 (著作権保持者) には法的分野における幅広い権利を認める一方で、
ユーザにはほんのわずかな権利しか認めない、というやり方です。
著作権保持者こそが一番重要であり、
またライセンスの論理における制限があまりに厳しいために、
ライセンス条項そのものの厳密な特記事項は
大抵の場合あまり重要でなかったりします。

<!--
In open-source software, the situation is usually the exact opposite;
the copyright exists to protect the license.  The only rights the
copyright holder always keeps are to enforce the license.  Otherwise,
only a few rights are reserved and most choices pass to the user.  In
particular, the copyright holder cannot change the terms on a copy you
already have.  Therefore, in open-source software the copyright holder
is almost irrelevant - - but the license terms are very important.
-->
オープン・ソース・ソフトウェアにおいては、状況はまったく正反対です。
著作権はライセンスを保護するために存在しています。
著作権保持者が常に維持できる唯一の権利は、
ライセンスを強く主張することだけです。
その一方で、ほんのわずかな権利を除く、ほとんど全ての選択権はユーザにあります。
とりわけ、著作権保持者はすでに人手に渡ったコピーに関する条項は変更できません。
それゆえ、オープン・ソース・ソフトウェアにおいては、
著作権保持者はほとんど無力です。
しかし、ライセンス条項はとても重要な意味を持っています。

<!--
Normally the copyright holder of a project is the current project leader or
sponsoring organization.  Transfer of the project to a new leader is often
signaled by changing the copyright holder.  However, this is not a hard and
fast rule; many open-source projects have multiple copyright holders, and
there is no instance on record of this leading to legal problems.

Some projects choose to assign copyright to the Free Software Foundation,
on the theory that it has an interest in defending open source and lawyers
available to do it.
-->
通常、プロジェクトの著作権保持者はその時点でのプロジェクトリーダーか、
プロジェクトを援助している組織です。
プロジェクトを新しいリーダーに引き継ぐことが、
著作権保持者が変わることによって示されることもよくあります。
しかしながら、これは絶対的に堅固なルールというわけではありません。
たとえば多くのオープン・ソース・プロジェクトには
複数の著作権保持者が存在していますが、
このことが法的な問題を引き起こしたという
実例は過去にありません。

いくつかのプロジェクトは
著作権を Free Software Foundation に譲渡することを選択しています。
この組織はオープン・ソースを防御することに関心があり、
そのために法律家の力も借りることができる、という考えに基づくものです。

<sect1><!-- What qualifies as open source -->オープン・ソースである条件
<p>
<!--
For licensing purposes, we can distinguish several different kinds of
rights that a license may convey.  Rights to <em>copy and
redistribute</em>, rights to <em>use</em>, rights to <em>modify for
personal use</em>, and rights to <em>redistribute modified
copies</em>.  A license may restrict or attach conditions to any
of these rights.
-->
実際のライセンス供与にあたり、
そのライセンスが誘引するいくつかの異なった種類の権利について、
区別して考えることができます。
<em>複製・再配布する</em>権利、
<em>使用する</em>権利、
<em>個人的な用途にあわせて改変する</em>権利、そして
<em>改変したものの複製物を再配布する</em>権利です。
どの権利においてもライセンスによって制限が加えられる可能性があります。

<!-- 
The <url name="Open Source Initiative" url="http://www.opensource.org"> is
the result of a great deal of thought about what makes software ``open
source'' or (in older terminology) ``free''.  Its constraints on licensing
require that:
-->

あるソフトウェアを ``オープン・ソース'' あるいは ``フリー'' (古くからの用語)
と定義づける条件について、深く掘り下げて考察した結果が 
<url name="Open Source Initiative" url="http://www.opensource.org"> 
にまとめられています。
ここではライセンスに関して以下のような制限事項が要求されています : 

<!--
<enum>
<item>An unlimited right to copy be granted.
<item>An unlimited right to use be granted.
<item>An unlimited right to modify for personal use be granted.
</enum>
-->

<enum>
<item>複製に関しては無制限の権利が認められていること
<item>使用に関しては無制限の権利が認められていること
<item>個人的使用を目的とした改変に関しては無制限の権利が認められていること
</enum>

<!--
The guidelines prohibit restrictions on redistribution of modified
binaries; this meets the needs of software distributors, who need to be
able to ship working code without encumbrance.  It allows authors
to require that modified sources be redistributed as pristine
sources plus patches, thus establishing the author's intentions and an
``audit trail'' of any changes by others.
-->
このガイドラインでは
改変をほどこしたバイナリの再配布に関する制限も
禁止されています。
これは、余計な負担を強いられることなく、
自分たちの作業したコードを提供したいという
ソフトウェア・ディストビュータのニーズに合わせた結果です。
一方で改変したソース・コードは
改変前のソース・コードとそれに対するパッチの組合わせで再配布されるよう、
作者が要求することを認めています。
これによって当初の作者の意図と、
第三者による改変の様子を ``追跡調査'' する仕組みが確立できることになります。

<!--
The OSD is the legal definition of the `OSI Certified Open Source'
certification mark, and as good a definition of ``free software'' as
anyone has ever come up with.  All of the standard licenses (MIT, BSD,
Artistic, and GPL/LGPL) meet it (though some, like GPL, have other
restrictions which you should understand before choosing it).
-->
OSD は `OSI Certified Open Source (OSI 公認オープン・ソース)' 認定マーク
の法的な定義であり、
どんな人でも歩み寄れるように ``フリー・ソフトウェア'' を
より良く定義したものです。
全ての標準的なライセンス (MIT, BSD, Artistic, そして GPL/LGPL)
がこれに合致します
(ただし、GPL のようないくつかのライセンスには、
それを選択する前に理解しなければならない別の制限事項も存在しています)。

<!--
Note that licenses which allow noncommercial use only do <em>not</em>
qualify as open-source licenses, even if they are decorated with
``GPL'' or some other standard license.  They discriminate against
particular occupations, persons, and groups.  They make life too
complicated for CD-ROM distributors and others trying to spread
open-source software commercially.
-->
非商用に限定して使用を許可するライセンスは、
たとえ ``GPL'' あるいは
その他の標準ライセンスによる装飾がされていたとしても、
オープン・ソースのライセンス形態は
<em>満たしていない</em> ことに注意してください。
それは特定の職業、人間、集団を差別するものなのです。
そして、CD-ROM 配布業者や
オープン・ソース・ソフトウェアを商業的に普及させようとする人々にとっては、
非常に悩ましい頭痛の種となるのです。

<sect><!-- Good licensing and copyright practice: the practice -->正しいライセンスと著作権に関する提案: 実践篇

<p>
<!--
Here's how to translate the theory above into practice:
-->
これまでに説明してきた一般法則を実践に移す方法について説明します。

<sect1><!-- Make yourself or the FSF as the copright holder -->自分自身、または FSF を著作権保持者にしましょう
<p>
<!--
In some cases, if you have a sponsoring organization behind you with
lawyers, youi might wish to give copyright to that organization.
-->
法律家を擁するスポンサー団体による支援がある場合、
その団体に著作権を渡したい、というケースもあるでしょう。

<sect1><!-- Use a license conformant to the Open Source Definition -->Open Source Definition に準じたライセンスを設定しましょう
<p>
<!--
The Open Source Definition is the community gold standard for licenses.
The OSD is not a license itself; rather, it defines a minimum set of rights
that a license must guarantee in order to be considered an open-source
license.  The OSD, and supporting materials, may be found at the web site
of the <url name="Open Source Initiative" url="http://www.opensource.org">.
-->
Open Source Definition は、
この世界におけるライセンスの確固たる標準です。
OSD そのものはライセンス条項ではなく、
あるライセンス条項がオープン・ソース・ライセンスとして
機能することを保証するための、
必要最小限の権利関係を定義づけるものといえます。
OSD とそれを補足するものは
<url name="Open Source Initiative" url="http://www.opensource.org">
のウェブ・サイトから入手できます。

<sect1><!-- Don't write your own license if you can possibly avoid it.-->無効になるようなライセンスを自分自身で書かないようにしましょう
<p>
<!--
The widely-known OSD-conformant licenses have well-established interpretive
traditions.  Developers (and, to the extent they care, users) know what
they imply, and have a reasonable take on the risks and tradeoffs they
involve.  Therefore, use one of the standard licenses carried on the OSI
site if at all possible.
-->
すでに普及している OSD 準拠のライセンスには、
大変よく確立された伝統ある解釈が盛り込まれています。
開発者は (その気さえあれば、ユーザも) 
それらが意図するものを理解しており、
納得できるならリスクを引き受け、
そして自らの関与したものを交換取引するのです。
ですから、
可能な限り OSI のサイトにある標準的なライセンスのどれかを
利用するようにしましょう。

<!--
If you must write your own license, be sure to have it certified by OSI.  This
will avoid a lot of argument and overhead.  Unless you've been through it, 
you have no idea how nasty a licensing flamewar can get; people become
passionate because the licenses are regarded as almost-sacred covenants
touching the core values of the open-source community.
-->
もし自分自身でライセンス条項を書かなければならないなら、
OSI によって認定を受けるようにしましょう。
これによって際限のない論争と無駄を回避することができるでしょう。
ライセンスについての議論の応酬がいかに始末に負えないものになるか、
あなたがそれを経験していないなら想像もつかないでしょうが、
ライセンスはオープン・ソース社会の真核部分に触れる
ほとんど宗教がかった誓約に関するものなので、
人々はつい激情に駆られやすくなってしまうのです。

<!--
Furthermore, the presence of an established interpretive tradition may
prove important if your license is ever tested in court.  At time of 
writing (late 1999) there is no case law either supporting or invalidating
any open-source license.  However, it is a legal doctrine (at least in
the U.S., and probably in other common-law countries such as England
and the rest of the British Commonwealth) that courts are supposed to 
interpret licenses and contracts according to the expectations and
practices of the community in which they originated.
-->
さらにいえば、
もしあなたのライセンス条項が法廷で審判を受けることになれば、
すでに確立された解釈体系の存在がいかに重要であるか、
証明されることになるでしょう。
これを書いている時点 (1999 年後半) では、
どのオープン・ソース・ライセンスに関しても、
有効・無効のどちらの判例もありません。
しかしながら、これは起源となった共同体においては当然予期され、
また妥当な慣習に基づいたライセンス条項および契約事項であると
法廷で解釈されるはずの、法律的に有効な主張です
(少なくともアメリカ合衆国では。
そしておそらくイングランドとそれ以外のブリテン諸国など、
他の慣習法に則った国々でも)。

<sect><!-- Good development practice -->正しい開発作業についての提案
<p>
<!--
Most of these are concerned with ensuring portability, not only across
Linuxes but to other Unixes as well.  Being portable to other Unixes 
is not just a worthy form of professionalism and hackerly politeness, 
it's valuable insurance against future changes in Linux itself.

Finally, other people <em>will</em> try to build your code on non-Linux
systems; portability minimizes the number of annoying perplexed email
messages you will get.
-->

ここで触れる話題のほとんどは、Linux 圏のみならず、
他の Unix も含めた移植性の確保に関係するものです。
他の Unix へ移植可能であるということは、
プロフェッショナリズムとハッカー主義の美徳であるだけでなく、
将来において Linux 自体に変化が起きた場合にそなえた
貴重な保険ということもできます。

結論から言えば、誰かがあなたのコードを Linux 以外のシステムにおいて
ビルドしようとするのは<em>明らかです</em>。
移植性を高めておけば、あなたが受け取る煩わしくて面倒な email の数を
減らすことができるでしょう。

<sect1><!-- Write either pure ANSI C or a portable scripting language -->
純粋な ANSI C もしくは可搬性の高いスクリプト言語を使いましょう
<p>
<!--
For portability and stability, you should write either in ANSI C or a
scripting language that is guaranteed portable because it has just one
cross-platform implementation.
-->
移植性と安定性のために、ANSI C もしくは可搬性の保証されているスクリプト言語を
使いましょう。
プラットフォームを越えて単一の実装が存在しているからです。

<!--
Scripting languages that qualify include Python, Perl, Tcl, and Emacs Lisp.
Plain old shell does <em>not</em> qualify; there are too many different
implementations with subtle idiosyncracies, and the shell environment
is subject to disruption by user customizations such as shell aliases.
-->
これに適合するスクリプト言語としては、
Python, Perl, Tcl, そして Emacs Lisp などがあります。
プレインな古い shell は<em>不合格</em>です。
微妙な違いのある、たくさんの異なる実装が存在していますし、
エイリアスのようなユーザカスタマイズによって、
shell の実行環境が
ごちゃごちゃになっていることも想定されるからです。

<!--
Java holds promise as a portable language, but the Linux-available 
implementations are still scratchy and poorly integrated with Linux.
Java is still a bleeding-edge choice, though one likely to become more
popular as it matures.
-->
Java は可搬性の高い言語であることを約束していますが、
今のところ Linux で利用できる実装は完全ではなく、
Linux との親和性も貧弱です。
Java は成熟するに連れてさらに人気を増していくように見えますが、
現時点ではまだ薄氷を踏むような選択と言えます。

<sect1><!-- Follow good C portability practices-->
正しい C 言語の互換性に留意しましょう
<p>
<!--
If you are writing C, do feel free to use the full ANSI features - -
including function prototypes, which will help you spot cross-module
inconsistancies.  The old-style K&amp;R compilers are history.

On the other hand, do <em>not</em> assume that GCC-specific 
features such as the `-pipe' option or nested functions are available.
These will come around and bite you the second somebody ports to a
non-Linux, non-GCC system.
-->
C 言語で開発しているなら、ANSI で用意されたすべての機能を
好きなように使ってください。モジュール間の矛盾を洗い出すために
便利なファンクション・プロトタイプもこれに含まれます。
旧式の K&amp;R コンパイラはすでに歴史の遺物です。

その一方で、たとえば `-pipe' オプションやネストされた関数構造など、
GCC 固有の機能が使えると仮定しては<em>いけません</em>。
誰かが Linux 以外、GCC 以外のシステムに移植する際に、
この問題が付きまとい、困らせることになります。

<sect1><!-- Use autoconf/automake/autoheader -->
autoconf/automake/autoheader を使いましょう
<p>
<!--
If you're writing C, use autoconf/automake/autoheader to handle portability
issues, do system-configuration probes, and tailor your makefiles.  People
building from sources today expect to be able to type "configure; make"
and get a clean build - - and rightly so.
-->
C 言語で開発しているなら、システムの環境設定を探査したり、
makefile を仕立てたりといった、可搬性にまつわる事柄を操作するために、
autoconf/automake/autoheader ユーティリティーを使いましょう。
今日では、ソースからビルドする際に、
"configure; make" とタイプして、
きれいに、そして正しく作り上げられることを人々は期待しているのです。

<sect1><!-- Sanity-check your code before release -->
リリースの前にコードの正当性をチェックしましょう
<p>
<!--
If you're writing C, test-compile with -Wall and clean up the errors at
least once before each release.  This catches a surprising number of
errors.  For real thoroughness, compile with -pedantic as well.
-->
C 言語で開発している場合は、
リリースの前に少なくとも一回は -Wall オプションを付けてテストコンパイルを行い、
エラーが出ないことを確認しましょう。
これは非常に多くのエラーを検出します。
究極を目指すなら、-pedantic オプションを付けてコンパイルしてみましょう。

<!--
If you're writing Perl, check your code with perl -c (and maybe -T, if
applicable).  Use perl -w and 'use strict' religiously.  (See the Perl
documentation for discussion.)
-->
Perl で書いている場合は、コードに -c (場合によっては -T) オプションを付けて
チェックしてみましょう。信心深く行うなら perl -w と `use strict' ですね
(これについては Perl のドキュメントを参照してください)。

<sect><!-- Good distribution-making practice -->
正しい配布形態についての提案
<p>
<!--
These guidelines describe how your distribution should look when someone
downloads, retrieves and unpacks it.
-->
これから述べるガイドラインでは、誰かが配布物をダウンロードし、中身を取り出して
展開した際に、配布物はどのように現れるべきか、という事を説明します。

<sect1><!-- Make sure tarballs always unpack into a single new directory -->
tarball からは常に単一の新しいディレクトリに展開されることを確認しましょう
<p>
<!--
The single most annoying mistake newbie developers make is to build
tarballs that unpack the files and directories in the distribution into
the current directory, potentially stepping on files already located there.
<em>Never do this!</em>
-->
開発の初心者が冒しやすい誤りの中で、もっともわずらわしいものは、
配布物中のファイルとディレクトリをカレントディレクトリにぶちまけ、
すでにそこにあるファイル群を上書きする可能性のある
tarball を作ってしまう、というものです。
<em>こうしては絶対にいけません！</em>

<!--
Instead, make sure your archive files all have a common directory part
named after the project, so they will unpack into a single top-level 
directory directly <em>beneath</em> the current one.

Here's a makefile trick that, assuming your distribution directory is
named `foobar' and SRC contains a list of your distribution files,
accomplishes this.  It requires GNU tar 1.13
-->
これを避けるには、アーカイヴされたファイルを全てプロジェクト名で始まる
専用のディレクトリに入れれば、現在のディレクトリの<em>直下</em>
にある、単一のトップ・ディレクトリの中に展開されるでしょう。

これを完璧に行うための makefile の裏技があります。
配布物のディレクトリが `foobar' という名前で、
SRC という変数には配布ファイルのリストが入っているとします。
これには GNU tar 1.13 が必要です。

<verb>
VERS=1.0
foobar-$(VERS).tar.gz:
	tar --name-prefix='foobar-$(VERS)/' -czf foobar-$(VERS).tar.gz $(SRC)
</verb>

<!--
If you have an older tar program, do something like this:
-->
もし古い tar を使っている場合は、以下のようにします。

<verb>
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))
</verb>

<sect1><!-- Have a README -->README を用意しましょう
<p>
<!--
Have a file called README or READ.ME that is a roadmap of your source
distribution.  By ancient convention, this is the first file intrepid
explorers will read after unpacking the source.

Good things to have in the README include:
-->
ソース配布物のロードマップとなる README もしくは READ.ME というファイルを
用意しましょう。古来の言い伝えでは、これはソースを展開した勇敢なる探検者たちが
最初に目にして読むはずの書、ということになっています。

README の中に書いておきたい項目は:

<!--
<itemize>
<item>A brief description of the project.
<item>A pointer to the project website (if it has one)
<item>Notes on the developer's build environment and potential portability
      problems.
<item>A roadmap describing important files and subdirectories. 
<item>Either build/installation instructions or a pointer to a file
      containing same (usually INSTALL).
<item>Either a maintainers/credits list or a pointer to a file containing
      same (usually CREDITS). 
<item>Either recent project news or a pointer to a file containing same
      (usually NEWS). 
</itemize>
-->

<itemize>
<item>プロジェクトの概要説明.
<item>プロジェクトの Web サイトへのポインタ(もしあるなら).
<item>開発者のビルド環境と可搬性についての説明.
<item>重要なファイルとサブディレクトリについて説明したロードマップ.
<item>ビルドとインストールの手引き、または同じ内容を含んだファイルへのポインタ.
      (大抵は INSTALL というファイル) 
<item>管理者/関係者のリスト、または同じ内容を含んだファイルへのポインタ.
      (大抵は CREDITS というファイル) 
<item>プロジェクトに関する最近のニュース、あるいは同じ内容を含んだファイルへのポインタ. (大抵は NEWS というファイル) 
</itemize>

<sect1><!-- Respect and follow standard file naming practices -->
標準的なファイル命名規則を重んじてそれに従いましょう
<p>
<!--
Before even looking at the README, your intrepid explorer will have scanned
the filenames in the top-level directory of your unpacked distribution.
Those names can themselves convey information.  By adhering to certain
standard naming practices, you can give the explorer valuable clues
about what to look in next.
-->
README ファイルを読むより先に、
勇敢なる探検者たちは展開した
配布物のトップディレクトリのファイル名を探索するでしょう。
ファイルの名称は、それ自体が情報を含んでいます。
標準的な名前付けの慣例を踏襲することによって、
次に何を見るべきなのかという重要な手がかりを、探検者たちに示すことができます。

<!--
Here are some standard top-level file names and what they mean.  Not
every distribution needs all of these.
-->
標準的なトップレベルのファイル名とそれが意味するものについて説明しましょう。
配布物にこれら全部が必要ではありません。

<!--
<descrip>
<tag>README or READ.ME</tag> the roadmap file, to be read first

<tag>INSTALL</tag> configuration, build, and installation instructions

<tag>CREDITS</tag> list of project contributers

<tag>NEWS</tag> recent project news

<tag>HISTORY</tag> project history

<tag>COPYING</tag> project license terms (GNU convention)

<tag>LICENSE</tag> project license terms

<tag>MANIFEST</tag> list of files in the distribution

<tag>FAQ</tag> plain-text Frequently-Asked-Questions document for the project 

<tag>TAGS</tag> generated tag file for use by Emacs or vi
</descrip>
-->

<descrip>
<tag>README または READ.ME</tag> 最初に読む案内書

<tag>INSTALL</tag> 設定・ビルド・インストール方法の解説

<tag>CREDITS</tag> プロジェクトに対する貢献者のリスト

<tag>NEWS</tag> プロジェクトに関する最近のニュース

<tag>HISTORY</tag> プロジェクトの履歴

<tag>COPYING</tag> プロジェクトのライセンス (GNU 流の慣習)

<tag>LICENSE</tag> プロジェクトのライセンス

<tag>MANIFEST</tag> 配布物に含まれるファイルの一覧

<tag>FAQ</tag> プロジェクトに関して、よく尋ねられる質問とその回答を記したプレインテキストのドキュメント

<tag>TAGS</tag> Emacs や vi で利用するタグファイル
</descrip>

<!--
Note the overall convention that filenames with all-caps names are
human-readable metainformation about the package, rather than build
components.
-->
これらのファイル名が全て大文字で構成されているという慣習は、
それらがビルドの部品として使われるのではなく、
パッケージに関する一般的情報を含んだ人間が読むべきものだと
暗示していることに注意してください。

<sect1><!-- Provide RPMs -->RPM バイナリパッケージを提供しましょう
<p>
<!--
The de-facto standard format for installable binary packages is that used
by the Red Hat Package manager, RPM.  It's featured in the most popular
Linux distribution, and supported by effectively all other Linux
distributions (except Debian and Slackware; and Debian can install from
RPMs).
-->
インストールに使われるバイナリパッケージの事実上の標準フォーマットは、
Red Hat Package Manager, RPM です。
これはもっとも人気のある Linux ディストリビューションの特長となっており、
事実上他の Linux ディストリビューションでも
サポートされています
(Debian と Slackware は除きます。
ただし Debian では RPM からインストールすることも可能です)。

<!--
Accordingly, it's a good idea for your project site to provide installable 
RPMs as well as source tarballs.
-->
したがって、ソースコードの tarball と同様に、
インストール可能な RPM 形式のファイルを
プロジェクトのサイトで提供するのは良い考えです。

<!--
It's also a good idea for you to include in your source tarball the RPM
spec file, with a production that makes RPMs from it in your Makefile.
The spec file should have the extension `.spec'; that's how the rpm -t
option finds it in a tarball.
-->
また、ソース・コードの tarball の中には RPM の spec ファイルを含め、
Makefile の中ではそこから RPM を生成する仕組みを提供するのも良い考えでしょう。
spec ファイルには rpm の -t オプションで tarball から見つけられるように、
`.spec' という拡張子を与えておきましょう。

<!--
For extra style points, generate your spec file with a shellscript that
automatically plugs in the correct version number by analyzing the Makefile
or a version.h.
-->
形式に関して点数を稼ぎたいなら、
Makefile あるいは version.h を読み込んで正しいバージョン番号を自動的に
返すような Shell スクリプトを利用し、spec ファイルを生成するようにしましょう。

<sect><!-- Good communication practice -->正しいコミュニケーションについての提案
<p>
<!--
Your software won't do the world much good if nobody but you knows it
exists.  Also, developing a visible presence for the project on the
Internet will assist you in recruiting users and co-developers.  Here
are the standard ways to do that.
-->

あなたのソフトウェアは、
その存在を知られない限り世界に貢献することはできません。
また、プロジェクトの存在をインターネット上で明らかにすることは、
ユーザを増やしたり共同開発者を募るのに役立つでしょう。
これについての標準的な手法に関して解説します。

<sect1><!-- Announce to c.o.l.a --> c.o.l.a でアナウンスしましょう
<p>
<!--
Announce new releases to <url url="news:comp.os.linux.announce" 
name="comp.os.linux.announce">.  Besides being widely read itself,
this group is a major feeder for web-based what's-new sites like
<url url="http://www.freshmeat.net" name="Freshmeat">.
-->
<url url="news:comp.os.linux.announce" 
name="comp.os.linux.announce">
で新たなリリースのお知らせをしましょう。

それ自体がよく購読されている Newsgroup である上に、
<url url="http://www.freshmeat.net" name="Freshmeat">
のような Web ベースで新着情報を扱うサイトへも転送されています。

<sect1><!-- Announce to a relevant topic newsgroup-->
関連する Newsgroup にアナウンスしましょう
<p>
<!--
Find USENET topics group directly relevant to your application, 
and announce there as well.  Post only where the <em>function</em> of the
code is relevant, and exercise restraint.
-->
あなたのアプリケーションに直接関連する USENET の Newsgroup を見つけて、
そこでもアナウンスしましょう。
慎みを持って、
ソフトウェアとしての<em>機能</em>が関係する Newsgroup にのみ投稿してください。

<!--
If (for example) you are releasing a program written in Perl that queries
IMAP servers, you should certainly post to comp.mail.imap.  But you
should probably not post to comp.lang.perl unless the program is also
an instructive example of cutting-edge Perl techniques.

Your announcement should include the URL of a project website.
-->
例えば IMAP サーバに問い合わせを行う Perl で書かれたプログラムを
リリースしようとしているなら、
間違いなく comp.mail.imap には投稿するべきでしょう。
しかしプログラムが Perl の先鋭的テクニックのお手本にもなるものでなければ、
おそらく comp.lang.perl には投稿しない方がよいでしょう。

アナウンスにはプロジェクトの Web サイトの URL も示しておきましょう。

(訳注: 日本語の Newsgroup では
<url url="news:fj.sources" name="fj.sources">
でソフトウェア公開のアナウンスがされています。
本来テキストエンコードされたソースコードのアーカイブを、
直接投稿する Newsgroup でしたが、
最近はアナウンスのみを投稿することの方が増えています。
投稿する記事には <tt>Followup-To:</tt> ヘッダで
<url url="news:fj.sources.d" name="fj.sources.d">
を指定することがマナーとなっています。)

<sect1><!-- Have a website -->Web サイトを用意しましょう
<p>
<!--
If you intend try to build any substantial user or developer community
around your project, it should have a website.  Standard things to have
on the website include:
-->
プロジェクトのユーザあるいは開発者のコミュニティを
しっかりと築くことを目指すならば、
Web サイトを用意した方がよいでしょう。
Web サイトに用意する標準的な内容は以下のようなものです:
<!--
<itemize>
<item>The project charter (why it exists, who the audience is, etc).
<item>Download links for the project sources.
<item>Instructions on how to join the project mailing list(s).
<item>A FAQ (Frequently Asked Questions) list.
<item>HTMLized versions of the project documentation
<item>Links to related and/or competing projects.
</itemize>
-->
<itemize>
<item>プロジェクトの目的 (存在の意義、対象となる読者、等々).
<item>プロジェクトのソースをダウンロードできるリンク.
<item>プロジェクトのメーリングリストへの加入方法.
<item>FAQ リスト (よくある質問と回答集).
<item>プロジェクトのドキュメントを HTML 化したもの.
<item>関連する、あるいは競合するプロジェクトへのリンク集.
</itemize>

<!--
Some project sites even have URLs for anonymous access to the master
source tree.
-->
プロジェクトのサイトによっては、
一次ソースツリーへの匿名アクセスが可能な URL を用意することもあります。

<sect1><!-- Host project mailing lists -->
プロジェクトのメーリングリストを用意しましょう
<p>
<!--
It's standard practice to have a private development list through which project
collaborators can communicate and exchange patches.  You may also
want to have an announcements list for people who want to be kept informed
of the project's process
-->
開発の協力者が交流を行い、パッチを交換できるような非公開のメーリングリストを
用意することが一般によく行われています。
プロジェクトの進歩状況を知らせて欲しい人々を対象とした、アナウンスのための
メーリングリストがあってもよいでしょう。

<sect1><!-- Release to major archives -->主要なアーカイブサイトに置きましょう
<p>
<!--
For the last several years, the <url
url="http://www.metalab.unc.edu/pub/Linux/" name="Metalab archive"> has
been the most important interchange location for Linux software.

Other important locations include:

<itemize>
<item>the <url url="http://www.python.org" name="Python Software Activity">
site (for software written in Python).
<item>the <url url="http://language.perl.com/CPAN" name="CPAN">, the
Comprehensive Perl Archive Network, (for software written in Perl).
</itemize>
-->
ここ数年の間、
<url url="http://www.metalab.unc.edu/pub/Linux/" name="Metalab archive">
は Linux のソフトウェアのための重要な拠点となってきました。

それ以外に以下のような重要なサイトがあります:

<itemize>
<item>the <url url="http://www.python.org" name="Python Software Activity">
site (Python で書かれたソフトウェア用).
<item>the <url url="http://language.perl.com/CPAN" name="CPAN">, the
Comprehensive Perl Archive Network. (Perl で書かれたソフトウェア用).
</itemize>

<sect><!-- Good project-management practice -->正しいプロジェクト運営に関する提案
<p>
<!--
Managing a project well when all the participants are volunteers presents
some unique challenges.  This is too large a topic to cover in a HOWTO.
Fortunately, there are some useful white papers available that will help you
understand the major issues.
-->
関係者がみなボランティアである場合、
プロジェクトを上手に運用するということは、
それ自体が特殊な課題となります。
このことは、この HOWTO で取り上げるには大きすぎる題材です。
幸いなことに、これに関する要点を理解するための助けとなる、
幾つかの文書が存在しています。

<!--
For discussion of basic development organization and the 
release-early-release-often `bazaar mode', see <url name="The Cathedral and
the Bazaar" url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">.
-->
基礎となる開発集団と、
'早目にリリース、しょっちゅうリリース' の 'バザール・モデル' に関しては、
<url name="The Cathedral and
the Bazaar (伽藍とバザール)" url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">
を参照してください。

<!--
For discussion of motivational psychology, community customs, and conflict
resolution, see
<url name="Homesteading the Noosphere"
url="http://www.tuxedo.org/~esr/writings/homesteading/">.
-->
動機付けに関する考察、共同体の風習、衝突の解決といった話題については、
<url name="Homesteading the Noosphere (ノウアスフィアの開墾)"
url="http://www.tuxedo.org/~esr/writings/homesteading/">
をご覧下さい。

<!--
For discussion of economics and appropriate business models, see 
<url name="The Magic Cauldron"
url="http://www.tuxedo.org/~esr/writings/mafic-cauldron/">.
-->
経済的側面と適切なビジネス・モデルに関しては、
<url name="The Magic Cauldron (魔法のおなべ)"
url="http://www.tuxedo.org/~esr/writings/mafic-cauldron/">.
を参照してください。

<!--
These papers are not the last word on open-source development.  But they
were the first serious analyses to be written, and have yet to be
superseded.
-->
これらの文書はオープン・ソース開発に関する決定版というわけではありません。
しかし、もっとも早くに書かれた意義深い分析であり、
これに代わる文書は未だに出てきていません。

(訳注: この節で取り上げた文書の翻訳が以下で参照できます。
<itemize>
<item><htmlurl
      url="http://www.post1.com/home/hiyori13/freeware/cathedral.html"
      name="http://www.post1.com/home/hiyori13/freeware/cathedral.html">
      The Cathedral and the Bazaar (伽藍とバザール),
      Eric S. Raymond 著,
      山形浩生 訳

<item><htmlurl
      url="http://www.post1.com/home/hiyori13/freeware/noosphere.html"
      name="http://www.post1.com/home/hiyori13/freeware/noosphere.html">
      Homesteading the Noosphere (ノウアスフィアの開墾),
      Eric S. Raymond 著,
      山形浩生 訳

<item><htmlurl
      url="http://www.post1.com/home/hiyori13/freeware/magicpot.html"
      name="http://www.post1.com/home/hiyori13/freeware/magicpot.html">
      The Magic Cauldron (魔法のおなべ),
      Eric S. Raymond 著,
      山形浩生 + 田宮まや 訳
</itemize>
)
</article>
