Subject: [Ietf-and-github] Mail regarding draft-ietf-git-github-wg-configuration, section 3.1 (Contributions)

From: Stephan Wenger <[email-masked]>
Date: Mon, 4 Mar 2019 17:16:09 +0000

Hi,

One concern I have when I see people, in an IETF context, work on docs in toolchains other than IETF mailing lists and posting of I-Ds on the IETF infrastructure is that I think we should ensure that BCP79 sticks.  BCP79 is the IETF’s patent policy.  A scenario to avoid is that people insert patented technologies without being bound by the patent policy.  To avoid that, there ought to be a mechanism that a) unambiguously makes it clear that any written contribution using GitHib tools constitute Contributions in the BCP79 sense, and b) ensures that a user that makes a written contribution using GitHub tools would have seen the Note Well at least once.

I believe that most GitHub-using working groups in the IETF have assured that by including something like a click-through of the Note Well when accessing the GitHub repository (writing to it in whatever form).  That, I think is sufficient, but perhaps should be documented in this draft.  I  don’t know enough about the mechanics to propose text myself.   Lots of that may already be present in Martin’s template, but that template is hard to read/understand for someone like me, who’s not writing software or webpages.

One thing I don’t understand is why the Trust outbound license needs to be present in the repository, as suggested in section 3.1.  Especially for a WG that uses GitHub only for maintaining documents and not software.  Can someone explain or point me to an explanation?

Thanks,
Stephan

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Mar 2019 21:42:33 -0500

Hi Stephan,

I encourage you to attempt to contribute to a draft repository on GitHub.  The BCP79 notice is perhaps not as prominent as you might like, but there is a fairly clear path to it.

In case you can't find an example, here's a link where you can create an issue for the draft I just posted: https://github.com/martinthomson/hx-uri/issues/new

I tend to think that is adequate.  If you disagree, we can discuss the pros and cons of searching for something more robust.

Section 3.1 of the draft we're discussing here (of the long name) includes provisions designed to accomplish the goal you describe.  And yes, the template code I maintain emplaces a default notice.  I understand that reading the code is difficult (I'll be the first to acknowledge how arcane this stuff is), but it is described in language I hope you can understand here: https://github.com/martinthomson/i-d-template/blob/master/doc/FEATURES.md#setup-a-repository

Regarding the trust notice or the content of the contributing notice, that's not something I'd care to comment on.  You can see what I have, which is - in part - something recommended by the IETF Trust and IESG, and in part just text that I believe to be helpful: https://github.com/martinthomson/i-d-template/blob/master/template/CONTRIBUTING.md

Cheers,
Martin

On Tue, Mar 5, 2019, at 04:16, Stephan Wenger wrote:
>  
> Hi,
> 
> 
> One concern I have when I see people, in an IETF context, work on docs 
> in toolchains other than IETF mailing lists and posting of I-Ds on the 
> IETF infrastructure is that I think we should ensure that BCP79 sticks. 
> BCP79 is the IETF’s patent policy. A scenario to avoid is that people 
> insert patented technologies without being bound by the patent policy. 
> To avoid that, there ought to be a mechanism that a) unambiguously 
> makes it clear that any written contribution using GitHib tools 
> constitute Contributions in the BCP79 sense, and b) ensures that a user 
> that makes a written contribution using GitHub tools would have seen 
> the Note Well at least once. 
> 
> 
> I believe that most GitHub-using working groups in the IETF have 
> assured that by including something like a click-through of the Note 
> Well when accessing the GitHub repository (writing to it in whatever 
> form). That, I think is sufficient, but perhaps should be documented in 
> this draft. I don’t know enough about the mechanics to propose text 
> myself. Lots of that may already be present in Martin’s template, but 
> that template is hard to read/understand for someone like me, who’s not 
> writing software or webpages.
> 
> 
> One thing I don’t understand is why the Trust outbound license needs to 
> be present in the repository, as suggested in section 3.1. Especially 
> for a WG that uses GitHub only for maintaining documents and not 
> software. Can someone explain or point me to an explanation?
> 
> 
> Thanks,
> 
> Stephan
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf-and-github mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-and-github
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 5 Mar 2019 02:57:55 +0000

Hi Martin,
Thanks for your comments.  Please see inline.
S.

On 3/4/19, 18:42, "Ietf-and-github on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Stephan,

    

StW: Yes, this seems adequate.  However, I thought the subject draft is guidance for WGs setting up their own GitHub projects.  Nowhere it is mandated that they use the IETF "tree" or whatever that thing may be called.  In theory, I could set up my own GitHub repository under my own name, not using your excellent infrastructure, no Note Well, no nothing, and invite the working group to contribute.  Then all kinds of random people (including potentially malicious ones) could theoretically make Contributions in the BCP79 sense arguably without being bound by BCP79.  So I guess there should be a word of warning in this draft--using the Martin Thomson-style infrastructure and the IETF tree (or whatever that thing is called), or otherwise be very careful to implement your own mechanisms to ensure that all Contributions are made in accordance with BCP79 and the Note Well.

StW: yes, this is good, and so is your whole infrastructure.  As pointed out above, we are not mandating its use, though...

StW: Your "Contributing" file is just fine with me.  Personally, I consider the code component part of it a rather minor aspect for IETF work, and I think if you look at litigation statistics of IETF related subject matter, you would likely agree.  That's why I asked why that aspect is prominently mentioned, while no particular attention is drawn to BCP79 (which is where the music plays).  I'll wait a bit more for others to comment.

    Cheers,
    Martin

---

From: "Brad Biddle" <[email-masked]>
Date: Mon, 04 Mar 2019 22:11:55 -0800

All — an idea, offered for discussion: what about using the 
CLA-assistant tool to ensure that participants affirmatively acknowledge 
the current CONTRIBUTING.MD text (or a similar variation on the Note 
Well text)? I.e., the tool could present this text and require an 
express acknowledgement.

See:
https://github.com/cla-assistant/cla-assistant
https://cla-assistant.io/

Several groups I work with use this tool in connection with their GitHub 
repositories, and I gather it’s pretty seamless. From a legal 
perspective it would offer a stronger argument that participants have in 
fact agreed to the relevant IETF terms than the current model.

—Brad

Brad Biddle | [email-masked] | +1.503.502.1259 (mobile) | 
http://biddle.law

On 4 Mar 2019, at 18:57, Stephan Wenger wrote:

> On 3/4/19, 18:42, "Ietf-and-github on behalf of Martin Thomson" 
> <[email-masked] on behalf of [email-masked]> 
> wrote:
>
>     Hi Stephan,
>
>     I encourage you to attempt to contribute to a draft repository on 
> GitHub.  The BCP79 notice is perhaps not as prominent as you might 
> like, but there is a fairly clear path to it.
>
>     In case you can't find an example, here's a link where you can 
> create an issue for the draft I just posted: 
> https://github.com/martinthomson/hx-uri/issues/new
>
>     I tend to think that is adequate.  If you disagree, we can discuss 
> the pros and cons of searching for something more robust.
>
> StW: Yes, this seems adequate.  However, I thought the subject draft 
> is guidance for WGs setting up their own GitHub projects.  Nowhere it 
> is mandated that they use the IETF "tree" or whatever that thing may 
> be called.  In theory, I could set up my own GitHub repository under 
> my own name, not using your excellent infrastructure, no Note Well, no 
> nothing, and invite the working group to contribute.  Then all kinds 
> of random people (including potentially malicious ones) could 
> theoretically make Contributions in the BCP79 sense arguably without 
> being bound by BCP79.  So I guess there should be a word of warning in 
> this draft--using the Martin Thomson-style infrastructure and the IETF 
> tree (or whatever that thing is called), or otherwise be very careful 
> to implement your own mechanisms to ensure that all Contributions are 
> made in accordance with BCP79 and the Note Well.
>
>     Section 3.1 of the draft we're discussing here (of the long name) 
> includes provisions designed to accomplish the goal you describe.  And 
> yes, the template code I maintain emplaces a default notice.  I 
> understand that reading the code is difficult (I'll be the first to 
> acknowledge how arcane this stuff is), but it is described in language 
> I hope you can understand here: 
> https://github.com/martinthomson/i-d-template/blob/master/doc/FEATURES.md#setup-a-repository
>
> StW: yes, this is good, and so is your whole infrastructure.  As 
> pointed out above, we are not mandating its use, though...
>
>     Regarding the trust notice or the content of the contributing 
> notice, that's not something I'd care to comment on.  You can see what 
> I have, which is - in part - something recommended by the IETF Trust 
> and IESG, and in part just text that I believe to be helpful: 
> https://github.com/martinthomson/i-d-template/blob/master/template/CONTRIBUTING.md
>
> StW: Your "Contributing" file is just fine with me.  Personally, I 
> consider the code component part of it a rather minor aspect for IETF 
> work, and I think if you look at litigation statistics of IETF related 
> subject matter, you would likely agree.  That's why I asked why that 
> aspect is prominently mentioned, while no particular attention is 
> drawn to BCP79 (which is where the music plays).  I'll wait a bit more 
> for others to comment.
>
>     Cheers,
>     Martin
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Mar 2019 12:37:31 -0500

Hi Brad,

That is certainly an option.  My experience with the W3C process, which uses a similar setup, is that it does add friction.  My personal preference is not to add that.  Though they are fairly simple and lightweight, they tend to trigger processes in legal departments that are less lightweight, so it is not entirely free from costs.

--Martin

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Mar 2019 12:44:26 -0500

> StW: Yes, this seems adequate.  However, I thought the subject draft is 
> guidance for WGs setting up their own GitHub projects.  Nowhere it is 
> mandated that they use the IETF "tree" or whatever that thing may be 
> called.  In theory, I could set up my own GitHub repository under my 
> own name, not using your excellent infrastructure, no Note Well, no 
> nothing, and invite the working group to contribute.  Then all kinds of 
> random people (including potentially malicious ones) could 

This is certainly a risk we bear, but not one that we avoid by writing things down in documents (which seems to be our only real tool, other than filling inboxes and mail archives with words, that is).  People will make venues that accept contributions and fail to create the proper notices.  That is what tends to happen already.  For instance, not to pick on anyone in particular, but I see plenty of personal repositories with drafts sitting in them that accept issues and pull requests but don't have any notices attached.

The best we can do is write down what should happen and smooth the path for the good stuff as much as possible.  My view is that the draft we're discussing does pretty much what it needs to do (or at least can do) in this regard.

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 5 Mar 2019 18:08:53 +0000

StW: Reading this, I grow really worried.  Are we potentially giving up a, so far, reasonably solid, and reasonably well working (compared to certain other SDOs I could name) IPR regime for the mere expediency developing specs?  Specs, that may potentially become unusable due to IPR problems that were made possible by perhaps somewhat naïve facilitators?
It may be out of scope of the WG as chartered, but it sounds to me that a somewhat heavier hand may be required.

StW: within the scope of the WG and the draft in question, I believe, as a minimum we could and should add large warning signs making readers aware of possible IPR related pitfalls of using anything beyond IETF-hosted mailing lists and I-D submissions for the deliberation of documents.  And point them to appropriate toolchainss, like yours.  For example (and this needs to be wordsmithed for sure):

"The IETF requires in certain cases the disclosure of IP inserted in into Internet Drafts through Contributions; see BCP79.  If a WG using GitHub does not ensure, through technical means, that contributing through GitHub mechanisms falls under the BCP79 definition of Contributions and that contributors through GitHub are aware that they contribute under BCP79, the resulting RFC may run a considerably higher risk of not being deployable through IP encumbrance not known to the WG.  Martin/the IETF/the tools team/whoever provides a handy set of mechanisms for GitHub that to a large extent alleviates that risk--go <here> to download it.  We suggest to use it, or use something else that has the same effect. "

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Mar 2019 18:27:21 +0000

> but I see plenty of personal repositories with drafts sitting in them that accept issues and pull requests but don't have any notices attached.

Isn't that okay?  Presumably when the submit the document to the IETF datatracker, they are accepting the IETF copyright and intellectual property requirements.   If folks choose to collaborate with an individual, trusting that the right thing will be done, who can stop them?  Prior to that, consider it as a dual-licensed thing if you want.

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 5 Mar 2019 18:45:59 +0000

Hi Rich,
No, I fear it's not OK.  See below.
Stephan

    > but I see plenty of personal repositories with drafts sitting in them that accept issues and pull requests but don't have any notices attached.
    
    Isn't that okay?  Presumably when the submit the document to the IETF datatracker, they are accepting the IETF copyright and intellectual property requirements.  

StW: Who's "They"?  The submitters, right?    Assume there are 10 people contributing on GitHub, three named editors,  seven guys contributing through GitHub, and one of the editors finally submits to the IETF machine.  Clearly, the submitter is under BCP79.  The (named) editors, perhaps.  (Perhaps not.  Haven't done that analysis.)  But the other seven, who may have never seen a Note Well, and could perhaps convincingly argue in a courtroom that they didn't know that they have a disclosure obligation under BCP79?  What if one of them is nice and competent enough to be accepted into the gang, but has malicious intent?  With the perhaps only sanction being bad reputation in the community?  
There's a reason why most sane open source projects make you sign a CLA before they accept anything into their repository.  I'm arguing we need something similar, or at least need text in the subject draft that tells folks that they enter a minefield if they are not careful.

 If folks choose to collaborate with an individual, trusting that the right thing will be done, who can stop them?  Prior to that, consider it as a dual-licensed thing if you want.

StW: I agree there's always a risk.  Private communication can be done today.  However, the current toolchain generally discourages such individualism--more often than not people are ask to propose text in writing, on the IETF mailing lists--whereas private GitHub repositories would almost encourage such behavior (as it may be seen as more lightweight and friendly than posting to an IETF list).  
Further, I argued before that a more heavy-handed approach may be the best, though that's out of scope.
Another point: your remark regarding dual licensing seems to suggest that you think here in the copyright dimension.  There may be a risk in that dimension as well, but it's dwarfed by the patent related risks.  With patent IP in mind, your "dual licensing" remark does not make sense to me.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Mar 2019 22:42:05 -0500

On Wed, Mar 6, 2019, at 05:08, Stephan Wenger wrote:
> "The IETF requires in certain cases the disclosure of IP inserted in 
> into Internet Drafts through Contributions; see BCP79.  If a WG using 
> GitHub does not ensure, through technical means, that contributing 
> through GitHub mechanisms falls under the BCP79 definition of 
> Contributions and that contributors through GitHub are aware that they 
> contribute under BCP79, the resulting RFC may run a considerably higher 
> risk of not being deployable through IP encumbrance not known to the 
> WG.  Martin/the IETF/the tools team/whoever provides a handy set of 
> mechanisms for GitHub that to a large extent alleviates that risk--go 
> <here> to download it.  We suggest to use it, or use something else 
> that has the same effect. "

I'm OK with adding more language here, explaining why we have CONTRIBUTING terms and what they should include.  Like (I suspect) Rich, I'm leery of over-proscribing here because there are just too many ways in which IPR-encumbered stuff can leak in.  However, if these notices are in place, tools like GitHub are an improvement in that they provide better audit trails.  It's not much good if we don't have the notices though, so by all means add the text.

Perhaps the authors of this draft have it sitting somewhere in GitHub and you could make a pull request.  I think that half of what you ask for is there, it's just missing some of the rationale-y context.

---

From: Christopher Wood <[email-masked]>
Date: Tue, 19 Mar 2019 09:02:31 -0700

On Tue, Mar 5, 2019 at 7:42 PM Martin Thomson <[email-masked]> wrote:
> Perhaps the authors of this draft have it sitting somewhere in GitHub and you could make a pull request.

For reference: https://github.com/ietf-gitwg/draft-ietf-git-github-wg-configuration

Best,
Chris