It should move to MIT licence. I dont think there is any strong opposition to it. Yes, even if we paid for it.
Edit: Realized there’s a poll. Clearly im wrong, some people do think that it should stay BOSL…
1 Like
I did mean Orchard as the Rust crate with “unless an alternative implementation was provided” immediately following the quote you provided. As for Zebra, it’s only Zebra as published by the Zcash Foundation, which was my second paragraph.
1 Like
My opinion: I voted for MIT licence.
My reasoning: Having a licence that is hard to work with will hurt Zcash more than it helps by stifling ecosystem, wallet software in particular. We already have the exact same situation with the trademark, let’s not repeat same mistakes.
6 Likes
How does BOSL affect your other project RYO @fireice_uk ? I thought I heard you were going to use Halo?
1 Like
You can mix MIT and GPL code (large parts of Linux kernel are MIT-licenced drivers) as long as the final licence is GPL. If there is no re-licence I will consider that route.
What if we agree to relicense Orchard crate from BOSL into MIT by NU6? I believe the current plan by QEDIT is to release the Orchard Shielded Asset protocol (i.e. UDA/ZSA) by building on Orchard. This way, we can ensure some stability in the next few months while at the same time giving the community more chance for input and ask for clarification if ECC would do it, or not, and why.
Personally, I think there should be some discussion on how to solve this particular problem. At the end of the day, not many Zcashers joining the movement to support unrelated, or worse, competing projects in the space.
I still don’t see anyone who dislike BOSL address this particular question. Cheers!
1 Like
@spectre I will attempt to.
Zcash is, to put it politely, severely stunted in any area that doesn’t involve research (wallets, community spaces, exchanges with z-addr support, to name a few). Do we really want to make it even harder (bordering on impossible actually, since any wallet would need to be re-licenced to BOSL and not use any GPL code) for wallet developers to adopt Zcash?
5 Likes
I don’t think this is true at all. ECC Wallet SDKs are MIT-licensed. Also, wallets interacts with lightwalletd, which is, surprise surprise, MIT-licensed. Also, the Orchard protocol is free to be implemented by anyone. Consuming what Zcashd with BOSL Orchard-crate produce is not the same as including the Orchard-crate code into your code base.
Since most of us are not lawyers, I think we might have misunderstood a lot of consequence in using BOSL.
5 Likes
I am a wallet developer, so I am speaking from that POV. You will need to include the Orchard crate in your wallet code for a very simple reason that the wallet cannot just go to a remote node, give it the keys and say “I would like my transactions please” - that would present gigantic security and privacy problems.
Any wallet creating an Orchard transaction needs to “speak” Orchard. And that means either including the crate, or re-implementing most of the code in it. Or skipping Zcash support altogether.
Consuming what Zcashd with BOSL Orchard-create
To address that part specifically, if a wallet includes zcashd, we would call it a full node wallet. Those are extremely unpopular, for a very simple reason that they need to download and verify full blockchain to work. There is only one wallet for Zcash that does it IIRC.
6 Likes
If this were to be the case, I wonder why there’s no pushback from current non-ECC wallet devs. I mean, does @NighthawkApps feel that their work is impeded because of BOSL Orchard crate?
Now I’m convinced we should move away from BOSL, if not just to stop FUD from inside the community. 
1 Like
I have a sneaky feeling that they are doing exactly what we decided to do with Zephyr - wait until the “inevitable” re-licencing (well, I told the other dev that it isn’t as inevitable as he thinks it is given this coin’s propensity for shooting itself in the foot).
A we out in our case we don’t care about public availability of the code too much, we can always make the whole thing BSOL. But for multi-coin wallets that are closed source or GPL, that’s not an option.
3 Likes
I’m strongly opposed to the use of BOSL license for any consensus-critical code, and at least for the time being in code that third party wallet devs would need to make.
I like the principle behind it - encouraging incentives for innovative development (“sustainability”) while also ending up with a public good at the end of the transitory period. That’s a great idea and a nice balance of competing interests.
Additionally since this is a new idea, there’s no way to get any experience with it without actually putting it to the test on some real software. So I view this as the strongest reason for ECC to try this out now -they have a new software release that has some commercial demand. How else would we have the opportunity to try it out an unfamiliar new license without first using it on some new software where the unfamiliarity is felt? Have to start somewhere.
The reasons I think it’s not appropriate for consensus code that every node developer or wallet developer would need to make are:
- The perceived novelty and uncertainty around the license I expect will have a chilling effect of keeping outside developers from contributing, and this is among the very top priorities for zcash community growth. Even if BOSL is essentially an interpolation between more familiar MIT and GPL licenses, it’s the novelty here that is creating its own effect
- I think it’s inappropriate to use the threat of state enforcement as the means to achieve the desired ends of incentive alignment. Like the license works because it carries the threat of creating a lawsuit against developers who don’t follow the license. Lawsuits work in part based on power asymmetry, a well-prepared and well funded entity like ECC would have too much of an edge against independent developers. I personally view there being a 0% chance of ECC attacking an independent dev team because of their values, but I can’t prove that to anyone else and I don’t see anything in the way of safeguards against it. This is equally true for GPL or any copy-left too.
- Creating exceptions where needed like for Zebra is retaining too much discretion within the couple of leading organizations when we should be trying to diffuse power more where we can
I said strongly opposed, but there are plenty of things that could change my mind or mitigate the issues I have. What could address #2 is a safeguard clause that prevents using this license to sue small independent development teams. Something that would change my mind about #1 is hearing from wallet developers that they really don’t care about the distinction or that they prefer this
11 Likes
Who made this decision and why are they not speaking up to defend it? All I see is ECC key devs, Zfnd devs, Zfnd head and Zfnd board members speak against it. If all these important protocol stakeholders are against it why and how was this decision reached?
5 Likes
Here were the first discussions (about as mucky as this one) and the first blog, Im sure theres another one coming
4 Likes
By now I don’t think it really matters much which license the code is running under. Financial compensation through litigation vs. governance/reputational damage. @amiller already said it, even if it comes to a legal dispute with (small) copy cat developers, what kind of impression does it make when an organization with the goals of an ECC uses the state/law to punish open source distribution/development of their own software. It just doesn’t fit and makes a crooked impression - “empower economic freedom”.
This is even more true for the Zcash Foundation as a 501(c)(3) organization. Therefore, the stance of the ZF members is completely understandable and expected.
I still doubt that this BOSL license really has such a big impact on whether people look at the code and re-use/contribute to it under this license. (NB I have no clue, the people here know licensing and its aspects much better obviously)
My opinion: If the code is good and gets some publicity (especially new ground-breaking cryptographic tech), then everyone who has the time/brain for it will take a look. Just because it’s a new license you haven’t heard of, you won’t look at the code? The license has 1600 words, is it really that much/complex? I don’t think the license is such a bigger hurdle than the MIT license.
At the end of the day, it’s all good - even for the investors, who pay the ECC/ZF Funding Tax. At least as long as the team continues to deliver and doesn’t break apart/split up among competitor chains, price will catch up.
Open source and an honorable global mission is more than fine for me, but don’t forget, the financial interests of the stake and thus ZEC holders are important to consider along this path. Looking at the price in the last few weeks, we could really REALLY use a bit more market share. 
Not sure if such a license will help with that though.
4 Likes
I still doubt that this BOSL license really has such a big impact on whether people look at the code and re-use/contribute to it under this license. (NB I have no clue, the people here know licensing and its aspects much better obviously)
It isn’t about not being willing to read the text of the license. It’s about being unable to use the library in literally any project with existing contributions (assuming the inability to sublicense which I brought up above) without striking a deal with the ECC. This immediately removes any incentive to contribute.
Besides my commentary there, I do want to say I explicitly agree with
It just doesn’t fit and makes a crooked impression - “empower economic freedom”.
EDIT: Even if the MIT license can be successfully sublicensed, that’d still prevent usage of Orchard in multiple other codebases, such as GPL ones from my understanding (as those would not have their license terms satisfied under the BOSL). I do want to be clear that identifying MIT specifically as sublicensable is not an end all solution to the problems faced, nor the issues posed/debates caused by the BOSL.
2 Likes
ECC is also a 501 (c)(3) non-profit under Bootstrap.
“Bootstrap Open Source License”
1 Like
Actually many multinational software companies have this policy. If the software license doesn’t fall into a small set of well known licenses then the staff members of the company are not permitted to look at the code even outside their day job due to the risk of contamination.
3 Likes
This may partially be due to the Apache license, where it claims they can claim copyright over your code if you even look at theirs IIRC. I remember a C++ author doing a ranges? implementation getting hit over this.
As a side note, the poll currently favors MIT, yet I would like to say if it’s going to be kept as BOSL I’d hope the copyright becomes split between the ECC and Zcash Foundation like the trademark, allowing either/requiring both to grant exceptions, as this is consensus critical code for the project.
(Speaking for myself, not any open-source project I’ve been involved in.)
Many open-source projects also have this policy, for two reasons:
- the risk of the project or devs getting sued if devs write code similar to code they’ve looked at
- it’s expensive to get lawyers to look at new licenses
- those licenses have never been tested in court, so it’s still risky even with a legal opinion
- every project that wants to re-use the code takes on the same risks
7 Likes