Proposal to amend ZIP 1014 to require MIT license for core code

Governance
1

ZIP 1014 allowed for a continuation of block reward allocation to the ECC and ZF beyond the original termination date.

As a condition of the continued funding, ZIP 1014 included the following:

All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative 5), preferably the MIT license.

Clearly the intent was to push major development efforts to be released under the permissive MIT license. However, this was not strictly required.

Voters (including myself) viewed this as a reasonable statement. Surely good-faith actors would prefer to release code under the same MIT license as before, right?

Instead, we got a brand new, silly BOSL “open source” license that nobody wanted, and that is incompatible with every other open source project out there.

Lesson learned. ZIP 1014 should be far stricter if the ECC (or any other entity receiving funds from the block reward) are going to regularly act against community expectations for no clear reason. They are taking advantage of the fact that the MIT license is not a requirement to retain licensing power for the for-profit company.

I propose a simple, clear amendment. Additions in bold:

All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined and approved by the Open Source Initiative 5), preferably the MIT license. All software funded this way that will be used in any core Zcash implementation MUST be MIT licensed.

I believe SHOULD was used primarily to protect the ZF if they sensibly issued a grant to design an interesting closed-source application with Zcash. No one reasonably wanted or expected the situation we have now with a core part of the Zcash consensus code being released under a restricted license that could result in legal actions against those who fork Zcash, Ycash style.

I’m open to better final wording. I’m just kicking off the discussion. This discussion is ultimately one of the only ways to hold the ECC accountable. Luckily, ZIP 1014 contains this interesting section (“conditions” includes the license condition paragraph):

BP, ECC, and ZF MUST contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other party to issue a modified version of Zcash node software that removes the violating party’s Dev Fund slice, and use the Zcash trademark for this modified version. The slice’s funds will be reassigned to MG (whose integrity is legally protected by the Restricted Fund treatment).

This creates a possible real, legally enforceable pressure against the ECC to comply with this modified ZIP 1014.

It sucks that the ECC decided to add this unexpected restrictive license to community-funded code, but here we are. We’re well past the point where they could have backed down in good faith following the severe negative feedback. Continuing with this license strongly strays from the goodwill and flexibility currently permitted. ZIP 1014 thus should be changed to disallow this.

4 Likes
2

+1. I believe financial, and human, freedom, means freedom from corporations dictating what we can and cannot do. This ensures Zcash is always accessible, usable, and advanceable by the community.

Regarding wording, instead of “used”, potentially “submitted for usage”, and instead of “core Zcash impl”, “Zcash impl endorsed by the ECC or ZFND”? This moves a potential ambiguity to a literal, and makes sponsored projects funded by the dev fund (yet not directly done under the ECC/ZFND, such as Qedit’s work) required to be under MIT as well.

3 Likes
3

I was supportive of permissive licensing - definitely my default position; but, I personally have found the arguments for BOSL convincing. ZEC holders support the dev fund, the dev fund supports ZEC. Maybe in a year or two we can let the lesser privacy coins and for-profit corporations have the code for free once ZEC has become the dominant cryptocurrency :wink:

There is a z2z poll here that costs 0.05 ZEC: Free2z interesting experiment in my opinion.

11 Likes
4

As someone who thinks GPL could better serve some use-case, I don’t think restricting a choice down to just one license is the best for the long-term.

To clarify my position: I support dual licensing Orchard with BOSL/GPL.

1 Like
5

Unfortunately we don’t exist in a bubble. I believe the BOSL licensed greatly increases the chances of our beloved and valued partners jumping ship and working on a fork. It’d probably only take a skilled team a year…

IMG20220507151104
IMG202205071511041920Ă—1440 180 KB

2 Likes
6

If you still engaged in meaningful discourse here on the forum like you used to and, per recent events, if the XMR community was at all still interested in Orchard than I’d probably take your proposal more seriously.

2 Likes
7

Again, I already have a personal example of code developed for ZEC which would no longer be possible with this change. As for the poll, I don’t really care to vote on a random poll site piping capital when I already advocated for a binding poll of the officially recognized group.

1 Like
8

Free2z.cash is a random content and fundraising site based on ZEC that I built, not a random poll site. The creator who posted the poll is unidentified and not affiliated with me or the site (that I know of). Proceeds from the poll do not go to me or the site. I was just mentioning it as an interesting experiment. And, if nothing else, a small data point of actual ZEC holders ponying up a non-trivial amount of ZEC from the Sapling pool to vote - any poll on Twitter or this forum can be voted on by any troll or Johnny-come-lately who doesnt even hold shielded ZEC.

Where do you propose having a “binding” poll exactly and what exactly is “the officially recognized group”?

Also, curious what is “piping capital”?

1 Like
9

A Helios poll to ZCAP to amend ZIP 1014 where if broken, one of the orgs would legally be allowed to effectively remove the other.

I did recognize the site didn’t take any funds (donating to The Giving Block) and noted you didn’t say you created it, which I didn’t suggest. I will say I didn’t note the site had a larger existence beyond polls as I didn’t spend much time on it. Piping capital meant taking in ZEC to forward it (“piping” it) to the TGB.

1 Like
10

Kayaba is referring to the ZCAP : Zcash Community Advisory Panel - zcash foundation

2 Likes
11

Edited:
I support the spirit of this suggestion, in light of the dynamics we now experience: an ill-reasoned harmful license is being forced on the community despite the strong objections of cognizant participants.

(And yes, I share the blame for the optimistically permissive phrasing in ZIP 1014, which originated in my ZIP 1012 proposal.)

This will have a grave cost, in preventing some projects from being funded, because they need to, e.g., include GPL code. Permitting MIT or GPL seems better.

Maybe OSI in general, as a MUST rather than a SHOULD? Restricted to their Popular Licenses list to minimize fragmentation?

5 Likes
12

+1

Agree with the intention of the policy to correct everything from now onwards.

1 Like
13

Another possibility is to be strict for code that is critical for consensus and enabling forking (see related discussion here and here).

For example, adding language in the following spirit:

All software whose development is funded by the Dev Fund, and which is intended to be used in implementing blockchain consensus rules, node operations, or other critical functions needed for operation of the Zcash blockchain or forks thereof, MUST be released under the MIT license.

2 Likes
14

I think that’s covered by “core Zcash implementation”, yet your definition expands a bit to software which doesn’t currently exist (for example, if Zcash practically relied on Kubernetes, it would also cover those files) and I don’t expect to exist in the future. It’s also ambiguous (is Kubernetes scripts critical when you can manually run commands?) and I don’t see it as being a practically meaning distinction. I’m also not against it though :slight_smile:

1 Like