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

Thu Aug 1 02:39:07 PDT 2019

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