On the Bootstrap Open Source Licence for Zcash Orchard, and a brief backstory of scams

[I copied this text to here from https://forum.zcashcommunity.com/t/bosl-or-mit-orchard/41439/124, since the moderators of that forum — which is owned by the Zcash Foundation—told me that they are removing a related thread: 1, 2. The quoted parts below are quotes from this post by Jack “Dodger” Gavigan, Executive Director and Board Member of the Zcash Foundation.]

* Has ECC carried out an assessment of the full implications of using the BOSL license for Orchard, instead of the preferred MIT license? If so, will you make that assessment public?
* In ECC’s estimation, what are the expected and potential negative implications of retaining the BOSL license for Orchard?
* Will wallet developers who want to support Orchard addresses and transactions be required to either (a) open source and relicense their entire codebase under BOSL, or (b) get permission from ECC to continue using their existing license(s)? Or is there an alternative approach? Has ECC appraised the developers of wallets like Edge, Unstoppable, ZecWallet and Zwallet of the impact of the BOSL license, and will those wallets support Orchard transactions and addresses following NU5?
* Same question for exchanges and custodians who want to support Orchard transactions and addresses by using the Orchard library within their own software tooling (as Gemini does with their Sapling withdrawals). Has ECC appraised Gemini of the impact of the BOSL license, and will Gemini be adding support for Orchard withdrawals after NU5?
* Same question for other products and services that may want to integrate the Orchard library in order to support shielded transactions (e.g. Blockchair’s support for Sapling viewing keys in their blockchain explorer).
I don’t think we have a formal “Assessment” document, but I’ll check.

In general, yes, we’ve been studying the pros and cons of this strategy, debating it and gaining alignment around it within ECC, and communicating about it to the Zcash community, for years. The most substantial data points we’ve gotten so far have been through our relationships with the current Zcash partners — the wallets, exchanges, custodians, services, etc. that you mention above — and with potential future Zcash partners — the numerous businesses in crypto and outside of crypto that are potentially interested in supporting Zcash.

None of the current Zcash-supporting orgs have yet expressed any concerns over licensing. However, we’ll circle back with them and make sure their aware and make sure there are no legal hindrances to their ongoing support of Zcash. This conversation makes me think it would be good for ECC to issue a blanket exception for everyone to be able to use our Orchard code to support Zcash (ZEC) without having to BOSL their other code. We’ll work on that, because I think it would help. However, in general the data points we have so far indicate that this concern isn’t currently a big deal.

* What does the requirement to adopt the BOSL license mean for projects that incorporate permissively-licensed (e.g. MIT and/or Apache) code created by third parties? For example, if someone wants to fork Zcash post-NU5 by creating a code fork of zcash/zcash, will they need to get agreement from all the Zcash and Bitcoin developers (including Satoshi Nakamoto) to relicense the entire codebase under BOSL? If so (and given the unlikelihood of successfully collecting the necessary agreements), does this effectively mean that the Zcash cryptocurrency can longer be forked without ECC’s permission? Are existing Zcash forks (e.g. Ycash) required to obtain permission from ECC before adding support for Orchard?

Satoshi, and everyone else who has ever published MIT-licensed code, have already given us (and everyone in the world) permission to use their MIT-licensed code in our derived work and share our derived work under other licenses, whether proprietary non-open-source licenses, the GNU General Public Licence, the BOSL, or others. So this part isn’t an issue.

But your question raises something else that I think is potentially a big issue.

That is, if zcashd (the only current mainnet-capable software implementation of Zcash) has BOSLed code in it, then someone who wants to make a _chain-fork_ of Zcash would not have the legal right to do so unless (a) their codebase is Zebra as published by the Zcash Foundation (since Zebra-as-published-by-the-Zcash-Foundation already has an exception), or (b) getting a license exception from ECC, or © BOSL’ing their entire derived work (i.e. their code base).

Now in principle, chain-forkers (other than the Zcash Foundation, which already has an exception) could solve this by BOSL’ing their entire codebase, unless their codebase also included other code that couldn’t be BOSLed for some reason, such as non-open-source code.

However, ease of chain-forking is super important because it is the basis of all blockchain governance. It is what makes Zcash a consensual currency, and it is what allows groups of people with different ideas about how to improve Zcash try their own thing. So I think it is really important to remove hurdles to chain-forkers.

(This is why, by the way, the first substantial upgrades that we made to Zcash were to add protections for users during chain-forks. We added those in the first Network Upgrade, which was called “Overwinter”. During the ETC/ETH and BTC/BCH forks, lack of these protocol-level protections resulted in some users losing funds, and we wanted to make sure that future friendly forkers (chain-forkers) wouldn’t have to contend with such problems and that the users of both new chains would be protected. These protections worked great during the “ZEC/YEC” fork.)

Thanks for touching on this issue in the above, Dodger, and thanks to Sean Bowe for contacting me over this weekend to draw my attention to this issue.

I’m going to ask our lawyers how to write a blanket exception so that anyone (not just the Zcash Foundation, who already have this legal right) who wants to make a chain-fork of Zcash can do so.

Now there’s an important nuance here, which is that we don’t want to allow source-code-forkers to be able to use Orchard for free, only chain-forkers!

Let me explain the difference for people who aren’t familiar with the terminology.

A chain-fork — also known as a Future Friendly Fork — is when two different groups want to try different, mutually incompatible consensus rules going forward, _starting from the same current contents of the blockchain_. Examples of this pattern include then BTC/BCH, ETC/ETH, STEEM/HIVE, and ZEC/YEC chain-forks. In each case, there is a block which is the last block before the fork, and that is the most recent common ancestor block of both of the new blockchains. The important consequence of that is that the owners of coins in the common ancestor block automatically become the owners of the same number of coins — and the same proportion of the total monetary base — on _both_ of the new blockchains. This means the chain-forkers are rewarding the current owners (as of the common ancestor block) with ownership of the new coins, and any improvements they make over time that make the new coins more valuable will benefit the original coin holders.

On the other hand, a source-code-fork is where someone just copies the source code and launches a new blockchain in which someone else (usually them) is the owner of the new coins, without giving any coins to the original coin-holders. An example of that pattern is ZClassic (ZCL) [footnote 1].

In my current opinion, if someone wants to launch a new coin, which starts life with no reward to the ZEC holders, like ZClassic did, then they should either a. BOSL all their source code, b. ask for an exception from ECC — where we can ask them to contribute something valuable back to the ZEC holders in order to get that exception, or c. just not use Orchard in their alternative coin. Orchard can remain special for the ZEC holders.

So, I’m going to ask our lawyers how to craft a blanket exception which gives all users the necessary legal permissions to create their own Future Friendly Fork of the Zcash blockchain, meaning that all current ZEC holders before the fork become holders of the new coin, in the same proportions, and the same proportion of the total monetary base, as before, but not to give blanket permission for source-code-forkers who just want to clone the tech to launch their own blockchain without BOSL’ing their own codebase.

* What criteria has ECC set for evaluating requests for a license exception?

The most important criteria is whether their intended use benefits the ZEC holders. A good example of this is the Ethereum-and-Filecoin partnership, in which — in addition to helping us improve the Halo technology and integrating the Halo into other cool world-improving projects — the Filecoin orgs also agreed to (when all is said and done) give $9m worth of grants to people who implement projects that add utility and value to ZEC.

Other factors we would probably consider include whether their intended use is creating value for the world, and whether we think they are potentially good long-term partners that we want to build a collaborative relationship with.

* Finally, why did Filecoin insist that Halo2 be licensed under MIT/Apache instead of BOSL?

~~Hm, I don’t want to speak for them, but I’ve just now reached out to each of them to ask if they want to answer this for themselves, or if they want me to answer that question for them, or what.~~

[Update: Marta Belcher who is President and Chair of the Filecoin Foundation, and General Counsel of Protocol Labs, and Special Counsel for Electronic Frontier Foundation, got back to me right away on a Sunday — bless her — and said that I could explain that, although they love the idea of the BOSL, they have a policy of strongly preferring MIT in order to facilitate the work of their downstream, downstream partners in the broader Filecoin ecosystem. She also said that they will have news soon about the $9m Filecoin-Zcash grant programme, and to stay tuned! :-) ]

This is a really useful data point though for the difference between Halo — the world’s best zero-knowledge proof system — and Orchard — the world’s best private money protocol.

Halo is useful for all kinds of things! The power and flexibility of zero-knowledge-proof-systems are just barely being discovered, and the additional power and flexibility of Halo, thanks to it being the first ever ZKP that is both Ceremony-free and capable of recursion, is even better. The Filecoin orgs are using Halo to scale the Filecoin distributed storage service, and the Ethereum Foundation is using Halo (or part of it) to implement a “zkEVM”, which promises to help scale Ethereum and might also turn out to form the basis of cross-chain-interop between Ethereum and Zcash, and might also form the basis of general-purpose programmability on top of Zcash. There are probably a lot of other applications of Halo that people have not even conceived of yet.

So it really makes a huge difference for the Filecoin ecosystem, the Ethereum ecosystem, and probably lots of other people around the world if they have permissive (MIT) access to Halo instead of BOSL-protected access to it.

Now, Orchard is very different! You can’t use Orchard to scale Filecoin or Ethereum, or implement generic cross-chain-interop, or create general-purpose ZK virtual machines. The only thing you can do with it is implement shielded money. That means that all of the applications of Orchard that I can currently think of are either competitive or complementary to Zcash. So from my perspective (and thanks especially to Steven Smith from ECC and David “DC” Campbell for convincing me of this a while back), there’s a lot more value-generation for the rest of the world to having permissive access to Halo, and a lot more potential for both downsides (parasitic competition) and upsides (win/win partnerships) in Orchard.

I hope this answered all your questions, Dodger. Please let me know if you have more questions or concerns.

[footnote 1]

Funny story, which seems to be oddly relevant to current events in Zcashland today. When ZClassic was announced by Rhett Creighton it was originally called “Zcash Classic”. A lot of folks in the Zcash community at the time had a negative reaction to its announcement, perceiving it as a threat, but I thought it would not be a threat, and told my team at ECC that we should actually give Rhett Creighton and the other ZClassic folks a normal level of tech support and encouragement, like we would any well-intentioned open source project.

Then it turned out that the ZClassic folks didn’t seem to know what they were doing, technically, so I modified that by saying that we shouldn’t give them too much tech support, like we shouldn’t do things for them that they wouldn’t have the skills to support going forward, since that would endanger their users — ZCL coin holders.

I did notify the “Zcash Classic” folks that thanks to the Zcash trademark, they could not call their coin “Zcash Classic”, but that if they named it “ZClassic”, then the trademark would not give us the right to stop them, so they did that. Ever since then, I’ve been really glad that the trademark existed and worked for that!

A couple of years later Riccardo “fluffypony” Spagni posted some chat logs to some exclusive crypto Telegram groups that I was in. The chat logs were from an IRC channel named “#altcoin-dev”, and they were conversations between Rhett Creighton and Riccardo Spagni about launching “Zcash Classic”. Spagni said in the Telegram channels that the reason he was posting the logs was to show that Creighton didn’t have tech skills and that Spagni had to show him how to do all kinds of basic things, like invoke gcc on the command-line.

However, what I saw in those logs was something else: a repeated pattern of Spagni saying, in effect, “But how can we do this differently in order to do more damage to Zcash!?”, and they would talk about that for awhile. Never once, as far as I remember, did either of them mention protecting the ZCL users or providing value to the ZCL users.

Others apparently saw the same things in the chat logs that I did, because a couple of influential, respected crypto folks who were in those telegram groups said to Spagni, “Dude, that’s not cool, what those logs show you doing.”. He took the logs down.

By the way, there’s a longer story here about the subsequent “Bitcoin Private” pump-and-dump scam and counterfeiting-theft, and “Bitcoin Diamond”, which was a joint project between Rhett Creighton and Gary Le, the serial scammer behind Vert (which Spagni was also involved in), ZeroVert, Moneta, and Zcoin (which was later renamed to Firo), as well as Bitcoin Diamond. I really hope somebody does the research and tells these stories someday, but I’m not the right person for that job.