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