[SeasonOfDocs] TheGoodDocsProject: Contributor Agreements

Tue Jul 30 11:23:58 PDT 2019

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