You're also trying to protect against future Craig Wright style threats, when contributors are otherwise anonymous. This is why knowing who contributors are is important, and having a clear grant. (importantly: not just MIT license, which has no patent provision!) 4/12
-
-
Replying to @brianbehlendorf @BobSummerwill and
This is something we'll have to sort out with Rocket Labs if they want to get enterprise adoption for Avalanche. 5/12
2 replies 0 retweets 4 likes -
Replying to @brianbehlendorf @BobSummerwill and
This can all come across as a hassle to devs who just want to work together on code, share ideas, and not be a part of the IP industrial complex. This is the kind of anger that leads to MIT-licensed code, or WTFPL, or even nil copyright notice on code. 6/12
1 reply 0 retweets 6 likes -
Replying to @brianbehlendorf @BobSummerwill and
All of that presents a danger to end users. If you don't care about your end users, fine, put out code or specs with terms that don't protect them from potential abusers who would use your good will as subterfuge for their ends. Kudos to Bob for caring about ETC users. 7/12
2 replies 1 retweet 12 likes -
Replying to @brianbehlendorf @BobSummerwill and
But: code development and standards are different. DCOs and licenses attach to code and protect you from the code's authors. But standards are often the result of conversations and other interactions well beyond code. 8/12
1 reply 0 retweets 2 likes -
Replying to @brianbehlendorf @BobSummerwill and
For that reason, standards bodies have typically bonded all participants in a standards discussion to an IP agreement, especially in earlier days. They will also ask their members to signal if they have any IP rights in a standard before that standard is declared final. 9/12
1 reply 0 retweets 4 likes -
Replying to @brianbehlendorf @BobSummerwill and
But that's likely not practical in an EIP and ECIP setting, where even if you require non-anonymous authors, you want public input and don't want to burden every potential reviewer with revealing their real name. 10/12
1 reply 0 retweets 3 likes -
Replying to @brianbehlendorf @BobSummerwill and
There is clearly grey area here between the two; most standards specifications these days look and are built a whole lot like code. And even code development can incorporate ideas from discussions or other informal channels. 11/12
1 reply 0 retweets 2 likes -
Replying to @brianbehlendorf @BobSummerwill and
So this issue affects not only standards processes, but potentially open/public code development processes down the road. I'm not clear on what even the case law is right now on this, but the CW-as-Satoshi thing should make us all particularly wary. 12/12
1 reply 0 retweets 2 likes -
Thanks for all the input, Brian! And the CW-as-Satoshi thing is not just theoretical. The trigger for me to look to tighten ETC's IP policies is ProgPOW, whose only non-anon author
@OhGodAGirl has strong links to the CW / Ayre group - the same bad actorshttps://bobsummerwill.com/2019/09/17/progpow-author-kristy-leigh-minehan-uninvited-from-etc-summit/ …2 replies 0 retweets 1 like
The other two coauthors remain anonymous, and as per Kristy a group of around 40 anons have contributed in various ways (whether "hard" or "soft"). None of these actors will be bound to any CLA or DCO. To my knowledge, this will be first EIP accepted into Ethereum from anons.
-
-
Replying to @BobSummerwill @brianbehlendorf and
And it is a change to the most economically critical element of Ethereum - the POW algorithm - with this change steering perhaps ~$1B worth of economic activity per year. How this EIP can be passed boggles my mind. Truly. IP risk. Economic risk. Bad actor association.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.