[SeasonOfDocs] TheGoodDocsProject: Contributor Agreements

Tue Jul 30 05:36:47 PDT 2019

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