New subject: Handling spec writing process @ GitHub [+legal]

2 Sep 2015

      As promised, here is a primer specifically for UMA on how to use open
GitHub repositories for open standards work while proportionally managing
the need to avoid or deflect proprietary and other inappropriate
contributions.

The concern about GitHub issues potentially introducing unacceptable IP
into the workgroup content pipeline is addressed by projects on GitHub in a
few ways.  The main thing is what Justin said: use a LICENSE.md file in the
main project repository root directory and that is generally agreed to
apply to all the content in the repo unless otherwise indicated.  However,
this may be too loose for some projects.

To provide even more tools for managing the risks of inappropriate or
unacceptable contributions, GitHub directly supports workflow and event
trigger solutions to ensure appropriate notices.  To trigger an automatic
notice to all users who submit an issue in our repo, I recommend adding a
CONTRIBUTING file (CONTRIBUTING.md).  If a repo has a file with this name,
then whenever someone opens a pull request or creates an issue, they will
see a link to that file.

A good example is:
https://github.com/opengovernment/opengovernment/blob/master/CONTRIBUTING.md

The GitHub documentation is here:
https://help.github.com/articles/setting-guidelines-for-repository-contribut...

I have created a starting file for our repository and submitted a pull
request here:
https://github.com/KantaraInitiative/wg-uma/pull/186

The CONTRIBUTING.md file just needs to be anywhere in the root of your
project's repository, where one expects to see a README and LICENSE file.
This is one of the basic practices that makes participation and
contribution to a variety of projects in GitHub quick, easy and effective.
The standard practice enables anybody to quickly scan a few key files and
get a sense of the project landscape.

The very tightest method to lock down contributor IP assignment is an
affirmative signed agreement to terms.  I'm speaking with GitHub people
about legal projects operating on their site and ask what they think about
adding a function enabling Repo owners to require an affirmative assent to
the LICENSE file in order to make a pull request or submit an issue (eg a
check box creating a logged event associating the user account with the
action and the then current files at the time of the action).

For the UMA GitHub repository, at this point requiring an affirmative
consent to our open IP terms seems like overkill.  Especially given it is
our choice whether to accept and incorporate material submitted via issues
into our work.  Using GitHub is a very very good way to open up to a larger
world of collaborators and implementers and others and it is a powerful way
for teams to collaborate internally and with partner teams/projects.
Closing the repo to prevent contribution of issues would be disproportional
to the risk and would signal a less open style. Given Kantara membership
for contributors is free and depends on voluntary allocation of time and
donation of IP, a culture of inviting participation rather than dampening
it would be the best fit.  The best GitHub projects (and the best open
projects I am familiar with) embrace using issues for the general public to
ask questions and sometime for other innovative and very beneficial
solicitations of feedback/public review and other innovative uses.  The
current best practice of presenting a notice at the top of the submission
box is appropriate and well used by GitHub projects of all sizes and types.

Thanks,
 - Dazza

PS: I just noticed we actually don't have a standard LICENSE.md file in our
repo.  Not good. I created a Pull request for that too, here:
https://github.com/KantaraInitiative/wg-uma/pull/187  The wording of the
LICENSE.md file I threw together should probably be further crafted, but it
inludes links to the Kantara source license materials and it should be good
enough to get this on the map and start garnering the benefits of this
standard practice for identifying the license terms applicable to content
in GitHub repositories.  Some discussion of license wording is needed (eg
whether to copy/paste the Kantara license into a GitHub LICENSE.md file or
to use the LICENSE.md file to point people to the Kantara IP pages).
   _ _ _ _ _ _ _ _ _ _ _ _ _ _
   |   Dazza Greenwood, JD
   |   CIVICS.com, Founder & Principal
   |   MIT Media Lab, Visiting Scientist
   |     Vmail: 617.500.3644
   |     Email: dazza@CIVICS.com
   |     Biz: http://CIVICS.com
   |     MIT: https://law.MIT.edu
   |     Me: DazzaGreenwood.com
   |     Twitter: @DazzaGreenwood
   |     Google+: google.com/+DazzaGreenwood
   |     LinkedIn: linkedin.com/in/DazzaGreenwood
   |     GitHub: github.com/DazzaGreenwood/Interface
   |     Postal: P.O. Box 425845 Cambridge, MA  02142
   | _ _ _ _ _ _ _ _ _ _ _ _ _ _

On Wed, Sep 2, 2015 at 10:47 AM, Dazza Greenwood  wrote:
...
What Justin said should reasonably suffice but to add more IP protection GitHub
can produce an automatic notice to all issue submitters. We just need a How
to Contribute to the Repo file to trigger this feature. I'll post a link in
a few minutes to show how and provide example organizations that do this
practice.
|  Sent from my iPhone
   |  Please Forgive Typos
   _________________
   |   Dazza Greenwood, JD
   |   CIVICS.com http://civics.com/, Founder & Principal
   |   MIT Media Lab, Visiting Scientist
   |     Vmail: 617.500.3644
   |     Email: dazza@CIVICS.com
   |     Biz: http://CIVICS.com
   |     MIT: https://law.MIT.edu https://law.mit.edu/
   |     Me: DazzaGreenwood.com http://dazzagreenwood.com/
   |     Twitter: @DazzaGreenwood
   |     Google+: google.com/+DazzaGreenwood
   |     LinkedIn: linkedin.com/in/DazzaGreenwood
   |     GitHub: github.com/DazzaGreenwood/Interface
On Sep 2, 2015, at 10:40 AM, Eve Maler  wrote:
This is great input. Dazza also aligned with transparency generically in
his previous note; now that we’ve brought up the IP regime specifically, it
would be good to see if the DoLs (disputation of lawyers) as a whole have
additional thoughts. I’ve flagged the topic in the subject line.
We do have a README with an IP health warning now, seen here…
https://github.com/KantaraInitiative/wg-uma
Perhaps you and Maciej and I can take this offline, but I see that COSE
decided to have separate repositories in order to get …/cose-issues. Since
the wg-uma repository currently sits under …/KantaraInitiative, I wonder
what’s a good way to put the warning in front of people when they hit the
issues landing page.
Eve
On 2 Sep 2015, at 7:18 AM, Justin Richer  wrote:
I would strongly recommend *against* closing the issue tracker. If you had
done so before, I wouldn’t have been able to submit *any* of the issues
that I had. Don’t stand in the way of well meaning people who want to make
contributions. :)
I’m not a lawyer, but I’ve dealt with this in other venues. In software,
generally, reported issues in a public tracker like this are considered
contributions, and not all contributions covered by whatever licensing the
codebase has. And since the issues do not directly affect the codebase
(even pull requests) but have to go through a core contributor’s hands,
there’s a gating system built in. You can also put a notice to this effect
(like the IETF Note Well or a software project’s LICENSE file) in the main
project that the issue tracker is attached to. We’re doing something like
this with COSE:
https://github.com/cose-wg/cose-issues/
Basically, it’s a contract-of-adhesion kind of thing, where if you
contribute you’re agreeing to IPR associated with it, without signing
anything. Now if only we had consent receipts or something that could
generate from this transaction...
— Justin
On Sep 2, 2015, at 12:07 AM, Eve Maler  wrote:
Oh sorry, you did address closing the repo. I think we can only execute on
“Only primary editors should have write access to the repository and should
be allowed to make changes directly to it” if we do that, and it will have
the same effect on the issues, iirc.
Eve
On 1 Sep 2015, at 9:05 PM, Eve Maler  wrote:
This makes sense to me. I think James brought up using branches for
everything just because he’s involved in insanely large projects. :-)
We didn’t actually conclude our discussion of whether to “close” the repo
in order to look after IP hygiene, but it sort of relates to this topic.
(Though pull requests from random non-participant strangers can always be
put aside; it’s more the issue discussions that we were asking about).
Eve
On 1 Sep 2015, at 7:24 PM, Justin Richer  wrote:
The overhead associated with fully distributed development when there is a
clear core team is not worth the headaches it can cause, especially since
nobody that I can see would be taking the job of patch integrator to manage
all the pull requests. Having an editor create a pull request and then
merge it themselves into the main repository is just a waste of that
editor’s time.
Only primary editors should have write access to the repository and should
be allowed to make changes directly to it. Things that are WG consensus
should go on “master” (or the appropriate version-tracked major branch),
proposed solutions and text by the primary editors should go on branches in
the main repository and brought to the group for feedback.
Non-editors (like myself) can fork the repository, branch, and create
either pull requests or simply reference commits and issues from there.
— Justin
On Sep 1, 2015, at 10:14 PM, Maciej Machulak 
wrote:
Hi all,
I refer to my earlier email - any comments? :-) Thanks!
Maciej
On 27 August 2015 at 22:39, Maciej Machulak 
wrote:
...
Hi,
It was discussed today how the current process of spec editing looks like
on GitHub (currently the spec is here:
https://github.com/KantaraInitiative/wg-uma). All the changes are done
on this repository, some via branches and some directly to the master
branch. It was suggested that maybe we could use distributed repos (each
editor would have a fork of the repo) and changes to the main repo would be
done via pull requests.
While I agree that using pull requests is best practice, I think we could
do without this for UMA spec editing. The current setup which we have is
pretty low overhead and sufficient for our needs (we could probably improve
on using branches but that's also not something we have to strictly stick
to).
However, I'd like to hear the opinion of others. Let me know so that we
can act accordingly.
Maciej
--
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)
--
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl |
Calendar: xmlgrrl@gmail.com
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl |
Calendar: xmlgrrl@gmail.com
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl |
Calendar: xmlgrrl@gmail.com
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

Re: [WG-UMA] Handling spec writing process @ GitHub [+legal]

Dazza Greenwood

Justin Richer

James Hazard

Eve Maler

tags

participants (4)