It has to protect our contributors to the point that they feel comfortable contributing. This means protection from people that used code from the site, experienced what they feel are damages and want someone to sue. Hey — no warranty. Protection of the integrity of their contribution (attribution is needed being a big one) is also very important. The point that you feel comfortable is part of the discussion you're having right now.
It has to protect people that use those contributions. We have to give people clear permission to use the code found on our site, for any purpose, provided that they comply with the terms of the license.
It has to be easy for end users to comply. The easier it is to comply, the more likely folks will be compliant. We're not ruling out changes in the UI that could help this if we can find a scheme that works and people like. Most people just use a link to the post because it does give credit, and it's easy to reference if anything ever does come into question.
It has to be an OSI-approved license that isn't modified. We're in an interesting position, we don't actually distribute software, we distribute blocks of code for educational use that eventually work their way into software. That's why it really has to be a software license. Ideally, we don't create a new one (by writing one, or directly changing the language of one that exists, which essentially creates a new one).
The first three make sense:
Without contributors, there are no Stack Exchange sites. Any license(s) must give sufficient protection to the contributors (for example, ensure that there is no warranty on the content) and to protect the integrity of the contributions (ensure attribution).
If people can't safely and easily use the contributions, then Stack Exchange isn't fulfilling its goals. The permissions granted to users must be sufficient to help them as well as clearly understood.
If users have a hard time complying, then they simply won't. I liken this to piracy rates in Australia dropping after Netflix arrived. If you make it easy for people to do the right thing, they will. Making it hard won't stop them from using the content, they will just do it illegally.
As far as the fourth point goes, the necessity for an OSI-approved license makes sense. It makes sense to have a trusted and tested license that should hold up to scrutiny.
The part that doesn't make sense is that it says "isn't modified". So far, both proposals may not have affected the wording of the licenses, but have modified how people can use it. The first proposal removed the requirement to carry the MIT license with a recommendation to include attribution in the form of a URL to the question. The second proposal still removed the requirement to carry the MIT license but required an in-code attribution in the form of a URL.
The purpose of this question is for Tim Post to respond, since he was unable to answer in the comments.
@ThomasOwens, tim can probably give a much more detailed version than I, but the short version was that a lot of the devs we pitched MIT to were concerned that the need to reproduce the code block, potentially dozens of times in the code for different citations, was a lot of friction and hassle that might cause less compliance and attribution as a result. I won't speak for all the folks involved, but if the community was a lot more comfortable with MIT, but without the "lightweight" attribution option, I'd certainly be open to considering an option along those lines.
I specifically mentioned three OSI-approved permissive licenses: MIT (which appears to be a favorite of Stack Overflow, since the first two proposals used it), BSD (this applies to 2- and 3-clause), and Apache License v2. Each of these has a relatively simply attribution requirement: put one LICENSE file (and an optional NOTICE file, for ALv2) in the root directory of your project. The standard MIT license is about 20 lines if you wrap it to 80 characters and the BSD 3-clause is about 25 wrapped to the same:
The MIT License (MIT)
Copyright (c) <year> <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
The attribution line is:
Copyright (c) <year> <copyright holders>. Full and proper attribution can be achieved by putting this file somewhere in the project and duplicating that line for every Stack Exchange Contributor who's work was used in the project. The BSD licenses have a similar clause.
My question: Why is this approach not possible to Stack Exchange? Since it appears to be so simple (and any project already using open source software does similar things with any MIT, BSD, or Apache License v2 software), it seems like it would be the natural first-choice proposal to present to the community.
It doesn't resolve 100% of the issues, but it addresses all four of the requirements in Tim Post's post as well as ensures full attribution by name and URL in both source and binary distributions of software products, both open and closed source.
There are still open questions to discuss and iron out, but it seems like a very obvious solution would have prevented a lot of backlash and helped to get to more substantial issues sooner.