AGPLv3 is GPLv3-compatible. I don’t personally recommend the use of AGPL (any version), and I don’t think it solves any problem we have here.
For previous discussion about AGPL (which is used by BDB, a dependency of zcashd), see zcash/zcash issue 1469. At the risk of oversimplifying an involved discussion, the licensing of this dependency was considered acceptable only because Oracle published a license exception that allows permissively licensed software to be linked with BDB.
I thoroughly agree with this argument, and have raised essentially the same point internally at ECC. I’d like to state publically (speaking only for myself) that I believe this is a really important argument for using a well-established, permissive license. In particular it was used to argue for the relicensing of the halo2 repo as MIT, and I don’t personally see why it shouldn’t apply equally to the orchard repo.
To clarify, my position is “MIT, or (BOSL/GPLv3 plus a broader exception that allows both permissionless forks and any Zcash-related use)”. If the non-MIT route is taken then I would also prefer that any fork exception not make a distinction between chain and code forks.
Agreed; I should be clear that I think the exception for Zcash-related use (including at least permissionless friendly forks) is a critical part of BOSL/GPLv3 licensing. MIT is “simpler”, but I continue to think that copyleft licensing is important for public goods.
One other point I’ll make: I think that @daira and @ebfull and @str4d and @therealyingtong’s opinions on what license to use for Orchard are more important than mine, because they’re the ones who wrote the code. I’m an interested bystander and acting as a community member in this discussion.
Keep it as BOSL , time gate it for 3y , In 3 years we can review again our stance.
Authorship isn’t just about writing code, it’s also about review, discussion, and design. Anyway, you’re credited as an author, Kris.
BOSL seems best.
Maybe also post preliminary license terms to make it clear the goal is to promote ZEC, and protect ZEC. After all, we are taking about money. So ZEC value proposition should be protected at all costs; and there should be proprietary tech that is shielded from outside interests.
Give guidance on license terms
other factors
Build a licensing fees structure(s) where the positive loop reverts back to ZEC (increases it’s value) which then means more funding to ECC to build more and better tech more people can use and so on….
It has already been established that there is no proprietary tech in Zcash: there are no patent restrictions, and everyone is free to reimplement the protocol. It’s clear that reimplementation incurs significant cost and risk, but it is important that it is possible. The possibility of doing so is not what this licensing discussion is about.
In my opinion, and from the perspective of protecting the people putting their time and money on the line. It’s a mistake to not have a least some critical proprietary code/tech. so if BOSL helps to protect ZEC tech, it’s the best route.
I would really love for crypto teams to reach out & ask that they want the Orchard repo in MIT licensed that BOSL doesn’t work for reasons XYZ. I would have said yes to Monero but contingent on them respecting Zcash & their community acceptance of using Orchard (which they had no plan, as they are focused on Bullet Proof +).
You arnt working for free are you? Do unto others means we do something for you and you do something for us. It all breaks down when you do something for free; they take what you did and resell it for themselves. it’s all solved with a fair and reasonable licensing fee.
No problem giving away for free with delayed or deferred fees to help people get started. But once they start making money they need to be contractually obligated to pay.
I’d like to note, from a technical perspective, that’s not how a lot of that works 
But you are correct that Monero is not interested in Orchard. While Halo 2, already MIT licensed, has some level of academic value to Monero, they are focusing on circuits over Bulletproofs++.
Bitcoin was given for free to the people. FOSS is for freedom, as is privacy, and I don’t see why the Zcash software should be anything but free. It’s hard to call BOSL free when it’s effectively the GPL when discussing FOSS, except it’s not actually dual licensed which prevents integration and restarts every legal discussion on the matter costing hundreds to thousands of dollars to even consider its status, which will likely simply result in it being ignored and unused. It’s an unnecessary hurdle thrown in to route people to the non-free path, and that’s just duplicitous.
May be it’s okay to take a different path & see how it works. One thing that is certain is change. Let’s get the real data & assess.
Doesn’t any developer who downloads Zcash and make any edit immediately subject their local copy and edits to BOSL? If for some reason it’s legally argued Apache 2.0 code, as currently in the codebase, cannot be successfully used with BOSL, every single developer who touches Zcash would be open to liability.
Also, as a developer who has a local copy and edits, whose work is no longer covered by the exception, if I ever publish my work, say, in a PR to Zcash… I first have to upload it to a repo establishing it’s BOSL at some point in the future no later than 12 months from the day of publication? I guess the PR itself is kinda submitting it to a repo? Except the work and license grant needs to be published “prior” and this is simultaneously?
And for the license, with each PR I make, I just need to attach “an irrevocable offer to license said copies to the public free of charge under this License,”? Isn’t it considered such offers must be an explicit statement by the party, as you can’t implicitly consider GPL-derivatives GPL? It’s how GPL violations occur in the first place? While I don’t assume the ECC would ever prosecute people behind these PRs, will the Zcash repo PR template be edited to automatically include this statement to ease the development process and ensure there’s no potential outstanding liability? If a submitter does not include it initially, yet corrects their PR to include one, will the ECC publish a statement renouncing any claim of liability despite the contributor having already broken the BOSL license in a publicly verifiable way (albeit, one without damages if corrected soon after, making it a waste of time for everyone if the ECC wanted to action on it)?
This is the plethora of legal questions which now threaten development, even to Zcash itself, making people and organizations unwilling to work with it, and not only will I no longer be interested in contributing to the Zcash ecosystem if BOSL hits mainnet, but I feel like it might even be legally inadvisable for any developer to contribute to any Zcash daemon at that point.
Zooko did say “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,”, which will likely mimic BSV’s own license, and that would void such issues for ZEC itself (but what about the regtest environment which is a brand new chain? what if it’s desirable to restart testnet?) along with friendly forks, yet this blanket exception isn’t in front of us and Zcashd had the BOSL license applied 5 days ago, making it already in this legal nightmare.
Beyond my existing question about what the community process Zooko claims exists (by saying we, the community, can change it) is, I would also like to ask does the ECC have any actionable plans to sell this technology for the benefit of Zcash, or does it know of any party planning to use Orchard, who wouldn’t be willing to simply BOSL their work (which we can’t even merge back because we’re not BOSL), the ECC considers notable enough to warrant this “experiment” applied to the entire protocol?
EDIT: This entire time I thought librustzcash was MIT by exception and that’d be enough for wallets and integrators. You cannot create Orchard shielded transactions through librustzcash AFAICT. You have to directly use the BOSL licensed orchard crate. That means every single wallet, exchange integration, L2… using Orchard will either be reliant on an ECC corporate exception or need to move to BOSL (which may not be possible for existing projects) even if they’re fine with the crates as-is used on the Zcash network. This will directly force most of the shielded ecosystem into this licensing hell which is not just limited to Zcashd itself and people forking it for their own protocols. That was my misunderstanding and this just makes it all the more problematic.
I respect the opinions of everyone in the Zcash community, because they are all Zcash lovers.
Check out the voting results.
This is the answer from the Zcash community.
@AidenZ Was there some kind of campaign or call to action to get South Korean Zcash users to register and vote in this forum poll?
Between 19 hours ago and 8 hours ago, a few dozen new forum accounts have been registered, most of them from South Korean IP addresses.
Examples include @yoloi_jh, @yang_p1, @Alslll137, @Juwon, @parkkiho, @Banmandoga, @Inja, @Kwon, @moon, @mvnbebe, @donghyun, @497856, @moya, @Jeonglee, and @Bbojju.
@GiantZEC, @CryptoZEC, @Bitcoincash, @Kingzecs, and @EthKingzec all registered 19 hours ago, and logged in from the same IP address.
@zecdaya and @zeccodes both registered 11-12 hours ago, from the same IP address.
@sammks and @sammks2 registered 9 hours ago, from the same IP address.
ETA: It looks like the Korean Zcash community may have been motivated to join the forum and vote in the poll by a Twitter conversation.
I guess a silver lining of the cloud that’s hanging over our community at the moment is that more people are being motivated to join and make their voice heard! 
Coming to think of it… I don’t think it’s possible to create an interoperable reimplementation of Orchard without violating its copyright. While the ideas of Orchard are well-documented, the specific expression as a constraint system is protected by the BOSL copyright. And that expression is necessary for creating a new compatible implementation, whether of the tx generation or of tx verification.
Sure, given the docs and specs, it’s possible to create a clean-room reimplementation of the high-level protocol. With enough effort, it will have similar performance. But it won’t be wire-compatible with Orchard, because of course some of the (numerous) implementation choices in the constraint system will happen to be different.
… unless the engineer doing the reimplementation looks at the Orchard constraint-system code, and basically copies all its structure, choices and idiosyncracies. Which would take them deep into derivative-work copyright-violation land.
(They could argue that it’s fair use because they had to do that for interoperability. Well good luck. The recent Google vs. Oracle lawsuit, which entailed a similar question, took 12 years, untold millions of USD of legal expenses, and the US Supreme Court, to decide.)
Therefore: it is effectively impermissible, no matter the implementation cost, to verify or generate Orchard transaction using your own code — unless you get permission from ECC or BOSL-license your whole codebase.
Curiously, this is a problem only for people who want to interoperate with Zcash. Someone who launches their own chain or whatever, and doesn’t care about Zcash tx compatibility, can reimplement Orchard from its docs and specs — no copyright problem there.
I was concerned about this. I was personally thinking about projects like Dolphin, where very specific hardware and software was recreated… yet only based on blinded sum product testing which isn’t feasible with Orchard (as I’m pretty sure it tries to make all its values look random. Something about being a privacy protocol?) and so on. Won’t another Orchard implementation fail if the order of a single constraint is swapped? Meaning it has to line for line implement every check the same way?
And if you’re line for line implementing things, and you can’t change the underlying math underneath… maybe you can change function boundaries? ECC Orchard used one 100 line function and we did 2 50 line functions! They use a 4 space indent and I preferred 2! But the fact the Orchard spec doesn’t have the needed information means unless someone wants to argue they can legally gdb Orchard to the point needed, there is no clean room implementation possible, which is all the ECC needs to argue a case which is all that’s needed to prevent any developer from spending the year attempting this.
Edit for clarity: The privacy protocol bit was a joke meant to emphasize the differences between a clean room implementation of a video game console, itself a complex effort taking years while being a legal minefield, which has an opcode for add which very clearly loads two registers and produces a sum, and an opcode for if which will change the active code instruction based on some flag… to SNARKS where every variable is a Pedersen commitment to itself and the blinding factor, hiding the variable and how it flows, and logic is… SNARKS. SNARK magic.
As another question… what happens if the ECC ever went bankrupt? Would it be possible for its assets, including the Orchard copyright, to be held by another organization who may not support Zcash? Is the community willing to commit to a potential future where Zcash is either:
A) Unverifiable because we can no longer verify historical Orchard segments, burning all funds in that pool at time of move
B) BOSL for the entire project, severely breaking exchange integrations, severely depreciating the price and value being clamored for with BOSL
C) Unable to update its software because only the ECC is legally allowed to publish updates for Orchard while maintaining exception status as we’re stuck to it like flies?
BOSL and MIT were also discussed within the South Korean Zcash community.
So, we encouraged voting to express our opinions, but it seems that some people voted tiwce or more by creating different IDs.
I told people who voted more than once to cancel their votes.
There are currently two different Korean communities in which there are 174 and 221 in each group.
They are strong Zcash holders. Please remember!
