Clarify and widen license exceptions #334
Conversation
The intent is to make clear that it is possible to extend the functionality of Zcash implementations (not necessarily only published by the ECC or ZF), and to experiment on testnets, while still relying on the BOSL exception. The leeway given to forks is increased to 3456 blocks (roughly 3 days) to make reasonable allowance for release processes.
|
I'll collect all of these suggestions and comments and also see if we get other feedback from partners or the community and then get them reviewed. Thanks for all the feedback! |
Codecov Report
@@ Coverage Diff @@
## main #334 +/- ##
==========================================
+ Coverage 89.51% 91.11% +1.60%
==========================================
Files 36 36
Lines 3824 4527 +703
==========================================
+ Hits 3423 4125 +702
- Misses 401 402 +1
Continue to review full report at Codecov.
|
| - A project that implements Zcash; | ||
| - A project that implements a Zcash Chain Fork; | ||
| - A project that implements a Zcash Technology Testnet; | ||
| - A project that is designed to integrate with Zcash (whether or not it can |
There was a problem hiding this comment.
How to define integrate with Zcash?
Can a Zcash forked chain application add a ZEC donation deposit and transaction explorer option while having only advanced features for the forked chain version? And still qualify, as the application that "provides additional functionality or utility to the Zcash network and holders of ZEC" by allowing a deposit address and other "limited" features for ZEC in the same application.
There was a problem hiding this comment.
My intent was that if you add features for a chain fork then you should make a reasonable effort to provide them for the Zcash chain. That is the whole point of saying "integrate with Zcash" as opposed to "integrate with Zcash or a Zcash Chain Fork". Sometimes this might not be possible, if the features rely on particular consensus or peer-to-peer protocol differences. I'm not sure that the intent can be fully captured in legal wording; at some point you have to assume good faith.
There was a problem hiding this comment.
Note that this is only a clarification; it does not change what is allowed. The substantive changes to what is allowed are:
- the change on line 28 to allow use on testnets;
- the change to give Zcash Chain Forks the 3456 block leeway;
- not limiting "a project that implements Zcash" to the Zcash projects by ECC and the Zebra project by ZF, instead defining "Zcash" based on the Zcash Trademark Agreement. This potentially allows other consensus-compatible implementations, including code forks of Zcashd and Zebra that follow the Zcash block chain.
The last of these is important because without it, it is not clear that a party other than ECC or ZF can code-fork Zcashd or Zebra at all unless they reimplement orchard.
… addition of "or was"). Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Kris Nuttycombe <[email protected]>
| - A "Zcash Chain Fork" means a blockchain that descends from the Zcash | ||
| blockchain and that activates its first change to the consensus rules | ||
| relative to Zcash at a block height that is or was within 3456 blocks | ||
| of the current height of the Zcash chain at the time of activation. |
There was a problem hiding this comment.
The idea of the change to allow a 3456-block leeway, is that the fork's implementation might need to hard-code information (e.g. a checkpoint or a snapshot of some of the chain state) that depends on the Zcash chain, and then have nodes running that code when the fork happens. This change allows 3 days between those two points, which is enough time to prepare the code, do a release, and have a reasonable number of nodes running that release at the fork height.
Not all forks will need this; it depends how much they are changing. But it could plausibly be needed.
|
Closing in favour of #405. |
The intent is to make clear that it is possible to extend the functionality of Zcash implementations (not necessarily only published by the ECC or ZF), and to experiment on testnets, while still relying on the BOSL exception. The leeway given to chain forks is increased to 3456 blocks (roughly 3 days) to make reasonable allowance for release processes.
closes #332