Revisit CLA guideline for contributors about foundation HOT 19 CLOSED

The largest difference is that CLAs enable the project to relicense the code later. For instance, Facebook would have been unable to relicense osquery from BSD+patents to Apache2.0/GPL2 if they used a DCO and not a CLA. If we plan on sticking with Apache2.0/GPL2 until the end of time, then use the DCO. If there's a chance we might want to change the license in the future again, then use a CLA.

CLAs provide more protections for the covered project regarding things like legal indemnities. Endpoint security companies are somewhat litigious compared to other security sub-industries. If you think someone could involve the Linux Foundation or osquery in a future lawsuit over certain capabilities or components and their origin, it might be safer to use a CLA.

The workflow for both of these is fairly similar. It's a Github bot that keeps a CSV of allowed committers. Adding yourself to the list involves an Oauth click-through to agree to terms. The DCO is 5 bullet points and the CLA is ~10. I don't immediately buy that a DCO is less friction than a CLA. I tend to lean on the conservative side for these things and acquire the most rights/control as possible in case of future issues.

It might help to survey what other projects under the Linux Foundation have done. At the very least, the answer is one or the other (DCO or a CLA). Any other option is strictly worse.

from foundation.

I strongly recommend taking the CLA from the Apache Foundation, swapping out the appropriate entity names, and placing the text into a gist for cla-assistant to use. I can help you set it up if you want. cla-assistant was robust enough that Microsoft now depends on it for all their open-source code. You'll need to review anyone who made commits without it and get their signatures. I see at least one commit was merged without one. Offering swag and stickers helps :-).

Do we have a contact at the Linux Foundation that can help resolve this? I'm unaware if there is an official CLA and/or method for signing them, or if this is left up to individual projects.

EDIT: oic the CNCF has a guide for starting to use theirs. We should do that.

from foundation.

I think we're not under the CNCF umbrella, so your original suggestion is probably correct. I'll reach out to the linux foundation to confirm.

from foundation.

Update!

Chris points out that our charter does not require a CLA:
https://github.com/osquery/foundation/blob/master/CHARTER.md#7-intellectual-property-policy

i. All new inbound code contributions to the Project must be made using the Apache License, Version 2.0, available at https://www.apache.org/licenses/LICENSE-2.0 (the “Project License”).
ii. All new inbound code contributions must also be accompanied by a Developer Certificate of Origin (http://developercertificate.org) sign-off in the source code system that is submitted through a TSC-approved contribution process which will bind the authorized contributor and, if not self-employed, their employer to the applicable license;

He recommends against adopting a CLA as we don't need it, and instead enabling https://github.com/apps/dco and being done. This leaves copyright as held by the contributors.

Thumbsup / thumbsdown? Assuming we hit consensus, I'll add that and test some PRs with it

from foundation.

re: relicensing the code, that won't be needed anymore imho given the neutral ownership of the code and I think an ideal permissive licensing structure now

DCO is generally lower barrier to entry and from my experience, easier than an individual dealing with their company's legal department. For example, in CNCF, we give projects the choice, out of ~30 projects only a few use the CLA, the rest are just Apache-2.0+DCO

from foundation.

Hi all, sorry I didn't realize this discussion was happening here. Every project should enable the DCO. You can use this tool we coordinate with GitHub on: https://github.com/apps/dco

If your lawyers want to add a CLA, we generally use the Apache CCLA and modify it for the entity and our CLA system. We have an automated e-signature system for CLAs that simplifies the process and management of contributors for companies. It's all electronic. If you want we can draft the CCLA and get the system setup.

from foundation.

Thanks for explanation @mkdolan, can we get started on drafting the CCLA and setting up that system?

from foundation.

I think all repos in the org. Simpler that way.

from foundation.

It looks like the Linux Foundation (Or at least the CNCF) has an umbrella one. So we probably need to ping our contacts there.

cf:

• https://github.com/kubernetes/community/blob/master/CLA.md
• cncf/foundation#1

from foundation.

I think I see https://cla-assistant.io/ showing up in random PRs I use. In the interest of getting something in place, 👍 or 👎 for that? Of course, we still need text

from foundation.

I'm chatting with my contact at the CNCF. Sounds like the linux foundation does maintain a CLA tool. It’s at https://project.lfcla.com (which you can’t see any real content on yet). Details as I get them

from foundation.

He recommends against adopting a CLA as we don't need it, and instead enabling https://github.com/apps/dco and being done. This leaves copyright as held by the contributors.

@dguido, you've consistently provided good feedback on related matters, I'm curious about your thoughts of going with DCO over CLA.

from foundation.

The DCO is quite common, it's what the linux kernel uses. It is also what our charter says. (We can, of course, change the charter)

from foundation.

I spent a few hours tonight contrasting both and I feel sticking with a CLA is the best option.

• osquery has used Facebook's CLA for years and I've heard no escalations that this prevented contributions.
• Putting myself into the shoes of a contributor (I've signed CLAs, asked for approvals for DCOs, etc) as a Facebook employee the work is about the same for me (just using my experience, super super biased)
• CLA as a 1-time vs. DCO as a every-time sounds better from a casual contributor friction perspective. Again from experience working on osquery, where the majority of the community are not developers, asking for commit updates/squashes/etc is significant overhead.
• The specifics of the security industry that @dguido references suggest a CLA. We should pay special attention to the attributes of the project and what is best for it and the specific community.

from foundation.

Sounds like we think the CLA is a better route for us.

@caniszczyk can you help me setup https://project.lfcla.com/ ?

from foundation.

@mkdolan is there anything we can do to help with drafting the CCLA? It's currently a blocker for us to merge community contributions.

Also a reminder for us to update the text in https://github.com/osquery/osquery/blob/master/CONTRIBUTING.md when the CCLA is in place.

from foundation.

I wrote a blog with @mkdolan input and review on EasyCLA (with a short section versus DCO) that describes how EasyCLA works: https://www.linuxfoundation.org/blog/2019/07/easycla-beta/

from foundation.

The Apache style CLA is now in effect and I created this PR to test it: osquery/osquery#5671

It's only set for the osquery repository, but we could apply it to all. Not sure what makes the most sense. All probably?

from foundation.

I think this issue is done.

from foundation.