mirror of https://github.com/zcash/zips.git
640 lines
27 KiB
ReStructuredText
640 lines
27 KiB
ReStructuredText
::
|
|
|
|
ZIP: 0
|
|
Title: ZIP Process
|
|
Owners: Daira Hopwood <daira@electriccoin.co>
|
|
Deirdre Connolly <deirdre@zfnd.org>
|
|
Original-Authors: Daira Hopwood
|
|
Josh Cincinnati
|
|
George Tankersley
|
|
Credits: Luke Dashjr
|
|
Status: Active
|
|
Category: 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 Owner(s) of the ZIP
|
|
(usually the authors(s)) 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 partly on the work done by Luke Dashjr with
|
|
`BIP 2 <https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki>`__.
|
|
|
|
|
|
ZIP Workflow
|
|
============
|
|
|
|
The ZIP process begins with a new idea for Zcash. Each potential ZIP
|
|
must have Owners — one or more people who write the ZIP using the style
|
|
and format described below, shepherd the discussions in the appropriate
|
|
forums, and attempt to build community consensus around the idea. The
|
|
ZIP Owners 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 Community Forum <https://forum.zcashcommunity.com/>`__.
|
|
|
|
Vetting an idea publicly before going as far as writing a ZIP is meant
|
|
to save both the potential Owners 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 Owners. Just because an idea sounds good to
|
|
the Owners does not mean it will work for most people in most areas
|
|
where Zcash is used.
|
|
|
|
Once the Owners have asked the Zcash community as to whether an idea
|
|
has any chance of acceptance, a draft ZIP should be presented to the
|
|
`Zcash Community Forum <https://forum.zcashcommunity.com/>`__.
|
|
This gives the Owners 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 forums 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 (if that has not already been done) and one or more Categories,
|
|
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 Owners may update the draft as necessary in the git repository.
|
|
Updates to drafts should also be submitted by the Owners as pull requests.
|
|
|
|
|
|
ZIP Numbering Conventions
|
|
-------------------------
|
|
|
|
The ZIP Editors currently use the following conventions when numbering
|
|
ZIPs:
|
|
|
|
* if a ZIP directly corresponds to a BIP (Bitcoin Improvement Proposal),
|
|
and the number doesn't clash, assign the same number;
|
|
* if it affects the consensus layer or the core protocol, assign a
|
|
number in the range 200..299;
|
|
* if it affects only higher layers but is needed for interoperability
|
|
between node implementations or other parts of the ecosystem, assign
|
|
a number in the range 300..399;
|
|
* if it is specific to an implementation (e.g. zcashd or zebra), assign
|
|
a number in the range 400..499;
|
|
* try to number ZIPs that should or will be deployed together
|
|
consecutively (subject to the above conventions), and in a coherent
|
|
reading order.
|
|
|
|
These conventions are subject to change by consensus of the ZIP Editors.
|
|
|
|
|
|
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 :).
|
|
|
|
If an author of a ZIP is no longer an Owner, an Original-Authors field
|
|
SHOULD be added to the ZIP metadata indicating the original authorship,
|
|
unless the original author(s) request otherwise.
|
|
|
|
|
|
ZIP Editors
|
|
-----------
|
|
|
|
The current ZIP Editors are Daira Hopwood, representing the Electric Coin
|
|
Company, and Deirdre Connolly, 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 Community Forum.
|
|
<https://forum.zcashcommunity.com/>`__
|
|
|
|
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 Community Forum or as
|
|
a PR to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
|
* 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 Owners 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. It SHOULD NOT contain a ZIP number
|
|
unless one had already been assigned by the ZIP Editors. The pull
|
|
request SHOULD initially be marked as a Draft.
|
|
|
|
The ZIP Editors will:
|
|
|
|
* Assign a ZIP number in the pull request.
|
|
* Remove Draft status and 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,
|
|
if there is one;
|
|
* 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 in reStructuredText [#rst]_, Markdown [#markdown]_,
|
|
or LaTeX [#latex]_. For ZIPs written in LaTeX, 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 [#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” or “Final”,
|
|
but it generally need not be completed before the ZIP is accepted
|
|
into “Proposed”.
|
|
|
|
ZIP header preamble
|
|
-------------------
|
|
|
|
Each ZIP MUST begin with a RFC 822-style header preamble. For ZIPs written
|
|
in reStructuredText, this is represented as ``::`` on the first line,
|
|
followed by a blank line, then the preamble indented by 2 spaces.
|
|
|
|
The following header fields are REQUIRED::
|
|
|
|
ZIP:
|
|
Title:
|
|
Owners:
|
|
Status:
|
|
Category:
|
|
Created:
|
|
License:
|
|
|
|
The following additional header fields are OPTIONAL::
|
|
|
|
Credits:
|
|
Original-Authors:
|
|
Discussions-To:
|
|
Pull-Request:
|
|
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.
|
|
|
|
The "Owners", "Credits", and "Original-Authors" headers always use
|
|
these plural spellings even there is only one Owner, one person to be
|
|
credited, or one original author.
|
|
|
|
While a ZIP is in public discussions (usually during the initial Draft
|
|
phase), a Discussions-To header will indicate the URL where the ZIP is
|
|
being discussed. No Discussions-To header is necessary if the ZIP is being
|
|
discussed privately with the Owner.
|
|
|
|
The Pull-Request header, if present, gives an URL to a Pull Request for
|
|
the ZIP.
|
|
|
|
The Category header specifies the type of ZIP, as described in
|
|
`ZIP categories`_. Multiple categories MAY be specified, separated by
|
|
" ``/`` ".
|
|
|
|
The Created header records the date that the ZIP was submitted.
|
|
Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.
|
|
|
|
For ZIPs written in reStructuredText, URLs in header fields SHOULD be
|
|
surrounded by ``<`` ``>``; this ensures that the link is rendered correctly.
|
|
|
|
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 categories
|
|
==============
|
|
|
|
Each ZIP is in one or more of the following categories, as specified
|
|
in the Category header:
|
|
|
|
Consensus
|
|
Rules that affect the consensus protocol followed by all Zcash
|
|
implementations.
|
|
Standards
|
|
Non-consensus changes affecting most or all Zcash implementations, or
|
|
the interoperability of applications using Zcash.
|
|
Process
|
|
A Process ZIP describes a process surrounding Zcash, or proposes a
|
|
change to (or an event in) a process. 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.
|
|
Consensus Process
|
|
A subcategory of Process ZIP that specifies requirements and processes
|
|
that are to be realized by one or more Consensus ZIPs, and/or by social
|
|
consensus of the Zcash community.
|
|
Informational
|
|
An Informational ZIP describes non-consensus Zcash design issues, or
|
|
general guidelines or information for the Zcash community. These ZIPs
|
|
do not not necessarily represent a Zcash community consensus or
|
|
recommendation, so users and implementors are free to ignore
|
|
Informational ZIPs or follow their advice.
|
|
Network
|
|
Specifications of peer-to-peer networking behaviour.
|
|
RPC
|
|
Specifications of the RPC interface provided by zcashd nodes.
|
|
Wallet
|
|
Specifications affecting wallets (e.g. non-consensus changes to how
|
|
transactions, addresses, etc. are constructed or interpreted).
|
|
Ecosystem
|
|
Specifications otherwise useful to the Zcash ecosystem.
|
|
|
|
New categories may be added by consensus among the ZIP Editors.
|
|
|
|
Consensus and Standards ZIPs SHOULD have a Reference Implementation section,
|
|
which includes or (more often) links to an implementation.
|
|
|
|
Consensus ZIPs SHOULD have a Deployment section, describing how and when
|
|
the consensus change is planned to be deployed (for example, in a particular
|
|
network upgrade).
|
|
|
|
|
|
ZIP Status Field
|
|
================
|
|
|
|
* Reserved: The ZIP Editors have reserved this ZIP number, and there MAY
|
|
be a Pull Request for it, but no ZIP has been published. The ZIP Editors
|
|
SHOULD publish a stub header so that the reservation appears in the
|
|
`ZIP index <https://zips.z.cash#index-of-zips>`__.
|
|
|
|
* 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/forum posts 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 ZIP has a working
|
|
reference implementation but before activation on the Zcash network.
|
|
|
|
* Final: When a Consensus or Standards 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 are given 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
|
|
forums, 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 Consensus ZIP, a Deployment section MUST
|
|
be present in order for the ZIP to change status to Proposed. Typically,
|
|
although not necessarily, this will specify a network upgrade in which
|
|
the consensus change is to activate.
|
|
|
|
A Standards ZIP may only change status from Proposed to Implemented once
|
|
the Owners provide an associated reference implementation, typically in
|
|
the period after the network upgrade's specification freeze but before
|
|
the implementation audit. If the Owners miss this deadline, the Editors
|
|
or Owners MAY choose to update the Deployment section of the ZIP 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 paragraphs.
|
|
|
|
A Consensus or Standards 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 forum or PR. Such a proposal is
|
|
said to have rough consensus if it has been open to discussion on the
|
|
forum or GitHub PR 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
|
|
Community Forum 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://www.rfc-editor.org/rfc/rfc7282.html>`__
|
|
* `Zcash Network Upgrade Pipeline <https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/>`__
|
|
|
|
|
|
References
|
|
==========
|
|
|
|
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
|
.. [#RFC3552] `RFC 3552: Guidelines for Writing RFC Text on Security Considerations <https://www.rfc-editor.org/rfc/rfc3552.html>`_
|
|
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <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>`_
|
|
.. [#markdown] `The Markdown Guide <https://www.markdownguide.org/>`_
|
|
.. [#latex] `LaTeX — a document preparation system <https://www.latex-project.org/>`_
|