fix: add apache 2 license🚧

LICENSE

@@ -0,0 +1,11 @@
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

_specs/ecip-1000.md

@@ -18,10 +18,6 @@ We intend ECIPs to be the primary mechanism for proposing new features, for coll
 
 Because the ECIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
 
-# Copyright
-
-This ECIP is licensed Apache-2, originally by [Luke Dashjr](https://github.com/luke-jr) under BSD 2-clause license.
-
 # ECIP Workflow
 
 ## Introduction
@@ -112,7 +108,6 @@ Each ECIP should have the following parts:
 
 - **Preamble** -- Headers containing metadata about the ECIP [see below](https://github.com/ethereumclassic/ECIPs/blob/master/ECIPs/ECIP-1000.mediawiki#ecip-header-preamble).
 - **Abstract** -- A short (~200 word) description of the technical issue being addressed.
-- **Copyright** -- The ECIP must be explicitly licensed under acceptable copyright terms [see below](https://github.com/ethereumclassic/ECIPs/blob/master/ECIPs/ECIP-1000.mediawiki#ecip-licensing)
 - **Specification** -- The technical specification should describe the syntax and semantics of any new feature. It should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum Classic platforms.
 - **Motivation** -- The motivation is critical for ECIPs that want to change the Ethereum Classic protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the ECIP solves.
 - **Rationale** -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. It should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
@@ -133,8 +128,6 @@ Each ECIP must begin with an RFC 822 style header preamble. The headers must app
 - **Status:** (Draft | Last Call | Accepted | Final | Deferred | Replaced | Rejected | Withdrawn)
 - **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))
 - **Requires:** (ECIP number(s))
 - **Replaces:** (ECIP number)
 - **Superseded-By:** (ECIP number)
@@ -291,66 +284,7 @@ To avoid doubt: comments and status are unrelated metrics to judge an ECIP, and
 
 ## ECIP Licensing
 
-### Specification
-
-New ECIPs may be accepted with the following licenses. Each new ECIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below.
-
-For example, a preamble might include the following License header:
-
-    License: BSD-2-Clause
-             GNU-All-Permissive
-
-In this case, the ECIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement.
-
-It is also possible to license source code differently from the ECIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
-
-For example, a preamble specifying the optional License-Code header might look like:
-
-    License: BSD-2-Clause
-             GNU-All-Permissive
-    License-Code: GPL-2.0+
-
-In this case, the code in the ECIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer.
-If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation.
-For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent).
-
-    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*.
-
-In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the ECIP.
-
-ECIPs are not required to be *exclusively* licensed under approved terms, and may also be licensed under unacceptable licenses *in addition to* at least one acceptable license.
-In this case, only the acceptable license(s) should be listed in the License and License-Code headers.
-
-### Recommended licenses
-
-* Apache-2.0: [Apache License, version 2.0](http://www.apache.org/licenses/LICENSE-2.0)
-* BSD-2-Clause: [OSI-approved BSD 2-clause license](https://opensource.org/licenses/BSD-2-Clause)
-* BSD-3-Clause: [OSI-approved BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause)
-* CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
-* GNU-All-Permissive: [GNU All-Permissive License](http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html)
-
-In addition, it is recommended that literal code included in the ECIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Ethereum Classic Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the ECIP text.
-
-### Not recommended, but acceptable licenses
-
-* BSL-1.0: [Boost Software License, version 1.0](http://www.boost.org/LICENSE_1_0.txt)
-* CC-BY-4.0: [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/)
-* CC-BY-SA-4.0: [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)
-* MIT: [Expat/MIT/X11 license](https://opensource.org/licenses/MIT)
-* AGPL-3.0+: [GNU Affero General Public License (AGPL), version 3 or newer](http://www.gnu.org/licenses/agpl-3.0.en.html)
-* FDL-1.3: [GNU Free Documentation License, version 1.3](http://www.gnu.org/licenses/fdl-1.3.en.html)
-* GPL-2.0+: [GNU General Public License (GPL), version 2 or newer](http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)
-* LGPL-2.1+: [GNU Lesser General Public License (LGPL), version 2.1 or newer](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html)
-
-## Rationale
-
-**Why are there software licenses included?**
-
-* Some ECIPs, especially consensus layer, may include literal code in the ECIP itself which may not be available under the exact license terms of the ECIP.
-* Despite this, not all software licenses would be acceptable for content included in ECIPs.
+You may not specify a license. Claims to any license other than the one specified [here](https://github.com/ethereumclassic/ECIPs/blob/master/LICENSE) are invalid.
 
 # See Also