BOSL or MIT - Orchard

Looking at the big picture here, I want to point out a big red flag:

It’s nearly two years since the TGPPL/BOSL license was introduced to the Zcash community, and nearly a decade since an earlier version was published. (Edit: actually, more than 14 years.)

It’s been looked at by countless people, many of whom are cognizant in copyright law and open-source licenses. Many of us have been using and analyzing such licenses for decades.

Yet we still don’t understand what the license means. Looking at the above thread and related ones, I see ongoing confusion, misunderstandings and new realizations on fundamental questions of BOSL’s implications.

If ECC wishes to proceed with this license, I suggest they publish an FAQ answering these basic questions. A few examples, just from the last few of days:

  1. I’d like to launch a fork of the Zcash chain. Will I need anyone’s permission? (Of course, I’d like to keep the MIT-licensed parts under an MIT license.)
  2. I have an important bug fix to the Orchard code, and I published it under BOSL. Will ECC merge it? (Oh BTW, I’m on an offline vacation for the next couple of months.)
  3. I’d like to use Orchard code in my GPL project, which isn’t part of Zcash per se, but in my opinion it would help the Zcash community and ZEC. Can I? How does that work if ECC gets hit by a bus?
  4. Some third party company wants to use BOSL code in combination with their pre-existing proprietary closed codebase. They would consider releasing their codebase or paying for a private license, but they first want to do a small pilot and get feedback, before making any commitment about their codebase. Can they?
  5. How is BOSL substantially better than GPLv3, or AGPLv3, or dual licensing with either? Concrete scenarios, please.
11 Likes

This statement is so important if we are expecting Zcash to become a reserve internet money. Well said by @Dodger .

It’s one thing to experiment during R&D, testing, and for peripherals… but we need to remove “experiments” and testing in production (like BOSL) from Zcash strategy.

Many many folks who buy and hold Zcash do not see the live mainnet as an experiment… it’s literally their life savings and store of value. So, we should honor that and reduce risk by either avoiding things like BOSL or fully vetting the idea and getting widespread support first.

5 Likes

I’ve been thinking about the Contributor License Agreement angle and realized that beyond my initial reply, there’s a deeper problem here:

The BOSL world, as envisioned by ECC, is inherently fragmented into separate silios that cannot easily share code, even if they all use BOSL.

That’s because the purpose of BOSL is to incentivize external users to:

ask for an exception from ECC — where we can ask them to contribute something valuable back to the ZEC holders in order to get that exception

But ECC can only grant this exception if it has the requisite relicensing rights to all the pertinent code.
Crucially, these relicensing rights do not follow from BOSL! They follow only from having written the code in the first place, or having explicitly received them via a separate ad-hoc agreement:

Thus, effectively, ECC cannot incorporate BOSL code written by others unless it gets explicit permission from those others.

For example, if some competing coin forks Orchard and (therefore) chooses to license their improvements under BOSL, that’s OK because at least they’re giving back their improvements to the Zcash community, right? Wrong. ECC can’t merge those improvements into its own code, because that would break ECC’s ability to relicense the merged work (and thereby extract “value for ZEC holders” in the future).

Or, suppose someone publishes a cool BOSL-licensed Rust crate, and ECC wants to use it in its own BOSL-licensed code. Nope! That, too, would break ECC’s ability to relicense the merged work.

Well, ECC can politely ask those other parties to DocuSign a contributor agreement that grants relicensing rights to ECC, right? Maybe those parties happen to like ZEC, and have the money to pay lawyers to review that agreement. But if those other parties also buy into the narrative of value-extraction-from-public-goods-by-relicensing-rights, then they would be fools to give away their relicensing rights. If they do, ECC could eat their lunch, neutralizing their ability to extract value for their positive feedback loop.

So, anyone who believes BOSL’s narrative would be strongly disincentivized to intermingle BOSL code with anyone else who believes BOSL’s narrative — unless they are already strongly incentive-aligned and mutually-trusting (in which case what’s the point of convoluted licenses).

Consequentially, taken to its logical conclusion: the BOSL ecosystem becomes fragmented into separate incentive-locked BOSL licensing silos, that cannot share code, and each is controlled by a centralized legal entity that holds the relicensing rights and mandates a contributor agreement within that silo.

None of that is a problem with MIT, or with GPL as normally used, because neither relies on relicensing to work. Notably, in the past there have been attempts to use GPL-plus-offer-to-relicene to extract value via proprietary relicensing, in a similar spirit to BOSL’s motivation; but to my knowledge the vast majority of those attempts have failed, and either died off or found a different business model.

Am I missing something?

8 Likes

I think this was @nuttycom’s idea, probably.

3 Likes

AGPLv3 is GPLv3-compatible. I don’t personally recommend the use of AGPL (any version), and I don’t think it solves any problem we have here.

For previous discussion about AGPL (which is used by BDB, a dependency of zcashd), see zcash/zcash issue 1469. At the risk of oversimplifying an involved discussion, the licensing of this dependency was considered acceptable only because Oracle published a license exception that allows permissively licensed software to be linked with BDB.

3 Likes

I thoroughly agree with this argument, and have raised essentially the same point internally at ECC. I’d like to state publically (speaking only for myself) that I believe this is a really important argument for using a well-established, permissive license. In particular it was used to argue for the relicensing of the halo2 repo as MIT, and I don’t personally see why it shouldn’t apply equally to the orchard repo.

To clarify, my position is “MIT, or (BOSL/GPLv3 plus a broader exception that allows both permissionless forks and any Zcash-related use)”. If the non-MIT route is taken then I would also prefer that any fork exception not make a distinction between chain and code forks.

8 Likes

Agreed; I should be clear that I think the exception for Zcash-related use (including at least permissionless friendly forks) is a critical part of BOSL/GPLv3 licensing. MIT is “simpler”, but I continue to think that copyleft licensing is important for public goods.

One other point I’ll make: I think that @daira and @ebfull and @str4d and @therealyingtong’s opinions on what license to use for Orchard are more important than mine, because they’re the ones who wrote the code. I’m an interested bystander and acting as a community member in this discussion.

5 Likes

Keep it as BOSL , time gate it for 3y , In 3 years we can review again our stance.

4 Likes

Authorship isn’t just about writing code, it’s also about review, discussion, and design. Anyway, you’re credited as an author, Kris.

3 Likes

BOSL seems best.

Maybe also post preliminary license terms to make it clear the goal is to promote ZEC, and protect ZEC. After all, we are taking about money. So ZEC value proposition should be protected at all costs; and there should be proprietary tech that is shielded from outside interests.

Give guidance on license terms

  1. Small developers - very beneficial terms if not free
  2. Smaller enterprise
  3. Medium enterprise
  4. Large enterprise - case by case

other factors

  1. Complimentary products to zec - wallets; free
  2. Unrelated to money or banking
  3. Other coins - like monero pay fees if they want the tech.

Build a licensing fees structure(s) where the positive loop reverts back to ZEC (increases it’s value) which then means more funding to ECC to build more and better tech more people can use and so on….

3 Likes

It has already been established that there is no proprietary tech in Zcash: there are no patent restrictions, and everyone is free to reimplement the protocol. It’s clear that reimplementation incurs significant cost and risk, but it is important that it is possible. The possibility of doing so is not what this licensing discussion is about.

3 Likes

In my opinion, and from the perspective of protecting the people putting their time and money on the line. It’s a mistake to not have a least some critical proprietary code/tech. so if BOSL helps to protect ZEC tech, it’s the best route.

I would really love for crypto teams to reach out & ask that they want the Orchard repo in MIT licensed that BOSL doesn’t work for reasons XYZ. I would have said yes to Monero but contingent on them respecting Zcash & their community acceptance of using Orchard (which they had no plan, as they are focused on Bullet Proof +).

You arnt working for free are you? Do unto others means we do something for you and you do something for us. It all breaks down when you do something for free; they take what you did and resell it for themselves. it’s all solved with a fair and reasonable licensing fee.

No problem giving away for free with delayed or deferred fees to help people get started. But once they start making money they need to be contractually obligated to pay.

I’d like to note, from a technical perspective, that’s not how a lot of that works :stuck_out_tongue: But you are correct that Monero is not interested in Orchard. While Halo 2, already MIT licensed, has some level of academic value to Monero, they are focusing on circuits over Bulletproofs++.

1 Like

Bitcoin was given for free to the people. FOSS is for freedom, as is privacy, and I don’t see why the Zcash software should be anything but free. It’s hard to call BOSL free when it’s effectively the GPL when discussing FOSS, except it’s not actually dual licensed which prevents integration and restarts every legal discussion on the matter costing hundreds to thousands of dollars to even consider its status, which will likely simply result in it being ignored and unused. It’s an unnecessary hurdle thrown in to route people to the non-free path, and that’s just duplicitous.

2 Likes

May be it’s okay to take a different path & see how it works. One thing that is certain is change. Let’s get the real data & assess.

2 Likes

Doesn’t any developer who downloads Zcash and make any edit immediately subject their local copy and edits to BOSL? If for some reason it’s legally argued Apache 2.0 code, as currently in the codebase, cannot be successfully used with BOSL, every single developer who touches Zcash would be open to liability.

Also, as a developer who has a local copy and edits, whose work is no longer covered by the exception, if I ever publish my work, say, in a PR to Zcash… I first have to upload it to a repo establishing it’s BOSL at some point in the future no later than 12 months from the day of publication? I guess the PR itself is kinda submitting it to a repo? Except the work and license grant needs to be published “prior” and this is simultaneously?

And for the license, with each PR I make, I just need to attach “an irrevocable offer to license said copies to the public free of charge under this License,”? Isn’t it considered such offers must be an explicit statement by the party, as you can’t implicitly consider GPL-derivatives GPL? It’s how GPL violations occur in the first place? While I don’t assume the ECC would ever prosecute people behind these PRs, will the Zcash repo PR template be edited to automatically include this statement to ease the development process and ensure there’s no potential outstanding liability? If a submitter does not include it initially, yet corrects their PR to include one, will the ECC publish a statement renouncing any claim of liability despite the contributor having already broken the BOSL license in a publicly verifiable way (albeit, one without damages if corrected soon after, making it a waste of time for everyone if the ECC wanted to action on it)?

This is the plethora of legal questions which now threaten development, even to Zcash itself, making people and organizations unwilling to work with it, and not only will I no longer be interested in contributing to the Zcash ecosystem if BOSL hits mainnet, but I feel like it might even be legally inadvisable for any developer to contribute to any Zcash daemon at that point.

Zooko did say “So, I’m going to ask our lawyers how to craft a blanket exception which gives all users the necessary legal permissions to create their own Future Friendly Fork of the Zcash blockchain,”, which will likely mimic BSV’s own license, and that would void such issues for ZEC itself (but what about the regtest environment which is a brand new chain? what if it’s desirable to restart testnet?) along with friendly forks, yet this blanket exception isn’t in front of us and Zcashd had the BOSL license applied 5 days ago, making it already in this legal nightmare.

Beyond my existing question about what the community process Zooko claims exists (by saying we, the community, can change it) is, I would also like to ask does the ECC have any actionable plans to sell this technology for the benefit of Zcash, or does it know of any party planning to use Orchard, who wouldn’t be willing to simply BOSL their work (which we can’t even merge back because we’re not BOSL), the ECC considers notable enough to warrant this “experiment” applied to the entire protocol?

EDIT: This entire time I thought librustzcash was MIT by exception and that’d be enough for wallets and integrators. You cannot create Orchard shielded transactions through librustzcash AFAICT. You have to directly use the BOSL licensed orchard crate. That means every single wallet, exchange integration, L2… using Orchard will either be reliant on an ECC corporate exception or need to move to BOSL (which may not be possible for existing projects) even if they’re fine with the crates as-is used on the Zcash network. This will directly force most of the shielded ecosystem into this licensing hell which is not just limited to Zcashd itself and people forking it for their own protocols. That was my misunderstanding and this just makes it all the more problematic.

1 Like

I respect the opinions of everyone in the Zcash community, because they are all Zcash lovers.

Check out the voting results.

This is the answer from the Zcash community.

@AidenZ Was there some kind of campaign or call to action to get South Korean Zcash users to register and vote in this forum poll?

Between 19 hours ago and 8 hours ago, a few dozen new forum accounts have been registered, most of them from South Korean IP addresses.

Examples include @yoloi_jh, @yang_p1, @Alslll137, @Juwon, @parkkiho, @Banmandoga, @Inja, @Kwon, @moon, @mvnbebe, @donghyun, @497856, @moya, @Jeonglee, and @Bbojju.

@GiantZEC, @CryptoZEC, @Bitcoincash, @Kingzecs, and @EthKingzec all registered 19 hours ago, and logged in from the same IP address.

@zecdaya and @zeccodes both registered 11-12 hours ago, from the same IP address.

@sammks and @sammks2 registered 9 hours ago, from the same IP address.


ETA: It looks like the Korean Zcash community may have been motivated to join the forum and vote in the poll by a Twitter conversation.

Twitter conversation screenshot for context.

I guess a silver lining of the cloud that’s hanging over our community at the moment is that more people are being motivated to join and make their voice heard! :upside_down_face:

7 Likes