mirror of https://github.com/zcash/zips.git
commit
8af142b670
|
@ -10,5 +10,5 @@ Participation in the Zcash project is subject to a
|
|||
License
|
||||
-------
|
||||
|
||||
The contents of this repository are released under the terms of the MIT license.
|
||||
Unless otherwise stated in this repository's individual files, the contents of this repository are released under the terms of the MIT license.
|
||||
See [COPYING](COPYING) for more information or see http://opensource.org/licenses/MIT.
|
||||
|
|
|
@ -0,0 +1,579 @@
|
|||
::
|
||||
|
||||
ZIP: 0
|
||||
Title: ZIP Process
|
||||
Owners: Daira Hopwood
|
||||
Josh Cincinnati
|
||||
Status: Draft
|
||||
Type: Process
|
||||
Created: 2019-02-16
|
||||
License: BSD-2-Clause
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED",
|
||||
"OPTIONAL", and "REQUIRED" in this document are to be interpreted as
|
||||
described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as
|
||||
described in ZIP 200. [#zip-0200]_
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
A Zcash Improvement Proposal (ZIP) is a design document providing
|
||||
information to the Zcash community, or describing a new feature for
|
||||
Zcash or its processes or environment. The ZIP should provide a concise
|
||||
technical specification of the feature and a rationale for the feature.
|
||||
|
||||
We intend ZIPs to be the primary mechanism for proposing new features,
|
||||
for collecting community input on an issue, and for documenting the
|
||||
design decisions that have gone into Zcash. The author(s) of the ZIP
|
||||
(known as Owners in this document) are responsible for building
|
||||
consensus within the community and documenting dissenting opinions.
|
||||
|
||||
Because the ZIPs are maintained as text files in a versioned repository,
|
||||
their revision history is the historical record of the feature proposal.
|
||||
|
||||
This document is based on the work done by Luke Dashjr with
|
||||
`BIP 2 <https://github.com/bitcoin/bips>`__ and Daira Hopwood with
|
||||
`Draft ZIP 0 <https://github.com/daira/zips/tree/master/drafts/daira-zip-process>`__.
|
||||
|
||||
|
||||
ZIP Workflow
|
||||
============
|
||||
|
||||
The ZIP process begins with a new idea for Zcash. Each potential ZIP
|
||||
must have a Owner -- someone who writes the ZIP using the style and
|
||||
format described below, shepherds the discussions in the appropriate
|
||||
forums, and attempts to build community consensus around the idea. The
|
||||
ZIP Owner (a.k.a. author) should first attempt to ascertain whether
|
||||
the idea is ZIP-able. Small enhancements or patches to a particular
|
||||
piece of software often don't require standardisation between multiple
|
||||
projects; these don't need a ZIP and should be injected into the
|
||||
relevant project-specific development workflow with a patch submission
|
||||
to the applicable issue tracker. Additionally, many ideas have been
|
||||
brought forward for changing Zcash that have been rejected for various
|
||||
reasons. The first step should be to search past discussions to see if
|
||||
an idea has been considered before, and if so, what issues arose in its
|
||||
progression. After investigating past work, the best way to proceed is
|
||||
by posting about the new idea to the `Zcash Ecosystem Development
|
||||
list <https://lists.z.cash.foundation/mailman/listinfo/zcash-ecosystem-dev>`__.
|
||||
|
||||
Vetting an idea publicly before going as far as writing a ZIP is meant
|
||||
to save both the potential Owner and the wider community time. Asking
|
||||
the Zcash community first if an idea is original helps prevent too much
|
||||
time being spent on something that is guaranteed to be rejected based on
|
||||
prior discussions (searching the internet does not always do the trick).
|
||||
It also helps to make sure the idea is applicable to the entire
|
||||
community and not just the Owner. Just because an idea sounds good to
|
||||
the Owner does not mean it will work for most people in most areas
|
||||
where Zcash is used.
|
||||
|
||||
Once the Owner has asked the Zcash community as to whether an idea
|
||||
has any chance of acceptance, a draft ZIP should be presented to the
|
||||
`Zcash Ecosystem Development list
|
||||
<https://lists.z.cash.foundation/mailman/listinfo/zcash-ecosystem-dev>`__.
|
||||
This gives the Owner a chance to flesh out the draft ZIP to make it
|
||||
properly formatted, of high quality, and to address additional concerns
|
||||
about the proposal. Following a discussion, the proposal should be
|
||||
submitted to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
||||
as a pull request. This draft must be written in ZIP style as described
|
||||
below, and named with an alias such as
|
||||
``zip-zatoshizakamoto-42millionzec`` until the ZIP Editors have assigned
|
||||
it a ZIP number (Owners MUST NOT self-assign ZIP numbers).
|
||||
|
||||
ZIP Owners are responsible for collecting community feedback on both
|
||||
the initial idea and the ZIP before submitting it for review. However,
|
||||
wherever possible, long open-ended discussions on public mailing lists
|
||||
should be avoided.
|
||||
|
||||
It is highly recommended that a single ZIP contain a single key proposal
|
||||
or new idea. The more focused the ZIP, the more successful it tends to
|
||||
be. If in doubt, split your ZIP into several well-focused ones.
|
||||
|
||||
When the ZIP draft is complete, the ZIP Editors will assign the ZIP a
|
||||
number, label it as Standards Track, Informational, or Process, and
|
||||
merge the pull request to the ZIPs git repository. The ZIP Editors
|
||||
will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include
|
||||
duplication of effort, disregard for formatting rules, being too
|
||||
unfocused or too broad, being technically unsound, not providing proper
|
||||
motivation or not in keeping with the Zcash philosophy. For a ZIP to be
|
||||
accepted it must meet certain minimum criteria. It must be a clear and
|
||||
complete description of the proposed enhancement. The enhancement must
|
||||
represent a net improvement. The proposed implementation, if applicable,
|
||||
must be solid and must not complicate the protocol unduly.
|
||||
|
||||
The ZIP Owner may update the draft as necessary in the git
|
||||
repository. Updates to drafts should also be submitted by the Owner
|
||||
as pull requests.
|
||||
|
||||
|
||||
Transferring ZIP Ownership
|
||||
--------------------------
|
||||
|
||||
It occasionally becomes necessary to transfer ownership of ZIPs to a new
|
||||
Owner. In general, we'd like to retain the original Owner as a
|
||||
co-Owner of the transferred ZIP, but that's really up to the original
|
||||
Owner. A good reason to transfer ownership is because the original
|
||||
Owner no longer has the time or interest in updating it or following
|
||||
through with the ZIP process, or has fallen off the face of the 'net
|
||||
(i.e. is unreachable or not responding to email). A bad reason to
|
||||
transfer ownership is because you don't agree with the direction of the
|
||||
ZIP. We try to build consensus around a ZIP, but if that's not possible,
|
||||
you can always submit a competing ZIP.
|
||||
|
||||
If you are interested in assuming ownership of a ZIP, send a message
|
||||
asking to take over, addressed to both the original Owner and the ZIP
|
||||
Editors. If the original Owner doesn't respond to email in a timely
|
||||
manner, the ZIP Editors will make a unilateral decision (it's not like
|
||||
such decisions can't be reversed :).
|
||||
|
||||
|
||||
ZIP Editors
|
||||
-----------
|
||||
|
||||
The current ZIP Editors are Daira Hopwood, representing the Electric Coin
|
||||
Company, and Josh Cincinnati, representing the Zcash Foundation. Both
|
||||
can be reached at zips@z.cash . The current design of the ZIP Process
|
||||
dictates that there are always at least two ZIP Editors: one from the
|
||||
Electric Coin Company and one from the Zcash Foundation. Additional Editors may
|
||||
be selected by consensus among the current Editors.
|
||||
|
||||
|
||||
ZIP Editor Responsibilities & Workflow
|
||||
--------------------------------------
|
||||
|
||||
The ZIP Editors subscribe to the Zcash Ecosystem Development list.
|
||||
|
||||
For each new ZIP that comes in an Editor confirms the following:
|
||||
|
||||
* Read the ZIP to check if it is ready: sound and complete. The ideas
|
||||
must make technical sense, even if they don't seem likely to be
|
||||
accepted.
|
||||
* The title should accurately describe the content.
|
||||
* The ZIP draft must have been sent to the Zcash Ecosystem Development
|
||||
mailing list or another suitable forum for discussion.
|
||||
* Motivation and backward compatibility (when applicable) must be
|
||||
addressed.
|
||||
* The licensing terms are acceptable for ZIPs.
|
||||
|
||||
If the ZIP isn't ready, the editor will send it back to the Owner for
|
||||
revision, with specific instructions.
|
||||
|
||||
Once the ZIP is ready for the repository it should be submitted as a
|
||||
"pull request" to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
||||
where it may get further feedback.
|
||||
|
||||
The ZIP Editors will:
|
||||
|
||||
* Assign a ZIP number in the pull request.
|
||||
* Merge the pull request when it is ready.
|
||||
|
||||
The ZIP editors monitor ZIP changes and update ZIP headers as
|
||||
appropriate.
|
||||
|
||||
The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP
|
||||
for any of the following reasons:
|
||||
|
||||
* it violates the Zcash Code of Conduct [#conduct]_ ;
|
||||
* it appears too unfocused or broad;
|
||||
* it duplicates effort in other ZIPs without sufficient technical justification
|
||||
(however, alternative proposals to address similar or overlapping problems
|
||||
are not excluded for this reason);
|
||||
* it has manifest security flaws (including being unrealistically dependent
|
||||
on user vigilance to avoid security weaknesses);
|
||||
* it disregards compatibility with the existing Zcash blockchain or ecosystem;
|
||||
* it is manifestly unimplementable;
|
||||
* it includes buggy code, pseudocode, or algorithms;
|
||||
* it manifestly violates common expectations of a significant portion of the
|
||||
Zcash community;
|
||||
* it updates a Draft ZIP to Released when there is significant community
|
||||
opposition to its content (however, Draft ZIPs explicitly may describe
|
||||
proposals to which there is, or could be expected, significant community
|
||||
opposition);
|
||||
* in the case of a Released ZIP, the update makes a substantive change to
|
||||
which there is significant community opposition;
|
||||
* it is dependent on a patent that could potentially be an obstacle to
|
||||
adoption of the ZIP;
|
||||
* it includes commercial advertising or spam;
|
||||
* it disregards formatting rules;
|
||||
* it makes non-editorial edits to previous entries in a ZIP's Change history;
|
||||
* an update to an existing ZIP extends or changes its scope to an extent
|
||||
that would be better handled as a separate ZIP;
|
||||
* a new ZIP has been proposed for a category that does not reflect its content,
|
||||
or an update would change a ZIP to an inappropriate category;
|
||||
* it updates a Released ZIP to Draft when the specification is already
|
||||
implemented and has been in common use;
|
||||
* it violates any specific "MUST" or "MUST NOT" rule in this document;
|
||||
* the expressed political views of a Owner of the document are inimical
|
||||
to the Zcash Code of Conduct [#conduct]_ (except in the case of an update
|
||||
removing that Owner);
|
||||
* it is not authorized by the stated ZIP Owners;
|
||||
* it removes an Owner without their consent (unless the reason for removal
|
||||
is directly related to a breach of the Code of Conduct by that Owner).
|
||||
|
||||
The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal
|
||||
or update that does not violate any of these criteria. If they refuse a
|
||||
proposal or update, they MUST give an explanation of which of the
|
||||
criteria were violated, with the exception that spam may be deleted
|
||||
without an explanation.
|
||||
|
||||
Note that it is not the primary responsibility of the ZIP Editors to
|
||||
review proposals for security, correctness, or implementability.
|
||||
|
||||
Please send all ZIP-related communications either by email to
|
||||
<zips@z.cash>, or by opening an issue on the `ZIPs issue
|
||||
tracker <https://github.com/zcash/zips/issues>`__. All communications
|
||||
should abide by the Zcash Code of Conduct [#conduct]_
|
||||
and follow `the GNU Kind Communication
|
||||
Guidelines <https://www.gnu.org/philosophy/kind-communication.en.html>`__
|
||||
|
||||
|
||||
ZIP format and structure
|
||||
========================
|
||||
|
||||
ZIPs SHOULD be written either in reStructuredText [#rst]_ or LaTeX [#latex]_.
|
||||
In the latter case, a `Makefile` MUST be provided to build (at least) a
|
||||
PDF version of the document.
|
||||
|
||||
Each ZIP SHOULD have the following parts:
|
||||
|
||||
* Preamble -- Headers containing metadata about the ZIP (`see
|
||||
below <#zip-header-preamble>`__).
|
||||
The License field of the preamble indicates the licensing terms,
|
||||
which MUST be acceptable according to `the ZIP licensing requirements <#zip-licensing>`__.
|
||||
|
||||
* Terminology -- Definitions of technical or non-obvious terms used
|
||||
in the document.
|
||||
|
||||
* Abstract -- A short (~200 word) description of the technical issue
|
||||
being addressed.
|
||||
|
||||
* Motivation -- The motivation is critical for ZIPs that want to change
|
||||
the Zcash protocol. It should clearly explain why the existing
|
||||
protocol is inadequate to address the problem that the ZIP solves.
|
||||
|
||||
* Specification -- The technical specification should describe the
|
||||
interface and semantics of any new feature. The specification should be
|
||||
detailed enough to allow competing, interoperable implementations for
|
||||
any of the current Zcash platforms.
|
||||
|
||||
* 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. The rationale should provide evidence of
|
||||
consensus within the community and discuss important objections or
|
||||
concerns raised during discussion.
|
||||
|
||||
* Security and privacy considerations -- If applicable, security
|
||||
and privacy considerations should be explicitly described, particularly
|
||||
if the ZIP makes explicit trade-offs or assumptions. For guidance on
|
||||
this section consider `RFC 3552 <https://tools.ietf.org/html/rfc3552>`__.
|
||||
as a starting point.
|
||||
|
||||
* Reference implementation -- Literal code implementing the ZIP's
|
||||
specification, and/or a link to the reference implementation of
|
||||
the ZIP's specification. The reference implementation must be
|
||||
completed before any ZIP is given status “Implemented”, but it
|
||||
generally need not be completed before the ZIP is accepted into
|
||||
Proposed.
|
||||
|
||||
ZIP header preamble
|
||||
-------------------
|
||||
|
||||
Each ZIP must begin with an RFC 822-style header preamble. The following
|
||||
header fields are REQUIRED::
|
||||
|
||||
ZIP:
|
||||
Title:
|
||||
Owners:
|
||||
Status:
|
||||
Category:
|
||||
Created:
|
||||
License:
|
||||
|
||||
The following additional header fields are OPTIONAL::
|
||||
|
||||
Discussions-To:
|
||||
Network Upgrade:
|
||||
Obsoleted by:
|
||||
Updated by:
|
||||
Obsoletes:
|
||||
Updates:
|
||||
|
||||
The Owners header lists the names and email addresses of all the
|
||||
Owners of the ZIP. The format of the Owners header value SHOULD be::
|
||||
|
||||
Random J. User <address@dom.ain>
|
||||
|
||||
If there are multiple Owners, each should be on a separate line.
|
||||
|
||||
While a ZIP is in private discussions (usually during the initial Draft
|
||||
phase), a Discussions-To header will indicate the mailing list or URL
|
||||
where the ZIP is being discussed. No Discussions-To header is necessary
|
||||
if the ZIP is being discussed privately with the Owner, or on the
|
||||
Zcash email mailing lists.
|
||||
|
||||
The Category header specifies the type of ZIP: Consensus, Standards Track,
|
||||
Informational, or Process.
|
||||
|
||||
The Created header records the date that the ZIP was submitted.
|
||||
Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.
|
||||
|
||||
Auxiliary Files
|
||||
---------------
|
||||
|
||||
ZIPs may include auxiliary files such as diagrams. Auxiliary files
|
||||
should be included in a subdirectory for that ZIP; that is, for any ZIP
|
||||
that requires more than one file, all of the files SHOULD be in a
|
||||
subdirectory named zip-XXXX.
|
||||
|
||||
|
||||
ZIP types
|
||||
=========
|
||||
|
||||
There are several kinds of ZIP:
|
||||
|
||||
* A Consensus ZIP describes a change that affects the consensus protocol
|
||||
followed by all Zcash implementations.
|
||||
|
||||
* A Standards Track ZIP describes any non-consensus change that affects
|
||||
most or all Zcash implementations, such as a change to the network
|
||||
protocol, or any change or addition that affects the interoperability
|
||||
of applications using Zcash.
|
||||
|
||||
Consensus and Standards Track ZIPs consist of two parts: a design document
|
||||
and a reference implementation.
|
||||
|
||||
* An Informational ZIP describes Zcash design issues, or general
|
||||
guidelines or information for the Zcash community, that do not fall
|
||||
into either of the above categories. Informational ZIPs do not
|
||||
necessarily represent a Zcash community consensus or recommendation,
|
||||
so users and implementers are free to ignore Informational ZIPs or
|
||||
follow their advice.
|
||||
|
||||
* A Process ZIP describes a process surrounding Zcash, or proposes a
|
||||
change to (or an event in) a process. Process ZIPs are like Standards
|
||||
Track ZIPs but apply to areas other than the Zcash protocol itself.
|
||||
They may propose an implementation, but not to Zcash's codebase; they
|
||||
often require community consensus; unlike Informational ZIPs, they
|
||||
are more than recommendations, and users are typically not free to
|
||||
ignore them. Examples include procedures, guidelines, changes to the
|
||||
decision-making process, and changes to the tools or environment used
|
||||
in Zcash development.
|
||||
|
||||
New categories may be added by consensus among the ZIP Editors.
|
||||
|
||||
|
||||
ZIP Status Field
|
||||
================
|
||||
|
||||
* Draft: All initial ZIP submissions have this status.
|
||||
|
||||
* Withdrawn: If the Owner decides to remove the ZIP from
|
||||
consideration by the community, they may set the status to Withdrawn.
|
||||
|
||||
* Active: Typically only used for Process/Informational ZIPs, achieved
|
||||
once rough consensus is reached in PR/mailing list from Draft Process
|
||||
ZIP.
|
||||
|
||||
* Proposed: Typically the stage after Draft, added to a ZIP after
|
||||
consideration, feedback, and rough consensus from the community. The ZIP Editors must
|
||||
validate this change before it is approved.
|
||||
|
||||
* Rejected: The status when progress hasn't been made on the ZIP in one
|
||||
year. Can revert back to Draft/Proposed if the Owner resumes work
|
||||
or resolves issues preventing consensus.
|
||||
|
||||
* Implemented: When a Consensus or Standards Track ZIP has a working
|
||||
reference implementation but before activation on the Zcash network.
|
||||
|
||||
* Final: When a Consensus or Standards Track ZIP is both implemented
|
||||
and activated on the Zcash network.
|
||||
|
||||
* Obsolete: The status when a ZIP is no longer relevant (typically when
|
||||
superseded by another ZIP).
|
||||
|
||||
More details on the status workflow in the section below.
|
||||
|
||||
Specification
|
||||
-------------
|
||||
|
||||
Owners of a ZIP may decide on their own to change the status between
|
||||
Draft or Withdrawn.
|
||||
|
||||
A ZIP may only change status from Draft (or Rejected) to Proposed, when
|
||||
the Owner deems it is complete and there is rough consensus on the
|
||||
mailing list, validated by both the Electric Coin Company and Zcash Foundation
|
||||
Editors. One Editor will not suffice -- there needs to be consensus
|
||||
among the Editors. If it's a Standards Track ZIP, upon changing status to
|
||||
Proposed the Editors will add the optional ``Network Upgrade`` header
|
||||
to the preamble, indicating the intent for the ZIP to be implemented in
|
||||
the specified network upgrade. (All ``Network Upgrade`` schedules will be
|
||||
distributed via the Zcash Ecosystem Developer list by the Editors.)
|
||||
|
||||
A Standards Track ZIP may only change status from Proposed to
|
||||
Implemented once the Owner provides an associated reference
|
||||
implementation, typically in the period after the network upgrade's
|
||||
specification freeze but before the implementation audit. If the Owner
|
||||
misses this deadline, the Editors or Owner(s) may choose to update
|
||||
the ``Network Upgrade`` header to target another upgrade, at their
|
||||
discretion.
|
||||
|
||||
ZIPs should be changed from Draft or Proposed status, to Rejected
|
||||
status, upon request by any person, if they have not made progress in
|
||||
one year. Such a ZIP may be changed to Draft status if the Owner
|
||||
provides revisions that meaningfully address public criticism of the
|
||||
proposal, or to Proposed status if it meets the criteria required as
|
||||
described in the previous paragraph.
|
||||
|
||||
A Consensus or Standards Track ZIP becomes Final when its associated
|
||||
network upgrade or other protocol change is activated on Zcash's mainnet.
|
||||
|
||||
A Process or Informational ZIP may change status from Draft to Active
|
||||
when it achieves rough consensus on the mailing list. Such a proposal is
|
||||
said to have rough consensus if it has been open to discussion on the
|
||||
development mailing list for at least one month, and no person maintains
|
||||
any unaddressed substantiated objections to it. Addressed or obstructive
|
||||
objections may be ignored/overruled by general agreement that they have
|
||||
been sufficiently addressed, but clear reasoning must be given in such
|
||||
circumstances.
|
||||
|
||||
When an Active or Final ZIP is no longer relevant, its status may be
|
||||
changed to Obsolete. This change must also be objectively verifiable
|
||||
and/or discussed. Final ZIPs may be updated; the specification is still
|
||||
in force but modified by another specified ZIP or ZIPs (check the
|
||||
optional Updated-by header).
|
||||
|
||||
|
||||
ZIP Comments
|
||||
============
|
||||
|
||||
Comments from the community on the ZIP should occur on the Zcash
|
||||
Ecosystem Developer list and the comment fields of the pull requests in
|
||||
any open ZIPs. Editors will use these sources to judge rough consensus.
|
||||
|
||||
|
||||
ZIP licensing
|
||||
=============
|
||||
|
||||
New ZIPs may be accepted with the following licenses. Each new ZIP MUST
|
||||
identify at least one acceptable license in its preamble. 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 ZIP 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 ZIP
|
||||
text. This case SHOULD be indicated in the Reference Implementation
|
||||
section of the ZIP. Again, each license MUST be referenced by its
|
||||
respective abbreviation given below.
|
||||
|
||||
Statements of code licenses in ZIPs are only advisory; anyone intending
|
||||
to use the code should look for license statements in the code itself.
|
||||
|
||||
ZIPs 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 header.
|
||||
|
||||
|
||||
Recommended licenses
|
||||
--------------------
|
||||
|
||||
* MIT: `Expat/MIT/X11 license <https://opensource.org/licenses/MIT>`__
|
||||
* 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>`__
|
||||
* Apache-2.0: `Apache License, version
|
||||
2.0 <http://www.apache.org/licenses/LICENSE-2.0>`__
|
||||
|
||||
In addition, it is RECOMMENDED that literal code included in the ZIP be
|
||||
dual-licensed under the same license terms as the project it modifies.
|
||||
For example, literal code intended for zcashd would ideally be
|
||||
dual-licensed under the MIT license terms as well as one of the above
|
||||
with the rest of the ZIP 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/>`__
|
||||
* 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>`__
|
||||
|
||||
Not acceptable licenses
|
||||
-----------------------
|
||||
|
||||
All licenses not explicitly included in the above lists are not
|
||||
acceptable terms for a Zcash Improvement Proposal.
|
||||
|
||||
Rationale
|
||||
---------
|
||||
|
||||
Bitcoin's BIP 1 allowed the Open Publication License or releasing into
|
||||
the public domain; was this insufficient?
|
||||
|
||||
* The OPL is generally regarded as obsolete, and not a license suitable
|
||||
for new publications.
|
||||
* The OPL license terms allowed for the author to prevent publication
|
||||
and derived works, which was widely considered inappropriate.
|
||||
* In some jurisdictions, releasing a work to the public domain is not
|
||||
recognised as a legitimate legal action, leaving the ZIP simply
|
||||
copyrighted with no redistribution or modification allowed at all.
|
||||
|
||||
Why are there software licenses included?
|
||||
|
||||
* Some ZIPs, especially in the Consensus category, may include literal
|
||||
code in the ZIP itself which may not be available under the exact
|
||||
license terms of the ZIP.
|
||||
* Despite this, not all software licenses would be acceptable for
|
||||
content included in ZIPs.
|
||||
|
||||
|
||||
See Also
|
||||
========
|
||||
|
||||
* `The GNU Kind Communication
|
||||
Guidelines <https://www.gnu.org/philosophy/kind-communication.en.html>`__
|
||||
* `RFC 7282: On Consensus and Humming in the
|
||||
IETF <https://tools.ietf.org/html/rfc7282>`__
|
||||
* `Zcash Network Upgrade Pipeline <https://z.cash/blog/the-zcash-network-upgrade-pipeline/>`__
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
||||
.. [#conduct] `Zcash Code of Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`_
|
||||
.. [#rst] `reStructuredText documentation <http://docutils.sourceforge.net/rst.html>`_
|
||||
.. [#latex] `LaTeX -- a document preparation system <https://www.latex-project.org/>`_
|
||||
|
Loading…
Reference in New Issue