RFD：Linuxパッチの配布プロセスを明示的に記録する提案
やあ！
RFD（Request For Discussion）だ。
SCO（別名「Smoking Crack Organization」）というおかしな会社が、自分たちが擁する5人のエンジニアよりもオープンソースのほうが優れているということをどうしても信じられないらしい、というのは周知のとおりだ。彼らは、われわれのソース・コードの出所に関して奇怪な主張をいくつか繰り広げており、10年以上前に私が書いたことが明らかなコードまで、自分たちのものだと言い張っている。
人々は、これらの主張が誤りであることを示すのにかなり（控えめすぎる表現だが）成功している。しかし、これらの反論が、1992年といった古いメーリング・リストのアーカイブを探ったうえで行われているというのは、あまりありがたくない事実だ。
たとえば、ctype.hのケースでは、オリジナルのコードを識別する手がかりになったのは、当初コードに含まれていたひどいバグだった。われわれはもうこんなバグはやらかさないのだから（そうだろ？）、コードの出自を記録するほかの方法を考えるべきではないだろうか。
10年も前のこういった問題を避ける手段として、私は、パッチの出所（これはすでに、changelogsによってかなりうまくいっている）だけでなく、そのパッチがたどった経緯も明確に記録するプロセスを採用することを提案する。
パッチの出身地だけでなく、完全な経路を記録しなければならないのはなぜか。
現在、カーネルに当てられるほとんどのパッチは、直接私には送られてこない。これは、私のところまで届いてこないというだけではなく、実際のところ、私がまったく把握していないサブシステムが数多くあるので、パッチの良し悪しを判断する手段がないのだ。最終的には、サブシステムの保守を誰が行っているかを確認するくらいしかできない。バグが発生したら、今もアクティブかどうかさえ分からないような開発者の名前ではなく、保守担当の名前を知りたい。つまり、少なくとも私にとっては、原作者よりも、パッチがたどった経緯のほうが重要なのだ。
問題はもう1つある。私（誰かほかの人でもいい）が電子メールでパッチを受け取った場合、直接見ることができるのは電子メールの送信者情報だけで、それを信頼するかどうかもその情報だけを基に判断しなければならない。Andrewが私にパッチを送ってくれる場合、送ってきたのが彼だからという理由で、私はそれを信用する。原作者が私の知らない誰かほかの人物であっても関係ない。つまり、パッチが私の元に届くまでのパスは、信用の鎖を表しているといえる。「次のホップ」については皆知っているが、鎖全体を知っているとは限らない。
そこで、パッチがたどった道筋を示し、信頼の鎖を記録するために、パッチの「サインオフ」を始めることを提案したい。最終的にカーネルに適用されるパッチは、何人かの手に渡るうちオリジナルのものから変更されることが多いが、これにより、パッチに編集を加えた中間者も自分たちの名前を残すことができる。
非常に軽量で、なおかつ、現時点でのパッチの受け渡し方法に対応できるような方法にしたい。パッチの説明の末尾に、サインオフを追加するだけだ。次のような1行を（おそらく、ほかの人々のサインオフの後に）追加することになる。
Signed-off-by: Random J Developer
ルールをできるだけ単純にし、パッチのサインオフの意義を明確にするため、何人かのカーネル開発者（主にサブシステムの管理者）と「Developer’s Certificate of Origin（原作者証明書）」について話し合ってきた。これは、基本的には、開発者（または、パッチの受け渡しを行う管理者）が、サインオフするときに署名し、下流（上流？）の開発者たちが、何も問題がなかったことを確認できるようにするものだ。
これにより、鎖の前のエントリがサインオフされていることを確認できさえすれば、ほかの人物が作成したパッチをサインオフすることができる。同時に、この仕組みを理解していない人々に対して、「個人的信頼関係」を明示することができる。
「リリース基準」が規定されている企業では、その企業の「リリース担当者」がパッチをサインオフすればよい。各企業内のリリース手順をこれに統合するのは簡単だし、こうすればすべてのパッチが正しいチャネルを経由したかどうかを確認できる。同時にこれは、誰かの作業内容が変更されることがない（つまり、追加の事務作業が発生することはない）ように考えられている。
感想、改善案、アイデア大歓迎だ。そうそう、デジタル署名だとかそういったもののことは私も知っているが、それとこれとは別物だ。これは著作権を証明するためのものではなく、プロセスをドキュメント化する提案だ。PGP署名付きの電子メールのようなものを否定したり、代替したりするのが目的ではない。あくまで、オープンソースのプロセスを理解しない人々に対して、われわれのやり方を示すのが目的なのだ。
Developer's Certificate of Origin 1.0
By making a contribution to this project, I certify that:
（このプロジェクトへのコントリビューション提供者として、以下の事項を証明する。）
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
（私はこのコントリビューションの全体または一部を作成し、
ファイル内に明示したオープンソース・ライセンスの下で
これを配布する権利を有する。）
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
（このコントリビューションは、私の知る限りにおいて適切な
オープンソース・ライセンスによってカバーされている既存
の作品を基にしており、私はそのライセンスに基づき、私が
一部または全体を作成した変更内容を加えて、ファイル内に
明示されている同じオープンソース・ライセンス（別のライ
センスの下で配布する許可を得ている場合を除き）の下でこ
れを配布する権利を有する。）
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
（私は、(a)、(b)、(c)を証明する別の人物からこのコントリビ
ューションを直接提供され、これに変更を加えていない。）
Linus
