It was recently brought to my attention that @Zooko authored the BOSL license. With that new contextual understanding I’m really stumped about why this kabuki theatre of debate against MIT licensing ever took place. @Zooko is the leader of this whole entire ecosystem and considering that most of the pros and cons are nuanced hypotheticals - (?)how about we save ourselves all the energy and close this debate in favor of BOSL. In the future, challenges encountered can be re-assessed post-hoc against MIT to determine if in hindsight it would have been the better choice, and reconfiguration to MIT could be reviewed again
2 Likes
(Speaking for myself.)
I disagree with the implication [clarification: from ECC in general, not specifically @joshs] that the community should just “trust us” to get this right. We didn’t get it right before. The proposed changes need wider review, and we definitely shouldn’t dig in our heels if there are substantive arguments that they are insufficient.
10 Likes
is the post published?
1 Like
I didn’t say that. I asked that people read what’s released and then let’s take a look at the outstanding questions as I believe the update will likely address a number of the questions asked.
1 Like
No, apologies. It was intended for today but we need a little bit more time.
2 Likes
I know this has been sort of tried before. But, I worked hard to implement a nice z2z polling interface on free2z and put up a poll there: Free2z
What’s cool about this one:
- Vote for as little as 1 zatoshi
- Number of votes and amount of $ZEC are tallied separately
- All proceeds go to help with medical expenses for Marbelis
It’s a pretty sweet interface for a first pass IMHO. You can also vote from the screenshots 
It’s 0.00000007 to 0.00000006 so far! 
3 Likes
Lots of nice theory… I’m curious:
Is there evidence that zcash tech is suffering from the issues that BOSL is designed to mitigate?
“underfunding” and “capture” ← Is this even a fair way to frame the debate?
Do we have observed costs incurred by depending on MIT?
For example, if JP Morgan Chase were to be reaping huge profits by building closed source infrastructure on top of zcash-derived ZK Tech… because it was able to under MIT… would that “observable” fact be relevant here?
It’s easy for me to see the costs of BOSL from the perspective of someone who just wants to build something neat. I assume there are some countering benefits that aren’t obvious to me.
5 Likes
Hi everyone. We just published an update to the BOSL license that provides exceptions for Zcash supporting projects and friendly forks.
Thanks to @steven-ecc for coordinating this with reviews and feedback from @zooko, @Dodger, Bootstrap board member Alan Fairless, @adityapk00, @aiyadt, the team at Unstoppable and @aquietinvestor. I hope I didn’t miss anyone.
I’m happy to answer any questions. I’m hopeful that this workable for all involved and honors the spirit of what we all want for the Zcash community and the future of ZEC.
16 Likes
Kudos to community members who made this happen! Never stop asking hard questions even if uncomfortable (assume good intentions on the both sides especially when they are/were positively contributing community member)
8 Likes
Thanks @joshs and @steven-ecc. I have opened another PR for some changes (widening the exceptions a little) and clarifications that came up in review by ECC engineers: Clarify and widen license exceptions by daira · Pull Request #334 · zcash/orchard · GitHub
Please note: GitHub PRs are for collaboration on software development. Please keep comments there to productive discussion of the license exception text and potential changes to it.
7 Likes
I discussed ECC’s blog post with Alan Fairless yesterday, and I’ll summarize here the feedback I provided.
I welcome these changes. They represent a significant improvement, by reducing - but not entirely eliminating - the disincentive that BOSL posed for current and future members of the Zcash ecosystem. Importantly, existing ecosystem partners can now add support for Orchard without facing the prospect of relicensing their entire project and grappling with license compatibility questions.
However, I still fear that BOSL will continue to present a cognitive and legal hurdle for future ecosystem members, especially large corporations, whose adoption and support of Zcash (whether that be by listing ZEC, adding it as a payment option, or including support for ZEC in tools, software and services such as point-of-sale software, custody services and risk management products) are essential if it is to ever achieve the level of adoption that we hope it will.
This is a great question, and helps a crystallise a growing concern of mine regarding how we make major decisions that have far-reaching consequences.
Decisions like these normally follow a process along these lines:
-
Identify the problem, and assess its impact.
a. “What’s the problem? Is it really a problem?” -
Brainstorm potential solutions, and do an initial assessment of their impact.
a. “Any ideas?” -
Create a shortlist of options, and do a deeper dive into the consequences and risks of each one.
a. “So, if we do x, that will reduce the impact of the problem by this much but it will also…” -
Decide what, if any, solution should be implemented, taking into account the net impact of the positive and negative consequences, and the risks incurred.
a. “Let’s do x.” or
b. conclude that “The best thing is to do nothing because the negative consequences and/or risks outweigh the positive consequences.”
In my opinion, the Zcash community should be involved at all four stages, so that a diversity of opinions and ideas can be heard, and there’s an opportunity for a clear consensus to emerge. Involving the community in the process builds trust (both in the organisations involved, and in the suitability of the end result) and supports decentralisation.
However, in this instance, ECC jumped straight to 4b., anchoring themselves to a specific solution, and presenting it as a fait accompli.
Contrast with ZF’s approach to expanding ZCAP:
-
Problem hypothesis: “ZCAP is not sufficiently independent and representative of the Zcash community.”
a. Is this really a problem? Yes.
b. What’s the impact? We risk missing out on valid and important opinions and input on decisions that are presented to ZCAP. Some community members feel disenfranchised and/or marginalised, and confidence in ZCAP as a decision-making body is compromised as a result. -
Openly solicit Ideas for Expanding ZCAP from the community.
-
Assess the ideas put forward.
a. You can also see this process happening live as we assess @aquietinvestor’s idea of adding active members of the Zcash Community on Telegram who joined prior to March 2021. -
Adopt suitable solutions.
a. @decentralistdan’s idea of adding grant recipients
b. @elenita’s idea of adding anyone who has submitted a successfully merged community PR
If we truly want to give the Zcash community a genuine voice in how Zcash is governed, we must involve them in the decision-making process.
Making decisions behind closed doors and presenting them as faits accomplis is not the way we should be doing things. It centralises power, shuts down open discussion, disenfranchises the community, fosters division and conflict, and generally makes for worse decisions (as evidenced by the fact that these changes are being made to the BOSL licensing regime at the eleventh hour).
16 Likes
2 posts were merged into an existing topic: Thoughts on conflicts of interest within the Zcash Foundation
I like this approach…
1 Like
My understanding is that contributions to the orchard crate, for as long as it remains under BOSL (or BOSL/GPLv3, if that option is taken) will continue to require copyright assignment to ECC.
That is accurate. In particular, someone who forks orchard would be under no legal obligation to retain the license exceptions (and the fact that the source of the derived work must be published under BOSL does not by itself entitle ECC to apply those exceptions to the changes). If they assigned copyright to ECC in order to merge those changes back upstream, the merged code would be covered by the exceptions.
To reiterate, I hope it is clear why I favour —and have always favoured from the start— just licensing all of zcashd’s code as MIT [OR Apache-2.0].
7 Likes
Since people may miss the edit I made in a comment above, I just filed the following issues:
Also, Copyright statements for the LICENSE-BOSL file are conflicting · Issue #330 · zcash/orchard · GitHub has been fixed in orchard 0.2.0, which will be used in zcashd v5.1.0.
Clarify and widen license exceptions by daira · Pull Request #334 · zcash/orchard · GitHub is still open because it hasn’t had legal review yet.
1 Like
Your suggested text uses the term “permissive”:
An exception is provided that makes this a “permissive” license when used in Zcash or some of its chain forks.
The Open Source Initiative defines the term “permissive” thus:
A “permissive” license is simply a non-copyleft open source license — one that guarantees the freedoms to use, modify, and redistribute, but that permits proprietary derivative works.
That definition doesn’t seem to apply to BOSL (whether or not the exception applies).
3 Likes
I think you are correct, for two reasons:
- “BOSL 1.0 or later + Zcash license exception” does not satisfy parts 6 and 8 of the Open Source Definition.
- BOSL 1.0, with or without the exception, does not permit fully proprietary derivative works due to clause 1.c.
This should also be fixed in zcash’s COPYING file. We’re discussing in ECC’s Core team what wording to use instead.
It is misleading to call this an OSI definition. The above text comes from their FAQ, but their website also advocates that the terms “copyleft” and “permissive” should not be used.
I’d be perfectly happy to reword the text to use “reciprocal” and “non-reciprocal” instead, which is the core difference that we are trying to convey in this context.
The latter is an opinion article, reflecting the view of the author (who seems to have a pro-reciprocal-license bias, reading between the lines). We might infer that OSI having it on their website means they don’t entirely disagree with it as an organisation, but I don’t think it is any kind of official position.
In any case, I agree that “copyleft” and “permissive” are both ambiguous and could be misleading in this context. I’m unconvinced that we should replace them with “reciprocal” and “non-reciprocal”, since it’s not obvious what those mean and I think they are likely to be unfamiliar to many developers/users.
We can replace them with a summary of what the exception actually allows, which is that if a project falling under the exception is linked or combined with the orchard crate, the resulting work can still be copied or distributed under the original licenses documented in contrib/debian/copyright, provided that the included portions of the orchard code remain subject to BOSL.
(We can’t actually refer to contrib/debian/copyright except in zcashd’s copy of this wording. In librustzcash we can just say “MIT / Apache 2.0” instead.)
Suggested wording:
Downstream code forks should note that the code in this repository depends on
the ‘orchard’ crate, which is licensed under the Bootstrap Open Source License.
A license exception is provided allowing some derived works that are linked or
combined with the ‘orchard’ crate to be copied or distributed under the original
licenses [specify which], provided that the included portions of the ‘orchard’ code
remain subject to BOSL.
See https://github.com/zcash/orchard/blob/main/COPYING for details of which
derived works can make use of this exception.
This wording has been added to zcashd and to librustzcash.
zcash_script #36 and zebra #4716 is still open.