BOSL or MIT - Orchard

[Dodger]

@zooko

I don’t think we have a formal “Assessment” document, but I’ll check.

This response leads me to conclude that ECC did not carry out an assessment of the full implications of using the BOSL license for Orchard, instead of the MIT license.

@zooko

In general, yes, we’ve been studying the pros and cons of this strategy, debating it and gaining alignment around it within ECC, and communicating about it to the Zcash community, for years.

Firstly, I’m not asking about “in general”. I’m asking very specific questions which you don’t seem to be able to give straight and unambiguous answers to.

Secondly, it’s clear that you have not gained alignment around this decision within ECC. If you had, we would see full-throated and unreserved support for the BOSL license from the entire ECC engineering. However, we’re not seeing that. Other than @nuttycom, most ECC folks seem to be either openly opposed, or have been careful to avoid expressing an opinion one way or the other (which leads me to suspect that they are, at best, unconvinced).

Thirdly, ECC’s communication “to” the Zcash community about BOSL consisted of a blog post announcing that Halo2 would be licensed under TGPPL, followed by assurances that ECC was open to community input. However, the input that was provided, the concerns, objections and questions that were raised (including about license compatibility, by @tromer) were subsequently ignored.

Communication is a two way street, and it’s disingenuous to invite feedback only to then ignore anyone who doesn’t agree with you.

You haven’t provided any answers at all to these questions that I posed:

• 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).

The fact that you are unable or unwilling to answer these questions raises further red flags.

@zooko

None of the current Zcash-supporting orgs have yet expressed any concerns over licensing.

Have they been fully apprised of the new license and what it means for them? Or are they unaware of what the new license entails and what the implications are?

Are Gemini aware that they will be required to open source and BOSL-license their shielded withdrawal tooling?

@zooko

This conversation makes me think it would be good for ECC to issue a blanket exception for everyone to be able to use our Orchard code to support Zcash (ZEC) without having to BOSL their other code.

This indicates to me that you have not previously given due consideration to the questions and issues that I and others raised, and reinforces my belief that ECC did not carry out an assessment of the full implications of using the BOSL license for Orchard.

@zooko

Satoshi, and everyone else who has ever published MIT-licensed code, have already given us (and everyone in the world) permission to use their MIT-licensed code in our derived work and share our derived work under other licenses, whether proprietary non-open-source licenses, the GNU General Public Licence, the BOSL, or others.

The MIT license specifies that.

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

So what are the implications of mixing BOSL and MIT-licensed software to create a derivative work? The BOSL license states that one must make “an irrevocable offer to license” the derivative work under BOSL after 12 months but the MIT-licensed portions must remain subject to MIT, so is the end result a mish mash of dual BOSL/MIT-licensed software with some BOSL-only portions?

Quite frankly, the lack of clarity on how BOSL interacts with other licenses is deeply concerning. It’s clear from looking at the list of (17!) exceptions attached to the Tahoe-LAFS TGPPL license that license compatibility is a longstanding issue.

@zooko

But your question raises something else that I think is potentially a big issue.

That is, if zcashd (the only current mainnet-capable software implementation of Zcash) has BOSLed code in it, then someone who wants to make a chain-fork of Zcash would not have the legal right to do so…

This is further evidence that ECC did not carry out an assessment of the full implications of using the BOSL license for Orchard. If you had, you would have recognised the impact on Zcash forks.

@zooko

The most important criteria is whether their intended use benefits the ZEC holders.

…

Other factors we would probably consider include whether their intended use is creating value for the world, and whether we think they are potentially good long-term partners that we want to build a collaborative relationship with.

These criteria are entirely subjective, and there is no mention of any community input, so my interpretation is that the criteria will boil down to “ECC decides.”

This means that ECC would be able to exercise a veto over potential Zcash Community Grant recipients (like @hanh) refusing to grant a BOSL license exception because, for example, they don’t judge them to be “potentially good long-term partners”.

@zooko

Marta Belcher who is President and Chair of the Filecoin Foundation, and General Counsel of Protocol Labs, and Special Counsel for Electronic Frontier Foundation … said that … although they love the idea of the BOSL, they have a policy of strongly preferring MIT in order to facilitate the work of their downstream, downstream partners in the broader Filecoin ecosystem.

Not exactly a ringing endorsement of the BOSL license.

Note that the Zcash community also has a policy (clearly expressed in ZIP 1014) of preferring MIT.

@Zooko Has any organisation or software project that isn’t controlled by you voluntarily adopted TGPPL or BOSL?

There are two polls on this thread and both currently indicate greater support for ditching BOSL in favour of MIT:

When I look at the spread of opinions expressed, it’s clear that many of the people who are opposed to BOSL are active contributors to the Zcash ecosystem, including admins of the Zcash Community group on Telegram, Zcash Community Grant recipients, a core Zcash developer, and multiple members of the 7 Scientists. Their judgment on this matter should be respected and taken seriously.

@gottabeJay

It should move to MIT licence.

@fireice_uk

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.

@daira

For the record, and speaking only for myself:

• I prefer MIT licensing for everything;

• I think that the license compatibility down-sides of BOSL have been underestimated by ECC.

@kayabaNerve

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.

@tromer

an ill-reasoned harmful license is being forced on the community despite the strong objections of cognizant participants.

@covfefe

I know @hanh, developer of ZWallet, has indicated that the BOSL licence is a showstopper for him…

Note that @hanh’s departure would also likely result in Zcash support in BTCPay being deprecated, effectively squandering $120,000 of Zcash Community Grant funding.

Other grants may be abandoned and, of course, we have no way of knowing how many potential grant applicants will be dissuaded by BOSL.

Zcash support in multi-coin wallets like Edge and Unstoppable is also at risk.

@fireice_uk

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.

@fireice_uk

…we can always make the whole thing BSOL. But for multi-coin wallets that are closed source or GPL, that’s not an option.

It’s now crystal clear that BOSL will undoubtedly have a negative impact on the Zcash ecosystem (as I predicted a year ago), and it seems highly likely that adoption will actually decline - not just slow, but actually decline, as organisations drop support for shielded Zcash transactions and addresses.

It’s also clear that significant portions of the Zcash community oppose the use of BOSL.

@zooko While you may honestly believe that licensing BOSL will benefit the Zcash ecosystem, you clearly haven’t convinced the rest of the Zcash community (despite having had over 18 months to do so).

Imposing BOSL on the Zcash community would be entirely non-consensual, and would violate the trust that the Zcash community placed in you and ECC when they approved ZIP 1014.

If you want to experiment with BOSL, I suggest you use it for the ECC wallet SDKs or some other non-core software but the risk to Zcash of experimenting with the core protocol is too great.

I urge you to listen to the community, and re-license Orchard under MIT.