[SeasonOfDocs] TheGoodDocsProject: Motion 1: Adopt "Developer Certificate of Origin"

Fri Aug 2 12:04:17 PDT 2019

-1 (Google legal prefers not to use DCOs ...)

On Thu, Aug 1, 2019 at 1:40 PM Jared Morgan <jaredleonmorgan at gmail.com>
wrote:

> +1
>
> On Fri., 2 Aug. 2019, 02:24 Stephanie Blotner, <sblotner59 at gmail.com>
> wrote:
>
>> +1
>>
>> On Thu, Aug 1, 2019 at 6:11 AM Clarence Cromwell <
>> 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>
>>> wrote:
>>>
>>> +1
>>>
>>> On Thu, Aug 1, 2019 at 7:03 PM Sanket Totewar <sanket at totewar.com>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> On Thu, Aug 1, 2019 at 5:59 PM Jo Cook <jo.k.cook at gmail.com> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> On Wed, Jul 31, 2019 at 11:23 PM Cameron Shorter <
>>>>> 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> 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> 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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> 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
>>>
>>> _______________________________________________
>>> SeasonOfDocs mailing list
>>> SeasonOfDocs at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>
>>
>>
>> --
>> Stephanie Blotner
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/seasonofdocs/attachments/20190802/fd9c1825/attachment-0001.html>