BOSL or MIT - Orchard

[tromer]

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:

@str4d

ECC requires a Contributor License Agreement to be signed for contributions to the orchard crate, which ensures it retains the ability to relicense if necessary. See here for the text (from the zcash/halo2 repo which had the file checked in, but the actual agreements are done via something like DocuSign).

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?

[daira]

@secparam

I think this is probably the best case for @daira’s excellent idea to just dual license under GPL and BOSL.

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

[daira]

@kayabaNerve

The problem with AGPL is I’d have to double check its GPL compatibility, as AGPL has a much smaller market share.

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.

[daira]

@PabloK

My main argument is: More eyes on the code → more security.

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.

@kayabaNerve

Daira: MIT, or at least BOSL/GPLv3

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.

[nuttycom]

@daira

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.

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.

[gus]

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

[daira]

@nuttycom

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.

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

[Jgx7]

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

[daira]

@Jgx7

So ZEC value proposition should be protected at all costs; and there should be proprietary tech that is shielded from outside interests.

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.

[Jgx7]

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.

[dontbeevil]

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

[Jgx7]

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.

[kayabaNerve]

I’d like to note, from a technical perspective, that’s not how a lot of that works 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++.

[kayabaNerve]

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.

[dontbeevil]

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.

[kayabaNerve]

@daira

(It is unclear to me, legally, whether another option would be to relicense all of the zcashd or zebra code as BOSL. The MIT license allows relicensing, but some of the dependencies are Apache 2.0-only; see the contrib/debian/copyright file for details. Is it possible to link Apache 2.0 code with BOSL code without permission from the Apache code’s copyright holders? I don’t know. Note that the scope of the license exception is significantly narrower than I was originally led to believe it would be, otherwise I would have kicked up a bigger fuss about this at an earlier stage. The only other project using a TGPPL-derived license, Tahoe-LAFS, had a bunch of license exceptions allowing linking with any code using a wide range of open-source licenses, but zcashd doesn’t have that. Note that dual-licensing the orchard crate as BOSL/GPLv3, as suggested by @nuttycom and as I’ve previously indicated support for, would resolve this question since there is a well-established social consensus that each of the licenses used by dependencies of zcashd is compatible with GPLv3. I would still prefer MIT though.)

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.

[AidenZ]

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.

[Dodger]

@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!

[tromer]

@daira

It’s clear that reimplementation incurs significant cost and risk, but it is important that it is possible.

Coming to think of it… I don’t think it’s possible to create an interoperable reimplementation of Orchard without violating its copyright. While the ideas of Orchard are well-documented, the specific expression as a constraint system is protected by the BOSL copyright. And that expression is necessary for creating a new compatible implementation, whether of the tx generation or of tx verification.

Sure, given the docs and specs, it’s possible to create a clean-room reimplementation of the high-level protocol. With enough effort, it will have similar performance. But it won’t be wire-compatible with Orchard, because of course some of the (numerous) implementation choices in the constraint system will happen to be different.

… unless the engineer doing the reimplementation looks at the Orchard constraint-system code, and basically copies all its structure, choices and idiosyncracies. Which would take them deep into derivative-work copyright-violation land.

(They could argue that it’s fair use because they had to do that for interoperability. Well good luck. The recent Google vs. Oracle lawsuit, which entailed a similar question, took 12 years, untold millions of USD of legal expenses, and the US Supreme Court, to decide.)

Therefore: it is effectively impermissible, no matter the implementation cost, to verify or generate Orchard transaction using your own code — unless you get permission from ECC or BOSL-license your whole codebase.

Curiously, this is a problem only for people who want to interoperate with Zcash. Someone who launches their own chain or whatever, and doesn’t care about Zcash tx compatibility, can reimplement Orchard from its docs and specs — no copyright problem there.

[kayabaNerve]

I was concerned about this. I was personally thinking about projects like Dolphin, where very specific hardware and software was recreated… yet only based on blinded sum product testing which isn’t feasible with Orchard (as I’m pretty sure it tries to make all its values look random. Something about being a privacy protocol?) and so on. Won’t another Orchard implementation fail if the order of a single constraint is swapped? Meaning it has to line for line implement every check the same way?

And if you’re line for line implementing things, and you can’t change the underlying math underneath… maybe you can change function boundaries? ECC Orchard used one 100 line function and we did 2 50 line functions! They use a 4 space indent and I preferred 2! But the fact the Orchard spec doesn’t have the needed information means unless someone wants to argue they can legally gdb Orchard to the point needed, there is no clean room implementation possible, which is all the ECC needs to argue a case which is all that’s needed to prevent any developer from spending the year attempting this.

Edit for clarity: The privacy protocol bit was a joke meant to emphasize the differences between a clean room implementation of a video game console, itself a complex effort taking years while being a legal minefield, which has an opcode for add which very clearly loads two registers and produces a sum, and an opcode for if which will change the active code instruction based on some flag… to SNARKS where every variable is a Pedersen commitment to itself and the blinding factor, hiding the variable and how it flows, and logic is… SNARKS. SNARK magic.