[SeasonOfDocs] TheGoodDocsProject: Motion 2: Investigate implementing CLA/DCO via cla-assistant

Thu Aug 1 00:59:25 PDT 2019

+1

On Wed, Jul 31, 2019 at 11:29 PM Cameron Shorter <cameron.shorter at gmail.com>
wrote:

> Motion 2: We accept Erin's offer to do a test set up of CLA Assist.
> +1 Cameron
>
> I suspect CLA assist will address our needs. Let's accept Erin's offer to
> set it up and test to see if it will work for us. If it works, we can raise
> a separate motion to accept it.
>
> (I retrospect, this probably didn't need a motion, but I said I'd raise
> two motions in my last email, so I better follow through).
>
> On Wed, 31 Jul 2019 at 06:11, Erin McKean <emckean at google.com> wrote:
>
>> I did a little digging -- I think we could get a lightweight CLA with
>> https://github.com/cla-assistant/cla-assistant which allows for signing
>> CLAs right inside pull requests. I'm happy to volunteer to set it up if we
>> decide to go this way.
>>
>> Cameron has an excellent point about us already having the most
>> permissive license. :)
>>
>> On Tue, Jul 30, 2019 at 1:05 PM Jo Cook <jo.k.cook at gmail.com> wrote:
>>
>>> I'm in favour of 4, which could be made even better by adding it to a
>>> pull request template. That way even people who contribute by editing a
>>> file in the github interface will see it, whether they like it or not!
>>>
>>> Jo
>>>
>>> On Tue, Jul 30, 2019 at 7:24 PM Sanket Totewar <sanket at totewar.com>
>>> wrote:
>>>
>>>> I like 3. Seamless... But happy with 4 or 5 too.
>>>>
>>>> On Tue, 30 Jul 2019 at 22:37, Jared Morgan <jaredleonmorgan at gmail.com>
>>>> wrote:
>>>>
>>>>> I'd be OK with 4 if necessary and definitely 5.
>>>>>
>>>>> On Tue., 30 Jul. 2019, 21:28 Cameron Shorter, <
>>>>> cameron.shorter at gmail.com> wrote:
>>>>>
>>>>>> From my recent reading:
>>>>>> There are a few variants of CLAs.
>>>>>> 1. Developers/Employers assign their code ownership to an entity -
>>>>>> typically a trusted not-for-profit. The not-for-profit can later relicense
>>>>>> as required. This appears to be the option that Google legal explained to
>>>>>> Erin.
>>>>>> 2. Developers/Employers own their code, but provide a statement
>>>>>> saying they confirm that the not-for-profit can use under license provided.
>>>>>>
>>>>>> Both these options require a legal entity (which we haven't sourced
>>>>>> yet). Both require a system for processing CLA statements (such as
>>>>>> accepting signed statements). Both are a pain to manage.
>>>>>> For 1. having the ability to relicense can be both a positive and
>>>>>> negative, more likely a negative as you will need to get a CLA for any
>>>>>> library you depend upon.
>>>>>> Being able to relicense is important if you want to make the license
>>>>>> more permissive (eg from GPL to MIT license).
>>>>>> By selecting the CC0 licence (for templates) we are proposing to be
>>>>>> as permissive as possible, so anyone can relicense to any other license. So
>>>>>> the value of relicensing is not an issue in that case.
>>>>>>
>>>>>> 3. The DCO is lighter as usually implemented is lower overhead. All
>>>>>> developers need do is add a "--signoff" argument to a git commit message.
>>>>>> This effectively acknowledges that in the commit you agree to the DCO
>>>>>> statement.
>>>>>>
>>>>>> 4. We could go for a lighter version of this, by making a statement
>>>>>> in our CONTRIBUTOR.md doc stating. If you submit a commit to our
>>>>>> repository, then we assume that you are abiding by our DCO (which we
>>>>>> reference and include on our site). This would be the easiest option, and
>>>>>> has the same effort for contributors as 5.
>>>>>>
>>>>>> 5. Do nothing.
>>>>>>
>>>>>> My preference is 3 or 4. (I haven't seen an implementation of 4 yet
>>>>>> and would like to confirm it is a legitimate option, but there appears to
>>>>>> be plenty of 5.)
>>>>>>
>>>>>> On Tue, 30 Jul 2019 at 09:06, Erin McKean <emckean at google.com> wrote:
>>>>>>
>>>>>>> More answers: fwiw, turns out that the strongest argument for a CLA
>>>>>>> (over a DCO or nothing) is relicensing rights:
>>>>>>>
>>>>>>> "Let's say the project has code samples under Apache, and
>>>>>>> documentation under CC 4 (common licensing scheme). If they accept a
>>>>>>> patch to the docs under DCO, that patch is CC4 forever, and they
>>>>>>> don't
>>>>>>> have the right to put it in the Apache code section! And vice-versa;
>>>>>>> they'd have to ask each contribution author every single time.
>>>>>>>
>>>>>>> With CLA you have relicense rights."
>>>>>>>
>>>>>>> Also it turns out they will review a CLA (and fairly quickly) from
>>>>>>> projects not already on the approved list. :)
>>>>>>>
>>>>>>> Erin
>>>>>>>
>>>>>>> On Mon, Jul 29, 2019 at 3:54 PM Erin McKean <emckean at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I heard back that given a choice between CLA/DCO, they strongly
>>>>>>>> suggest an Apache-style CLA.
>>>>>>>>
>>>>>>>> Am now asking about the choice between CLA and nothing. ;)
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Erin
>>>>>>>>
>>>>>>>> On Mon, Jul 29, 2019 at 3:36 PM Jennifer Rondeau <
>>>>>>>> jennifer.rondeau at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> More reasons not to require a CLA. Google undoubtedly not the only
>>>>>>>>> employer with this kind of limitation.
>>>>>>>>>
>>>>>>>>> Note that although I said I'd support a DCO, my strong
>>>>>>>>> recommendation is against neither CLA nor DCO.
>>>>>>>>>
>>>>>>>>> On Mon, Jul 29, 2019 at 6:18 PM Erin McKean <emckean at google.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> From the "big company" POV, I'm not allowed to sign a CLA that
>>>>>>>>>> isn't on a (SHORT) approved list of CLAs. So it would likely be a barrier
>>>>>>>>>> for a new/small project to get on that list.
>>>>>>>>>>
>>>>>>>>>> I am asking about DCOs, will report back!
>>>>>>>>>>
>>>>>>>>>> Erin
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 29, 2019 at 2:33 PM Jennifer Rondeau <
>>>>>>>>>> jennifer.rondeau at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> A CLA involves signing and in the case of the CLAs I've needed
>>>>>>>>>>> to sign review by the governing board before you're good to go. Typically
>>>>>>>>>>> automated, but a multi-step process and more complicated if you need to
>>>>>>>>>>> sign an org-based CLA (as opposed to a CLA for an individual).
>>>>>>>>>>>
>>>>>>>>>>> A DCO is integrated with Git (GitHub and I assume other Git
>>>>>>>>>>> servers), so you provide a `--signoff` argument to your git commits. Or add
>>>>>>>>>>> it to your git alias.
>>>>>>>>>>>
>>>>>>>>>>> Either way it's an extra step of some sort, not implicit.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 29, 2019 at 5:18 PM Jared Morgan <
>>>>>>>>>>> jaredleonmorgan at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> With these agreements, does anyone have to actually sign and
>>>>>>>>>>>> return the agreement? Or do they take the form of "submitting your change
>>>>>>>>>>>> is like signing the agreement"?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm just following along with this thread for now because (as
>>>>>>>>>>>> you can probably tell) I have never heard of this before in open source
>>>>>>>>>>>> projects.
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon., 29 Jul. 2019, 07:21 Jennifer Rondeau, <
>>>>>>>>>>>> jennifer.rondeau at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> It's been my experience working with the Kubernetes community
>>>>>>>>>>>>> that a CLA can pose a non-insignificant barrier to entry for new
>>>>>>>>>>>>> contributors, especially if they aren't already familiar with FOSS. And
>>>>>>>>>>>>> it's my observation from working with a range of Write the Docs communities
>>>>>>>>>>>>> that technical writers tend to be less familiar with FOSS norms and
>>>>>>>>>>>>> practices than coders -- this includes writers from large companies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we want to maintain a project that's an open and welcoming
>>>>>>>>>>>>> for all as possible, I'd support a DCO, but I also wonder whether we need
>>>>>>>>>>>>> or want even that much. My guess is that it would be enough to drive away
>>>>>>>>>>>>> at least some otherwise valuable contributors. I don't have data about how
>>>>>>>>>>>>> many potential contributors lack of a DCO would keep away -- anyone else?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Related but not quite on topic: how do we want to solicit and
>>>>>>>>>>>>> encourage contributions? Are we assuming only contributors who are already
>>>>>>>>>>>>> familiar with a Git workflow? That would definitely keep some good work
>>>>>>>>>>>>> away, based on my experience with writing day sessions for the Write the
>>>>>>>>>>>>> Docs guide at WtD conferences.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Jul 28, 2019 at 2:25 PM Jo Cook <jo.k.cook at gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Personally I'm fine with the light tough DCO but happy to go
>>>>>>>>>>>>>> with whatever works for people contributing from large companies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All the best
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Jul 28, 2019 at 1:15 PM Cameron Shorter <
>>>>>>>>>>>>>> cameron.shorter at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It has been ~ 10 years since I last looked into open source
>>>>>>>>>>>>>>> contributor
>>>>>>>>>>>>>>> agreements, so I've been doing some research. I feel this is
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> important consideration for a project which is hopefully to
>>>>>>>>>>>>>>> be as
>>>>>>>>>>>>>>> central as ours will become.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is about having contributors confirm they are allowed to
>>>>>>>>>>>>>>> give to our
>>>>>>>>>>>>>>> project and to agree we can distribute contributions under
>>>>>>>>>>>>>>> our open
>>>>>>>>>>>>>>> licenses.
>>>>>>>>>>>>>>> We have a few options: do nothing, old heavy weight
>>>>>>>>>>>>>>> Contributor License
>>>>>>>>>>>>>>> Agreement (CLA), or lightweight Developer Certificate of
>>>>>>>>>>>>>>> Origin (DCO)
>>>>>>>>>>>>>>> Pros and cons are explained in Producing Open Source
>>>>>>>>>>>>>>> Software:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://producingoss.com/en/contributor-agreements.html#developer-certificate-of-origin
>>>>>>>>>>>>>>> I propose we adopt the light DCO:
>>>>>>>>>>>>>>> https://developercertificate.org/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd like to hear if anyone has any opinions or experience in
>>>>>>>>>>>>>>> this area
>>>>>>>>>>>>>>> (especially from those of you in big companies which have
>>>>>>>>>>>>>>> legal
>>>>>>>>>>>>>>> departments which may be opinionated.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After we've discussed for a few days (weeks if being
>>>>>>>>>>>>>>> debated), I'll put
>>>>>>>>>>>>>>> together a motion to vote on.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Cameron Shorter
>>>>>>>>>>>>>>> Technology Demystifier
>>>>>>>>>>>>>>> Open Technologies and Geospatial Consultant
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> M +61 (0) 419 142 254
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> http://about.me/jocook
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Erin McKean | Developer Relations Program Manager, Open Source
>>>>>>>>>> Strategy | emckean at google.com | she/her
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Erin McKean | Developer Relations Program Manager, Open Source
>>>>>>>> Strategy | emckean at google.com | she/her
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Erin McKean | Developer Relations Program Manager, Open Source
>>>>>>> Strategy | emckean at google.com | she/her
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SeasonOfDocs mailing list
>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cameron Shorter
>>>>>> Technology Demystifier
>>>>>> Open Technologies and Geospatial Consultant
>>>>>>
>>>>>> M +61 (0) 419 142 254
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SeasonOfDocs mailing list
>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>
>>>>> _______________________________________________
>>>>> SeasonOfDocs mailing list
>>>>> SeasonOfDocs at lists.osgeo.org
>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>
>>>> _______________________________________________
>>>> SeasonOfDocs mailing list
>>>> SeasonOfDocs at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> http://about.me/jocook
>>> _______________________________________________
>>> SeasonOfDocs mailing list
>>> SeasonOfDocs at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>
>>
>>
>> --
>> Erin McKean | Developer Relations Program Manager, Open Source Strategy |
>>  emckean at google.com | she/her
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>
>
> --
> Cameron Shorter
> Technology Demystifier
> Open Technologies and Geospatial Consultant
>
> M +61 (0) 419 142 254
>
>
>
> _______________________________________________
> SeasonOfDocs mailing list
> SeasonOfDocs at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>

-- 
------------------------
http://about.me/jocook
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/seasonofdocs/attachments/20190801/2a7f5457/attachment-0001.html>