It somehow hasn’t dawned on me, until now, that BOSL-licensing Orchard would have a completely unacceptable consequence: it would become infeasible to fork Zcash as governance fallback or a “friendly fork”.
As @daira explained today (see further analysis there):
I think it would be preferable to release the
orchardcrate under MIT. Part of the reason I think that is that I agree with the position (which Zooko has also relied on in previous governance discussions) that it should be possible to do a fully permissionless fork of the Zcash mainnet block chain based on zcashd and/or zebra code. [*]That has always been possible up to NU5. After NU5, it very likely will not be possible without either rewriting the
orchardcrate, or stripping Orchard out of the protocol. Note that the other possibility of asking ECC for a license exception is not permissionless.
To recall, the ability of anyone to fork the Zcash chain (whether code or code+state) has been a key point in governance discussions:
- as a cornerstone of decentralization in a consensual currency that is contintuously reaffirmed by those who have chosen to not fork it
- as a fallback in case governance mechanisms do not reach adequate consensus
- as an escape hatch in case of capture or misconduct by power-wielding entities
- as a legitimate way for “friendly forks” to emerge
Are we just throwing all of that away, without even an explicit discussion of these consequences and whether they are acceptable?
(Like @daira, I think that stateful chain-forks are a costly and undesirable “nuclear option”, but the possibility of forking is still important and impactful.)