Hi all, Just in case, you can find some notes from the EasyCLA webinar and Jenkins-specific questions from the webinar here <https://docs.google.com/presentation/d/1vy8riAfqzaW-PmvNIK0N6btHq2d4MYA81DKDPqWhrKU/edit?usp=sharing> . 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 <[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/fed406a1-87e9-47f7-9026-64196fc0b60en%40googlegroups.com.
