mirror of https://github.com/zcash/zips.git
570 lines
24 KiB
ReStructuredText
570 lines
24 KiB
ReStructuredText
::
|
||
|
||
ZIP: 0
|
||
Title: ZIP Process
|
||
Champions: 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 Champions 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 Champion -- 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 Champion (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 Champion 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 Champion. Just because an idea sounds good to
|
||
the Champion does not mean it will work for most people in most areas
|
||
where Zcash is used.
|
||
|
||
Once the Champion 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 Champion 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 (Champions MUST NOT self-assign ZIP numbers).
|
||
|
||
ZIP Champions 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 Champion may update the draft as necessary in the git
|
||
repository. Updates to drafts should also be submitted by the Champion
|
||
as pull requests.
|
||
|
||
|
||
Transferring ZIP Ownership
|
||
--------------------------
|
||
|
||
It occasionally becomes necessary to transfer ownership of ZIPs to a new
|
||
Champion. In general, we'd like to retain the original Champion as a
|
||
co-Champion of the transferred ZIP, but that's really up to the original
|
||
Champion. A good reason to transfer ownership is because the original
|
||
Champion 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 Champion and the ZIP
|
||
Editors. If the original Champion 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 Zcash
|
||
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
|
||
Zcash 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 Champion 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.
|
||
* List the ZIP in `README.rst <README.rst>`__
|
||
|
||
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 Champion of the document are inimical
|
||
to the Zcash Code of Conduct [#conduct]_ (except in the case of an update
|
||
removing that Champion);
|
||
* it is not authorized by the stated ZIP Champions;
|
||
* it removes an Champion without their consent (unless the reason for removal
|
||
is directly related to a breach of the Code of Conduct by that Champion).
|
||
|
||
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 <#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.
|
||
|
||
* 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.
|
||
|
||
* 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.
|
||
|
||
* 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.
|
||
|
||
* Reference implementation -- 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:
|
||
Champions:
|
||
Status:
|
||
Category:
|
||
Created:
|
||
License:
|
||
|
||
The following additional header fields are OPTIONAL::
|
||
|
||
Discussions-To:
|
||
Network Upgrade:
|
||
Obsoleted by:
|
||
Updated by:
|
||
Obsoletes:
|
||
Updates:
|
||
|
||
The Champions header lists the names and email addresses of all the
|
||
champions/owners of the ZIP. The format of the Champions header value
|
||
SHOULD be::
|
||
|
||
Random J. User <address@dom.ain>
|
||
|
||
If there are multiple champions, 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 Champion, 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, any ZIP that
|
||
requires more than one file 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 Champion 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 and feedback 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 Champion resumes work
|
||
or resolves issues preventing consensus.
|
||
|
||
* 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
|
||
-------------
|
||
|
||
Champions 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 Champion deems it is complete and there is rough consensus on the
|
||
mailing list, validated by both the Zcash 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 Champion provides an associated reference
|
||
implementation, typically in the period after the network upgrade's
|
||
specification freeze but before the implementation audit. If the Champion
|
||
misses this deadline, the Editors or Champion(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 Champion
|
||
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/>`_
|
||
|