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

Thu Aug 1 02:02:50 PDT 2019

+1

On Thu, Aug 1, 2019 at 6:00 PM Jo Cook <jo.k.cook at gmail.com> wrote:

> +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
> _______________________________________________
> SeasonOfDocs mailing list
> SeasonOfDocs at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/seasonofdocs/attachments/20190801/4afa7e1e/attachment-0001.html>