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

Thu Aug 1 09:24:15 PDT 2019

+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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/seasonofdocs/attachments/20190801/3ff04420/attachment-0001.html>