The EF not disclosing grant amounts is a new thing that they started, last year. They use to publish the amounts alongside the grant announcement. Seems odd that the ECC would need approval for that.
2 Likes
Maybe this is a weird edge case if Halo 2 was the linux kernel with who knows how many independent contributions, but right now it is an ECC software project, and in such a case, unless I’m missing something cause I’m new to this stuff, it is not a weird edge case but a common business model called dual licensing.
1 Like
It’s interesting to see the next steps of Halo 2 include “Publish a development branch using PLONK, including benchmarking for various circuit sizes.”
Hey all, just got caught up on this thread.
From my perspective, when taking the criticisms in this thread as a whole (which may not represent the position of any participant) there seems to be a contradiction:
- Should ECC wait to publish our work until it’s well developed as it sounds like from this comment or that one, or
- Should ECC engage the community very early before any “announcements” or “blog posts” to make sure the community is looped into each decision by ECC such as suggested in this comment or that one?
So which is it?
Would you like ECC to announce our work early as we’re doing it? The benefit here is we all get to discuss work as it progresses. For this to work, you must be ready to accept a response to questions or concerns of “ECC hasn’t yet completed the work to answer that issue, we’ll be doing that down the road”.
Or would you prefer ECC to wait to share something until it’s “fully baked”? The benefit here is that the result will be more complete so it’s more likely that any question or concern will be immediately addressable. The downside is that the community won’t be involved in a bunch of the internalized steps.
I personally tend to prefer the former option, which I often refer to as release early, release often.
With that being said, each of these approaches is an ideal and no communication from ECC (or any person or org, really) will fall cleanly on either side. In reality it takes time, effort, and ZEC to communicate and coordinate with the Zcash community, whether in release early/often or in only-when-baked modes.
So if I could rewind this thread and jump in at the perfect moments, I would have responded to @secparam and @tromer’s questions about circuit/consensus design by saying “we have had discussions but don’t have something written down we’re ready to share yet; that’s coming down the road”, as @daira did here;
-and to @TheMaxPowerWay and @Yugo I would say “I hear that you feel blind-sided or surprised about this. That’s why we posted the blog post and this forum thread, so that we can start that discussion.” as @amiller did as well as @joshs here.
Ok, now, aside from the issue of what stage of progress ECC engages with the community in, all of the topics and discussion about tech or licensing details seems totally relevant and important to have.
How would this thread look different if it were more collaboratively focused on discussing those details? Is there anything that ECC could change to facilitate that, or is it something that requires all of the participants to change as well?
6 Likes
I’m curious what kind of answer you’re looking for.
Could you role-play that you are at making a decisions about licensing and engaging an associated community about it, and then answer the question above?
Bonus points: after answering it the way you want to see, flip it around and answer the other side of your “or” in a steel-manned manner.
1 Like
I know this isnt directly aimed at me: but for future reference this kind of dicholotmy causes problems.
If you think I am acting in bad faith, Please raise your concerns with a forum moderator.
This is not how public development works. If you want to be closed soource and to input. Please come out and say that.
- Should ECC engage the community very early before any “announcements” or “blog posts” to make sure the community is looped into each decision by ECC
This is just disingenuous. How can modifying a KEY licence to the future of zcash not be a community issue?
the ZFND have already said that this licence could stop them putting halo in zebra - What due diligence did you do with your sister company?
All this could have been avoided along time ago, if you had put a forum post saying we like “TGGPL” - but because the ECC officially refuses to support any form of two way communication between the ECC and community
I really dont understand why you did not feel the need to do this.
IF this is the ECC’s idea of a conversation (after release) then I am at a loss.
I consider myself a valuable member of this community and would be exceptionally disappointed if you handwave me away as a concern troll.
THE MGRC MAY NOT BE ABLE TO USE HALO/2 this is a massive concern. Please advise on how you are going to reconcile this.
3 Likes
It’s easy to ensure compatibility of the TGGPL with any desired license. For example see tahoe-lafs/COPYING.TGPPL.rst at master · tahoe-lafs/tahoe-lafs · GitHub
FWIW, I agree that the communication here was poor, despite the blog post. Indeed, I predicted concerns about license compatibility and said so internally.
7 Likes
Think this is getting blown out of proportion.
Sure, its a change, people are always worried by changes. Its a new license & there are uncertainties, but at some point there’s always going to be a ‘new thing with uncertainties’.
There’s no history of malicious actions, things are done with good intentions (at least all the time I’ve been here). If it doesn’t work out then it doesn’t and things change - but if it does work out to be a change for the better then great, have at it.
8 Likes
I am a total n00b a licensing, so sorry if im being stupid. but I think others might have the same question.
So Apache 2 is fine: (I think I am not a lawyer)
What about MIT (this from a brief look seems to be the most popular on git hub… yet not mentioned.
I am way out of my depth. @lawzec and ideas?
Im not upset, I like the new license. I am just a little worried that the MGRC might not be able to use it, or software that uses it.
If someone can say “steve, its fine. dont worry” then I will be happy.
Im not on the “all licences must be pre approved camp. and I am certainly not in the design by committee.” I just need a reassurance that this will not be an issue for zebra or MGRC projects.
1 Like
Then all is well 
There are public statements on putting Halo into Zcash, as that’s the intention things like licenses will either support it or be adapted. Not worried at all.
1 Like
Thank you! It is great to have diverse opinions. Also, this is nth proof that daira holds community pulse
I agree with what Nathan said above.
Regardless of how it was done, think about what needs to be changed (if any). Suggest any improvements/change ECC can do.
ECC can’t move fast & take community input every time. Also, it is not trivial to predict which decisions need to be made here (it is always trivial in retrospect/hindsight - like this one).
5 Likes
Normally I would agree, but…
I dont think these are small changes, not in the way the ECC wants - the ECC has stated the reasons for their T style licence. (except daira - who is the peoples champion)
I guess ZF & ECC will work to fix that valid concern??
3 Likes
Its easy to make a license more permissive, but almost impossible to go in the other direction - or put another way, you can give more rights away but you can’t take them back once given.
Too early to tell right now whats needed but there’s also no burning need to sort it out immediately.
3 Likes
I agree. I did follow that reasoning behind the posts too.
and yes it is easier to make something less restrictive. however, the restrictiveness already suggests that their has been a compromise.
My current worse case scenario is that the zfnd get to do what they want, but the T licence stands for everyone else.
I have very specific concerns, that relate to me, that I am not happy discussing on the forum. (no I am not a govt employee!) anyone at the ECC use PGP? (without s/mime!!!)
Is this a conversation up for private external input (you can make it public after)
Hopefully for everyone and not just the ecc/zfnd
1 Like
Hi Nathan,
There are two things on this thread by very different groups of people. Please don’t compare one to the other. Second, they aren’t contradictory, you missed the point of Eran and I’s comments.
The last issue in this thread is the license brew hahah and I think the people who started it were off-base. What people were accusing ECC of didn’t make much sense and I spent some time trying to talk people out of it privately. The issue is, it was hard to give them a reasonable case. It has come to the point in this community where people mistrust what they cannot explain. A simple clear explanation for why this license was picked would have avoided this. Instead, answers were vague platitudes, even to me in DMs.
The original issue is Halo itself, of which I think there does need to be some discussion.
But, the common thread is the only communication the community gets is marketing blog posts which are devoid of content. They seem to be allergic to these now.
The precise problem Eran and I are worried about is is it seems you all went all in on halo and scaling without a plan for how halo would be used to scale. In fact, its not the least bit clear Halo can readily be used for scaling (and I say this as someone with a fair amount of experience in this stuff). But every indication we have gotten from previous ECC blog posts is Halo was intended for scaling and trustlessness was just a stepping stone.
So we weren’t saying don’t publish work without finishing it. Quite the contrary, the details should have been sketched out and probably published before the work started. And certainly they should have been discussed before ECC blogs present it as a fait accompli that you all are going to push for this. Notably this last post seems to play lip service to it being the community’s choice, but then you offer no information for the community to make an informed decision and in fact have spent the last year priming them Halo without details (but with socks).
Even if thats water under the bridge, then when you making claims like about Halo and scaling now, then you need to actually describe how. Otherwise, it’s just marketing blog posts and the community is allergic to them.
I should note the blog posts were ALSO a communications failure because it seems, from talking to people at ECC, that at least some of the engineers really just want to get rid of trusted setup and scaling is a nice to have after it that might not work. This is more reasonable to not have plans for up front but that was not how this was read by anyone else.
I should add that were halo merely about trusted setup, then there is a serious discussion that needs to happen about the limited benefit of removing trusted setup ( reduced attack surface area and bug surface area) against the risks of more complicated cryptography and new code. And a serious question of if removing trusted setup will actually address the “zcash trusted setup” meme/FUD or if that will just change to " you can’t audit zcash coin supply/ it isn’t sound money."
None of these discussions have happened. Why? Because no one ever works out the reasons choices are made et ECC and communicates them. All we get is marketing copy. And that is the one point commonality between the two issues on this thread: the allergy to marketing copy and lack of details and discussion.
4 Likes
So the prescription is to add this clause:
This work also comes with the added permission that you may combine it with a work licensed under the OTHER_LICENSE (any version) and distribute the resulting combined work, as long as you follow the requirements of the licences of this work in regard to all of the resulting combined work aside from the work licensed under the OTHER_LICENSE.
Does this work?! If you create a combined work which is a derivative work of something licensed under OTHER_LICENSE, then by definition the entire combined work is subject to OTHER_LICENSE.