BIPs 30, 32, 62, 66, and 103: License under BSD-2-Clause terms

[Thursday, January 19, 2017] [7:46:36 PM UTC] <luke-jr> sipa: if you get a minute, can you give me at least a text-"verbal" ACK for some copyright license to put on BIPs 30, 32, 62, 66, and 103 please? is BSD-2-Clause okay?
[Thursday, January 19, 2017] [7:47:01 PM UTC] <sipa>    luke-jr: ACK on 2-clause BSD for 30,32,62,66,103
[Thursday, January 19, 2017] [7:47:13 PM UTC] <sipa>    (and for any other BIPs I contributed to)

Author: luke-jr

bip-0030.mediawiki

@@ -8,11 +8,16 @@
   Status: Final
   Type: Standards Track
   Created: 2012-02-22
+  License: BSD-2-Clause
 </pre>
 
 ==Abstract==
 This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementations has with them.
 
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
+
 ==Motivation==
 So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network.
 

bip-0032.mediawiki

@@ -14,6 +14,7 @@ RECENT CHANGES:
   Status: Final
   Type: Informational
   Created: 2012-02-11
+  License: BSD-2-Clause
 </pre>
 
 ==Abstract==
@@ -24,6 +25,10 @@ The specification is intended to set a standard for deterministic wallets that c
 
 The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.
 
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
+
 ==Motivation==
 
 The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well.

bip-0062.mediawiki

@@ -10,12 +10,17 @@
   Status: Withdrawn
   Type: Standards Track
   Created: 2014-03-12
+  License: BSD-2-Clause
 </pre>
 
 ==Abstract==
 
 This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it).
 
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
+
 ==Motivation==
 
 As of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys.

bip-0066.mediawiki

@@ -8,12 +8,17 @@
   Status: Final
   Type: Standards Track
   Created: 2015-01-10
+  License: BSD-2-Clause
 </pre>
 
 ==Abstract==
 
 This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding.
 
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
+
 ==Motivation==
 
 Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software.

bip-0103.mediawiki

@@ -8,12 +8,17 @@
   Status: Draft
   Type: Standards Track
   Created: 2015-07-21
+  License: BSD-2-Clause
 </pre>
 
 ==Abstract==
 
 This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future.
 
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
+
 ==Motivation==
 
 Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally.