Thank you zooko for your support to the zec holders… maybe i m wrong but i think your take is the right choice.
I support this strategy.
It will be interesting to see what data this decision creates.
Are future changes possible though if needed?
A quick note about forum polls:
Forum polls have no parameters set on them as to the age of an account or involvement in the Zcash community. It literally just takes a disposable or real email address to make a new account and click the vote button.
This is in contrast to a ZCAP poll where the number of expected voters are a known quantity and the polling is resistant to Sybil style attacks.
I disagree with your approach but I understand your perspective given your status/position in the community. Thank you for taking the time to clarify your reasons. I have never been more optimistic for the future of Zcash.
Usual disclaimer: these opinions are my own, not likely to be those of others at ECC, etc.
I’ll just very briefly add my position here: I am a fan of copyleft licenses, and I believe that Orchard should be dual-licensed under BOSL/GPLv3. As the GPL is a more restrictive license than BOSL (it requires immediate release of source code with a binary, rather than a 1-year buffer) this increases the usability of Orchard within the free software ecosystem, while still allowing closed-source use with the “1 year head start” that BOSL provides.
Copyleft licenses explicitly defend against private capture of public goods. And I wanted to respond here to something that @secparam suggested - that BOSL is intended to be a “try before you buy” license. I personally don’t believe that this is the intent of the license. As I understand it, when a third party creates a derived work from BOSL-licensed software, they are compelled to provide the source under the same conditions after one year. This means that if, on day 1, I make a modification to BOSL-licensed software, those modifications must be released under BOSL on day 366. However, consider what happens to the modifications that I make on day 2: those must be released on day 367. This creates what one could consider a “sliding window” of proprietary advantage: a company making BOSL-licensed software gets a perennial 1-year head start on competitors that want to take advantage of their improvements, but the important part is that those improvements eventually become usable by the commons. Software evolves quickly, and a sliding 1-year head start is sufficient to obtain a profitable first-mover advantage, without requiring closed-source software.
In a way, this is kind of the same idea implemented by patents and copyright ownership in general: an entity gets time-limited exclusive rights to their improvements, which must eventually be shared with the commons. It’s the duration of copyright and patent terms that makes them abusive; a 1-year exclusive right seems like a better balance for software, to me.
- What will happen to
librustzcash
? Everything depends on it and it has a dependency on the orchard crate.
Currently, it’s MIT but mustn’t it switch to BOSL?
If yes, aren’t you worried that this will deter community contributions and leave all the dev work with the ECC and their friends? - I understand the position of many people is that the zcash dev fund paid for ECC to build Orchard and that it should not be given away for free.
But what prevents Monero (for example) to fund a rewrite for 1M on the condition that it is MIT licensed? Still cheaper than paying ECC
IMO, the BOSL only prevents open source contributions to zcash rather than encouraging broader adoption.
@nuttycom For me, the issue lies in the “virality” of the BOSL. Even if projects release their source from day 1, they will still have to adopt the BOSL and thus make sure that it’s ok with their contributors.
Ok, so both you and Str4d have brought up this idea. That BOSL is purely a time limited grant of exclusive use and there’s no permission involved and no way out of it after. BOSL is merely intended to encourage short term innovation privately that must become public. I’ve seen that said no where else, so if its true, that should be clarified officially and prominently . Also ECC should explicitly pledge not to relicense proprietary work done during the 12 month period (because i’m pretty sure they could now in practice even if by some pinky promise in the license its allegedly immutable. And very sure people will accuse them of planning that,)
But, at least as a plausible intent, this makes sense. But even by the intent this license is a whole lot of headache for almost no gain. Weird licenses cause people to have doubts about safely including a library in their source code. All it takes is someone raising the issue in a meeting, everyone realizing they’d need to talk to a lawyer, and then people deciding its not worth the money and headache. That’s going to prevent some wallet dev from making a zcash wallet. It’s going to get us artfully trolled by the monero community when they ask for permission again for an exception. All for the hope that 1) someone could do proprietary stuff they’d then release it later and we’d benefit 2) you can make meaningful profits off only a year of keeping stuff secret. Having spun up a few blockchain startups now, I wouldn’t take that bet and would therefore not use Orchard. Instead I’d tell a team to do a clean room implementation from the spec + the MIT licensed crates and then never reveal their secret sauce.
This is still not worth the headache.
@zooko, a quick but very important question your post raises: why, today, is Orchard BOSL licensed going forward and not GPL or even MIT? Its great ECC got 9 million for MIT licensing HALO in the past, but
-
would anyone really pay for Orchard? Orchard isn’t Halo, the awesome general zk proof tech ECC invented. Its much more niche to the Zcash ecosystem. And, given the halo libraries, someone who wanted to do proprietary work modifying orchard could easily build a clean room implementation from the spec fairly easily. That would avoid a licensing mess and the weird 12 month window BOSL gives them to profit off proprietary changes to Orchard.
-
Did BOSL play a role in these deal? Remember, the whole question is can we replace BOSL with MIT or GPL.
Specifically, did the 12 month exception actually come in to play for licensing Halo (before it was MIT licensed)? Because if it didn’t, then BOSL was functionally equivalent to GPL in the negotiations and you could have done the same deal with GPL and Eth/Filecoin paying to get out of a copy left license (which is, in effect, what they did to remove BOSL). And so, even if there was potential revenue for licensing Orchard, we could still get it without the BOSL headaches.
Without BOSL, we’d get rid of these headaches about having a weird license. We wouldn’t be getting trolled by the Monero community, we wouldn’t have a source of FUD against Halo and Zcash, nor would we risk wallet devs not wanting to touch Zcash because some of our libraries the devs must use have a weird license and the devs worry this will get them in trouble.
Thanks zooko. So it appears there are 3 options. GPL only is a 4th option but has similar outcomes to BOSL + GPL so won’t specifically mention it. I’ll try and summarise where I think the discussion is at.
BOSL
BOSL + GPL
MIT
experiment
Trying to reach some form of outcome from this discussion I think @zooko raises a very important point that I think it warrants another poll. (P.S. I know these polls are not perfect but it might help those not posting express their views).
- I would prefer to continue the BOSL experiment for (at least) a few more months so we can review outcomes/feedback
- I would prefer to change (or adjust) the license now
0 voters
Hey folks, it’s been less than a day since I posted my long comment above, and tweeted it, and I’ve gotten an overwhelmingly supportive response from Zcashers on Zcash twitter. I collected all of them that I saw (excluding, of course, ones I didn’t see, from twitter accounts that I have blocked because I think they are counter-productive or low-quality), and I’m pasting them all in here. If you want to understand or predict my choices, be aware that I consider this kind of feedback to be a strong signal of support from the Zcash community.
First of all, I want to give a shout-out to BlocksAdvisors for boiling down my main theme into one succinct sentence: “Positive feedback loops create positive externalities.”. That’s exactly right!!
Second, the handful of responses that weren’t entirely supportive. See attached threads on twitter for the ensuing conversations:
And lastly, the overwhelmingly supportive responses:
https://twitter.com/rekodi_i/status/1521985921721278470
https://twitter.com/ildep2015/status/1521997335823323137
Can we have delayed MIT but baked in that it will go to MIT after a fixed time period. And baked in exceptions for all code that benfits Zcash i.e. wallets, free2z,com, etc?
Edit: Realized the poll at the top has now more people MIT than BOSL
Edit: We should go full MIT after a fixed period! With the current BOSL license no exceptions to unfriendly projects that dont benefit Zcash.
P.S. I consider this to be a strong signal of support from the Zcash community for the general model, not necessarily for specific decisions like whether to grant a licensing exception for Monero or whether to release Orchard under the MIT licence right away. The model I mean is the one shown in this diagram, and succinctly stated by BlocksAdvisors as “Positive feedback loops create positive externalities.”
The enclosure of the commons has produced a lot of negative outcomes too - so the details of how we manage shared resources are important.
For example, there is almost no cost to duplicating open access digital resources, unlike common land. And people who are deprived of access to common land often became much poorer.
The “tragedy of the commons” model itself has been criticised heavily:
Here is some in-depth research on alternative models of property:
As Shawn intimated, forum polls are of limited utility in assessing the sentiment of the Zcash community.
However, the Zcash community has already expressed a clear preference for how Zcash should be licensed, in ZIP 1014:
All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative), preferably the MIT license.
The definition of the term “SHOULD”, as used in ZIP 1014, is “that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.”
“Full implications” includes both the expected beneficial impact and any expected or potential negative impacts.
@zooko: You have been eloquent in describing why you believe that adopting BOSL for the Orchard library would be good for Zcash. However, many people have raised concerns about the potential negative impacts, both at the time Halo2 was announced, over 18 months ago, and since (including by me on an Arborist call a year ago).
Those concerns have not been addressed or allayed. Many questions have been raised but there has been very little response from ECC. The best we have is @str4d’s attempts to help people understand what the BOSL license means. However, without clear guidance from ECC, there is inevitably a lot of uncertainty and doubt about the implications of Orchard being BOSL-licensed.
So, @zooko, here some direct questions to you and ECC:
-
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).
-
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?
-
What criteria has ECC set for evaluating requests for a license exception?
-
Finally, why did Filecoin insist that Halo2 be licensed under MIT/Apache instead of BOSL?
Hi, Teor. Thanks for the response. I’m aware of some criticisms of the “tragedy of the commons” theory, especially the fantastic work (combining both theoretical and empirical research) of Elinor Ostrom and her husband. There’s an episode of the Econtalk podcast about that work that I really enjoyed: Peter Boettke on Elinor Ostrom, Vincent Ostrom, and the Bloomington School. In an open source project that I used to contribute to — Tahoe-LAFS — we tried to leverage Ostrom’s theory.
It sounds like you might be one of those people whose opinions I respect that I differ from on this, as I mentioned:
Since I wrote that, BlocksAdvisors provided me with a much better way to state that last sentence: “Positive feedback loops create positive externalities!".
I agree with the goal of creating positive feedback loops, and I recognise the huge issues in funding open-source software in a sustainable way.
And I think that helps clarify my question:
- what property rights are we controlling here? What are the benefits and drawbacks?
- are there alternative ways to get similar benefits?
Not speaking for ECC, and limiting this comment just to an easily answered technical question:
librustzcash
is a “Zcash project published by the Electric Coin Company” as defined in the orchard
crate’s copyright terms, and therefore it need not switch to BOSL.
Note that the orchard
crate is not a huge amount of code; it’s about 38 kloc including comments and documentation (measured using Count LOC online). The bulk of the Orchard circuit is implemented in halo2_gadgets
.
@zooko I’m not sure your diagram addresses the underlying concern many have.
Currently we do have a feedback loop. It comes from the community using the value created by ECC and then others (some of which are in the Zcash ecosystem) multiply that value. Some of that value comes back to ZEC.
I’m not sure it’s easy to short-circuit that feedback loop without reducing the value produced by others.
Now the thing I want everyone to notice is that the community and others are really effective at multiplying that value produced by ECC. It seems like an extraordinarily risky experiment to try and short circuit that feedback loop when long term we should be looking to focus our efforts on things that have a multiplying effect.
The Arborist call helped clarify these questions, at least from my personal perspective.
For the Zcash community, the benefits are:
- ECC’s BOSL-licensed software is paid for by the Zcash community via the dev fund
- ECC controls the right to use its software libraries in specific ways
- ECC gets to decide what good uses of its software are
- ECC gets to decide how to direct the benefits (for example, the FileCoin partnership payments)
But the drawbacks are:
- outside contributors who want to avoid the risk of BOSL don’t join the Zcash community
- the Zcash community is smaller and less productive
So while ECC gains from using BOSL, it isn’t guaranteed to achieve an overall benefit for the entire Zcash community. So if there is a positive feedback loop here, it’s quite narrow.
Similarly, when we look at the wider tech ecosystem, the Zcash community benefits because:
- zcashd is built on bitcoind, Rust & crates, sqlite, gcc/llvm …
- Zebra is built on Rust & crates, rocksdb, parts of bitcoind, gcc/llvm, …
If we want those technology stacks to remain healthy, so we continue to benefit from new features and performance improvements, we might need to give back as well.