Given devfund extension, think it would be better for company rep to use MIT license on all software; otherwise feels like you’re having your cake and eating it - having guaranteed income stream, but also acting like a for profit that doesn’t have that guaranteed stream.
Paraphrasing, devfund would be more acceptable imo, if software generated were public goods…in which case what’s wrong if some party later makes profit with it?
There are three concerns here.
I don’t see the last one, but it’s hard to argue against because I have not the foggiest idea what this license was trying to achieve.
I think this might be easily addressed by a simple fill in the blank:
If ECC released Halo under GPL/aGPL (a viral license that disallows proprietary uses/including services), ___($1) bad thing would happen. By releasing it under TGPPL, this lets ECC do ____($2). (2) prevents (1) by ______.
a8d79a582572d777357bb5b6cfe2b4b29096486a
Is it because we are worried our competitors leverage Halo 2 & deploy it before Zcash? zksnarks, Sapling are already being used by other projects - should we be happy or sad about that? I would say HAPPY
Many members already made great points regd. this. What’s the one thing that made ECC take this step for Halo 2?
It seems like a way of enforcing alignment of principles i.e. Zcash is for everyone, proprietary development is dissuaded due to the legal reprecussions and open source isn’t because its exactly the same for them as it was before, Zebras have standards and if you’d like to fork the thing the herd has decided to continue funding then I don’t think adhering to one of them (a fundamental one but nonetheless) is too much to ask (unless it is, in which case begone)
Hi @Autotunafish you responded something similar in another thread, what are you talking about? are you asking community to fork off if they want something to change?
TGPPL says (emphasis mine):
- External Deployment. The term “External Deployment” means the use,
distribution, or communication of the Original Work or Derivative Works
in any way such that the Original Work or Derivative Works may be used by
anyone other than You, whether those works are distributed or
communicated to those persons or made available as an application
intended for use over a network. As an express condition for the grants
of license hereunder, You must treat any External Deployment by You of
the Original Work or a Derivative Work as a distribution under section
1(c).
So, similarly to the Affero GPL, remote services such as websites and SaaS that are derivate works must publish their sourcecode within a year? (Note that some contend that even linking in the code, as a library, makes the whole application derivative work.)
A few questions:
What is the rationale for this, especially in the present context? I observe that Affero GPL is far less popular then the GPLv3, which is identical other than not having such a provision.
How does the above phrasing compare, in its implications (other than the 1 year grace period), to the analogous phrasing in the Affero GPL? To recall, the latter is:
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
and in the latter:
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.
More generally, what licenses are compatible with TGPPL?
Ideology and abstract goals aside, this is a crucial practical question. We are very used to compromising and using open-source license that don’t perfectly match our tastes, because the alternative is a compatability nightmare or (more commonly) an adoption blocker that benefit no one. I’m not innocent, myself, of crafting custom licenses in the past; but in this day and age, I’ve come to view custom open-source licenses with much suspicion. They are more commonly the result of juvenile playfulness or idealism, than of well-reasoned problem-solving.
I’m not suggesting it but you are free to do that and I might ask you to consider the constraints that make that possible because all I can tell the new liscense does is ensure that future possibility with forked derivatives after a year, it protects the publicly allocated resources directed at this public good by ensuring things copied from it will eventually remain there too
But so would have gpl/agpl right? In fact, it doesn’t give the 1 year waiting period. It just immediately means no proprietary works. So that’s actually stronger.
edit: this is a duplicate of what @secparam concurrently wrote above, but has more detail so I’ll keep it.
I’ll take your word that you heard that often (though I can’t say I have).
But then, why not use GPLv3? You would get even stronger protection from “capture” of what you built for Zcash! So, who are the people to whom you want to grant a year’s worth of proprietary exploitation, if they just open source their apps at the year’s end?
(Not to mention that GPLv3 would drastically reduce the license compatibility mess, by sticking to a common, well-understood license.)
I would argue the new liscense is actually better because then the development that otherwise would not have happened is then only in queue lest the dev decided the hard no for themselves
I think it really does come down to this question. You’re thinking it’s a benefit, others are worried it’s malicious. I genuinely have no idea what the point is.
I do feel like I’m in the other Venn diagram circle of understanding because I feel the exact opposite! So I agree
I’m pretty excited to see a proposed use of TGPPL. My understanding is this has been a backburner idea of Zooko’s for a long time, it seems like it was used in Tahoe-LAFS, but only alongside other concurrent licenses, so it hasn’t really been tested in public much.
I’m hoping in the other thread there’s a broader discussion about what this sort of license could achieve more generally for incentivizing cryptocurrency code. Would wallets or something benefit from using a grace period like this, so that other wallet companies couldn’t copy their code, yet it would still be open for public review?
Given that this is in the Halo thread, and ECC is thinking of using Halo for a future Zcash improvement, my main questions would be,
I agree with @joshs; you wouldn’t even be talking about this contrived objection were it not for some other user on the forum concern trolling about it. The ECC is constantly responsible for making decisions (resource allocation, etc.) without first consulting the community, or else we wouldn’t be able to function as an organization. We make decisions based on the best interest of Zcash. The community can hold us accountable by not using the software we publish or by not funding us. The idea that we’d need to consult people before publishing some code, which is currently not incorporated in Zcash, is an imagined fiction.
In the same sense, you could object to us releasing the code under “MIT / Apache2” without consulting the community beforehand, because “we funded you to do development for Zcash and you just gave it away to all our competitors!!!11”
We retain the ability to republish the code under a new license, and we may have to do this to fix compatibility issues or to address criticisms from the community. Hold on a second — that sounds familiar — it’s like… some sort of feedback loop with the community where we can figure out how to best license the code! It kind of sounds like what you’re asking for, except actually constructive.
I’m confident the issue here has to do with the community getting blindsided. In my humble opinion, some advanced communication on this would have been seen as a gesture of goodwill and would have done a lot to settle nerves. This is not a technical issue but is instead one of communication.
By the way, using “concern trolling” is a great way to dismiss somebody without addressing their arguments. I’m not sure where this ad hominem tactic came from on these boards but it only lowers the cultural standard of the entire community.
Fair point. To those people I would argue that open licensing and collaboration hasn’t stopped other projects from capitalizing on what they’ve created. I feel that when people are making this argument they’re more upset on how new code is not being leveraged properly but I won’t go beyond that.
Indeed. However, acting constructively would imply that somebody with the authority to do so answers the questions by @secparam, @amiller, @tromer, @sarang, and others. Knowing that a license can be changed doesn’t do much for us at this stage. The community needs to know that their comments are being addressed and not ignored.
I’m in the camp of simply wanting to understand the decision process, reasoning, and business plan behind choosing this license. Hand waving these concerns away and telling us “it’s great for Zcash” simply isn’t enough.
I addressed their arguments, but let’s be honest: this is concern trolling. This forum is inundated with rhetorical games and trolling dressed up in civil language. These same people then say callous and cynical things about us on other forums. I see this for what it is, and I think somebody needs to call it out.
True, but here is the problem. ECC has a long history of announcing weird decisions, supposedly open to feedback and discussion, but then not truly engaging in discussion, and not backtracking even in the face of overwhelming near-consensus community pressure. Once the blog post or the tweet are out, ECC often just digs in its hills and keeps an appearance of listening using empty prose, but doesn’t budge or truly engage unless forced by circumstances.
(I won’t go into examples to avoid derailing, but I’m sure you can recall several such examples over recent years.)
This is very painful, and many people in the community feel on their back foot and forced to take stand against such behavior.
Unfortunately, the current license airdrop (and accompanying PR fanfare) feel like the beginning of another instance of such dynamics. Hence the hair-trigger response you’re seeing.
The community can hold us accountable by not using the software we publish or by not funding us.
We both know this is not a realistic answer. The bar for the nuclear options of defunding ECC, or shunning the only node implementation, is very high. This does not automatically legitimize (allegedly) bad behavior that passes below the nuclear bar.
I understand where you’re coming from. However, I just don’t agree about what you believe their motivations are. It is clear that there is frustration on several sides but I personally believe that we (as a community) should be isolating the reasons why that is. To be frank, this set of causal factors are driving much of the tension. @tromer just pointed one out.
The more we neglect to confront these hard issues the worse we’ll be overall. Anyway, have a good one.
I won’t dispute the perspective you outlined, and I do recall many of the incidents you’re referring to, but I often feel as though regardless of what we do, there will be something we “didn’t engage with the community” about and it’ll be exaggerated by a few people. This thread has two good examples of this already.
People in this industry buy worthless companies for $140M just to flex with trademarks, and then announce “we’re adding Sapling to TRON!” The research we’ve done for Zcash has been incorporated in millions of dollars worth of other businesses in the ecosystem. The intention is clear and in good faith: let’s try to preserve some of the value of our research and development efforts in the period of time before we can realize it in our project. We can all disagree about whether the license is effective in doing this (in fact, I’ve been bearish about it so far), but we don’t have to act like posting some code unrelated to Zcash under a different open-source license “blindsides” the community. If the bar is that low for us to blindside the community, people will find failure in everything we try to do.
The other example of course is that we can’t even announce that we’ve received a grant from EF to do development of Halo, and that we’re excited to post benchmarks and other details soon once we’ve finished implementing it, without getting it shot down as an impossible waste of time because… we haven’t posted the benchmarks yet.
Perhaps I’m missing the vibe of encouragement as people in the community try new things and solve problems.
It seems like this thread counts as the advance communication… There’s clearly a dilemma here, announce something too early, and it’s harder to answer all the questions about it, announce later and it seems like more of a surprise.