Licensing/authoring considerations

[thanethomson]

@xla brought up a good point in today's tendermint-rs call, in that we need to clarify our licensing/authoring considerations.

Some questions:

1. What's the historical context around going with the Apache 2.0 license? (cc @ebuchman) I suppose the precedent in the Rust community is to dual-license with Apache 2.0 and MIT.
2. Are there any incompatibilities between the Apache 2.0 license and our longer term goals? (cc @brapse)
3. To whom does copyright belong for the code in the repo?
4. Should we look at implementing a DCO by enforcing signing of commits, as we did for themis-contract?

Once we've gotten to some workable answers for the above, @xla brought up that we should also look into sorting out things like:

• file headers
• authors
• harmonizing metadata across Cargo.toml files

[ebuchman]

1. Liberal licenses are the go to for open source projects. Many companies can't touch GPL. Apache seems to be the leading liberal license - it provides patent protections that MIT doesn't (I believe if someone submits a contribution that is patented, not only can they not enforce the patent, they lose the license to use the software!). We could dual license with MIT but don't really see the need, I don't believe it adds much value (happy to be convinced otherwise)

2. Potentially, but license design is a massive headache and a dangerous game since new licenses increase costs for all users and contributors. That said the new MariaDB license seems to be gaining some popularity with Uniswap v3 adopting it. We could consider something like that, but still, the "future" GPL nature of it could be dangerous

3. To the author of the code. The copyright of each particular contribution is owned by the contributor. Obviously this is a mess to disentangle so for simplicity repos behave as if all authors share copyright over the entire repo, but technically speaking each author owns the copyright to their particular contribution, and agrees to license it per the repo's license (ie. Apache 2.0)

4. If we feel this brings value. My impression is that this is really only important once we start to have significant contributions from people employed at other, especially larger, companies, but I'm not against starting it sooner.

I don't have strong opinions about file headers but fine if we want to add them. Would be good to get better about AUTHORS though I'm not sure the best approach. I think the simplest thing would be to have one AUTHORs file that listed everyone thats made a non-trivial contribution (ie. more than a typo fix), and the Cargo files could say "tendermint-rs authors" or something.