fix: add apache 2 license🚧 #163
Conversation
BelfordZ
requested review from
bobsummerwill,
mikeyb,
phyro,
pyskell,
realcodywburns,
shanejonas,
soc1c,
sorpaas,
TheEnthusiasticAs,
a user,
tyler-morrison,
tzdybal,
whilei,
YazzyYaz and
realroyzou
|
We will also need DCOs from all existing contributors (should not require "decloaking" for any pseudonymous prior contributors) and confirmation that they agree to the relicensing. The copyright sits with the contributors, not with the repository. We need everyone's consent to relicense, but I think this a GREAT approach. Let me stew on it and come back with feedback. Will also raise with the IP lawyers for their input. |
|
I disagree on changing licensing conditions in the current ECIP-1000 in this repo and making past ECIP contributors to agree on a single option retroactively based on no rational argument whatsoever. Related to #162 and what is written in the comments here, there is no rational argument, even less rough consensus, on making past contributors retroactively agree on DCOs. Any new changes conditions should apply going forward. The option of "decloaking" retroactively or imposing using developer legal name should not even be under discussion in ETC. |
|
Just to be clear - we CANNOT commit this change (which relicenses the repository) without the consent of all of the contributors to date. There are 55 of them. This is why licensing is so important to get right up-front. https://bobsummerwill.com/2016/07/12/ethereum-everywhere/ and https://bobsummerwill.com/2016/07/12/c-re-licensing-plan/ detail the 5-month long process I went through for cpp-ethereum, only for it be blocked by Parity at the last minute. |
|
Ok. This is your wind mill to tilt at, it is not important to me and wastes resources. .I'm fine with mine being relicensed and future ecips being apache 2 . This looks good to me as it is grammatical correct and functional accomplishes its stated goal. Please add a tracker to indicate progress |
realcodywburns
added
the
status:0 wip
|
@realcodywburns Tracker: https://docs.google.com/spreadsheets/d/1WxDIyg4s9O3FsrloJPt91c-2RWCgSUdEkpBaPpcw4E0/edit?usp=sharing Looks like there are only 25 people to chase. Plus MikO seems to have done some README edits, and I don't know who "whilei" is but he/she seems to be at ETC Labs. |
|
At least as far as United States copyright law pertains, this may be of interest:
So while US authors would, without an explicit license, hold exclusive copy rights for their document itself, the ideas (and methods... etc.) communicated are (in the US) free as in free range. |
|
As far as the "real names" thing goes (and I can't seem to find the kernel for this thread.. ?) I don't understand why at all it's in the discussion here. Again, for the US at least, there is NO (as in NONE) relationship assumed or necessary between matters of copyright and legal identification. Ben Franklin wrote as @SilenceDoGood extensively (among many other names as well), for example, and the legacy of copyright-happy royalty-collecting pseudonymous literaries extends so far and wide even @50-Cent wouldn't know where to start listing them. |
|
@meowsbits On your US copyright point above, what I believe that is saying is that the copyright refers to the textual description itself, which authors have implicitly, whether or not they add "Copyright (c) 2019 Bob Summerwill" or not anywhere in the text. You authored it, you have copyright. If you take care to have PROOF of that (which, I think, in the old days, would mean sending a copy of your manuscript, and signing and dating it and keeping it in a safe, or getting it notarized or whatever - but which is trivial now for open source software by just working in the open) then it is very easy to enforce your copyright if somebody plagiarizes your work. Hello, Justin Sun. That copyright does not stop others from doing something equivalent, no. That is where patents come in. Which is why I care about using Apache 2.0. Because I don't want a Craig Wright / nChain style patent trolling drama to happen to ETC because of the simple lack of IP protection which we are discussing here. Something which still seems up in the air in the US at least is whether APIs are copyrightable, as horrible, horrible Oracle have been trying to do to Android by asserting that the Java APIs are their copyright, and even though Android is built on a completely "clean house" implementation of Java that they deserve billions of dollars: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. The current status is ... "Oracle appealed to the United States Court of Appeals for the Federal Circuit, which found in March 2018 that Google's reuse of the APIs had not been fair use, ruling in favor of Oracle." It will likely go to the Supreme Court, where (hopefully) it will be struck down. But it looks like this horror show is actually going to lead to Google ditching Android ultimately, for their own new OS with no Java dependencies. This court case was a key reason why I strongly opposed any thought (while we were looking at eWASM) of considering retargeted the EVM on top of the JVM. Because of Oracle. That is what Corda does, but that route is poison. .NET VM is safer, but there is still a risk there, if Microsoft went rogue again. Not sure of the IP situation on eWASM. But the best of the lot there is sticking with EVM indefinitely, and iterating that along - total self-sovereignty. Which is what @gcolvin always advocated. Hurrah for Greg. |
|
DEVCON3 panel - evolving the EVM - where Greg spoke on this: https://www.youtube.com/watch?v=txBl6ekcZXY Look at your faces, @gcolvin! https://photos.app.goo.gl/KEAmwss8BvfVLDqh8 What an unhappy bunch. |
|
Here's a nice little thing curated by Github on "Here's what happens if you don't choose a license". |
|
@meowsbits The real name part is not to do with collecting royalties. It is the other way around. If somebody contributes a change through a pseudonym then the copyright and patent protection you think you are getting through using Apache 2.0 with DCOs is nullified. Because somebody "signed the contract" with a fake name. You might be in receipt of code/spec they copied from elsewhere and the original author can then make legal claims against ETC users/companies/exchanges etc. You might have patented content which you "sucked up" which they slipped in through this pseudonymous approach. There is nobody to go and kick in the balls. At least with a real name requirement, if some patsy is put up as a front you can go and get them. Ultimately all of this is just game theory. There is no perfect answer, but having no defences is the very worst answer. The better defences we can have (as long as they are not adding too much friction - which I don't think any of this will) the less likely we are to be attacked. Maybe social defence is good enough for ETC? Because we are so practiced at spotting social attacks. Whatever the case, if "real name" is too much then it is too much, and that is fine. Kernel of that thread was #162, which I withdrew because @BelfordZ's proposal here was much simpler and better. |
Can you cite this? |
|
And @bobsummerwill
Can you explain with citations how using an Apache 2 License avoids or would solve a patent troll scenario? |
|
@sorpaas "Given that this has become a controversial issue, we might want to be careful merging it." More than careful. We SHOULD NOT merge it until we have resolution on all the outstanding issues - specifically getting consent from all prior contributors - because addition of a repo-level license is re-licensing - and the copyright lies with the original authors. It was not "assigned". Nevertheless, I think this is the best approach. We are making rapid progress. |
|
@meowsbits "Can you explain with citations how using an Apache 2 License avoids or would solve a patent troll scenario?" Sure. The Apache 2.0 license states that any contributors grant rights to use of any patents they hold on their contribution. So if you hold patents then you cannot enforce them against the project. You could enforce them against projects which are using MIT, BSD or public domain licensing though, because there was no such corresponding grant. That is patent trolling in a nutshell. Sticking your stuff into unsuspecting projects and then making $$$ by saying "I have a patent which means I have exclusive rights to monetize this thing for N years, so you owe me a million dollars". That happened to Linux, and it has happened to many, many other projects with over-weak permissive licensing. It is the reason the GPLv3 exists too. The GPLv2 used for the Linux Kernel did not have that protection either, and so Microsoft had a multi-billion dollar per year business trolling their patents onto Android companies. Over $1B per year just from Samsung to Microsoft.
"Explicit grant of patent rights: Apache License 2.0 explicitly lays down the grant of patent rights while using, modifying or distributing Apache licensed software; it also lists the circumstances when such grant gets withdrawn." "Real name" matters because if you have a sockpuppet making the submission then you have lost the patent grant. There is plausible deniability where the patent holder says "Well - it wasn't us who made that addition - you just copied our patented material - so you owe us $$$" |
|
BTW - Microsoft have done a complete 180 in the last few years under Satya Nadella, and are utterly unlike Steve Ballmer's "Linux is a Cancer" Microsoft. There are real allies of open source now.
See also https://www.hanselman.com/blog/MicrosoftKilledMyPappy.aspx. This is NOT to say that Microsoft is not what we would like it to be in other axis, but for open source they are very good now. Windows has "spyware" in it. They are legally compliant so will shut down things on GitHub when asked to by governments. So they are not aligned on censorship resistance, but purely on the "open source friendly", we don't need to be afraid of them anymore. Apple are "the baddies" on that score, but many people give them a pass because of their privacy-respecting best practices. They do that because privacy is an absolute competitive advance for Apple over Google - not because they are "good people": https://ar.al/notes/apple-vs-google-on-privacy-a-tale-of-absolute-competitive-advantage/ |
|
Im going to start deleting any comments or suggestions relating to DCO, or real names. I hope you understand why censorship is required here. |
BelfordZ
removed request for
tyler-morrison,
mikeyb,
phyro,
soc1c,
whilei and
realroyzou
|
"Im going to start deleting any comments or suggestions relating to DCO, or real names. I hope you understand why censorship is required here." It is not required, @BelfordZ. Why censor? Just ignore anything you don't agree with. |
|
Because the derailing of conversation is wasting mine, and everyones time. |
|
Hi @BelfordZ to answer only about the topic, this PR does two things: (1) Proposes Apache 2.0 I am in favor of (1) Apache 2.0 as a license to be used in the ECIP process, I am not in favor of (2) establishing only one license as the only option in the ECIP process. I prefer to stay with the options given in ECIP-1000 which are:Recommended licenses:• Apache-2.0: Apache License, version 2.0 In addition, it is recommended that literal code included in the ECIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Ethereum Classic Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the ECIP text. Not recommended, but acceptable licenses:• BSL-1.0: Boost Software License, version 1.0 Rationale:The philosophy behind the above is that it is preferable for ETC to follow a "least authority" principle only establishing rules that are no more than is absolutely necessary. Although Apache 2.0 is fine, it is not absolutely necessary to limit the whole repo to only that license. Therefore I prefer to continue with the portfolio of options that exists in ECIP-1000. Logistics:As to logistics going forward, I think we can very easily align all previous contributions to one of the licenses in ECIP-1000, I can help with that, and from now on the ECIP editors can perfectly bounce any ECIP that doesn't have a correct license. So I think will be in order from now on. Multiple unrelated topics:As this PR is one step in a series of "protections" to ETC I thought it was relevant to include the other issues as related externalities. However, I agree with you that this thread relates to only the above issue, so I will stick to that rule from now on. |
|
Thank you @tokenhash for the well constructed criticism. Here are the main reasons for why I propose apache 2.0 for all, without exception:
That said, this isnt a hill im willing to die on. Should this be a deal breaker for you folks, I'm happy to meet halfway, adding root license of apache 2.0, allowing other licenses to be specified, but I would urge that any GNU, GPL, or as I put, politically infused licenses not be included in the allowable list. But just typing those words makes me feel dirty, as I don't really want to be an accomplice in having more than 1 license to maybe one day have to deal with. |
|
Thanks @BelfordZ,
Those are reasonable arguments. Especially the possible mixing of licenses that may invalidate or neutralize the others, thus possibly defaulting to copyright or other nefarious stuff. |
Yes, let's meet in the middle. Allowing Apache 2.0 as the root license so ETC has a default option, but having a more extended list in ECIP-1000 that allows devs to use alternatives, but perhaps post them in another repo or site e.g. ecips.that.world as @sorpaas has done in the past. The ETC ecosystem can use ECIP-1000 in this Github Organization (https://github.com/ethereumclassic/ECIPs/blob/master/_specs/ecip-1000.md) as the canonical reference of which licenses to use. @BelfordZ can you point out which licenses in ECIP-1000 are hyper-toxic to you? I just speak for myself here, others may have other opinions. |
|
yeah im over it |
|
"Allowing Apache 2.0 as the root license so ETC has a default option, but having a more extended list in ECIP-1000 that allows devs to use alternatives, but perhaps post them in another repo or site e.g. ecips.that.world as @sorpaas has done in the past." As long as those other repos are suitably constrained to have to use one of a very short list of acceptable alternatives, which I think likely boils down to only Apache 2.0 or the new Chinese license. So maybe we end up with another repo for proposals using that license, like @kimisan has said he would prefer? But we really don't want loads of repos, because it makes it horrible for people to work out where everything is. Also - even just to add the Apache 2.0 license in the root here, we still need to get consent from the previous contributors - with my spreadsheet and Donald's getting close to that already. |
THIS PROPOSAL HAS NOTHING TO DO WITH DCO, REAL NAMES, OR ANY RESTRICTIONS ON WHO CAN CONTRIBUTE
ref #162
All ECIP contributors who specified licenses other than apache 2.0 must resubmit their ECIP, removing the license. ( good job everyone, there are no examples of this.)