BOSL or MIT - Orchard

My personal belief on the forking problem is it’s too hard to legally enforce (chain) forks to behave by a certain set of rules set by ECC or the community. But I believe you can incentivise chain forks to behave by a certain set of rules by allowing what I call it fork and merge. Where the forked coins can optionally be batched up and merged (think rollups) back into Zcash (possibly periodically) as a ZSA.

When the next zkDOGE meme coin is launched I seriously hope it’s launched on a chain fork of Zcash :rocket:.

1 Like

These questions appear to be responding to things I didn’t say.

Aristarchus, I don’t understand your question. The two things you mention here are what I intended by these two parts in my post:

First, on the topic of BOSL exceptions for all projects (wallets, exchanges, zecpages, etc.) supporting Zcash — by which I mean Zcash-the-coin (ZEC), not just the Zcash-the-technology or the Zcash-the-network, unless their work thereby also supports Zcash-the-coin:

Second, on the topic of friendly forks:

Does that answer your questions?

1 Like

No, the blanket license exception that I am trying to craft to allow Future Friendly Forks to use Orchard without BOSL’ing their codebase would be irrevocable, so that people who use and develop on Future Friendly Forks would have all the legal rights they would need from that point forward.

5 Likes

Great, thanks :+1:

Yes that makes sense. I saw that the ZWallet developer had posted on the community telegram that BOSLing his code would be a blocker for him. So it seems ECC issuing a blanket exception would be a good solution.

With regard to friendly forks, I think the exact language of the exception matters a lot. Would we want to allow a chain fork that includes all ZEC holders, but then allocates a billion coins to the forkers 5 blocks, or 5 million blocks, after the chain split? It seems the exception needs to also say something about the future monetary policy, or else there is no economic difference between chain forks and code forks. This seems like a tricky problem, but maybe a good lawyer can draft something that works.

9 Likes

Emphasizing This!

2 Likes

There’s a certain point where I think one has to rely upon markets to do their job. This is why copyleft licenses are good to begin with - they inhibit the enclosure of public goods, and by doing so level the playing field so that participants in a market have to compete on quality of service to the end-user.

1 Like

I think this is probably the best case for @daira’s excellent idea to just dual license under GPL and BOSL. It gives all the claimed upsides of BOSL (including the same reason for paying licensing fees to ECC) , but for forks or people who are worried about non standard licenses, they can use the GPL version instead.

(To be clear, I still think MIT is a better idea. But baring that, Dual Licensing under GPL and BOSL is strictly better than BOSL)

6 Likes

I’m not convinced it does. BOSL requires public disclosure of source irrespective if you have a copy of the binaries or not.

Ah, I can’t recall the exact differences between GPLv3, v2, and AGPL. If modifications without binary distribution really are a concern of ours( IMHO, anyone who’s going to do that just isn’t going to ever admit they used the code), then dual license under BOSL and either AGPL or GPLv3 (one of them covers that).

1 Like

No. BOSL requires the source to be made public (e.g. on GitHub) even if the binary was distributed privately. It’s true that AGPL would require a public facing API to distribute the code publicly. But for non public facing APIs only those with access are required to be granted access to the source. (That’s my understanding at any rate).

We could probably debate if this extra requirement makes a significant difference to outcomes but in defence of BOSL it’s a really powerful distinction I think is something someone should explore. Not 100% convinced we should be the ones exploring it though :joy:.

1 Like

We want to attract more developers to build applications for Zcash, including many developers who strongly advocate building FOSS.

I am in favor of dual licencing under GPL and BOSL, but this must also include as zooko mentioned upthread a “blanket exception for everyone to be able to use our Orchard code to support Zcash (ZEC) without having to BOSL their other code”

We also want to enourage existing independant developers in the ecosystem who have similar principles.

I know @hanh, developer of ZWallet, has indicated that the BOSL licence is a showstopper for him, I would like to know if the above approach would work for him as I believe that will be an important data point.

My preference is to licence as MIT, it’s simpler and will more effectively further the goal of expanding/nurturing the developer ecosystem.

6 Likes

@zooko can we add a line to the Orchard readme advertising that ECC is open to granting exceptions in cases that benefit Zcash?

@zooko With regards to Zcash ecosystem exceptions would it be as simple as stating the exception will be granted to applications that connects, and only connects, to the official Zcash (or Ycash) chain (e.g. mainnet, testnet, etc)? IMO we’d have to make sure friendly forks are included in those exceptions somehow.

1 Like

Right, yet anyone who receives such a copy is entitled to the source and allowed to further distribute it. It’s not a notable restriction IMO, especially when AGPL will prevent frontend wrapping. The problem with AGPL is I’d have to double check its GPL compatibility, as AGPL has a much smaller market share.

Also, it needs to be public, not publicized. I can technically say I have some random FTP server for it which is publicly accessible and call it a day.

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.

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.

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?

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.

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.

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.

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”.

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.

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.

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.

11 Likes

This is very manipulative, just because you posted opinions of a few people saying they prefer Orchard would be MIT-licensed that does not make it “crystal clear that BOSL will undoubtely have a negative impact” on Zcash.

From the screenshots you yourself posted what seems clear is that those who voted are very evenly split, so it would probably be fairer (less manipulaitve?) to say “It’s clear that significant portions of the Zcash community oppose the use of BOSL, and also that significant portions of the Zcash community support Orchard to remain licensed as it is”

In my humble opinion, the judgement of ZEC holders on this matter should also be respected and taken seriously, and from both the polls and the comments from the “Allow special exception to the Orchard codebase for the Monero Project” it seems that a fair share of ZEC holders, the people funding the R&D, would not feel comfortable giving away the competitive advantage that Orchard brings to ZEC.

There is a shared perception among a number of zodlers that looking after their investment is not necessarily a priority, and that many times they are seen as little more than donors “to a mechanism for ZK research” by many of the people conducting the R&D these zodlers have been funding.

And exactly because of that @zooko, I also urge you to continue to listen to the community, and to keep on defending the interests of ZEC holders.

12 Likes

Dodger’s reply made me reconsider my stance on the matter as he raises a lot of interesting points, however I do still support BOSL. Consider the report I posted on the watchya readin’ thread (yes I know it’s a tangent but hear me out). It reads like it was written by people in the Zcash community (or just privacy activists) today but comes from half a century ago and is an excellent, if not extremely relative, case study in preventative measures that were either ignored or people at the time thought were too cumbersome. Had the opposite occured we would be living in very different world now.

Everyday I feel stronger about this issue…

I understand ECC’s intention to have this ammunition to be able to have leverage creating partnerships and other possible opportunities on behalf of Zcash Ecosystem, but I’m convinced this is not the right approach @zooko

Let’s go back to our crypto anarchists root, free open-source software for everyone. It has worked for projects that are currently reaching 1000x more users than Zcash, and it will continue to work. The revolution won’t be decentralised and it won’t be BSOL-licensed. Have faith in what we have been building for years and years.

ECC influence will continue to grow, and as we foster an open ecosystem so will the price of ZEC, and that will be the feedback loop that empowers the company even further.

I leave the discussion to more experienced people, but I pose the question to on: What is the difference of holding a bad license under the prerogative that you can do good for the ecosystem with it versus the government asking for our financial data because they might stop 2 dozens of bad guys?

2 Likes

Hello Dodger and everyone, the longer it takes me to write my replies to these complex topics, the more other stuff comes up in the threads and makes what I’ve drafted obsolete and makes me think I need to write much more stuff! So who knows if I’ll ever catch up, but I’m trying. Also, I just wrote a thread for the larger audience celebrating all the greatness that is NU5 (including the Bootstrap Open Source Licence). Please read!

I hope to follow-up to these threads here soon.

5 Likes