THIS THIS THIS
I see it is as dual licensed as MIT / Apache here:
“under BOSL” is the issue. We still don’t have any confirmation MIT is successfully sub-licenseable from the ECC. Therefore, my shielded atomic swap implementation (which I want to use as an example) can’t legally exist if it requires tweaked versions (as it currently does against the current librustzcash) as I’m not the sole copyright holder and can’t re-license it.
Any GPL projects would also be unable to integrate BOSL work as they definitely aren’t compatible. That’s why there’s also calls for BOSL/GPL dual licensing (as the BOSL is effectively the GPL with a grace period). It’s extremely concerning to wonder why it’s not already dual licensed as it could be described as an artificial integration burden designed solely to limit users while claiming to be a champion of FOSS.
Between the inability for my own contributions to exist under the license change, between being told I can integrate ZEC into my new work yet solely via an exception granted to the ECC which break’s FOSS according to the OSI (though BOSL would probably count as a FOSS license, it’d just force me to not use MIT or even GPL for my work yet a license incompatible with everything else on the planet), and between Zcash not being FOSS (except under BOSL which we still have 0 confirmation anyone can legally sublicense the existing Zcash codebase as), and now one of the two parties in control of the Zcash trademark publicly putting into doubt the contributions of the other as it actively increases corporate control over Zcash by copyrighting consensus critical code, it may simply be time for me to leave this behind. There’s only so much I can do as an individual and if this community doesn’t align, and I try my best to sway it, and it still doesn’t align, it’s up for me to leave.
As I’ve said, I literally have a fork which solely changes a few package versions so it works in my larger project expecting newer dependencies. With Orchard, this would no longer be librustzcash as published by the ECC, and therefore need to be subject to BOSL as a whole. Even if I could make my fork BOSL, I’d then have to make ASMR, the first and currently only implementation of shielded atomic swaps for Zcash BOSL, when I don’t have the copyright on it (it’s split with the other developer I built it with) UNLESS I can legally sublicense it, in which case I have to setup a dual-licensing scheme and add a trailer to the contribution conditions which is a mess.
I also wrote an implementation of FROST, AKA threshold multisig, which I tried to discuss with Zcash developers (in the Zcash R&D server) regarding Zcash integration and unfortunately haven’t gotten responses on. That may have either benefited from a similar version fork, as we describe versioning with larger projects such as my upcoming work, or been best implemented with a fork with a different signer that can access pub(crate) and private methods/fields. That would also no longer be an option despite me open sourcing my work in general.
Finally, there’s the moral viewpoint that your stack is then reliant on an exception, which breaks the OSI’s definition on FOSS, and issues there. Any GPL codebase reliant on librustzcash as MIT would not be FOSS as the non-exception BOSL form (assuming you can sublicense, which I haven’t assumed due to the complete lack of confirmation by the ECC’s directors/lawyers) would be incompatible with GPL (even if MIT is sublicenseable).
This is so true. Let’s talk about reality. ECC has pioneered Zcash and is the core team for Zcash software. Every successful cryptocurrency has such a core team at the epicenter, who has been the prime driver of technological growth, partnerships, collaboration in software & adoption, etc.
I’m a holder of Algorand, Avalanche & Cardano. I would not want the core teams of Algorand to lose their core devs or team, nor would I want the NY-based makers of Avalanche consensus software to leave, nor IOHK that manages a globally distributed team. I want these teams to drive the path forward for the next 10 years and beyond! Algorand has proprietary code for finality which powers their blockchain trilemma, ALGO holders are more than happy that tech is with Algorand and they see a future in enterprise adoption of the tech, USDC works like butter on ALGO. Same goes for Avalanche and Cardano, sometimes the community members make a noise about too much centralization and dependency on the leadership of the core teams, but soon they realize there is no real alternative! So, as long as the core team has inherent interests in the success of the coin, every decision made by the leaders of the core team needs to be respected. Yes, there are serious concerns brought forward by core devs regarding the usage of a custom license. It is good to know the challenges that lie ahead, and I support ECC in moving ahead with the BOSL license up till the next halving and then evaluate the decision. BOSL is a very open license, anyone is free to adopt it as long as they follow the rules of the license!
Since BOSL is limited to Orchard tech, every partner would still be able to integrate ZEC with T-address like they do today for interoperability and then use ZEC per the core benefit of Zcash - shielding ZEC for long-term storage that goes inside Orchard pool - and the tech benefits from every improvement a competitor makes! And since we pay & entrust ECC with maintaining our core zcashd mining node, we can trust them to extend the Orchard license/permission to partners and collaborators they have worked with - Nighthawk, Filecoin, Ethereum, etc.
My experience working with ECC has been fantastic, their engineers have always made time when there was a need to discuss critical matters. Obviously, I want all the outstanding items to be resolved and fixed yesterday, but I respect their prioritization choices & the degree of care taken by ECC devs to their software releases, powering multi-billion-dollar value in money.
What I love about Zcash is that we can have all the discussions out in the open, cry out our agonies, and raise & plant red flags everywhere like it is possible in a democracy. At the end of the day, when all the discussions have concluded, the majority of the community ends up agreeing on an obvious path ahead, even if there are compromises to be made, or worse, losing some community members.
The Monero party has decided to draw the line at MIT Licenses only, they also do not care about being lawfully compliant in any jurisdiction, treating software as pure software that doesn’t live in the real world of the 2020s. It is understandable they would be vocal in any deviation from their core beliefs, be it custom licensing to benefit ZEC only or block rewards funding legal compliance. Zcash holders on the other hand have been open to change - be it block rewards upgrades, modifying block rewards/dev fund, and larger items like the move to PoS. The announcement of BOSL license for Orchard was made a while back, and it is starting to look a bit contentious as it is brought up again & again, just before NU5 activation. I believe the majority of the Zcash holders have digested the news long ago about the choice of BOSL license.
When what-came-to-be-known-as-BOSL was first revealed, I raised several objections, including:
What licenses are compatible with TGPPL?
Ideology and abstract goals aside, this is a crucial practical question. We are very used to compromising and using open-source license that don’t perfectly match our tastes, because the alternative is a compatability nightmare or (more commonly) an adoption blocker that benefit no one.
See additional points in that thread.
Unfortunately, that skepticism still seems well-placed. Having read the ensuing forum discussions, I’m still doubtful about BOSL’s merits, worried about its downsides, and confused about why vanilla GPL isn’t clearly better (by itself or as dual license).
I thus strongly support transitioning to the MIT license, or at least dual-licensing under GPL.
Thanks for sharing the thread, there’s heavy discussion around the decision-making process and risks in the thread, but there is no clear response for:
With ECC/Zcash making breakthrough tech possible and releasing it for free, what is the incentive for any investor to buy and hold ZEC? When forks of Zcash or competing chains can incorporate the ZK advancements, Zcash is reduced to an R&D coin and pump/dump news traders. Where is the work towards real-world use cases & industry partnerships that use ZEC to transact?
I’ll object to this one because Aiyadt won’t bite the hand that feeds him
No, no we shouldn’t trust ECC to extend the license to partners because their judgment hasn’t been good on the business side. trusting the code is one thing… because we can read through the code, verify the code, test the code. ECC devs are extremely smart and I applaud their contributions… But we shouldn’t hand over the access/gatekeeper reigns like this for business decisions.
Why? Because of conflicts of interest. Which ones? The ones that have stopped ECC from reviewing products and solutions that are better than their own or their existing partners.
So, just a reminder so that we don’t lose our way here… we shouldn’t have to trust ECC. That’s kinda the whole true crypto ethos… trust-less.
+1 There have been countless times where people complained competing projects copy & doesn’t provide value back to Zcash in any form. BOSL was an attempt towards solving that problem.
In case it is not clear, Orchard will eventually be MIT licensed sometime in the future when WE reap the benefits.
Yodler, before assuming any backroom deals between me and ECC, know that the notes of the communication we have are all posted on LCWG https://github.com/zcash/lcwg
This year, my only compensation for my work towards Zcash is the stipend from ZF for contributing to ZCG, which itself is a very busy position. Beyond that, I work every day to keep up with the community and several Zcash-related products my company is working on, all because I am long ZEC.
I’ve seen posts from your account and similar targeting ZEC contributors and they are in bad faith.
Yes yes, we’ve heard the narrative about the whole world freeloading on ZEC-tech by copying ECC’s code and using it for protecting people’s privacy on other chains without giving back to ZEC.
But how is that concern better addressed by BOSL, than by a standard copyleft license such as GPLv3?
This seems to be the typical response when folks get called out. What’s the deal?
I’m long ZEC. My posts aren’t in bad faith.
Agree, the term “acting in bad faith” is being used too often to frame the argument of someone who disagrees with a given position.
I’m sure the majority of the people on the forum taking the time to debate these subjects want Zcash to succeed. The issue isn’t that they are secretly plotting against Zcash (ie: acting in bad-faith) they just have different perspectives about how to get there.
We should assume good faith of others unless proven otherwise.
This isn’t clear. The sole comment so far was that the ECC would reconsider in the future, despite previously saying it’d require a community decision. When the poll here slightly hit MIT, then it became that forum polls are unreliable. When I suggested a Helios Poll, and an amendment to ZIP 1014 was proposed… neither have been recognized as potential ZCAP submissions yet (the former without specific proposal text, the latter with yet under discussion).
The BOSL is copyleft except people don’t have to contribute to ZEC for the first year of it, enabling them to work a year in advance and establish themselves before re-submission. It’s actually worse than the GPL in those regards and that arguably is more than enough time for any other project to claim an advantage over ZEC that ZEC then plays catchup with (while appearing as copycats and having delays accordingly).
That said, instead of dual-licensing, enabling GPL projects to use this code while simultaneously getting the benefits back immediately, BOSL is incompatible with a ton of projects and groups and routes people to ECC partnership deals (so far looking at multi-million deals), which the ECC says is a new form of positive value loop when it solely expands the existing positive value flow (ECC gets money, ECC builds).
Open question for those in support of keeping the BOSL license.
When OSAs (a.k.a. ZSAs) are released are you worried that a BOSL license might hamper adoption? And if your not worried, why?
I’m not interested in ZSA’s but more generally no because all this is speculative (some is pretty smeary) and also seems easily remedied with something as simple as a web portal that might guide the developer with references and checklists.
(Speaking for myself, not ECC.)
You might have missed that it depends on the
orchard crate and so is relying on the license exception of that crate for “Zcash projects published by ECC”.
This is indeed, by my interpretation, not open-source (it conflicts with clause 8 of the Open Source Definition).
It is a bug that the README files of projects that rely on this exception don’t say that they’re relying on it. I’m on holiday but someone should fix that.
Edit: I filed Projects that rely on BOSL exceptions should say that they do · Issue #5931 · zcash/zcash · GitHub . This really should be filed for all of the repos depending on
Later edit: filed
- Projects that rely on BOSL exceptions should say that they do · Issue #576 · zcash/librustzcash · GitHub
- Projects that rely on BOSL exceptions should say that they do · Issue #36 · ZcashFoundation/zcash_script · GitHub
- Projects that rely on BOSL exceptions should say that they do · Issue #4716 · ZcashFoundation/zebra · GitHub
It somehow hasn’t dawned on me, until now, that BOSL-licensing Orchard would have a completely unacceptable consequence: it would become infeasible to fork Zcash as governance fallback or a “friendly fork”.
As @daira explained today (see further analysis there):
I think it would be preferable to release the
orchardcrate 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
orchardcrate, or stripping Orchard out of the protocol. Note that the other possibility of asking ECC for a license exception is not permissionless.
To recall, the ability of anyone to fork the Zcash chain (whether code or code+state) has been a key point in governance discussions:
- as a cornerstone of decentralization in a consensual currency that is contintuously reaffirmed by those who have chosen to not fork it
- as a fallback in case governance mechanisms do not reach adequate consensus
- as an escape hatch in case of capture or misconduct by power-wielding entities
- as a legitimate way for “friendly forks” to emerge
Are we just throwing all of that away, without even an explicit discussion of these consequences and whether they are acceptable?
(Like @daira, I think that stateful chain-forks are a costly and undesirable “nuclear option”, but the possibility of forking is still important and impactful.)
Directly? I’m not sure. But that’s not the relevant question, because a wallet supporting Orchard definitely does (unless they reimplement everything) need to rely on crates that depend on the
orchard crate, and therefore are relying on the BOSL license exceptions for “Zcash projects” published by ECC and ZF. That is, my reading is that you can’t use those crates without being such a project or relicensing all of the linked code as BOSL (and dealing with any resulting license incompatibilities, if possible).