It’s complicated. I am not a lawyer and what follows is not legal advice; also I am not speaking for ECC.
The requirement to provide source code licensed under BOSL (and therefore freely usable after 12 months) imposed by clause 1.c of the BOSL license only applies to “distribution or communication” of the derived work. Copyright licenses in general cannot place any restrictions on modification for private use. [Edit: @tromer disputed this and I am no longer sure about it. Note that if this is not true then we have an additional problem, because clause 1.c only grants a (conditional) right of distribution “to the public”, i.e. it assumes that granting a right of distribution other than “to the public” is unnecessary.]
But we can adjust your question to be about the case where zcashd is modified and then redistributed. I believe this analysis also applies to the case where Zebra (or some work based on both zcashd and Zebra) is modified and then redistributed.
Clause 1.c is the only “viral” part of the BOSL license — using “viral” as a technical term in which a copyright license imposes some requirement for its own application (fully or partly) to a derived work. Specifically, it requires you to make an irrevocable offer to license copies of the original and derived source code “to the public free of charge” under BOSL 12 months after the first distribution of the derived work.
This clause does not preclude you from also “distributing or communicating” copies of the derived source code under some other license than BOSL. That is, my interpretation is that you could distribute your derived work of zcashd under a dual MIT/BOSL (or triple MIT/Apache2.0/BOSL) license. This is because clause 1.c only restricts the sublicensing of “said copies”, that is, the source code of the original and derived works that you are obligated to make available under that section. These are not the same as the copies of the derived work that you are originally “distributing or communicating to the public”, which may be under any license compatible with zcashd’s current licensing (per component, i.e. the parts that are currently under MIT may be distributed as MIT, etc.).
That still leaves a critical problem: you can distribute your derived work under any compatible license for each component, but (if you did not relicense the derived work of zcashd/Zebra as BOSL) the only right you have to use the orchard crate that is linked with zcashd/Zebra is via the orchard license exception.
However, once a copy of the zcashd or Zebra source is edited, it ceases to be one of “The Zcash projects published by the Electric Coin Company” or “The Zebra project published by the Zcash Foundation” as described in that exception. And so you cannot use it, without relicensing as BOSL.
This appears to be a bug and not the intended effect. I will repeat here my dismay at the fact that the text of BOSL never went through a technical review by ECC engineers. (I did ask for such a review. I don’t remember the exact response from ECC management, but I was effectively told to leave it to the lawyers. I was skeptical — but at the end of the day, license review is not in our job descriptions, even though I am competent to do it and it would clearly have helped in this situation.)
Note that if the orchard crate were under other copyleft licensing, including GPLv3 or dual BOSL/GPLv3, then a similar argument (different in the detail, but with a similar conclusion) would apply. That is, a widening of the exceptions would solve it in the cases covered by that widening, but dual-licensing orchard as BOSL/GPLv3 by itself would not.
I note, however, that Zooko has already committed ECC (by my reading; still not speaking for either ECC or Zooko) to widening the orchard crate license exceptions to other projects that “support Zcash” and to any Zcash chain fork:
So this may be a somewhat temporary problem, modulo potential arguments about the scope of the widening, although it underlines the necessity of making those changes.
Widening the exceptions plus relicensing the orchard crate as BOSL/GPLv3 still prevents non-BOSL, non-GPLv3 projects using that crate from being open source, because they would not satisfy clauses 6 and/or 8 of the Open Source Definition (they can be open source if they relicense either as fully BOSL, assuming that is compatible with Apache 2.0, or as fully GPLv3):
- No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
- License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
“Field of endeavour” would clearly include the requirements that a project “support Zcash (ZEC)” or be a chain fork of Zcash.
I believe clauses 6 and 8 of the OSD are important, and that is partly why my preference is for the orchard crate to be licensed simply as MIT/Apache 2.0.