On 6/22/18 10:30 AM, Heather Flanagan wrote:
My reading of this suggests that a CLA doesn't
actually offer us any
assurances we don't already have by a) using GitHub (and therefore
agreeing to the ToS) and b) posting the licenses in the repos (which
must be inherited by anyone posting in those repos, again thanks to the
GitHub ToS).
Putting aside the question as to whether we should be using GitHub at
all, I'm reminded of a thread I was reading where people were making the
usual complaints about how dense legalese is. The answer is because when
you speak in simple, general terms you are often glossing over a lot of
detail, and in many cases this detail has real-world, legal effect.
CLAs give us many assurances that we don't already have by using GitHub
and posting licenses. For example "inbound=outbound" assumes you will
never want or need to change the license. If for some reason we need to,
without CLAs it will be impossible, we would have to rewrite the
affected code from scratch.
Or here's a problem with the agreement you excerpted: "and you agree
that you have the right to license your contribution under those terms".
Well, what if the author doesn't actually have the right to license the
contribution? What if a company decides its employee improperly
committed commercially viable IPR? In many employer/employee
relationships (varying internationally, but the case for at least some
contributors to this codebase), the CLA is what explicitly documents the
employee's right to contribute the code. You can agree that you have the
right, but if you don't actually have the right, the legal status of the
code becomes murky and that is not a situation that is favorable to the
project.
There's a reason that CLAs are longer than one paragraph... They cover
all of these edge cases. Ultimately, though, as we've discussed before
this comes down to a risk assessment. Taking the easier path now puts us
in a riskier situation over the long term. Is it too risky? Maybe...
maybe not...
Thanks,
-Benn-