[SeasonOfDocs] TheGoodDocsProject: Contributor Agreements

Tue Jul 30 04:28:29 PDT 2019

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