Remove MIT license, Gemfile.lock

[mbland]

Addresses #4. Leaving in COPYING.txt per the CC0 FAQ.

Also removes Gemfile.lock per http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/.

@adelevie

[adelevie]

Other than the fact that CC recommends this, is there anything written as to why we need redundant license files? cc/ @konklone

[mbland]

I've had an outstanding query to [email protected] about this since Jan 9; annoyingly, I've received neither a reply nor a redirect. But I've been erring on the side of what's documented in the CC0 Wiki, since presumably they'd be the authority on the proper application of CC0 license artifacts.

[adelevie]

This could very well be the correct move, but if that's the case, we should have all 18F projects licensed consistently. And barring any persuasive rationale other than CC says so, consistency should be prioritized. I think https://github.com/18f/open-source-policy is the proper area to discuss whether or not COPYING.txt should be used.

In other words, we should adhere to https://github.com/18F/open-source-policy/blob/master/practice.md#how-to-license-18f-repos. And if that's incorrect, let's fix it.

[mbland]

Opened 18F/open-source-policy#31.

My impression was that CC was comprised of legal authorities; hence I tried to adhere to their documented recommendation. But, I'll go ahead and remove COPYING.txt in the meanwhile.

[mbland]

I'm going to go ahead and merge this; been outstanding for a while, and the state after this merge will reflect what appears to be common 18F practice.