bip-biprevised: Add Rationales and clarify literal code licensing

1 files changed, 38 insertions, 5 deletions

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 18ec1dd..93af1b8 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -17,9 +17,9 @@ This BIP intends to address these problems by more specifically defining the Sta
 
 This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
 
-==Specification==
+==BIP status field==
 
-===BIP status field===
+===Specification===
 
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
 
@@ -51,7 +51,24 @@ Software authors are encouraged to publish summaries of what BIPs their software
 
 A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion.
 
-===BIP comments===
+===Rationale===
+
+Why can the economic consensus veto a soft-fork?
+
+* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.
+
+What is the ideal percentage of listening nodes needed to adopt peer services proposals?
+
+* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
+
+Should two software projects need to release an implementation of API/RPC and application layer BIPs?
+
+* With only one implementation of these, there is no other program for which a standard interface is used with or needed.
+* Even if there are only two projects, some standard coordination between them exists.
+
+==BIP comments==
+
+===Specification===
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 
@@ -66,10 +83,19 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 
-===BIP licensing===
+===Rationale===
+
+Will BIP comments be censored or limited to particular participants/"experts"?
+
+* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
+* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed.
+
+==BIP licensing==
 
 New BIPs may be accepted with the following licenses:
 
+===Specification===
+
 ====Recommended licenses====
 
 * [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
@@ -77,7 +103,7 @@ New BIPs may be accepted with the following licenses:
 * [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
 * [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
-In addition, it is recommended that literal code included in the BIP be available under the same license terms as the project it modifies, when that license is acceptable within a BIP. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms (listed below, as not recommended but acceptable) as well as one of the above with the rest of the BIP text.
+In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 
 ====Not recommented, but acceptable licenses====
 
@@ -92,6 +118,13 @@ In addition, it is recommended that literal code included in the BIP be availabl
 * [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
 * [http://opencontent.org/openpub/ Open Publication License, version 1.0]
 
+===Rationale===
+
+Why are there software licenses included?
+
+* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
+* Despite this, not all software licenses would be acceptable for content included in BIPs.
+
 ==See Also==
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]