Develop with pleasure!

福岡でCloudとかBlockchainとか。

BIPについて定義したBIP-002

BIP Bitcoin

BIPについて定義していたBIP-001が、2016年11月にBIP-002にリプレースされてたので見とく↓

bips/bip-0002.mediawiki at master · bitcoin/bips · GitHub

概要

BIPはBitcoin Improvement Proposalの略で、Bitcoinコミュニティに情報提供したり、Bitcoinの新しい機能やプロセス、環境について記述した設計ドキュメント。BIPは機能の技術仕様やその機能の根拠について完結に記述する必要がある。

BIPは新しい機能の提案や、コミュニティにおける課題の収集、Bitcoinに取り入れられる設計上の意思決定を文書化するための主要な仕組みであると考えている。BIPの著者にはコミュニティ内でコンセンサスをとり、反対意見を文書化する責任がある。

BIPはバージョン管理されたリポジトリでテキストファイルとして管理されているので、そのリビジョン履歴は機能提案の履歴になる。

BIPのワークフロー

BIPのプロセスはBitcoinの新しいアイディアから始まる。BIP候補には、後述するスタイルとフォーマットを使用してBIPを書き、適切なフォーラムでディスカッションを開催し、アイディアに関するコンセンサスを構築する著者が必要となる。BIPの著者は、そのアイディアがBIP化可能かまず確かめる必要がある。ちょっとした拡張やパッチは、多くの場合複数のプロジェクト間で標準化を行う必要は無い。そういったものにBIPは必要なく適切なイシュートラッカーにパッチを送ると共に、関連するプロジェクトの開発ワークフローに従えばいい。またさまざまな理由でリジェクトされたBitcoinの変更に関するアイディアが今まで多数提出されているので、BIPを作成する際は、まず最初に過去のディスカッションを検索し、アイディアが以前に検討されていないかどうかを確認し、もしあればどのような問題がその時生じたか調べること。過去のディスカッションを調査した後、新しいアイディアを提案する良い方法は、Bitcoinの開発メーリングリストにポストすることである。

BIPを書く前にアイディアを公開するこで、著者とコミュニティの時間の節約になる。オリジナルのアイディアが以前の議論に基づいて明らかにリジェクトされる場合、Bitcoinコミュニティに最初に相談することで無駄な時間を使うことがなくなる。また、アイディアが著者だけでなくコミュニティ全体にとってメリットになるか確認することにもなる。アイディが著者にとってだけ有益なものでBitcoinを使っているほとんどの人々にとっては有益ではないかもしれない。

著者がBitcoinコミュニティにアイディが受け入れられるかどうかを尋ねた後は、bitcoin-devのメーリングリストにBIPのドラフトを提出する必要がある。これは著者にとって、BIPのドラフトを適切なフォーマットで、高品質にし、提案に関する懸念事項に対処するためBIPのドラフトを完成させるチャンスになる。ディスカッションの後、プロポーザルはBIPのgitリポジトリにプルリクエストで提出する。このドラフトは後述するBIPスタイルで書かなければならない。編集者によりBIPに番号が割り当てられるまでは、”bip-johndoe-infinitebitcoins”のように著者の名前/ニックネームと件名を含むエイリアスを使う必要がある。

著者はレビューのためにBIPを提出する前に、初期のアイディアとBIPについてコミュニティからのフィードバックを集める責任がある。しかし可能であれば公開メーリングリストで長い議論は避けるべきである。ディスカッションを効率的にするためには、トピックのための個別のメーリングリストをセットアップし、著者に初期の設計段階のプライベートコメントを受けさせたり、wikiページやgitリポジトリのセットアップなどをするのが効果的である。どれを利用するかはBIPの著者が決めればいい。

１つのBIPに含めるのは、１つのプロポーザルにすることを推奨する。BIPの焦点を絞るほど採用される可能性があがる。必要であればBIPを複数に分割すると良い。

BIPのドラフトが完成すると、編集者はBIPに番号を割り当て、Standards TrackかInformationalかProcessかのラベルを付け、gitリポジトリにプルリクエストをマージする。編集者はBIPを不当に拒否することはない。BIPのステータスを拒否する理由としては、何度も努力したけど、フォーマットルールの無視や、あまりにも範囲が広いケース、技術的に不適切、適切な動機ではない、下位互換性に対処しない、Bitcoinの考え方に従わない、などが挙げられる。BIPが受け入れられるためには、一定の最小基準を満たさなければならない。提案の拡張内容について明確で完全に記述されている必要がある。適用された場合、その提案の実装は堅牢でプロトコルを過度に複雑にしてはならない。

BIPの著者は必要に応じてgitリポジトリ内のドラフトを更新することができる。ドラフトの更新は著者からのプルリクエストで提出される。

BIPの所有権の移転

BIPの所有権を新しい著者に移す必要がある場合がある。一般的に、移転する場合、元の著者を共同著者として残したいと思うが、それはオリジナルの著者次第である。所有権を移転する正当な理由には、元の著者がBIPを更新したりフォローしたりするのに時間や関心を持たなくなったり、（メールが届かなくなったりレスが無いなど）ネット上でコミュニケーションが取れないといった場合である。所有権を移転する悪い理由は、BIPの方向性に同意しない場合で、BIPについてコンセンサスを構築しようとするが、不可能な場合にはいつでも競合するBIPを提出することができる。

BIPの所有権を引き継ぐのに興味があれば、元の著者とBIPの編集者の両方に引き継ぐ意思があることを示すメッセージを送信する。元の著者がタイムリーに返信しない場合、BIPの編集者が一方的な決定を下す（このような決定が行われると元には戻らない）。

BIPの編集者

現在のBIPの編集者はLuke Dashjrで、luke_bipeditor@dashjr.orgでコンタクト可能。

BIPの編集者の責任とワークフロー

BIPの編集者はBitcoinの開発メーリングリストを購読している。メーリングリスト外でのBIP関連の対応はluke_bipeditor@dashjr.org宛（もしくはCc）に送る必要がある。

新しいBIPが届くと編集者は以下のチェックを行う

  • BIPを読み、準備が整っているか（アイディアは受け入れられそうになくても、技術的意味を持っているか）
  • タイトルが内容を正確に記述しているか
  • BIPのドラフトがBitcoinの開発メーリングリストに投稿されているか
  • 動機と後方互換性について言及されているか
  • 定義されたLayerヘッダが仕様通りに正しく割り当てられているか
  • BIPとして受け入れ可能なライセンス条項になっているか

BIPの準備ができていない場合は、編集者が特定の手順で著者に送り返す。

BIPの準備ができたら、BIPのgitリポジトリにプルリクエストを送り、さらなるフィードバックを得る。

そうすると編集者は、

  • プルリクエストに対してBIPの番号を割り当てる
  • プルリクエストをマージする
  • README.mediawikiのリストに加える

BIPの編集者は、管理上及び編集上の責務を果たすこと。また、BIPの編集者はBIPの変更を監視し、必要に応じてBIPのヘッダを更新する。

BIPのフォーマットと構造

仕様

BIPはmediawiki形式で記述する。

各BIPには以下のパートが必要

  • Preamble
    BIPに関するメタデータを含むヘッダ（後述）
  • Abstract
    このBIPで対処する技術的な問題についての記述（200ワードくらい）。
  • Copyright
    許容される著作権下（後述）の明示的な使用許諾
  • Specification
    技術仕様で、新機能の構文と意味について記述する。仕様は現行のBitcoinの各プラットフォームで相互運用可能な実装について詳細に記述する必要がある。
  • Motivation
    動機はBitcoinのプロトコルを変更したいBIPにとって重要なもの。既存のBitcoinのプロトコルがBIPが解決しようとしている問題に対して不十分である理由を明確に記述すること。充分な動機のないBIPの提出は拒否される場合がある。
  • Rationale
    論理的根拠は、設計上の動機となぜそのような設計上の決定をしたのかを記述することで、仕様を完成させる。ここには考慮した別の設計や関連する作業についても（機能が他の言語でどのようにサポートされているかなど）記述する必要がある。論理的根拠では、ディスカッションの中で提起された重要な異論や議論についてコミュニティ内でのコンセンサスの証拠を提供する必要がある。
  • Backwards Compatibility
    下位非互換性を導入する全てのBIPは、非互換性とその重要度の記述が含まれるセクションが必要。BIPでは著者が非互換性をどのように扱うべきか説明しなければならない。下位互換性について充分な説明のないBIPは完全にリジェクトされる可能性がある。
  • Reference Implementation
    BIPのステータスが"Final"になる前に参照実装は完成させる必要があるが、BIPが受け入れられる前に完成させる必要は無い。コードを書く前にSpecificationとRationaleを最初に完成させ合意する方が良い。最終的な実装には、Bitcoinプロトコルに適したテストコードとドキュメントが含まれていなければならない。
BIP Header Preamble

各BIPはRFC 822 スタイルのヘッダPreambleで始まる。ヘッダは以下の順序で記述する。* の付いたヘッダはオプションで、付いてない項目は必須。

  BIP: <BIP number, or "?" before being assigned>
* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
  Title: <BIP title; maximum 44 characters>
  Author: <list of authors' real names and email addrs>
* Discussions-To: <email address>
* Comments-Summary: <summary tone>
  Comments-URI: <links to wiki page for comments>
  Status: <Draft | Active | Proposed | Deferred | Rejected |
           Withdrawn | Final | Replaced | Obsolete>
  Type: <Standards Track | Informational | Process>
  Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
  License: <abbreviation for approved license(s)>
* License-Code: <abbreviation for code under different approved license(s)>
* Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive>
* Requires: <BIP number(s)>
* Replaces: <BIP number>
* Superseded-By: <BIP number>

（Standards Track BIPのみに含まれる）Layerヘッダは、このBIPがBitcoinのどのレイヤーに適用されるか文書化したもの。各BIPレイヤーについてはBIP-123を参照。

AuthorヘッダにはBIPの全ての著者/所有者の名前とメールアドレスが記載されている。Authorヘッダは以下の形式で書く。

  Random J. User <address@dom.ain>

著者が複数いる場合は、RFC 2822の継続行の規則に従って別々の行に記述すること。

通常初期のドラフトフェーズではBIPはプライベートで議論が行われているため、Discussions-ToヘッダにはそのBIPが議論されているメーリングリストもしくはURLを記述する。BIPが著者とプライベートで議論されている場合やBitcoinのメーリングリスト上で行われている場合はDiscussions-Toヘッダは不要。

TypeヘッダはBIPの種類を指定する（Standards Track、Informational、Processのいずれか）。

CreatedヘッダにはBIPに番号が割り当てられた日付が記録され、Post-HistoryヘッダにはBIPの新しいバージョンがBitcoinメーリングリストに投稿された日付を記録する。２つともyyyy-mm-ddの形式で記述すること。Post-Historにはメーリングリストのアーカイブ内の特定のスレッドのリンクを設定することが許可されている。

BIPにはこのBIPが依存するBIPの番号を示すRequiresヘッダもある。

BIPには後のドキュメントによってBIPが廃止されたことを示すSuperseded-Byヘッダを記述することも可能。設定する値は現在のドキュメントを置換するBIPの番号。置換した側のBIPには、廃止したBIPの番号をReplacesヘッダに記載する必要がある。

補助ファイル

BIPには図などの補助ファイルが含まれれる場合がある。補助ファイルはそのBIPのサブディレクトリに含めるか、BIP-XXXX-Y.extというファイル名にすること（XXXXはBIP番号で、Yは１から始まるシリアル番号、extは実際の拡張子）。

BIPの種類

BIPは以下の３種類に分けられる

  • Standards Track BIPは、ネットワークプロトコルの変更やブロック、トランザクションの検証ルールの変更、Bitcoinを使用するアプリケーションの相互運用性影響する追加・変更など、Bitcoinの実装のほとんどもしくは全てに影響を与える記述をする。Standards Track BIPは設計ドキュメントと参照実装の２つのパートで構成される。
  • Informational BIPは、Bitcoinの設計上の問題や、一般的なガイドラインや情報をBitcoinコミュニティに提供するために記述されるもので、新しい機能を提供するものではない。Informational BIPは、必ずしもBitcoinコミュニティのコンセンサスや勧告を示すものではないので、Informational BIPに従うか、無視するかはユーザー及び実装者の自由である。
  • Process BIPは、Bitconをとりまくプロセスや、プロセスの変更について記述する。Process BIPはStandards Track BIPに似ているが、Bitcoinのプロトコル以外の領域も対象とする。Bitcoinのコードベースではなく実装を提案するかもしれない。これらはコミュニティのコンセンサスが必要で、Informational BIPと異なり、ユーザーは通常この提案を無視することはできない。例としては、手順やガイドライン、意思決定プロセスの変更やBitcoinの開発に使われるツールや環境の変更などが含まれる。どのmeta-BIPもProcess BIPとみなされる。

BIPのステータスフィールド

仕様

BIPのステータスの典型的なパスは以下の通り

https://github.com/bitcoin/bips/raw/master/bip-0002/process.png

BIPの著者は、DraftとDeferred、Withdrawn間のステータスの変更は自身で決定することができる。BIPの進捗がない場合、編集者はステータスをDeferredに変更することもできる。

著者が作業を完了し、有効な実装があり、Finalステータスに進めるためのコミュニティ計画があるのみ、ステータスをDraft（もしくはRejected）からProposedに変更される。

BIPに３年間なんの進捗もない場合、誰かから要求があれば、DraftもしくはProposedからRejectedにステータスが変更される。Rejectedに変更されたBIPは、著者が提案の批判に対して意味のある修正を加えた場合はDraftに、また前の段落で説明したように要求された基準を満たす修正である場合はProposedにステータスを変更することができる。

ProposedステータスのBIPは、実世界で特定の基準を満たす採用の動きがあった場合のみFinalに進む。これは提案された変更の性質に応じてBIP毎に異なる（後述）。このステータス変更の評価は、客観的に検証可能で、また開発メーリングリストで議論されるべきである。

FinalのBIPが適切でない場合、そのステータスはReplacedもしくはObsoleteに変更されることがある。この変更は客観的に検証可能で、また議論される必要がある。

Process BIPはメーリングリストで大まかな合意に達したらDraftからActiveにステータスが変わる。大まかな合意というのは、開発メーリングリストでディスカッションを開始して、最低でも１ヶ月、誰も新たに対応が必要な異論が無い場合を言う。充分な対処がされているにも関らず異議があがるような状況では、反対する明確な理由がなければならない。

Finalステータスへの移行

ソフトフォークが必要なBIPは（BIP-9を利用した）ブロックチェーン上の投票によりマイナーの大部分の賛成(95%)が必要になる。さらに（PoWのアルゴリズムを変更するような）ハードフォークを行う意思があると思われる場合には、そのようなハードフォークが多数によってサポートされる限りソフトフォークはFinalにならない。ソフトフォークのBIPはその採用のため追加の要件を設定することがある。マイニングプールなどで行われる代理投票などによって、マイナーのパワーバランスが変わる可能性を考慮すると、BIPの適用には95%という大多数の投票を必要とすることを強く推奨する。（低い閾値でも大丈夫な理論的な根拠がない限り）

ハードフォークが必要なBIPは、Bitcoinエコノミー全体からの合意を必要とする。特にBitcoinの支払いと引き換えに商品やサービスを販売する事業者やコインの所有者など。合意は実際にハードフォークしたバージョンを使用するということである。この経済的な合意は、圧倒的多数を取ればいいという訳ではなく、少数派にもハードフォークの受け入れを強制させない限り（そういったことが可能かどうかはこのドキュメントの範囲外）実現できない。

Peer services BIPは、1ヶ月間少なくとも公開ノードの1%が採用するか監視する必要がある。

API/RPC及びapplicationレイヤーのBIPは、少なくとも２つ以上の独立した互換性のあるソフトウェアアプリケーションで実装される必要がある。

ソフトウェアの作成者は、ステータス変更の検証を支援するため、ソフトウェアがサポートするBIPの概要を公開することが推奨される。良いサンプルはBitcoin Coreのdoc/bips.mdファイルや、Bitcoin Wallet for Androidのwallet/README.specsである。

これらの基準はBIPの事実上の採用を観察する客観的な方法として、BIPをリジェクトする理由として使用されることはない。ここに記載した基準を満たしていないにも関らず、BIPが明確に採用された場合ははFinalステータスに更新される。

論理的根拠

このBIPは何故必要なのか？

  • BIP-1ではBIPのステータスフィールドの基準の定義が曖昧で、よく混乱の原因となった。その結果、実用性のある多くのBIPが長い間DraftやProposedステータスのまま残っている。この提案ではBIPの進行を判断する適切な基準を与えることで、ステータスを正確かつ最新に保つことを目的としている。

Bitcoinのエコノミー全体というのは、モノやサービスを販売する事業者やBitcoinの所有者によって定義されている？

  • Bitcoinが通貨として機能するためには、決済方法として受け入れられる必要がある。Bitcoinと引き換えに何かを手に得ることができないのであれば、そこに価値は無い。そのような決済を受け入れる全員が特定のコンセンサスルールを必要とする場合、"bitcoins"は事実上そのルールによって定義されている。このコンセンサスルールが（ハードフォークのように）拡大すると予想される場合、新しいルールセットの元ので行われた決済を受け入れる必要がある。Bitcoinの保有者は、彼らがBitcoinを使った決済ができる事業者を選択するという点で関係がある。

xがエコノミーに含まれないのはなぜ？

  • Bitcoinと引き換えに商品やサービスを提供するエンティティもあり、それらはエコノミーに関与している。
  • マイナーはエコノミーには含まれない。なぜなら彼らは、他の人にとっては価値の無いマイニング成果物を売ったり買ったりしてるだけだから。従って合意のルールを決定する際に、他の人の指示を受け入れる必要がある。
  • 交換所は単にコインを売りたい人と買いたい人をマッチングするサービスを提供してるだけなので、エコノミーには含まれない。例え全ての交換所がBitcoinから撤退しても、ユーザー同士はいつでも直接取引したり独自取引を確立できる。
  • 開発者はコードを書くだけなのでエコノミーには含まれない。そのコードを使うかどうかは他の人にまかせている。

しかし、彼らは何か重要なことをしていて、Bitcoinに多くの投資をしている。重要な決定に彼らを含めるべきでは？

  • このBIPは何を意思決定のベースにすべきかについて書かれたものではない。そのような声明はどんなに完璧に正当化されていても、他者にそれに従うよう強制させる方法が無ければ無駄になるだろう。BIPのプロセスはBitcoinの強力なガバナンスを目指すものではなく、人々が自発的に採用するかどうかについて情報を提供するための共同のリポジトリを提供するだけのもの。”彼らはどのようにすべき”ではなく、”ものごとが実際どのような”状況にあるのか正確に把握することのみを目的としている。

単一の事業者のみがハードフォークしたい場合はどうなる？

  • このBIPはハードフォーク自体のデプロイについてではなく、BIPのステータスフィールドの進捗にのみ対応する。
  • いずれにしても１店舗だけ孤立してオペレーションすることはできない。本当に１事業者のみであれば、彼らの店舗でBitcoinの決済が行われることはなくなるだろう。誰もそんなチェーンでの決済をしたいとは思わない。そしてBitcoinでの決済がなくなるということは、ここでいうエコノミーでも無くなるということになる。

お互いに商品を販売しあう少数の（多分２人）の売り手ではどう？

  • このシナリオでは、以前のBitcoinは動作していてハードフォークは失敗しているようだ。そのような分割を解決する方法は本BIPの対象外である。

経済的な合意はどうやってソフトフォークを拒否できる？

  • マイナーのグループを動的メンバーシップマルチパーティ署名（BitcoinではPoW）のコンセンサスルールによって決めるよう、ハードフォークすることができる。このグループを変更するのに必要な同じ条件がソフトフォークとは反対に満たされる場合、エコノミーがソフトフォークをサポートしないマイナーグループを選択すると、ソフトフォークをサポートしている大部分のマイナーは無効になる。

エコノミーが議論の余地のあるソフトフォークから３ヶ月後にハードフォークをすることを決めたらどうなる？

  • この状況では、議論の余地のあるソフトフォークのステータスは、決まったソフトフォークを置き換えるハードフォークの性質から、FinalからReplacedに変わる。

ピアサービスのプロポーザルを採択するのに必要な理想的なリスニングノードの割合は？

  • これについては未知で、現時点ではむしろ任意に設定される。ピアをランダムに選択し、その拡張を持つ他のピア１つ以上とつながるには13%以上必要だが、ノードはそのようなピアをスキャンし続けることができる。さらにそういったピアを識別するためのservice bitが存在する。

API/RPCとapplicationレイヤーのBIPの実装がすくなくとも２つのプロジェクトでリリースする必要があるのはなぜ？

  • 仕様の実装が１つしかない場合、標準インターフェースを必要としないから。
  • ２つだけのプロジェクトでも、それらの間で標準に関する調整が必要になる。

１つの特定のプロジェクトのみを対象にしたBIPが提案された場合どうなる？

  • BIPのプロセスは独立したプロジェクト間の標準化のために存在する。何かが１つのプロジェクトにしか影響を与えないのであれば、そのプロジェクトの内部プロセスで実行し、BIPとして提案することはできない。

BIPのコメント

仕様

各BIPはそのpreambleに、コメントの要約を含む公開Wikiページのリンクを記載する必要があり、自身がそのBIPの審査員だと思う人はそのWikiページに自分のコメントを投稿する必要がある。コメントページは通常完了したBIPの最終コメントを投稿するためのみに使う。BIPがまだ完成してない場合、レビューアはBIPの著者がレビューによって指摘された問題に対処できるよう、適切な開発メーリングリストのスレッドにポストすべき。

一部のBIPは完了する前に開発コミュニティ外に公開され、他のBIPは全く完了していない場合がある。期間中に批判的なBIPのレビューが気付かれないといったことがないよう、レビューアはコメントページにレビューを投稿してもいいし、最初にメーリングリストにポストし、完成したバージョンを元に後で必要に応じて削除・修正してもいい。このような改訂の場合、前回のレビューを編集しタイムスタンプを更新する必要がある。完成版より前に行われたレビューは、タイムリー（１ヶ月以内）に更新されない場合、削除される可能性がある。

ページはネームスペースとして"Comments"の後に（”BIP 0001”のような）完全なBIP番号を付与した名前にする必要がある。例えばBIP 1ののコメントページのリンクは以下のようになる。

https://github.com/bitcoin/bips/wiki/Comments:BIP-0001

このWikiにコメントを投稿する際は以下のフォーマットで投稿すること。

    <Your opinion> --<Your name>, <Date of posting, as YYYY-MM-DD>

BIPはWikiに加えてコメントのための第二のフォーラムを設置することも可能で、その場合第二のフォーラムのURIはpreambleのプライマリWikiのURIの下に掲載される。

しばらくすると、BIPの自体のコメントのサマリの傾向が更新されることがある。サマリの傾向は以下から選択できるが、これでBIPの全てのニュアンスをカバーするつもりはなく、必要に応じて他のサマリを使用することもできる。

  • No comments yet.
  • Unanimously Recommended for implementation
  • Unanimously Discourage for implementation
  • Mostly Recommended for implementation, with some Discouragement
  • Mostly Discouraged for implementation, with some Recommendation

例えばBIP 1のpreambleは以下の行を含むよう更新される。

    Comments-Summary: No comments yet.
    Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
                                https://some-other-wiki.org/BIP_1_Comments

これらのフィールドは、BIP-1で定義されているDiscussions-Toヘッダに従う必要がある。（Discussions-Toヘッダが存在しない場合は本来存在する位置に配置する。一般的にStatusヘッダの上）

疑義が生じないよう補足しておくと、BIPを判断するためにコメントとステータスには何の関連もなく、どちらも一方に直接影響を与えてはいけない。

論理的根拠

BIPのコメントの目的は？

  • 一般的に不適切と思われながらも様々なBIPが採用されている。現在BIPは単純にBIP番号が割り当てられているだけで”良いアイディア”とみなされている。新しいBIPを提出するエントリーの敷居が低いため、レビューアの意見を表現する方法がある方が望ましいため。

BIPにコメントをするのは特定の参加者/専門家に制限されてる？

  • 参加者は自分の知識の専門外であっても自由にコメントすべき。コメントは検閲されるべきではないし、参加は一般に公開されるべき。

BIPのライセンス

仕様

新しいBIPは後述するライセンスで受け入れられる。新しい各BIPはpreambleですくなくとも１つ許容するライセンスを分かるようにすること。preambleのLicenseヘッダはCreatedヘッダの後に配置する。各ライセンスは次のいずれかの略語で参照される。

例えばpreambleに以下のライセンスが含まれる場合

    License: BSD-2-Clause
                   GNU-All-Permissive

この場合、BIPのテキストはOSI-approved BSD 2-clauseライセンスとGNU All-Permissiveライセンスの両方のライセンスの下に認可されており、いずれかのライセンス条件に従う限り、誰でもテキストを修正し再配布することができる。言い換えると、リストアップされているライセンスには、AND条件ではなくOR条件が適用される。

BIPのライセンスとは異なるソースコードのライセンスを交付することも可能である。オプションのLicense-CodeヘッダはLicenseヘッダの後に配置する。ここでも後述する各ライセンスの略語を記載する。

例えばオプションのLicense-Codeヘッダを指定するpreambleは以下のようになる。

    License: BSD-2-Clause
                   GNU-All-Permissive
    License-Code: GPL-2.0+

この場合、BIPのコードはBSDもしくはAll-Permissiveライセンスではなく、 GNU General Public License (GPL)のバージョン２以降のライセンスでのみ利用可能になる。コードをバージョン２のみで利用可能とする場合は+のシンボルをライセンスから削除する。以降のバージョン（GPL 3.0など）については、バージョンをインクリメントする（必要に応じて+を付与・削除する）。

    License-Code: GPL-2.0    # This refers to GPL v2.0 *only*, no later license versions are acceptable.
    License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.
    License-Code: GPL-3.0    # This refers to GPL v3.0 *only*, no later license versions are acceptable.
    License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.

テキストやコードのライセンスが複雑過ぎて簡単に表現できない場合、リストアップせず"Complex"という単一の用語に置き換える必要がある。全ての場合において、ライセンス条項の詳細はBIPのCopyrightのセクションに記載されなければならない。

BIPは承認された条件のもとで独占的に認可される必要はなく、少なくとも１つの許容ライセンスに加えて容認できないライセンスの下で認可される場合もある。この場合、受け入れ可能なライセンスのみがLicense及びLicense-Codeヘッダに記載される。

推奨ライセンス

さらにBIP上に含まれるリテラルコードは、プロジェクトと同じライセンス条項とする二重ライセンスとすることを推奨する。例えば、Bitcoin Coreを対象にしたリテラルコードは、BIPのテキストのライセンスと同様、MIT ライセンス条項の２重ライセンスを取得することになる。

非推奨だが受け入れ可能なライセンス
受け入れ不可能なライセンス

上記のライセンスリストに含まれていないライセンスはBitcoin Improvement Proposal の条件として受け入れられない（後にこのBIPが更新されライセンスが追加された場合は別）。ただし、このBIPの承認以前のBIPは他の条件で許可されており、他のライセンスが明記されていない場合、以下の略語を使用する必要がある。

論理的根拠

BIP 1ではOpen Publication Licenseもしくは public domainを許可していたがこれでは不十分だったのか？

  • OPLは廃止されたものであり、新しい出版物に適したライセンスではない
  • 多くの人はOPLの用語に馴染みがなく、そういった不確実な条件よりpublic domainを好むかもしれない
  • OPLのライセンス条項により著者は出版や派生物の作成を防止できるが、これはBitcoinの標準としては不適切だと考えられてきた。
  • public domainは法的なアクションが普遍的に認められていないため、推奨できない。

ソフトウェアライセンスが含まれているのはなぜ？

  • 一部のBIP（特にコンセンサスレイヤー）は、BIP内にリテラルコードが含まれていることがあり、それはBIPの正確なライセンス条件では利用できない場合があるため。
  • ただ、BIP内の全てのコンテンツに対してソフトウェアライセンスが適用される訳ではない

新しいBIPでPublic Domainが受け入れられないのはなぜ？

  • いくつかの国では、Public Domainは合法的な法的措置であると認識されず、BIPは著作権で保護され、改変や再配布が一切許可されないため。

BIP 1からの変更点

  • BIPとして受け入れ可能なライセンスについて再選択し、多種多様なオープンライセンスを許容すると共に、問題のある古いライセンスを禁止
  • AcceptedステータスをProposedにリネーム
  • ステータスがProposedに進む前に、実装が必要
  • BIPのコメントを新しく導入
  • ライセンスのpreambleヘッダを追加
  • BIP-123からLayerヘッダを追加
  • bip-XXXXサブフォルダに画像ではない補助ファイルを配置可能に
  • 著者のメールアドレスが必須に
  • Post-Historyヘッダは単純な日付に代わって、リンクが記載される場合がある
  • BIPを書くフォーマットとしてmarkdownは不許可に
  • Resolutionヘッダは、最終決定を下す権限がない分散システムには不適切なので削除

所感

  • BIP-001ではProposed（旧Accepted）からFinalになる基準が曖昧だったので、変更の性質に合わせて客観的に移行可能かどうか判断する基準が設けられたのね。
  • 選択できるライセンスがガッツリ変わってる。
  • BIPのリポジトリのWikiページみると、数はそんなにないけどたしかにコメントページが作られてる。
  • このBIPとは直接関係ないけど、ピアサービスに関する拡張の場合その拡張をサポートするピアを識別するためのservice bitが存在するのね。2ndレイヤーのピア作る場合とかに仕組みが参考になるかも。
  • BIPはBitcoinのガバナンスを定義したものではなく、自発的な提案とコミュニケーションを促す場であるって認識大事。