zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Mostly trivial wording changes and cosmetics; some simplifications. 

Remove OPL licensing; BSD 2-clause is sufficient.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2019-02-24 05:25:56 +00:00
parent 14da9191fb
commit 04f4c32dda
1 changed files with 275 additions and 288 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

563
zip-0000.rst
View File

@ -1,12 +1,25 @@
::
ZIP: ??
Title: ZIP Process
Champions: Daira Hopwood, Josh Cincinnati
Status: Draft
Type: Process
Created: 2019-02-16
License: BSD-2-Clause
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
========
@ -16,7 +29,7 @@ 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 mechanisms for proposing new features,
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
@ -25,15 +38,10 @@ 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/zcash/zips/tree/master/drafts/daira-zip-process>`__.
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>`__.
Copyright
=========
This ZIP is dual-licensed under the Open Publication License and BSD
2-clause license.
ZIP Workflow
============
@ -67,16 +75,16 @@ 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>`__.
`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 editor(s) have assigned it
a ZIP number (Champions MUST NOT self-assign ZIP numbers).
``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,
@ -87,9 +95,9 @@ 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 Editor(s) will assign the ZIP a
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 Editor(s)
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
@ -103,6 +111,7 @@ 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
--------------------------
@ -119,10 +128,11 @@ 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
Editor(s). If the original Champion doesn't respond to email in a timely
manner, the ZIP Editor(s) will make a unilateral decision (it's not like
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
-----------
@ -133,6 +143,7 @@ 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
--------------------------------------
@ -140,29 +151,28 @@ 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 for discussion.
- Motivation and backward compatibility (when applicable) must be
addressed.
- Licensing terms must be acceptable for ZIPs.
* 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.
"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.mediawiki <README.mediawiki>`__
* 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.
@ -170,43 +180,42 @@ 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`_;``
| ``* 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;``
| ``* 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 <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`__
| ``  (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);``
| ``* it is spam.``
* 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
@ -220,82 +229,82 @@ 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 <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`__
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
========================
Specification
-------------
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.
ZIPs should be written in mediawiki format.
Each ZIP SHOULD have the following parts:
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>`__.
- Preamble -- Headers containing metadata about the ZIP (`see
below <#ZIP_header_preamble>`__).
* Terminology -- Definitions of technical or non-obvious terms used
in the document.
- Abstract -- A short (~200 word) description of the technical issue
being addressed.
* Abstract -- A short (~200 word) description of the technical issue
being addressed.
- Copyright -- The ZIP must be explicitly licensed under acceptable
copyright terms (`see below <#ZIP_licensing>`__).
* 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.
- Specification -- The technical specification should describe the
syntax 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.
- 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.
- 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.
* 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 headers
must appear in the following order. Headers marked with “\*” are
optional and are described below. All other headers are required.
Each ZIP must begin with an RFC 822-style header preamble. The following
header fields are REQUIRED::
| `` ZIP: ``\
| `` Title: ``\
| `` Champions: ``\
| `` Discussions-To: ``\
| `` Status: ``\
| `` Type: ``\
| `` Network Upgrade: ``\
| `` Created: ``\
| `` License: ``\
| `` License-Code: ``\
| `` Discussion-URL: ``\
| `` Obsoleted by: ``\
| `` Updated by: ``\
| `` Obsoletes: ``\
| `` Updates: ``\
 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
must be
SHOULD be::
`` Random J. User <address@dom.ain>``
Random J. User <address@dom.ain>
If there are multiple champions, each should be on a separate line
following RFC 2822 continuation line conventions.
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
@ -303,78 +312,81 @@ 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 Type header specifies the type of ZIP: Standards Track,
The Category header specifies the type of ZIP: Consensus, Standards Track,
Informational, or Process.
The Created header records the date that the ZIP was assigned a number,
while Discussion-URL is used to record when new versions of the ZIP are
posted to zcash mailing lists. Dates should be in yyyy-mm-dd format,
e.g. 2001-08-14.
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 Standards Track ZIP describes any change that affects most or all
Zcash implementations, such as a change to the network protocol, a
change in block or transaction validity rules, or any change or
addition that affects the interoperability of applications using
Zcash. Standards Track ZIPs consist of two parts, a design document
and a reference implementation -- but they need only include a design
document for the initial Draft.
* A Consensus ZIP describes a change that affects the consensus protocol
followed by all Zcash implementations.
- An Informational ZIP describes a Zcash design issue, or provides
general guidelines or information to the Zcash community, but does
not propose a new feature. 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 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.
- 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.
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.
* 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.
* 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.
* 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 Editor(s) must
validate this change before it is approved.
* 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.
* 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 Standards, Consensus, or P2P Network ZIP is both
implemented and activated 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).
* 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.
@ -387,19 +399,20 @@ 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
Editor(s). One Editor will not suffice -- there needs to consensus among
the Editors. If it's a Standards Track ZIP, upon changing status to
Proposed the Editor(s) will add the optional \*Network Upgrade\* to the
header, 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 Editor(s).)
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 they miss
this deadline, the Editor(s) or Champion(s) may choose to either update
the intended \*Network Upgrade Version\* at their discretion.
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
@ -408,8 +421,8 @@ 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 Standards, Consensus, or P2P Network ZIP becomes Final when its
associated Network Upgrade is activated on Zcash's mainnet.
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
@ -426,6 +439,7 @@ 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
============
@ -433,115 +447,83 @@ 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
=============
Specification
-------------
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.
New ZIPs may be accepted with the following licenses. Each new ZIP 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::
For example, a preamble might include the following License header:
| ``   License: BSD-2-Clause``
| ``   GNU-All-Permissive``
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.
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. A optional License-Code header is placed after the License header.
Again, each license must be referenced by their respective abbreviation
given below.
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.
For example, a preamble specifying the optional License-Code header
might look like:
Statements of code licenses in ZIPs are only advisory; anyone intending
to use the code should look for license statements in the code itself.
| ``   License: BSD-2-Clause``
| ``   GNU-All-Permissive``
| ``   License-Code: GPL-2.0+``
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.
In this case, the code in the ZIP 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 ZIP.
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 and License-Code
headers.
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>`__
* 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
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>`__
* 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 unless a later ZIP
extends this one to add them. However, ZIPs predating the acceptance of
this ZIP were allowed under other terms, and should use these
abbreviation when no other license is granted:
- OPL: `Open Publication License, version
1.0 <http://opencontent.org/openpub/>`__
- PD: Released into the public domain
acceptable terms for a Zcash Improvement Proposal.
Rationale
---------
@ -549,34 +531,39 @@ 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.
- Many are unfamiliar with the OPL terms, and may just prefer to use
the public domain rather than license under uncertain terms.
- The OPL license terms allowed for the author to prevent publication
and derived works, which was widely considered inappropriate.
- Public domain is not universally recognised as a legitimate action,
thus it is inadvisable.
* 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 consensus layer, 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.
* 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.
Why is Public Domain no longer acceptable for new ZIPs?
- In some jurisdictions, public domain is not recognised as a
legitimate legal action, leaving the ZIP simply copyrighted with no
redistribution or modification allowed at all.
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/>`__
* `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/>`_