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

Wed Jul 31 15:22:54 PDT 2019

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