CLA: Better wording and links around licensing

[kborchers]

This PR addresses concerns raised by individuals that our license links didn't point to specific licenses and instead wikipedia articles about the license. Instead of specifically mentioning the MIT license in the CLA, we reference the LICENSE.txt in the repo to accurately represent the license for the project and update the links to point to TLDRLegal which gives easy to understand summaries of licenses as well as the full text.

[scottgonzalez]

Any wording change requires a version increment.

[kborchers]

What is the appropriate new version for this type of change? Would it be 2.1 or 3.0?

[scottgonzalez]

I think 2.1 would be fine.

[scottgonzalez]

Section e requires an update now that the CLA allows for other licenses.

[scottgonzalez]

And with that change, I'd actually say we should bump to 3.0.

@StevenAyr Correct me if I'm wrong, but anyone who signed v2.0 will still have their future contributions licensed under MIT even if the project has a different license.

[kborchers]

Added some clarification to section e. Not sure about the need to bump to 3.0. @StevenAyr can you comment on that?

[StevenAyr]

I'll let you guys sort out the naming convention, though I do think this is a big change worthy of considering its effects on past contributions and contributors, and I think it probably makes sense to require re-signing the CLA in order to make future contributions.

Specifically, as Scott noted, anyone who signed 2.0 is explicitly contributing under the terms of the MIT license. Initially, the 2.1 change just dealt with how the Foundation was going to license any contributions (under the terms of the License file in any specific repo). With this most recent change, we bring the contributions and the licensing by the foundation in line with each other, but we also change the way in which the contributions themselves are made. Contributors under 2.0 haven't agreed to that specifically, and so it most likely wouldn't be enforceable against them. There's no clause in the CLA to the effect of "the Foundation reserves the right to make changes to this CLA from time to time, and the Contributor agrees that such changes will be effective upon publication by the Foundation," so we can't just change the CLA and have all prior contributions (or ongoing contributions) automatically be governed by the changes. (I actually don't think that a clause like that really has a place in the CLA, as I think it would probably raise concerns about hypothetical changes without consent and not really solve a big issue for the foundation).

All of which is to say, in a perfect world I would like to have all contributors sign on to a v 3.0, and I believe that the wording as proposed will be sufficient to apply the 3.0 to all prior contributions. This may be a big ask as a practical matter, especially with projects such as Esprima where we just had everyone already sign a new CLA, but I think it's the best route to go. The alternative, however, presents very little risk for the Foundation. That is, the Foundation is only going to allow use of permissive licenses that are compatible with MIT to begin with, so if someone contributes under MIT, the Foundation can still license that contribution under Apache 2.0, or BSD 2 or 3, since all three of those contain the basic disclaimer and limitation of liability required under the MIT license.

So to conclude a long and rambling comment, prior contributors and contributions will continue to be MIT unless they sign a new CLA. So ideally we'd like to have them sign a new CLA, but everything will be fine even if they don't, because the licenses the Foundation will use are interoperable.

[kborchers]

I would like to finish this up and we have had a bit of discussion off of the issue but I wanted to bring it back here. A few things that I would like to state so everyone is on the same page or possibly get clarified by @StevenAyr before we merge this are:

1. We will mark this as v3.0. I think everyone is on board with that.
2. Because the licenses we support are compatible, in most cases we should not need new CLA signatures from contributors that have signed the current CLA because we can accept those contributions under MIT, as stated in the current CLA, and then redistribute them under another compatible license, like BSD in the case of Esprima. I think everyone agrees there as well and unless @StevenAyr disagrees we are good.
3. The one item I still have concern with is the fact that the current CLA states that the contributions will be redistributed as MIT under the Licenses section as well as item (d) under certifications. Again, I think the compatibility of the licenses we intend to use/allow makes this a non-issue but if someone wanted to interpret their signing of the CLA as strictly being bound by these terms, would we be violating those terms of the current CLA by accepting a contribution under MIT and then distributing under BSD and if so what consequences could we be opening ourselves to?

[StevenAyr]

I'll just comment on 2 and 3.

1. You're right. MIT is the simplest of the licenses, so if someone contributes under MIT, and then that contribution is redistributed under BSD2, BSD3, or Apache 2.0, all of those licenses will fulfill the requirements of the MIT license so there are no concerns there.
2. This is primarily an academic concern. Someone could certainly complain that strictly speaking they made a contribution under a CLA that said any contribution would be licensed under MIT, and now that contribution is being licensed under something else. This is mostly an academic argument for a couple different reasons though.

First, the only projects not currently under MIT are new projects, if I'm not mistaken. So the only people who could complain are people who were contributors to Esprima and just signed the CLA, only to have the code licensed under BSD, or people who have contributed to other projects in the past, and now start to contribute to new projects under different licenses. I don't think the Esprima contributors would really have an argument, as that license was BSD when they contributed and has remained so. I don't think the prior contributors to new projects would have an argument either, as they contributed to a project with a specific license set forth in the license.txt file, and they therefore implicitly consented to that license. This is the same basic argument that people who support getting rid of CLAs entirely put forward.

Second, there's not really a whole lot that someone could do as a legal matter if they decided to press this issue. Violation of the strict terms of a license would be a copyright violation. Prior to suing for a violation of copyright you have to register your copyright. If the copyright wasn't registered with the copyright office at the time of the infringement, then all you're allowed to sue for are your actual damages (if you've already registered when the infringement occurs, you can get statutory damages and attorney's fees). Here, since all of the licenses do the same basic thing, and since any contributor is trying to give their code away for free anyways, there wouldn't be any actual damages. So while it's possible that someone could sue to make a point, it's very unlikely, as there would be nothing to gain. Either way, I think that potential legal risk to the foundation is minimal.

[kborchers]

I have squashed the previous commits and added a 3.0 commit. Anyone have any other thoughts before this is merged?

[scottgonzalez]

Just make sure to squash those into a single commit when you're landing this.