Proposal: Changing the Contributor License Agreement Process

[Oleg Nenashev]

Hi all,

The Jenkins trademark is now transferred to the CDF, and Software in Public Interest has officially removed the Jenkins project from its listing of the projects. It means that the transition is [almost] over.

One remaining thing is Contributor and Company License agreements. We use this CLA process only for contributors with advanced permissions (like Jenkins core merge, access to the infrastructure, security team membership, etc.). Our current process (https://github.com/jenkinsci/infra-cla) is quite tedious, and it would be great to replace it by EasyCLA provided by the Linux Foundation: https://easycla.lfx.linuxfoundation.org/#/ . It would allow to automate signing and storage of the contributor license agreements, and it would be a big relief for the Jenkins Governance Board.

I propose to:

1. Move the CLA process to https://easycla.lfx.linuxfoundation.org/#/
2. Update individual and company CLAs to use "Linux Foundation" instead of CLA. For example, Tekton CLAs are equal to the Jenkins ones except the header. We could follow the same approach if the LF/CDF Legal team does not have specific requirements.
3. File the new process as a JEP which would deprecate the current process.

Open questions for a discussion:

• Do we want current CLA signees (individuals and companies) to re-sign the CLAs on EasyCLA? I am not a lawyer, but I suspect the answer would be "yes". There is only a limited number of contributors who would need to resign that. I believe this is doable, and it is also a good opportunity to revise permissions of inactive contributors.
• Do we want to have a separate CLA for sensitive areas like Jenkins Security Team membership? The current CLA is focused only on granting license/patent to protect the project, but there is no Non-disclosure statements which might be important for unreleased security fixes
• Do we want to change the policy and to require all contributors to sign CLA? It might be reasonable for the Jenkins core components, with assumption that we have an easy process and bots assisting with verification. I am not a huge fan of that, but this is how many projects operate.

Any feedback would be appreciated!

Best regards,

Oleg Nenashev

[Rick]

+1 from to support moving CLA process to EasyCLA

It’s not necessary to let all contributors across all the projects to adapt this process. But it’s necessary for Jenkins core and some important projects.

Best,

Rick

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/052ac23d-f3f9-4b60-8e34-945bc282e51en%40googlegroups.com.

[Oleg Nenashev]

I reviewed the lists in https://github.com/jenkinsci/infra-cla , and it looks like we will need about 25 individuals and 2 companies to resign their CLAs. Maybe more if we count former maintainers who still have permissions but no longer active. Anyway, with EasyCLA automation it won't be a problem to handle this migration.

Best regards,.

Oleg

[Tim Jacomb]

> Do we want to change the policy and to require all contributors to sign CLA? It might be reasonable for the Jenkins core components, with assumption that we have an easy process and bots assisting with verification. I am not a huge fan of that, but this is how many projects operate.

Please no, that's just a barrier to entry that makes it a lot harder for a number of people to contribute

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1e3e0782-fd1d-4fc4-9dc2-827c0c5db6b0n%40googlegroups.com.

[Ullrich Hafner]

Am 23.03.2021 um 10:23 schrieb Oleg Nenashev <o.v.ne...@gmail.com>:

Hi all,

The Jenkins trademark is now transferred to the CDF, and Software in Public Interest has officially removed the Jenkins project from its listing of the projects. It means that the transition is [almost] over.

One remaining thing is Contributor and Company License agreements. We use this CLA process only for contributors with advanced permissions (like Jenkins core merge, access to the infrastructure, security team membership, etc.). Our current process (https://github.com/jenkinsci/infra-cla) is quite tedious, and it would be great to replace it by EasyCLA provided by the Linux Foundation: https://easycla.lfx.linuxfoundation.org/#/ . It would allow to automate signing and storage of the contributor license agreements, and it would be a big relief for the Jenkins Governance Board.

I propose to:

1. Move the CLA process to https://easycla.lfx.linuxfoundation.org/#/
2. Update individual and company CLAs to use "Linux Foundation" instead of CLA. For example, Tekton CLAs are equal to the Jenkins ones except the header. We could follow the same approach if the LF/CDF Legal team does not have specific requirements.
3. File the new process as a JEP which would deprecate the current process.

+1

Open questions for a discussion:

• Do we want current CLA signees (individuals and companies) to re-sign the CLAs on EasyCLA? I am not a lawyer, but I suspect the answer would be "yes". There is only a limited number of contributors who would need to resign that. I believe this is doable, and it is also a good opportunity to revise permissions of inactive contributors.

I think that makes sense and should be not a complicated process for the small number of people. 

• Do we want to have a separate CLA for sensitive areas like Jenkins Security Team membership? The current CLA is focused only on granting license/patent to protect the project, but there is no Non-disclosure statements which might be important for unreleased security fixes
• Do we want to change the policy and to require all contributors to sign CLA? It might be reasonable for the Jenkins core components, with assumption that we have an easy process and bots assisting with verification. I am not a huge fan of that, but this is how many projects operate.

I don’t think that we should go this way. Kohsuke always tried to keep the barrier for contributions very low and I think we should continue this way. I think that we would not have so many plugins (or PRs for plugins) if we make the contribution process more complex.

[Oleg Nenashev]

> I don’t think that we should go this way. Kohsuke always tried to keep the barrier for contributions very low and I think we should continue this way. I think that we would not have so many plugins (or PRs for plugins) if we make the contribution process more complex

I would prefer to avoid setting extra boundaries as well. At the same time, it makes sense to review the current model with the LF legal team. Right now we indeed avoid the contribution obstacles, but effectively common code contributors and plugin maintainers do not sign CLA. It may cause some legal loopholes, especially in the terms of the patent right which is not covered by the MIT License used in Jenkins. Not that I expect any real issues with that, but maybe there is a way to be on the safe side with minimum impact on contributors.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/MMCTtaJZ7z0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/BED89653-649A-4259-9589-2184B4D62A40%40gmail.com.

[Andrew Grimberg]

On 3/23/21 2:54 PM, Oleg Nenashev wrote:
>> I don’t think that we should go this way. Kohsuke always tried to keep
> the barrier for contributions very low and I think we should continue
> this way. I think that we would not have so many plugins (or PRs for
> plugins) if we make the contribution process more complex
>
> I would prefer to avoid setting extra boundaries as well. At the same
> time, it makes sense to review the current model with the LF legal team.
> Right now we indeed avoid the contribution obstacles, but effectively
> common code contributors and plugin maintainers do not sign CLA. It may
> cause some legal loopholes, especially in the terms of the patent right
> which is not covered by the MIT License used in Jenkins. Not that I
> expect any real issues with that, but maybe there is a way to be on the
> safe side with minimum impact on contributors.

I'm not legal council for LF, but since I do work with several of the
projects at LF I can give you some perspective. That being said, talking
with legal is still a good idea!

There's one hard and fast thing that I can recommend and that's to
require DCO (Signed-off-by) on all changes coming in. If the DCO Probot
is not setup on the GitHub org, it should be and enabled as a required
check on all repositories.

That's the lowest bar that legal is going to tell you that you really
need to do.

After that, CLAs are a thing that some of our projects use and others
don't. Those that don't, just stick with DCO.

Since you already have CLAs in play on some repos, legal is likely to
push for you to go all out and make it a blanket thing. That being said,
EasyCLA can be configured to only be required on some repos and not all,
so that really is going to come down to what you as a project want.

-Andy-

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation

[Oleg Nenashev]

Thanks for the insights Andrew!

I agree that DCO could be a good compromise for the Jenkins core and related repositories.

I am not sure about plugin repositories, I'd guess we should make it optional though recommended for the repositories.

Best regards,

Oleg Nenashev

[Oleg Nenashev]

Hi all,

Quick progress update:

• I have reached out to the Linux Foundation legal to clarify the CLA requirements. At the moment there is no strict guidelines how projects should use CLA/DCO, and there are projects using neither of them. Apart from the potential legal risks (e.g. MIT License does not cover patent grant listed in our CLA for the submitted code), the Jenkins community can proceed as is.
• I plan to setup the EasyCLA PoC so that the current contributors could try it out and see whether the process is convenient enough. Then we can discuss changes in the CLA policy.
• I have submitted an application form to create a Jenkins account on Easy CLA. Once it is created, I will share the permissions with the Jenkins governance board members

For your information, there will be also a webinar about EasyCLA on April 8th: https://linuxfoundation.org/webinars/lfx-easycla-streamline-your-development-workflow/ . It could be a good venue to ask any questions or to share our feedback.

Best regards,

Oleg Nenashev

[Oleg Nenashev]

Hi all,

Just in case, you can find some notes from the EasyCLA webinar and Jenkins-specific questions from the webinar here.

Slides and the Video will be published soon by the Linux Foundation.

Best regards,

Oleg

[Oleg Nenashev]

Hi all,

Just a quick update on the pending project:

• At the Governance meeting in April we agreed to proceed with exploring EasyCLA
• We submitted a request to the Linux Foundation. After several iterations, we agreed to keep EasyCLA management as a part of the CDF account for now. It technically allows all individuals and contributor companies to sign a single CLA for all projects, and then moderate where they contribute by company CLA and internal guidelines
• I have got an access yesterday so that I am able to configure EasyCLA for Jenkins
• I set up a test repository in https://github.com/jenkinsci-infra-ircbot-test/test-easycla and enabled EasyCLA for it. I also enabled branch protection there, and it works well. Anyone welcome to try out the new process by submitting pull requests to the repository.

I will proceed with a process JEP to document the current state. Any feedback is welcome!

Best regards,

Oleg

[Oleg Nenashev]

Thanks to Justin Harringa, Mark Waite and Coleen Waite for testing the EasyCLA process on the https://github.com/jenkinsci-infra-ircbot-test/test-easycla  repository.

We have reported a few minor issues discovered during testing, but overall the process works pretty well.

I suggest going ahead and enabling individual CLAs for a number of repositories within jenkinsci. I suggest taking peripheral repos, because we need to figure out company CLAs and have all key maintainer permissions before enabling EasyCLA for the Jenkins core. 

I suggest voting for enabling Easy CLA in the Jenkins core next week

Best regards,

Oleg

[Mark Waite]

Those all sound great to me.

I volunteer the platformlabeler-plugin and the elastic-axis-plugin as two that could be used for testing if needed.

Mark Waite

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f7528c47-2a58-4fe1-ada6-f62bea9ced1en%40googlegroups.com.

[Tim Jacomb]

Is this close enough for a vote? Do we actually want to do this?

Moving the CLA process away from the current process sure, but enabling it on Jenkins core?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGcaoiMMF5iNhe2nUnMJgW6R0L5PTjv%3D%2B45drEdaBdAOA%40mail.gmail.com.

[Oleg Nenashev]

Hi Tim. I would not like to enforce it for the Jenkins core and components until we have all active core maintainers and company contributors to sign ICLA/CCLA. It may take months. What I want to do is to enable EasyCLA without enforcement. So I need a few repositories where we could enable EasyCLA so that everyone can prepare.

I suggest the following repositories:

• https://github.com/jenkinsci/infra-cla - good repo for testing CLA. Everyone can submit PR with removing dated CLAs while verifying their signatures in the process :)
  
• platformlabeler-plugin and the elastic-axis-plugin as suggested by Mark
  
• https://github.com/jenkinsci/custom-war-packager - not actively developed at the moment
  
• https://github.com/jenkinsci/label-verifier-plugin - not actively developed at the moment
  

Is everyone fine with the ICLA/CCLA text? There are some minor differences from the current ICLA/CCLAs we use

BR, Oleg

[Oleg Nenashev]

Hi all,

I would like to proceed with  https://github.com/jenkinsci/infra-cla and to build a new process around this repository for now (TL;DR: ditching PDFs for new CLAs and gradually migrating old ones). Any objections?

Best rgeards,

Oleg

[Ullrich Hafner]

This is a good idea, thanks for driving this!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bc10978c-ddd4-4ec7-8117-27e1dab36cf8n%40googlegroups.com.

[Tim Jacomb]

Sounds good for infra-cla repo

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4A195CEC-BE44-46C4-A76B-2298A199656D%40gmail.com.

[Mark Waite]

+1 from me.  Thanks very much for doing it.

On Mon, Nov 8, 2021 at 2:38 AM Oleg Nenashev wrote:

Hi all,

[Matt Sicker]

I think simplifying the ICLA process is a fantastic idea. It’s something I’d like to implement at Apache at some point, too. Reducing contributor friction is usually a great idea.

Matt Sicker

On Nov 8, 2021, at 05:20, Mark Waite <mark.ea...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE_xBY3S__MB%2BkRdXML2-WRbDDz-3LkyUh11OApSCfm7w%40mail.gmail.com.

[Oleg Nenashev]

Hi all,

Quick update here from the yesterday's governance meeting:

• The LFX EasyCLA support ticket is still open for jenkinsci and jenkins-infra organizations. Stapler maintainers can already adopt it if they are ready & want to try
• I pinged the LFX support team to get the request over the line. I do not have permissions to manage the CDF EasyCLA GitHub organizations with my level of the permissions, but then I can manage the repositories
  

Best regards,

Oleg