BOSL or MIT - Orchard

Thoughts on BOSL exceptions for all projects building on top of Zcash? I’m thinking of wallets, zecpages, free2z etc.

I agree it’s also very important that BOSL not prevent friendly forks.


(Speaking for myself.)

I don’t see why chain forks should be treated differently to code forks, to be honest. I don’t think that the example of ZClassic is pertinent — there are other code forks (such as Pirate Chain, for example) whose devs have as far as I can tell always behaved ethically, and I’m glad that those chains exist.

As @GGuy points out below, projects that are technically chain forks can be effectively code forks, so I don’t think that this distinction is legally enforceable anyway.

“Any project related to Zcash” is indeed more like the exception that I thought we’d get; the narrowness of the current exceptions surprised me. (Note, however, that it still falls foul of sections 6 and/or 8 of the Open Source Definition, and it doesn’t solve all of the license compatibility issues. Combining a broader exception with dual BOSL/GPLv3 licensing would help.) I respectfully disagree with Zooko’s opinion that this “isn’t currently a big deal”; in fact it seems to be central to the arguments of some critics of the use of BOSL.

I wish that the BOSL licensing had gone through an engineering review process by Core team, and I think that if it had then most of the problems that have been raised would have been avoided.


What can zclassic and piratechain do that Zcash can’t do and what did the devs do that deserves this “ethic medal” in your opinion ?

Would a blanket exception for chain forks have constraints? Say Ycash receives an Orchard license, and then afterwards makes a not so friendly change. Could the license be revoked?

This is the reason why i can’t imagine how this blanket exception could be meaningfully put into the license.

So many unanswered questions:

  • Should BOSL allow ECC to revoke an exception at anytime? Of course not. That undermines the value of the fork if at anytime it could be killed off.
  • Should BOSL allow for forks to change the issuance rate and/or max issuance? I guess it can’t because diluting pool with 1billion new coins essentially achieve the same thing as a code fork right?
  • Should BOSL allow for ZSAs (when released) in the friendly fork? I guess we can’t because the friendly fork could just devalue the existing ZEC and use a ZSA instead.
  • Should BOSL …

My personal belief on the forking problem is it’s too hard to legally enforce (chain) forks to behave by a certain set of rules set by ECC or the community. But I believe you can incentivise chain forks to behave by a certain set of rules by allowing what I call it fork and merge. Where the forked coins can optionally be batched up and merged (think rollups) back into Zcash (possibly periodically) as a ZSA.

When the next zkDOGE meme coin is launched I seriously hope it’s launched on a chain fork of Zcash :rocket:.

1 Like

These questions appear to be responding to things I didn’t say.

Aristarchus, I don’t understand your question. The two things you mention here are what I intended by these two parts in my post:

First, on the topic of BOSL exceptions for all projects (wallets, exchanges, zecpages, etc.) supporting Zcash — by which I mean Zcash-the-coin (ZEC), not just the Zcash-the-technology or the Zcash-the-network, unless their work thereby also supports Zcash-the-coin:

Second, on the topic of friendly forks:

Does that answer your questions?

1 Like

No, the blanket license exception that I am trying to craft to allow Future Friendly Forks to use Orchard without BOSL’ing their codebase would be irrevocable, so that people who use and develop on Future Friendly Forks would have all the legal rights they would need from that point forward.


Great, thanks :+1:

Yes that makes sense. I saw that the ZWallet developer had posted on the community telegram that BOSLing his code would be a blocker for him. So it seems ECC issuing a blanket exception would be a good solution.

With regard to friendly forks, I think the exact language of the exception matters a lot. Would we want to allow a chain fork that includes all ZEC holders, but then allocates a billion coins to the forkers 5 blocks, or 5 million blocks, after the chain split? It seems the exception needs to also say something about the future monetary policy, or else there is no economic difference between chain forks and code forks. This seems like a tricky problem, but maybe a good lawyer can draft something that works.


Emphasizing This!


There’s a certain point where I think one has to rely upon markets to do their job. This is why copyleft licenses are good to begin with - they inhibit the enclosure of public goods, and by doing so level the playing field so that participants in a market have to compete on quality of service to the end-user.

1 Like

I think this is probably the best case for @daira’s excellent idea to just dual license under GPL and BOSL. It gives all the claimed upsides of BOSL (including the same reason for paying licensing fees to ECC) , but for forks or people who are worried about non standard licenses, they can use the GPL version instead.

(To be clear, I still think MIT is a better idea. But baring that, Dual Licensing under GPL and BOSL is strictly better than BOSL)


I’m not convinced it does. BOSL requires public disclosure of source irrespective if you have a copy of the binaries or not.

Ah, I can’t recall the exact differences between GPLv3, v2, and AGPL. If modifications without binary distribution really are a concern of ours( IMHO, anyone who’s going to do that just isn’t going to ever admit they used the code), then dual license under BOSL and either AGPL or GPLv3 (one of them covers that).

1 Like

No. BOSL requires the source to be made public (e.g. on GitHub) even if the binary was distributed privately. It’s true that AGPL would require a public facing API to distribute the code publicly. But for non public facing APIs only those with access are required to be granted access to the source. (That’s my understanding at any rate).

We could probably debate if this extra requirement makes a significant difference to outcomes but in defence of BOSL it’s a really powerful distinction I think is something someone should explore. Not 100% convinced we should be the ones exploring it though :joy:.

1 Like

We want to attract more developers to build applications for Zcash, including many developers who strongly advocate building FOSS.

I am in favor of dual licencing under GPL and BOSL, but this must also include as zooko mentioned upthread 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 also want to enourage existing independant developers in the ecosystem who have similar principles.

I know @hanh, developer of ZWallet, has indicated that the BOSL licence is a showstopper for him, I would like to know if the above approach would work for him as I believe that will be an important data point.

My preference is to licence as MIT, it’s simpler and will more effectively further the goal of expanding/nurturing the developer ecosystem.


@zooko can we add a line to the Orchard readme advertising that ECC is open to granting exceptions in cases that benefit Zcash?

@zooko With regards to Zcash ecosystem exceptions would it be as simple as stating the exception will be granted to applications that connects, and only connects, to the official Zcash (or Ycash) chain (e.g. mainnet, testnet, etc)? IMO we’d have to make sure friendly forks are included in those exceptions somehow.

1 Like

Right, yet anyone who receives such a copy is entitled to the source and allowed to further distribute it. It’s not a notable restriction IMO, especially when AGPL will prevent frontend wrapping. The problem with AGPL is I’d have to double check its GPL compatibility, as AGPL has a much smaller market share.

Also, it needs to be public, not publicized. I can technically say I have some random FTP server for it which is publicly accessible and call it a day.