Merge pull request #491 from luke-jr/sipa_licensing

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

7 files changed, 32 insertions, 1 deletions

diff --git a/bip-0030.mediawiki b/bip-0030.mediawiki
index 56ef3de..a63b737 100644
--- a/bip-0030.mediawiki
+++ b/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.
 
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index 50964a2..a4c1b96 100644
--- a/bip-0032.mediawiki
+++ b/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.
diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index deff62b..7dd2b5b 100644
--- a/bip-0062.mediawiki
+++ b/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.
diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki
index d2ab189..a47c82d 100644
--- a/bip-0066.mediawiki
+++ b/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.
diff --git a/bip-0103.mediawiki b/bip-0103.mediawiki
index 7cef84a..36bb87f 100644
--- a/bip-0103.mediawiki
+++ b/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.
diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki
index d438322..2404937 100644
--- a/bip-0123.mediawiki
+++ b/bip-0123.mediawiki
@@ -7,6 +7,8 @@
   Status: Active
   Type: Process
   Created: 2015-08-26
+  License: CC0-1.0
+           GNU-All-Permissive
 </pre>
 
 ==Abstract==
@@ -17,6 +19,10 @@ BIPs are classified by system layers with lower numbered layers involving more i
 
 The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs.
 
+==Copyright==
+
+This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses.
+
 ==Motivation==
 
 Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them.
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index 0de4a36..5589abb 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -86,7 +86,7 @@ my %DefinedLicenses = (
 	'PD' => undef,
 );
 my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152);
-my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 30 31 32 33 34 35 39 43 44 45 47 61 62 64 66 68 70 71 72 73 101 102 103 106 120 121 123);
+my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121);
 
 my %emails;