Hi Erin, would you mind expanding your reasoning for the -1. Typically
if you vote -1 (considered a blocking vote), then the onus is on you to
explain what it would take to change to vote to a non-blocking vote.
If Google legal are mildly against, then I suggest change to a -0 ("I
prefer not, and this is why ...").
I'm hoping Google legal can present us with a case which addresses the
concerns we have about introducing a high barrier to entry for
non-technical contributors, noting that we don't have a legal entity to
make use of.
I'd be happy to join a hangouts meeting with them, which I suspect would
be helpful.
Cheers, Cameron
On 3/8/19 5:04 am, Erin McKean wrote:
> -1 (Google legal prefers not to use DCOs ...)
>
> On Thu, Aug 1, 2019 at 1:40 PM Jared Morgan <jaredleonmorgan at gmail.com
> <mailto:jaredleonmorgan at gmail.com>> wrote:
>
> +1
>
> On Fri., 2 Aug. 2019, 02:24 Stephanie Blotner,
> <sblotner59 at gmail.com <mailto:sblotner59 at gmail.com>> wrote:
>
> +1
>
> On Thu, Aug 1, 2019 at 6:11 AM Clarence Cromwell
> <clarencewcromwell at gmail.com
> <mailto:clarencewcromwell at gmail.com>> wrote:
>
> +1 on developer’s certificate
> +1 on Doctopus
>
> Doctopus would be a more memorable name for the project
> itself.
>
> Quills and books are clear identifiers, but we can also
> have an Octopus with something more modern like a keyboard.
>
>
>
> Sent from my iPhone
>
> On Aug 1, 2019, at 2:39 AM, Felicity Brand
> <felicitybrand at gmail.com <mailto:felicitybrand at gmail.com>>
> wrote:
>
>> +1
>>
>> On Thu, Aug 1, 2019 at 7:03 PM Sanket Totewar
>> <sanket at totewar.com <mailto:sanket at totewar.com>> wrote:
>>
>> +1
>>
>> On Thu, Aug 1, 2019 at 5:59 PM Jo Cook
>> <jo.k.cook at gmail.com <mailto:jo.k.cook at gmail.com>> wrote:
>>
>> +1
>>
>> On Wed, Jul 31, 2019 at 11:23 PM Cameron Shorter
>> <cameron.shorter at gmail.com
>> <mailto:cameron.shorter at gmail.com>> wrote:
>>
>> Following on from our meeting yesterday, and
>> this email thread, and our meeting yesterday,
>> I'm breaking this discussion into two motions
>> to vote on.
>>
>> Motion 1: I propose that TheGoodDocsProject
>> adopt the "Developer Certificate of Origin",
>> current at version 1.0, as our Contributor
>> License Agreement:
>> https://developercertificate.org/
>> (This motion doesn't extend to how we implement).
>>
>> +1 Cameron
>>
>> On Wed, 31 Jul 2019 at 06:11, Erin McKean
>> <emckean at google.com
>> <mailto:emckean at google.com>> wrote:
>>
>> 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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>>
>>
>> --
>>
>> ------------------------
>> http://about.me/jocook
>> _______________________________________________
>> SeasonOfDocs
>> mailing
>> list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>> _______________________________________________
>> SeasonOfDocs
>> mailing
>> list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>> _______________________________________________
>> SeasonOfDocs
>> mailing
>> list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto: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
>> <mailto:emckean at google.com> | she/her
>>
>>
>>
>> --
>> Erin
>> McKean | Developer
>> Relations Program
>> Manager, Open
>> Source
>> Strategy |emckean at google.com
>> <mailto:emckean at google.com> | she/her
>>
>>
>>
>> --
>> Erin
>> McKean | Developer
>> Relations Program
>> Manager, Open Source
>> Strategy |emckean at google.com
>> <mailto:emckean at google.com> | she/her
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto: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
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>>
>>
>> --
>> ------------------------
>> http://about.me/jocook
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto: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
>> <mailto:emckean at google.com> | she/her
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto: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
>>
>>
>>
>>
>>
>> --
>> ------------------------
>> http://about.me/jocook
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> <mailto:SeasonOfDocs at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
> _______________________________________________
> SeasonOfDocs mailing list
> SeasonOfDocs at lists.osgeo.org
> <mailto:SeasonOfDocs at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>
>
>
> --
> Stephanie Blotner
>
> _______________________________________________
> SeasonOfDocs mailing list
> SeasonOfDocs at lists.osgeo.org <mailto:SeasonOfDocs at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>
> _______________________________________________
> SeasonOfDocs mailing list
> SeasonOfDocs at lists.osgeo.org <mailto: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 <mailto: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/20190803/1d7ab775/attachment-0001.html>