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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/052ac23d-f3f9-4b60-8e34-945bc282e51en%40googlegroups.com.

[Xiaojie Zhao]

+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

On 03/23/2021 17:23，[hidden email] wrote：

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/052ac23d-f3f9-4b60-8e34-945bc282e51en%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1d80d2fc.41da.1785e7783db.Coremail.zxjlwt%40126.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

On Tuesday, March 23, 2021 at 10:43:25 AM UTC+1 Xiaojie Zhao wrote:

+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

On 03/23/2021 17:23，Oleg Nenashev<[hidden email]> wrote：

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/052ac23d-f3f9-4b60-8e34-945bc282e51en%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1e3e0782-fd1d-4fc4-9dc2-827c0c5db6b0n%40googlegroups.com.

[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

On Tue, 23 Mar 2021 at 10:57, Oleg Nenashev <[hidden email]> wrote:

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

On Tuesday, March 23, 2021 at 10:43:25 AM UTC+1 Xiaojie Zhao wrote:

+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

On 03/23/2021 17:23，Oleg Nenashev<[hidden email]> wrote：

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/052ac23d-f3f9-4b60-8e34-945bc282e51en%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1e3e0782-fd1d-4fc4-9dc2-827c0c5db6b0n%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bickdh1Kd4f84nTuJwyhXJ3F6_O45X5m2X0yyD3UOLefTQ%40mail.gmail.com.

[Ulli Hafner]

Am 23.03.2021 um 10:23 schrieb Oleg Nenashev <[hidden email]>:

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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/BED89653-649A-4259-9589-2184B4D62A40%40gmail.com.

[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.

On Tue, Mar 23, 2021 at 10:29 PM Ullrich Hafner <[hidden email]> wrote:

Am 23.03.2021 um 10:23 schrieb Oleg Nenashev <[hidden email]>:

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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/BED89653-649A-4259-9589-2184B4D62A40%40gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCK9c0igJwHgxsiB5wGheM1jE8RdwtBs%2BS%3DS_uSbQ-%2BOw%40mail.gmail.com.

[Andrew Grimberg-2]

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3824c8de-c2f8-ed85-641c-54b27b538939%40linuxfoundation.org.

[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

On Tue, Mar 23, 2021, 23:10 Andrew Grimberg <[hidden email]> wrote:

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLChWJy-Yk_U%2B%3DD54J7vcF3SAS2Hf%3D7x_LjG1M4cOWbVrQ%40mail.gmail.com.

[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

On Wednesday, March 24, 2021 at 8:11:05 AM UTC+1 Oleg Nenashev wrote:

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

On Tue, Mar 23, 2021, 23:10 Andrew Grimberg <[hidden email]> wrote:

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4a67e60b-3906-4546-a845-1712121f0bdbn%40googlegroups.com.

[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

On Friday, April 2, 2021 at 4:12:31 PM UTC+2 Oleg Nenashev wrote:

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

On Wednesday, March 24, 2021 at 8:11:05 AM UTC+1 Oleg Nenashev wrote:

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

On Tue, Mar 23, 2021, 23:10 Andrew Grimberg <[hidden email]> wrote:

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/fed406a1-87e9-47f7-9026-64196fc0b60en%40googlegroups.com.