This is a Monero free discussion. If we discuss Monero in this thread I’m sure it’ll be closed. The intent of this poll is to gauge the support of using MIT again. It’s normal to revisit past decisions and even change our mind. My hope is the poll is overwhelming one sided and we can squash this discussion quickly 
.
0 voters
Doesn’t the BOSL convert to MIT at some point? I think the question some may have is why use the BOSL?
I’m sure ECC had reasons for using it but as a person who knows little of software licensing I would like a better understanding of it.
I won’t try and speak for ECC but here is the blog post introducing the license.
Thank you!
(Disclaimer: I am not a copyright lawyer.)
No. BOSL is basically equivalent to GPL, except for one specific difference (that makes it mutually incompatible with GPL unless specific exceptions are present): Derivative Works (i.e. code that incorporates, extends, or changes any BOSL-licensed code) may be licensed as non-BOSL for up to 12 months from first being used publicly, after which they become BOSL-licensed.
Put another way:
So if you’re comfortable with using GPL-licensed code in your projects, then BOSL can be used basically equivalently (by just ignoring the 12-month timer and immediately licensing your Derivative Work as BOSL). But BOSL can’t be used equivalently to MIT (or automatically convert to MIT after some time), because BOSL has the same kind of virality as GPL (more slowly, but still there), whereas MIT does not.
Thank you for the clarification. Still confusing but, like you, I’m not a copyright lawyer either.
Hi @str4d , any idea if forks of the zcashd repository will be allowed?
zcashd says MIT license, but will contain BOSL Halo 2 code.
Would someone be so kind to list a pro’s and con’s list here?
Thank you for the explanation! All this discussion about the BOSL has been very interesting. I was about to start a thread asking about it.
Your missing one other thing which is probably the key point:
You can, after using BOSL code with in the 12 month exemption, go get a license for the codebase that isn’t BOSL and keep it in your binaries.
Two ways you might do this:
Its important to keep this in mind, because theres are governance risks to handling that. They range from the minor (the thread yesterday) and some trolling to more major issues like what would happen to the money if, e.g., facebook, paid for a license.
The exception should be granted but the license, especially given the timeframes it involves with open-sourcing derivatives, should be left alone at least for a good while to see how it works out as a protective measure.
If we want Zcash to be the greatest privacy coin in the future we need all the help we can get. We need 100s or 1000s of developers comfortable contributing to the Zcash codebase. I don’t think it matters if the initial exposure to the Zcash code is through commercial applications or other cryptocurrencies. Chances are, if we have the best tech, some of those developers will also contribute to the Zcash community.
My reasoning is simply based on the assumption that a non-trivial amount of work went into figuring out the license and that the protective measures it affords may be worth that.
The problem is, there’s literally no upside to this license. The downside risk is someone asks to use the only thing the license creates the possibility off — a non-copy left version of the code. Because this option is permissioned— it must be granted by ECC — it creates governance problems. And is a source of fud in the general crypto currency community about Zcash. And we’ve already seen that happen. Against that, no one has offered a single potential upside.
if you read carefully, no one from ECC besides Zooko, possibly his brother, and the company coms people, are prepared to defend this publicly (and indeed even less privately). Several people (at ECC even) have explicitly and publicly said it’s a bad idea. Several others implicitly.
The thing is, BOSL is not a catastrophically bad idea. Its mostly harmles. Its just a brain fart that will 1) eat up time and energy when issues around it bubble to the surface (e.g. right now) 2) be a source for FUD against Halo2. Which is ironic, since the point of halo was to reduce the FUD against Zcash.
We should get rid of BOSL just to save the headache.
This does appear to be the case. It’s really unfortunate that the community is so divided on this.
Unfortunately the community is probably not going to hear about the any missed opportunities caused by this. Those that don’t like the license, or hear FUD about the license, will move on. Many won’t hang around to hear more or ask for an exception.
As part of both BOSL and GPL being copy-left, I’d at least hope Orchard is relicensed with a GPL exception (or such an exception is written into the BOSL as a whole which is then applied to Orchard). Given BOSL’s requirement on being OSS, which the GPL also requires (to some degree), removing the 12 month delay you’re permitted if you immediately want to OSS your code shouldn’t be an issue.
The one issue I see with such a scheme is the fact that the GPL doesn’t actually require open sourcing your code, only providing source to your customers who are allowed to distribute it, which is a slight distinction. It can also be further stated that if we shift it from GPL to GPL + OSS status, the GPL status arguably becomes irrelevant. So long as your code is actively OSS under one of several valid licenses… it shouldn’t be an issue IMO. The one distinction with moving from GPL + OSS to just {L} + OSS is that Zcash, if MIT licensed and using Orchard, could be forked into a private codebase without the Orchard library (yet potentially with an API matching alternative under a different license). With GPL/BOSL’s propagation applied, Zcash and its usage of Orchard would be ineligible for such private usage (ignoring the fact it has an exception and is MIT regardless).
I don’t think we should be concerned about license propagation to code using Orchard when the primary user doesn’t have such propagation, and should solely focus on ensuring that contributions to Orchard itself, along with its uses, are OSS (if that’s desired in the first place). That would mean a {L} + OSS exception, for {MIT, BSD, LGPL, GPL…}. That said, I do truly believe it should simply be MIT to not only encourage open development, remove all this drama, and remove legal ambiguities, yet also to remove Zcash’s dependency on a corporate exception (which I believe makes its binary non-FOSS? As you can no longer legally fork it as you’d immediately lose the exception and have a MIT codebase which is incompatible after 12 months? Can you promote an existing MIT codebase to BOSL without seeking permission from every single contributor?)
That’s a good point.
I also hadn’t thought about a community driven fork in this context. Let’s say a large portion of the Zcash community disagreed with a protocol decision made to Zcash and wanted to fork. Community would be required to adopt a BOSL license for the fork. ECC would still retain copyright which they could sell/relicense however they see fit.
The MIT license does allow sublicensing, of course, yet I’m not sure the BOSL text is compatible and if it isn’t… then it would be illegal for the community to fork Zcash from the ECC without not only removing Orchard as an active pool, yet also removing the blockchain verification enabling validation of the Orchard transactions on record (unless an alternative implementation was provided or an exception was acquired by the ECC who is theoretically being forked from, or every single contributor to every line of code in the project offered permission to license their work under the BOSL, which should be considered impossible).
There is the caveat that the Zcash Foundation has an exemption granted to Zebra, meaning if Zebra hits production status the Zcash Foundation could sponsor such a fork, but it prevents pure-community actions without any organizational support.
I think you might misunderstand what is it exactly being licensed under BOSL. Also, regarding forks, we have Zebra now. Another good reason to have multiple implementation of the protocol.
In defense of BOSL, can anyone point out the way to make sure people don’t just profit off what the Zcash community has funded through the development fund, without giving anything back to the community?
We don’t. We allow and even encourage usage from others outside the community. We shouldn’t assume the next breakthrough will come from ECC. We are nowhere near the limits of this technology. We need all the help we can get. And in the mind of many cryptographers and developers we create that friendly collaborative environment by releasing improvements and developments in a liberal open source license.
“Do to others as you would have them do to you.”
