In this post, Tim Post laid out four things that Stack Overflow was looking to get out of a license:

  • 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.

My question in the comments was simple:

Could you explain why you attempted to modify the MIT license instead of just using MIT, BSD 3-clause, or Apache v2? Although you didn't modify the license itself, the terms of use provided another waiver. Exactly what would be wrong with requiring a LICENSE and/or NOTICE file in a software release? Or am I misunderstanding your last two bullet points. Because I know that I wouldn't have had as much to complain about if you just said "code is MIT" or "code is BSD 3-clause" or "code is Apache" in the last round.

The purpose of this question is for Tim Post to respond, since he was unable to answer in the comments.

Jaydles, the Stack Overflow VP of Community Growth, responded (with a brief conversation):

@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 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.

The Apache License v2 also has a NOTICE file. The guidance says to "keep NOTICE as brief and simple as possible" and "do not add anything to NOTICE which is not legally required". Something to consider (with the assistance of the OSI and/or Apache Software Foundation) would be to see if this NOTICE file can be required by the site terms of use to require URLs to each Stack Exchange question or answer that includes code that was used in the software distribution.

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.

  • I'm a bit puzzled what the title of this question has to do with the body of this question. The title seems to focus specifically on the ToS aspect, but the body doesn't seem to say anything in particular about the ToS -- it seems to be about selection of which license to use. Was that title a left-over from an earlier draft?
    – D.W.
    Jan 19, 2016 at 11:10
  • 1
    @D.W. No, it's an accurate title. In both rounds, the MIT license was chosen. However, additional modifications to the Terms of Service were proposed, mainly centered around modifying the attribution requirements of the MIT license for content that came from Stack Exchange. Jan 19, 2016 at 11:15

1 Answer 1


There were a few reasons for this.

The first was not changing how folks that made a point to be compliant be compliant. Most people just put a link to the answer that helped them, some go a little farther with attribution in 'doxygen style' comment syntax. What do you have to do differently than you've been doing? Well, pretty much nothing. That wasn't a bad goal to have, and not changing years of institutional memory seemed desirable. It also makes becoming compliant relatively simple.

Jay hit the second reason pretty well in his comment, and since the 'lightweight' option mated so well with the way most people were currently doing it, it seemed like a pretty natural fit. It's also pretty easy to back up including a link as an overall best practice to begin with as well as a means to be compliant.

We were in contact with the OSI throughout the entire process and still are (they are a wonderful group of extremely helpful people, say hi to them, they're probably reading this), and they strongly objected to a license modification where the goal could be achieved through other means. You create a new license by modifying one, and that has to be vetted and approved all over again. This is a big ask. Sometimes that's the only way to reach a goal, but if other ways exist - try those first. We did originally try some small modifications to the MIT license.

Our biggest concern was that folks would be much less likely to be compliant if we made it any harder than just including the link, which most people are already accustomed to doing. What we came up with just felt like the only real middle ground we could find given the constraints that we had to work in. The next-best thing would be pretty easy guidance on how to maintain a "AUTHORS.TXT" file and a single copy of the license, but that's much more work than just grabbing a link.

That's not to say we were right, but that's how we arrived there. We're open to any ideas, and if it looks like a solid solution that people like is emerging, we're happy to get more feedback from the OSI as well as our own counsel to shore it up.

  • 1
    Thanks for the detailed answer. I think it's helpful to know the reasoning behind a certain direction. Today (with everything CC-BY-SA), a link is just one of the 5 things required for "appropriate credit", and I don't like changing the rules just because people aren't following the current rules. I'd also be curious as to if developers would actually have a problem putting a LICENSE (and a NOTICE file) in their distribution if SE made it easy to get the license file and copyright statements and drop it in to their application - anyone who is using open source today has to manage this. Jan 19, 2016 at 11:30
  • @ThomasOwens, I agree with your comment above. I felt (as many others evidently also did) that the crayon licenses were a terrible suggestion on SE's part. Thanks for asking the question and thereby drawing out from Tim the reason why SE made that bad decision.
    – user136089
    Jan 19, 2016 at 12:21
  • 1
    @ThomasOwens, Jaydles's said, "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", but that isn't a valid concern, because MIT doesn't require a licensee to reproduce anything at all (license or code) more than once in order to be compliant. It doesn't even require source code to be reproduced. It appears that SE's acceptance of that invalid concern as a valid concern was the key deductive error in SE's ratiocinations that led to the crayon licenses being proposed.
    – user136089
    Jan 19, 2016 at 12:23
  • @sampablokuper You're not wrong, but as the project started formalizing that misconception was quickly corrected. I was working on some guidance for maintainers to keep just a single copy of it, with an AUTHORS / COPYING file. But, since 'just use the link' was the easiest way for someone to be compliant in that plan, that's what we focused on. This spanned months from the time we started until announcing the first version, for a timeline perspective.
    – user50049
    Jan 19, 2016 at 12:47
  • @TimPost, "as the project started formalizing that misconception was quickly corrected". I'm not convinced the misconception was "corrected". Not before the two crayon license proposals, anyhow. The most charitable interpretation of your previous comment that I can find is, "We did at some point realise that the concern was invalid, but ultimately decided to reject that realisation and to act as though the concern was valid. That is why we proposed crayon licenses." Anyway, it's interesting to learn more about the missteps that led to the crayon licenses. Thanks for discussing them :)
    – user136089
    Jan 19, 2016 at 12:59
  • @sampablokuper You're welcome, and thank you for the comment, it made me smile.
    – user50049
    Jan 19, 2016 at 17:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .