Add MIT license to i18n WG

[obensource]

Purpose

In today's CommComm meeting, @amiller-gh brought up the important issue: that not providing an MIT license can prevent some people from contributing to our initiative and joining our WG.

Description

This adds the MIT license to our WG. The same license currently used by the Community Committee.

[RichardLitt]

I'm sorry, I didn't have a chance to comment on this earlier today.

I am not sure that the MIT license is the right license for this repository. As far as I know, it pertains to code, not to Markdown files with natural language.

Instead, could we use the Creative Commons license, perhaps with the Non-Commercial Share Alike Attribute options?

[obensource]

@RichardLitt my apologies, I should've given something like adding a license more time for review before merging.

In today's CommComm meeting the general consensus was that CommComm will audit its current initiatives (eg. WebSite Redesign, i18n, Evangelism), and request to add a license if one doesn't exist. Members were encouraged to go ahead and add MIT licenses in the interest that (even though it is a software license) some people may be obligated to only contribute to repositories with the MIT license, and we may be excluding some non-members from contributing.

I did come to your same question in the meeting as well (given that this isn't a code-bearing repo), and am interested in figuring out what kind of license would be best in this case. CommComm will open an issue about this soon and we should participate–the discussion will most likely determine what kind of license we and other initiatives might use. 😎

Hope that sheds a little more light on this for everyone, thanks Richard! 🍻

[obensource]

@bnb fyi^

[RichardLitt]

Members were encouraged to go ahead and add MIT licenses in the interest that (even though it is a software license) some people may be obligated to only contribute to repositories with the MIT license, and we may be excluding some non-members from contributing.

I think this is an interesting point. As far as I know, a license is meant to protect contributors, not to necessarily be welcoming - it is a good sign if it is useful, which can signal that the repository is welcoming, but that's only relevant if the license is valid and useful and conforms to the user's needs.

An MIT license doesn't do that for a non-code repository, because it explicitly says for software and associated documentation. That we're developing this on GitHub doesn't make these documents code. I am not a laywer, but as a contributor, I'd worry more about contributing to a project with an irrelevant license than a repository without one.

Do you see what I am getting at?

[obensource]

@RichardLitt I understand and completely agree. I think the action of adding this license to our WG repo may be premature at this juncture since it doesn't quite pertain to the nature of our project, and this overarching issue hasn't been fleshed out in CommComm yet. I'm definitely not opposed to reverting this change until we can solidify something that is 'valid & useful' for this project through a more thorough discussion.

cc @bnb @amiller-gh @mhdawson

[obensource]

@RichardLitt fyi: removal pending :)

[obensource]

@RichardLitt also if of interest, I found this great MIT line-by-line explanation in an old TSC discussion.

[RichardLitt]

Thanks, @obensource. Yep: @kemitchell's instructions are pretty much universally helpful.