Default License

[Psifour]

I have defaulted the repository to MIT, but defining an acceptable set of license for contributions (for inclusion in the OIPs definition that will be discussed in #3) may be necessary to ensure that this repo is freely available to be forked/extended. Maintaining permissive licensing means that if I (or other community member) were to attempt to undermine the purpose of this repo other's would be freely able to fork/clone and continue the valuable work of defining processes/standards for this ecosystem.

The most important aspects in choosing a license (from the perspective of being very permissive) is that it enable anyone to pickup a copy and host/display/modify/etc. in perpetuity. If there are other licenses you feel better meet this condition (or expand the condition) please share them below. Let's discuss these concerns now so that we can make Ordinals the best ecosystem for builders.

[Psifour]

I have included the definitions of permissible licenses (as defined by BIP 2) into the most recent push to #1.

This work is a copy of BIP 2 and will require ongoing rewrites to optimize it for this specific use-case.

[Psifour]

* BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
* BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
* GNU-All-Permissive: [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 OIP 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 OIP text.

====Not recommended, but acceptable licenses====

* Apache-2.0: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
* BSL-1.0: [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
* MIT: [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
* AGPL-3.0+: [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
* FDL-1.3: [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]
* GPL-2.0+: [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
* LGPL-2.1+: [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]

====Not acceptable licenses====

All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal unless a later OIP extends this one to add them.
However, OIPs predating the acceptance of this OIP were allowed under other terms, and should use these abbreviation when no other license is granted:

* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0]
* PD: Released into the public domain

===Rationale===

Why are there software licenses included?

* Some OIPs, especially consensus layer, may include literal code in the OIP itself which may not be available under the exact license terms of the OIP.
* Despite this, not all software licenses would be acceptable for content included in OIPs.

Why is Public Domain no longer acceptable for new OIPs?

* In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the OIP simply copyrighted with no redistribution or modification allowed at all.

If this definition is acceptable then it may also be necessary to update the LICENSE to one of these.