(Speaking for myself, not ECC.)
Is this thread about governance and ZF priorities, or it is about the license? Because it is absolutely not the case that thinking it would be preferable to release the orchard crate under MIT implies lack of support for ZEC holders.
For the record, I think it would be preferable to release the orchard crate 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 orchard crate, or stripping Orchard out of the protocol. Note that the other possibility of asking ECC for a license exception is not permissionless.
(It is unclear to me, legally, whether another option would be to relicense all of the zcashd or zebra code as BOSL. The MIT license allows relicensing, but some of the dependencies are Apache 2.0-only; see the contrib/debian/copyright file for details. Is it possible to link Apache 2.0 code with BOSL code without permission from the Apache code’s copyright holders? I don’t know. Note that the scope of the license exception is significantly narrower than I was originally led to believe it would be, otherwise I would have kicked up a bigger fuss about this at an earlier stage. The only other project using a TGPPL-derived license, Tahoe-LAFS, had a bunch of license exceptions allowing linking with any code using a wide range of open-source licenses, but zcashd doesn’t have that. Note that dual-licensing the orchard crate as BOSL/GPLv3, as suggested by @nuttycom and as I’ve previously indicated support for, would resolve this question since there is a well-established social consensus that each of the licenses used by dependencies of zcashd is compatible with GPLv3. I would still prefer MIT though.)
Rewriting the orchard crate is feasible (zebra has reimplemented some of the necessary non-circuit code), but would be a substantial, probably months-long, effort. Which precludes this option in precisely the circumstances (e.g. ECC attempting to push through a protocol change that a substantial portion of the community disagrees with) that it would be most necessary.
In any case, the relative merits of permissive vs non-permissive open-source licensing is a decades-old argument that we’re not going to be able to resolve here. And no, TGPPL or BOSL do not resolve it.
It is, incidentally, my birthday, and I’m supposed to be on holiday, so I probably won’t be engaging much more with this thread.
[*] I also think that it is usually an incredibly bad idea to fork a block chain, especially a privacy-oriented one, and anyone should be thinking really hard about downsides such as anonymity set; security against rollbacks; technical issues such as nullifier exposure across chains; and –most importantly– splitting the community. As you might expect from an anarchist, I don’t think that it being a bad idea in most circumstances means that you shouldn’t be able to do it.