[SeasonOfDocs] TheGoodDocsProject: Contributor Agreements

Tue Jul 30 13:04:17 PDT 2019

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