BOSL or MIT - Orchard

An unfamiliar account can also be a Zcash holder.

People are busy.

If you are not a Zcash holder, you will not join the Zcash community and will not vote.

1 Like

It’s undeniable voting multiple times is manipulation. I do not call the people who performed manipulation manipulators to suggest they’re not welcome. I call out that action to make it clear it’s unacceptable, or as you say, undesirable. It’s also potentially as high 1/6 of the votes cast, based solely on those who have already corrected their actions, and this is an important discussion for the community. I also did my best to be clear I appreciate a community sharing their voice, did my best to clarify where I draw lines and my views, and present the arguments thus far.

Yes, BOSL will make life harder for other projects. It will also make life harder for Zcash and prevent other groups from working on it. Independent developers immediately open themselves to liability. QEDIT, who’s doing ZSAs, had a developer say this will make it harder for corporations who likely won’t work with Zcash. hanh, who did ZWallet with Warp Sync, scanning 10,000 blocks a second on their phone, dropped out of Zcash development over this. I, who did shielded atomic swaps, offering private and absolutely secure trades to Zcash holders, will not developer for Zcash anymore thanks to this. Developers at the ECC itself, the organization under Zooko, have publicly stated they disagree with this when they have the most to gain from ZEC going up.

It’s ridiculous to see this painted as forkers trying to take advantage, and it’s ridiculous to to see this subtly painted as anti-Korean sentiment (“They are our new friends, not manipulator”, referring to new accounts on this forum from the Korean community) when I called out the ones who explicitly did manipulate and it’s therefore anti-made-multiple-accounts-to-manipulate-an-unverifiable-poll sentiment (when I’ve even clarified I’m fine with those people staying around and being community members if they no longer manipulate, and since we’ve lost a notable amount of votes… we both had at least a notable amount of manipulation and had a notable amount of honesty which means we now have a notable amount of honest community members ready to put their best foot forward, beyond the members who were honest from the start with the poll).

2 Likes

If Zooko chooses to give the ultimate decision of changing the license to the community, I see 2 routes to resolve this.

  1. Poll ZCAP.

or if the community, or Zooko, or ECC or ZF think ZCAP is not representative,

  1. Reform, and then poll ZCAP.

Having a poll here or selectively quoting tweets or posts is not a good way to poll legitimately the community, Sentiment yes. To make a decision on seemingly such a contentious issue, I dont think so.

Seems to me that Zooko and ECC dont need the talk to the community anything about the license. Its already been discussed and decided a long time ago. This whole debate started with a troll post from a monero influencer, and spiralled out of control.

As it stands now, The licensing isnt going to change.

We can always have theoretical and philosophical discussions about which license would have been a better. The pros and cons of MIT, BOSL, GPL. But the actual license will not change…

Perhaps we should move on…

4 Likes

Ultimately isnt the best way for community decisions staking zec coins? something like below

For major decisions

  1. greater than 50% in number and
  2. greater than 2/3 in value

For non major

  1. greater than 50 % in number
1 Like
  1. Zcash believes that developers/miners/holders/buyers should benefit first
  2. It should help to expand the blockchain ecosystem, but number 1 should be the first priority
  3. Zcash developers/miners/holders/buyers are not charities
2 Likes

It’s complicated. I am not a lawyer and what follows is not legal advice; also I am not speaking for ECC.

The requirement to provide source code licensed under BOSL (and therefore freely usable after 12 months) imposed by clause 1.c of the BOSL license only applies to “distribution or communication” of the derived work. Copyright licenses in general cannot place any restrictions on modification for private use. [Edit: @tromer disputed this and I am no longer sure about it. Note that if this is not true then we have an additional problem, because clause 1.c only grants a (conditional) right of distribution “to the public”, i.e. it assumes that granting a right of distribution other than “to the public” is unnecessary.]

But we can adjust your question to be about the case where zcashd is modified and then redistributed. I believe this analysis also applies to the case where Zebra (or some work based on both zcashd and Zebra) is modified and then redistributed.

Clause 1.c is the only “viral” part of the BOSL license — using “viral” as a technical term in which a copyright license imposes some requirement for its own application (fully or partly) to a derived work. Specifically, it requires you to make an irrevocable offer to license copies of the original and derived source code “to the public free of charge” under BOSL 12 months after the first distribution of the derived work.

This clause does not preclude you from also “distributing or communicating” copies of the derived source code under some other license than BOSL. That is, my interpretation is that you could distribute your derived work of zcashd under a dual MIT/BOSL (or triple MIT/Apache2.0/BOSL) license. This is because clause 1.c only restricts the sublicensing of “said copies”, that is, the source code of the original and derived works that you are obligated to make available under that section. These are not the same as the copies of the derived work that you are originally “distributing or communicating to the public”, which may be under any license compatible with zcashd’s current licensing (per component, i.e. the parts that are currently under MIT may be distributed as MIT, etc.).

That still leaves a critical problem: you can distribute your derived work under any compatible license for each component, but (if you did not relicense the derived work of zcashd/Zebra as BOSL) the only right you have to use the orchard crate that is linked with zcashd/Zebra is via the orchard license exception.

However, once a copy of the zcashd or Zebra source is edited, it ceases to be one of “The Zcash projects published by the Electric Coin Company” or “The Zebra project published by the Zcash Foundation” as described in that exception. And so you cannot use it, without relicensing as BOSL.

This appears to be a bug and not the intended effect. I will repeat here my dismay at the fact that the text of BOSL never went through a technical review by ECC engineers. (I did ask for such a review. I don’t remember the exact response from ECC management, but I was effectively told to leave it to the lawyers. I was skeptical — but at the end of the day, license review is not in our job descriptions, even though I am competent to do it and it would clearly have helped in this situation.)

Note that if the orchard crate were under other copyleft licensing, including GPLv3 or dual BOSL/GPLv3, then a similar argument (different in the detail, but with a similar conclusion) would apply. That is, a widening of the exceptions would solve it in the cases covered by that widening, but dual-licensing orchard as BOSL/GPLv3 by itself would not.

I note, however, that Zooko has already committed ECC (by my reading; still not speaking for either ECC or Zooko) to widening the orchard crate license exceptions to other projects that “support Zcash” and to any Zcash chain fork:

So this may be a somewhat temporary problem, modulo potential arguments about the scope of the widening, although it underlines the necessity of making those changes.

Widening the exceptions plus relicensing the orchard crate as BOSL/GPLv3 still prevents non-BOSL, non-GPLv3 projects using that crate from being open source, because they would not satisfy clauses 6 and/or 8 of the Open Source Definition (they can be open source if they relicense either as fully BOSL, assuming that is compatible with Apache 2.0, or as fully GPLv3):

  1. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

  1. License Must Not Be Specific to a Product

The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

“Field of endeavour” would clearly include the requirements that a project “support Zcash (ZEC)” or be a chain fork of Zcash.

I believe clauses 6 and 8 of the OSD are important, and that is partly why my preference is for the orchard crate to be licensed simply as MIT/Apache 2.0.

5 Likes

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.

8 Likes

An academic aside:

Crazily enough, it can. Without a license, any duplication of the work is infringement. Even just loading it into RAM or rendering it on-screen. Though you’re more likely to be able to argue fair use (and perhaps an implied license).

But yeah, BOSL talks only about public distribution (broadly construed).

This clause does not preclude you from also “distributing or communicating” copies of the derived source code under some other license than BOSL. That is, my interpretation is that you could distribute your derived work of zcashd under a dual MIT/BOSL (or triple MIT/Apache2.0/BOSL) license. [T]he copies of the derived work that you are originally “distributing or communicating to the public” […] may be under any license compatible with zcashd’s current licensing (per component, i.e. the parts that are currently under MIT may be distributed as MIT, etc.).

Hmm, my reading was different. The initial distribution of the derivative work is permitted, but no permission is given to license it. You’re just allowed to give it to other people. Those other people would be able to run it because they have ECC’s BOSL permissions to use ECC’s work (including this derivation thereof), and also your permissions to use your work (if you grant ppthat).

But you cannot just say, “this joint work is licensed under dual MIT/BOSL” (even if remember to BOSL it 12 mopnths later). That would be a misrepresentation, and probably a contributory copyright infringement. If the downstream recipient believes you, they could just treat the derivative work as if it were MIT-licensed (choosing to ignore the BOSL alternative), act accordingly, and thereby violate ECC’s BOSL license — infringing on ECC’s copyright.

Put otherwise, doing the initial distribution of the derivative work under dual MIT/BOSL is akin to saying “here’s an public-domain copy of Harry Potter with my illustrations”.

It’s unfortunate that BOSL doesn’t explicitly say anything about the license of that initial distribution.

I think it’s important not to just look at the BOSL in terms of what ECC might do. As far as I’m aware anyone has the ability to prosecute.

1 Like

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.

I disagree. If you license the derived work under MIT/BOSL, then you’ve satisfied clause 1.c, because its source code is available under BOSL immediately. (Technically, you also have to make the original source available, but in the situation we’re discussing it already will be.)

What you haven’t done is provide the sublicensee with the ability to use the orchard crate that is linked with your derived work.

It is not the case that BOSL placed a restriction on your distribution of either the BOSL source code or the non-BOSL code linked with it. On the contrary, the BOSL license insisted on it! 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. You cannot redistribute any part of the work with a license incompatible with the original one for that part, but BOSL has no equivalent to GPLv3 clauses 5 b) and 5 c) (“This License gives no permission to license the work in any other way …”).

No, because you can’t distribute the orchard crate under MIT, and by assumption, your derived work depends on the orchard crate. (We have an issue open to explicitly say in dependent projects of the orchard crate that they are relying on the zcashd license exception: Projects that rely on BOSL exceptions should say that they do · Issue #5931 · zcash/zcash · GitHub .)

If you were to remove the dependency on orchard, then you could run it.

1 Like

@daira this is an important point. What allows the contributors to allow GPLv2 code to upgrade to GPLv3? Would BOSL allow all contributors to permissions an upgrade to a BOSLv2?

EDIT: I think I misread your reply. I assume there are no issues there.

BOSL 1.0 itself does not, but the licensing for the orchard crate is “You may use this package under the Bootstrap Open Source Licence, version 1.0, or at your option, any later version.”.

Oh okay. So something that should be fixed in the license? Oh no it shouldn’t be I guess as it’s up to the licensee to decide that.

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.

2 Likes

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)

5 Likes

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.

1 Like

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

1 Like

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.

1 Like

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

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.