Intake of contributions, aka DCO or CLA or ...
Opened this issue · 17 comments
As part of governance that we may be able to address, at least for now, is if we want to take contributions right now under a DCO or do we need a CLA.
One option is to take things now under a DCO, and leave the CLA for how governance and umbrella organization work out.
Related to issue #5 .
I would strongly recommend DCO. CLA is a huge barrier to participation. That said, I'd strongly recommend having github enforce DCO automatically...
In my experience the Apache CLA sails through corporate legal departments, and I would expect a DCO to be difficult for some employees. Can we accept either?
@richsalz I appreciate you bringing other experience to the conversation :) One of the great things about working in groups is seeing how things differ from my own experience :)
My experience has been that CLAs are generally a hassle, because they require legal to wrap their heads around them. I addition, its pretty easy to scope them in ways that worry legal groups. For example: the Apache CLA (if memory serves) is scoped to everything at the Apache Foundation, not just a single project. I've had issues with this in the past with legal, as it often differs from the scope of what the company would like to approve.
I'm especially curious about situations where DCO is difficult, as I've usually experienced it as the low friction option :)
Take the Apache CLA and cross out ASF and write your own org. That's what we did at OpenSSL for example.
I don't have stories against DCO (had to do them all the time when I was an IBMer:), but I do know that companies find ASF CLA easy. Which is why I said can we do both?
Oh... and one other thing on CLAs... I often end up helping engineers who find legal very intimidating and haven't the foggiest notion how to begin engaging with them over a CLA. It's a big deal for a lot of folks. I've got over 15 years of trusted partnership with my legal group, and I still find it a hassle to work CLAs... for folks-on-the-line its much worse.
I meant either :) Either the individual signs a DCO with each commit, or their employer signs a CLA.
@richsalz Got it. One question though... does that mean we have some commits without a DCO in the repo?
One question though... does that mean we have some commits without a DCO in the repo?
Yes, because the org will have CLA on file for them. (I guess a corporate CLA and a schedule A naming them.)
I would be concerned about taking DCO contributions from some organization known for intellectual property concerns that didn't have corporate approval. Shrug.
@richsalz Do you know of other examples of folks doing either or? Do they have any tooling to support enforcing it we might borrow?
I know lots of folks who have CLA enforcement machinery :) And I know that github has out of the box DCO enforcement. The LF has a bunch of out of the box CLA enforcement machinery.
Reliable enforcement of 'either or' was what I was curious about. Particularly we need to make sure to maintain auditability so that a user looking at the repo can tell that each commit was either DCOed or under CLA reliably.
Since we are looking to take contributions nowish, I'd suggest we turn on Github's DCO enforcement now, and alternately accept a CLA when we can reliably support it in tooling. That produces the minimum impedance out of the box, but we can bring in the CLA option subsequently as we get tooling working.
Sound good?
Have we decided yet as a community what license for what sorts of things?
Starting with anecdata after my early years dealing with the Fedora CLA (that no longer exists but everyone still references), my experience talking with many community managers and members is that CLAs tend to have a very bad reputation. So I look at them with a lot of caution because I don't want to scare away all those contributors, especially ones who don't have their own legal departments. (Those who are neutral or even fans of CLAs may not find a lack of a CLA to be a barrier to participation, by comparison.)
I think a way to frame this is, what does a CLA give this project that it needs? We would need a legal entity to own the resulting copyright licenses. What would it do with those licenses? Are we anticipating legal or patent challenges to this list of words and terms?
Similarly, what does the DCO do for the project?
Let's wrap this into a list of requirements:
- Project needs to know a contribution can be legally put under the project's license. (MUST)
- To know the permissive state is true, there needs to be a process that is auditable. (MUST)
- It should be easy for contributors to use. (SHOULD)
- It should fit into the systems and tooling the project is adopting. (SHOULD)
I'm not sure I agree that the project needs to enforce copyright licenses in court as a requirement, for example.
What's missing on that list?
GitHub automatically declares that any pull requests that get merged come under the repository license, so that's a thing. CLAs are a bad choice, so that's probably not a great suggestion. A DCO would be the better of the two.
@inclusivenaming/leads -- for input
I'm +1 to DCO
+1 to DCO and reassess in the future, as necessary.