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.
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.
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?
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.
Wouldn’t the payment be made if they delivered the work. Are they going to pay back if they depart? I haven’t seen post from hanh about any “departure”
We can save a lot of time, if we can have a live session on this topic.
You’re saying Dodger’s post isn’t representative of the community, while then saying your commentary is representative of the community.
The obvious solution is simply to do an official Helios poll to ZCAP on how Orchard should be licensed, potentially as a wider discussion on ZIP-1014. Unfortunately, no one with authority seems to acknowledge it as an option yet, despite @zooko continuously saying it’d need a community decision/is for the community, and that being the official way to get advice from the community on the future of ZCAP. To be clear, ZFND does oversee the ZCAP, yet in order for such a poll to matter, the ECC would have to agree to follow it’s decision here.
I’d personally like to see 1/2 questions, one for Orchard specifically of:
Preferably as ranked choice.
Then for ZIP 1014, there’s a few different proposed wordings I’d want to include, with the acknowledgement that the changing of ZIP 1014 in a way incompatible with Orchard would either require the ECC to relicense it, regardless of the poll, OR it’d be prevented from deployment to the Zcash network (as the ZCAP officially modified a ZIP to reject such contributions, and any project including it would be an offshoot not acknowledging the ZIP process).
As far as I’m concerned, while this would be appreciated, it’s unlikely to produce results. We need a definitive way to end this conversation so it’s not just:
mad at ECC with no progress being made and no inroads occuring. While I think this would be good if it was prior to a ZCAP poll, to present all aspects and discuss the wording used, that would be it.
As for hanh’s contributions, I believe the comment is they built and completed a BTCPay integration. The end. Now, since they wouldn’t be working with Zcash if it relies on BOSL, it won’t have anyone maintaining it. Therefore, the BTCPay integration would be deprecated as it’s not updated. That’s the wasteful part.
Well, I mean, I’m just hopeful that it’ll pan out, like I said. We — the Zcash community — can always change our minds.
Apologies if I misunderstood what you meant.
I never said that. Putting words in other people’s mouths to try to force a point just shows the weakeness of your argument in the first place. It is also manipulative and lame.
You seem to (conveniently) have forgotten the most important stakeholders, the ones who paid for the research and development for Orchard: ZEC holders
Many of whom have already voiced on previous threads their support for BOSL as the type of licensing that will best reward them for their investments, and most of whom HAVE NEVER AND WILL NEVER vote on any ZCAP polls for a number of logistical reasons.
ZCAP polls, overseen by the Zcash Foundation (and for whom ZEC holders seem to be an afterthought at best ) are not really representative of most of the people holding ZEC, but of Zcash insiders.
This lack of interest in ZEC holders is mindblowing, and seems to be a recurring pattern with many here.
Luckily we have @zooko and ECC trying to protect their interests.
@Chammy Do you have an issue that all other ZEC holder funded and ECC developed code is MIT? Would you want everything that ECC has ever written until now to be changed into BOSL? Do you think that HALO is bigger deal than Orchard (which is spcific to Zcash)? Why do you not object to HALO (and all other ECC) code being MIT? What is it about Zcash Orchard licensing that you feel, here specifically, ZEC holders interests are being ignored and sidelined?
Lemme know your thoughts. Thanks
Do you know of the concept of “complex question fallacy”?, because that’s what you’re doing here, and I am not going to engage with that.
What I will say is that as much as I love FLOSS, Orchard is a particular case because of the extraordinary competitive advantage it gives ZEC as an electronic Medium of Exchange, and that that competitive advantage just should not be given away to competing projects.
Orchard is a game changer and ZEC needs, and deserves, to capitalise on it.
HALO is a game changer. Its groundbreaking cryptography. While Orchard is only Zcash specific. Having HALO MIT and having Orchard, something nearly every other project wont use, BOSL doesnt make sense at all, IMO.
Also, BOSL doesnt prevent forks… I dont see it giving ZEC any competitive advantage…
To keep this discussion constructive can we all stop the “you do/don’t support Zcash holder/investor” argument. Also we should refrain debating and comparing the value of ECC and ZFs contributions. That’s not the point of this discussion. I think we can safely assume almost everyone that’s contributed to this conversation is holding ZEC. I also believe everyone working on Zcash has the ultimate goal of having more ZEC holders and users in the future. Simply put the more holders and users we have, the greater the chances ZEC goes up in price and investors see positive returns. I think we all ultimately want the same thing.
I hate oversimplifying thing but I really want to keep this conversation on topic so let us try and debate the main points. I currently am going to oversimplify the two camps that exist. I’m not trying to put words in people’s mouths, I’m simply trying to establish that both parties have good arguments and evidence to support their beliefs and we need to stop getting angry or emotional about it. I may get some points wrong but let’s start with something.
MIT SUPPORTERS - Those that look at Bitcoin and other examples where the code has been MIT licensed, and think there is some pretty solid evidence that MIT works for cryptocurrencies. Why would we want to risk experimenting with another license? The BOSL license hasn’t been tested so at this point in time we can only speculate if the pros outweigh the cons. Some MIT supporters believe the cons of BOSL outweigh the pros. Others MIT supporters aren’t sure if BOSL pros outweigh the cons but think the risk of experimenting with a BOSL license is too high.
BOSL SUPPORTERS - Those that look at the Zcash adoption and price over the past few years and cant see the effort, work, and value of Zcash reflected in the ZEC price. They think that at least some of this is attributed to Zcash/ECC not capitalising on the value/product that it has produced. One way to try and capitalise on that value is for ECC to more aggressive in using their copyright to the code to negotiating deals that provide value to Zcash. We can also see that ECC has been able to achieve some remarkable deals that not only bring in funds that ECC can use for future development on Zcash, but also establishing a large grant program that we hope can provide value to Zcash.
I think the two camps are more similar then people think. Both MIT and BOSL supporters both seem to be advocating that we can’t do this on our own. MIT supporters advocate that through open licenses we can encourage a wider variety of participant. BOSL supporters advocate that a BOSL license will allow ECC to better advocate for “ZEC holders” by entering negotiations with interested parties.
“This is very manipulative, just because you posted opinions of a few people”
“I also urge you to continue to listen to the community”
@Chammy You attacked Dodger for using an unrepresentative subset and then immediately proceeded to claim the community actually wants something else, despite it being a distinct subset of the community who’s in favor of this. That subset may be the majority, yet the forums are against the current status and we don’t have any official polls which I’m advocating for. I don’t see how I was arguing in bad faith (or being manipulative) but I’m sorry you feel that way.
@zooko “We — the Zcash community — can always change our minds.”
I, a member of the Zcash community, who has seen many people agree licensing should be changed in some fashion, with community polls on this very forum advocating for MIT over BOSL, am explicitly asking to change the mind that you set without any community process. Will you, or will you not, acknowledge a process by which the community decides how to handle licensing, preferably the established ZCAP in my opinion? This has not been a community decision thus far, solely a decision you’ve made with the other ECC higher ups (despite multiple ECC developers disagreeing) backed by certain members of the community.
I don’t care to hear it presented as a community decision when it hasn’t been thus far and you haven’t acknowledged any ways for the community to actually decide. Despite the forums leaning MIT, unverifiably as previously stated, you put out a tweet and got supporters there (when your followers are people who wanted to follow you, whereas people on these forums are people who wanted to discuss Zcash), and have used that to suggest this is community backed when that’s just as unverifiable and wasn’t participated in by the Zcash community, yet rather your community, who likely have bias accordingly.
EDIT: Sorry for these pair of posts replying to completely different messages. I replied to the email in my inbox and didn’t realize replying to the thread as a whole would reply to specific posts in it (the most recent one).
Hi @zooko another important question.
I have a fear that a friendly fork could embrace the BOSL license. Many community members contribute to an experiment in the fork with smart contracts and gets it right! Tons of adoption! Great! Unfortunately for Zcash one of the contributors has some irrational hatred towards Zcash and refuses to negotiate licensing terms for the code (or holds ECC to ransom for a ton of money). Now ECC has 3 choices:
Pretty tricky IMO. And if we do decide to lose copyright to the whole codebase does that leave us in a worse situation then today?
Edit: I understand under MIT anyone can relicense the code but many forks choose to continue using the license the original repo used.
