BOSL or MIT - Orchard

[daira]

@GGuy

Oh okay. So something that should be fixed in the license?

Well, GPLv2 doesn’t automatically have an clause allowing use of a later version, yet “GPLv2 or, at your option, any later version” licensing is common.

I’m spending way too much time on this stuff and I’m going to stop for at least today.

[secparam]

Hi @Daira. this thread is getting long and it has three different things in it

1. a philosophical debate about MIT vs GPL/BOSL and which is better at getting the most work given back

2. a debate about if wallet devs will use BOSL/ BOSL is a blocker/ BOSL gets us trolled

3. A very important technical discussion of WTF BOSL does and all the problems it may raise, no matter your position on the above, as part of a software project with downstream stuff, licenses and forks.

You’ve done an amazing job pointing out all the bits with the third one, technical issues with BOSL. but its interspersed in a bunch of sock puppets entering the debate. Could we break off the “technical problems of BOSL as a license for our code” into a separate thread with a starting summary? (or Github issues, but this maybe needs broader community visibility)

[tromer]

@daira

They don’t have permission to run the derived work unless the derived work is one of “The Zcash projects published by Electric Coin Company” or “The Zebra project published by the Zcash Foundation”. So unless you ask ECC or ZF to publish it for you (which would apply if you’re making a PR to upstream), they can’t legally run it.

Oh my, you’re right, there’s no explicit permission to use the derivative work! It is plausibly implied by clause 1.b:

b. to translate, adapt, alter, transform, modify, or arrange the
Original Work, thereby creating derivative works (“Derivative Works”)
based upon the Original Work;

though taken literally, this would require the modifications to be distributed as patches on top of the Original Work.

This is bad.

To be sure, it insisted on it being “freely available to the public” under the BOSL license (at least), but nowhere does it say that this must be an exclusive license.
[…]
No, because you can’t distribute the orchard crate under MIT, and by assumption,

I’m losing you somewhere…

Are you saying I can take the orchard crate (whether with our without my own modifications to it) and distribute it under dual BOSL/MIT?

That means I’m saying “Hey, downstream recipient, you’re allowed to use this version of orchard under MIT or BOSL as you prefer.” But we agree that’s false — they not allowed to use orchard under MIT.

[moya]

It’s a Korean community A number of people shared their opinions this morning and just voted.

[GiantZEC]

You shouldn’t vote this way in the first place. Make sure that only ZEC holders participate in voting. I tested this vote yesterday. There was a duplicate vote by multiple emails. A few minutes after I voted twice, the number of votes for MIT again increased. Have any of those who voted for MIT voted twice? Can I disclose the personal information of the people who voted in this trashy way? I’m really speechless.

[daira]

Can we ban people who have admitted to multiple voting using sockpuppet accounts, please?

[daira]

@tromer

Are you saying I can take the orchard crate (whether with our without my own modifications to it) and distribute it under dual BOSL/MIT?

No. I’m saying that nothing prevents you from redistributing your derived work with each component under a license compatible with its original license. This is because the BOSL license requires free distribution of the original and derived source under clause 1.c, but does not say that this must be only under the BOSL license. That is, as long as you have satisfied clause 1.c (with any copies of the original and derived source), you can rely on your right to redistribute granted by (e.g.) the MIT license for components originally under MIT.

Your example is not allowed because you cannot change the licensing of the orchard crate from BOSL to MIT (or to dual MIT/BOSL), as MIT is not compatible with BOSL [*] and you are not the copyright holder for that code. This is why a user of your derived zcashd or Zebra work would encounter problems only if they try to use the work in a way that relies on it being linked with orchard (without the license exceptions being applicable). Simply aggregating the source files is okay.

[*] License compatibility is not a symmetric relation. “A is compatible with B” means that A imposes at least all of the requirements of B.

[Chammy]

@secparam

a bunch of sock puppets entering the debate

Just another example of how ZF-managed forums are not allowed to be representative of the interests of the wider Zcash community, aka, ZEC holders.

Zodlers tend to be perceived as little more than “sock puppets entering the debate” when they express their opinions here.

This is unacceptable.

[secparam]

This was the sock puppetry allegation I was referring to. To be clear most of the voices here are legitimate, just there’s also some spam that gets in the way of reading the debate.

@daira

Well spotted!

Sock-puppetry is a violation of, at least, the “Etiquette” section of the forum code of conduct (“Please do not … Create and use multiple accounts as sockpuppets.”). While it’s technically possible that these users are logging in from the same IP because they represent different people from the same household or the same ISP that is sharing external IPs, the coincidences of usernames and registration times make it more likely that they are sockpuppets. This is especially problematic if the purpose of the sockpuppetry was to vote multiple times in a forum poll. I would recommend banning or otherwise sanctioning all of these users.

[tromer]

@daira

No. I’m saying that nothing prevents you from redistributing your derived work with each component under a license compatible with its original license. This is because the BOSL license requires free distribution of the original and derived source under clause 1.c, but does not say that this must be only under the BOSL license.

Ah, I think I see where’s the misunderstanding. I was thinking of the case where the derivative work is itself a modified version of the orchard crate, in which case I think we agree I can’t distribute the derivative work (which includes the original orchard code!) under dual BOSL/MIT.

Conversely, in the case where the derivative work is (say) a program that uses the orchard crate as a black box… it’s messier. I think it’s OK to license the program code per se (without orchard) under dual BOSL/MIT, as you say. But a case could also be made that because the program code itself contains copyrighted expressive elements of orchard (e.g., function names), distributing that program code even without orchard would infringe on the orchard copyrights. And then a case can be made that nonetheless, that infringement is permissible as fair use. Fun stuff.

Edit: By “distributing that program code”, I mean distributing it under a dual BOSL/MIT license, thereby creating a false representation that would induce others to further distribute the code under just MIT, which would then be an infringement of the BOSL copyright — as discussed above.

[daira]

@tromer

Ah, I think I see where’s the misunderstanding. I was thinking of the case where the derivative work is itself a modified version of the orchard crate, in which case I think we agree I can’t distribute the derivative work (which includes the original orchard code!) under dual BOSL/MIT.

We still subtly disagree.

BOSL doesn’t have any provision like LGPLv3 clause 2 that restricts how combined works can be “conveyed”. (In the case of LGPL, this is quite complex and I don’t want to get bogged down in the detail, but one of the options when you modify an LGPL-licensed library is to relicense the whole work as GPL, and the other is to make “a good faith effort” for the library to still work on its own without the application. But to reiterate, BOSL has nothing like this.)

Let’s assume for simplicity that you have a pure MIT codebase that links with orchard [*]. Because nothing in BOSL requires relicensing (except of the copies under clause 1.c which could be distributed entirely separately) you are free to rely on the right that MIT gives you to distribute the MIT-licensed code. The fact that it links to BOSL code, or that you’re also distributing BOSL-licensed source alongside it, doesn’t affect your right to do so under MIT.

In order to use the result, you would be running both MIT-licensed and BOSL-licensed code, and the BOSL license doesn’t grant you a right to do so unless the whole derived work is under BOSL or you rely on an exception (which you can’t, if your project isn’t one of “The Zcash projects published by Electric Coin Company” or “The Zebra project published by the Zcash Foundation”).

@tromer

[…] because the program code itself contains copyrighted expressive elements of orchard (e.g., function names) […]

I believe that isn’t copyrightable. I know that it isn’t in the EU or the UK, because that would conflict with the interoperability provisions of EU copyright law, specifically clauses 10 and 11 of Directive 2009/24/EC. (UK copyright law was changed to follow this directive when the UK was in the EU, and the Tories haven’t had chance to ruin it yet after Brexit.)

[*] Zcashd actually has a bunch of dependencies under a range of funky licenses, from AGPL to WTFPL. They should all be documented in contrib/debian/copyright. We believe that none of those (including BOSL, and including AGPL for a specific reason depending on a statement that Oracle made about the licensing of Berkeley DB), prevent us from licensing the main codebase as MIT.

[tromer]

@daira

Let’s assume for simplicity that you have a pure MIT codebase that links with orchard [*]. Because nothing in BOSL requires relicensing, you are free to rely on the right that MIT gives you to distribute the MIT-licensed code. The fact that it links to BOSL code doesn’t affect your right to do so under MIT.

I almost agree. As argued above, this isn’t straightforward — you’d still need to invoke the fair use doctrine to absolve the fact that the MIT codebase copied things like function names from orchard. Practically speaking, this may be sufficiently well-established, especially after Google vs. Oracle. Though a good license would make this explicit, one way or another (e.g., GPL vs. LPGL).

In order to use the result, you would be running both MIT-licensed and BOSL-licensed code, and the BOSL license doesn’t grant you a right to do so unless the whole derived work is under BOSL or you rely on an exception (which you can’t, if your project isn’t one of “The Zcash projects published by Electric Coin Company” or “The Zebra project published by the Zcash Foundation”).

Yes, I agree that the usage-right limitation is very bad.

[daira]

@tromer

you’d still need to invoke the fair use doctrine to absolve the fact that MIT codebase copied things like function names from orchard . Practically speaking, this may be sufficiently well-established, especially after Google vs. Oracle.

We were already relying on this before BOSL (for example, for the function names that zcashd uses to call into Berkeley DB, which is AGPL-licensed, and for the macro names of the m4 macros listed here). I think it’s very well established. Note that Bitcoin Core and all other mainly-MIT-licensed Bitcoin forks also rely on this.

Though a good license would make this explicit, one way or another (e.g., GPL vs. LPGL).

Again I wish we would just relicense everything as MIT (MIT/Apache 2.0 for Rust code). I hope that the complexities discussed on this thread indicate why I would wish that.

[Allen]

So it appears the community prefers keeping BOSL per the unscientific poll and from what I’ve read from other Zodlers on twitter. My guess is most of the whole community, not just those in the poll, support BOSL by a wide margin. I’m pretty sure BOSL will not destroy Zcash. Let’s move on. May 31st can’t get here soon enough!

[Dodger]

It’s now a week since this post, in which I raised a number of important questions about BOSL (in some cases, re-raising them, as they remained unanswered from my previous post, nearly two weeks ago).

At this point, I fear that it’s inevitable that the Zcash ecosystem will suffer damage as a result of BOSL. @adityapk00 cited BOSL as an issue in his post about the Future of Zecwallet, and it appears that @kayabaNerve and @hanh will no longer work on supporting Zcash.

[Zzzzzz]

@adityapk00 had indicated he wouldn’t be continuing dev work on Zecwallet some time ago. It should be for ZF or any teams interested in maintaining Zecwallet to determine if there are any issues caused by BOSL.
I believe @hanh had already decided to work on his own project, a mix of Filecoin, ZEC & XMR tech before the BOSL discussions. From what I understand he was put out by his grants being rejected by ZCG.
@kayabaNerve came into the community and ran unsuccessfully for the ZCG, I believe this was partly due to voters opting for candidates they felt would be more committed to ZEC. IMO while @kayabaNerve was interested in ZEC I believe(without substantiation) that his main priority/loyalty was for the Monero community. I will say that he did seem genuinely Interested in the Zec tech.

I don’t think these 3 should be highlighted as examples of people exiting the Zec community due to BOSL.

2 seemed to leave for other reasons, the 3rd may have had other reasons for leaving in additional to his FOSS ideological alignment

[tloriato]

@Dodger

It’s now a week since this post, in which I raised a number of important questions about BOSL (in some cases, re-raising them, as they remained unanswered from my previous post, nearly two weeks ago).

At this point, I fear that it’s inevitable that the Zcash ecosystem will suffer damage as a result of BOSL. @adityapk00 cited BOSL as an issue in his post about the Future of Zecwallet , and it appears that @kayabaNerve and @hanh will no longer work on supporting Zcash.

Who from ECC can answer about this? @zooko @joshs

[joshs]

Hi. Which question?

We’ve been working with third party Zcash supporters and an attorney to address concerns. We’ll have a post out today that summarizes new general exclusions.

[edit] it may be another 24 hrs before we’ll have this out

[Dodger]

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

@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

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?

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

[joshs]

I suggest reading what comes out today and then re-asking relevant questions. I think it will address much of this.