[SeasonOfDocs] TheGoodDocsProject: Contributor Agreements

Tue Jul 30 13:11:15 PDT 2019

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