On 2 Sep 2015, at 12:54 PM, James Hazard <james.g.hazard@gmail.com> wrote:As a follow up on Contribution Agreements:_______________________________________________
They are of course an issue of broad applicability for software projects - and there is work around codifying this sponsored by the Shuttleworth Foundation. https://www.shuttleworthfoundation.org/fellows/catharina-maracke/
While the context is very different, this, too, is a multijurisdictional consent problem and I believe they did some good work on signature requirements in a great number of countries.
I did an extensive demo of some of these contribution agreements on an earlier version of the CommonAccord software platform and brought only a bit of it over into the new platform - http://www.commonaccord.org/index.php?action=source&file=/ContributorAgreements/ContributorAgreements_License_Library.01.md
On 9/2/15 7:47 PM, Dazza Greenwood wrote:
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:
The GitHub documentation is here:
I have created a starting file for our repository and submitted a pull request here:
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 <dazza@civics.com> 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, 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/InterfaceThis 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…
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 <jricher@mit.edu> 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:
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 <eve@xmlgrrl.com> 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 <eve@xmlgrrl.com> 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 <jricher@mit.edu> 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 <maciej.machulak@gmail.com> wrote:
Hi all,
I refer to my earlier email - any comments? :-) Thanks!
Maciej_______________________________________________
On 27 August 2015 at 22:39, Maciej Machulak <maciej.machulak@gmail.com> 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
_______________________________________________
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
-- @commonaccord
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma