[SeasonOfDocs] TheGoodDocsProject: Motion 1: Adopt "Developer Certificate of Origin"

Thu Aug 1 13:40:10 PDT 2019

+1

On Fri., 2 Aug. 2019, 02:24 Stephanie Blotner, <sblotner59 at gmail.com> wrote:

> +1
>
> On Thu, Aug 1, 2019 at 6:11 AM Clarence Cromwell <
> clarencewcromwell at gmail.com> wrote:
>
>> +1 on developer’s certificate
>> +1 on Doctopus
>>
>> Doctopus would be a more memorable name for the project itself.
>>
>> Quills and books are clear identifiers, but we can also have an Octopus
>> with something more modern like a keyboard.
>>
>>
>>
>> Sent from my iPhone
>>
>> On Aug 1, 2019, at 2:39 AM, Felicity Brand <felicitybrand at gmail.com>
>> wrote:
>>
>> +1
>>
>> On Thu, Aug 1, 2019 at 7:03 PM Sanket Totewar <sanket at totewar.com> wrote:
>>
>>> +1
>>>
>>> On Thu, Aug 1, 2019 at 5:59 PM Jo Cook <jo.k.cook at gmail.com> wrote:
>>>
>>>> +1
>>>>
>>>> On Wed, Jul 31, 2019 at 11:23 PM Cameron Shorter <
>>>> cameron.shorter at gmail.com> wrote:
>>>>
>>>>> Following on from our meeting yesterday, and this email thread, and
>>>>> our meeting yesterday, I'm breaking this discussion into two motions to
>>>>> vote on.
>>>>>
>>>>> Motion 1: I propose that TheGoodDocsProject adopt the "Developer
>>>>> Certificate of Origin", current at version 1.0, as our Contributor License
>>>>> Agreement:
>>>>> https://developercertificate.org/
>>>>> (This motion doesn't extend to how we implement).
>>>>>
>>>>> +1 Cameron
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> 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
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>
>
> --
> Stephanie Blotner
>
> _______________________________________________
> 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/20190802/cfb70f7f/attachment-0001.html>