There have been two rounds of discussion about code licensing:

  1. The MIT License – Clarity on Using Code on Stack Overflow and Stack Exchange
  2. A New Code License: The MIT, this time with Attribution Required

In my opinion (and with the benefit of hindsight), both rounds have been suboptimal ways of discussing the problem, even though we managed to collect a lot of good feedback.

I would characterize the conclusion from the first round as "this is more controversial than we thought". About twenty different issues were raised in the answers, and the proposal had to be postponed, then redone.

I would characterize the second round as, frankly, a gaffe. This proposal had just a tweak that resolved about three of the twenty issues, suggested that the "details" could be addressed in a yet-to-be-written FAQ, and set a transition date just 45 days out. The top five answers are, basically:

While the chaos of the first round could be forgiven as unexpected, the backlash from the second round was thoroughly predictable. Not only did the staff fail to do their homework, but they also put a tight deadline on the proposal that suggested that it was ready for implementation. (@Shog9 has subsequently added clarification that the "deadline" was just a scheduling goal, and that if it takes a year to get it right, that's OK — which was not apparent from the tone of the announcement.)

The second proposal has now been suspended, so I expect there to be a third round. However, given the chaos of the first two rounds, I fear that the third round will not go well either.

We can't have a sane discussion when half-baked proposals are presented as announcements with unrealistic implementation dates.

We can't have a sane discussion when twenty different issues are raised all at once, including fundamental preliminary concerns such as "What problem(s) are we trying to solve?" that impact all subsequent decisions. Now, we've spawned a whole collection of related Meta questions:

While those are all good questions, some of them put the cart before the horse. What we have is a project management problem.

We need to go meta meta. Putting aside your own opinions about licensing itself, can we design a process that is conducive to logical discussion? Please post your meta-meta ideas below.

  • 1
    "can we design a process that is conducive to logical discussion?" Using the Stack Exchange engine? Not likely. Commented Jan 24, 2016 at 0:46

4 Answers 4


First, let's start by understanding which problems with the current licensing exist (if any). Each of these could be a Meta question, spaced out over time.

  1. What is wrong with the status quo? What is the threat, if we do nothing? (Does your company limit your use of Stack Exchange due to legal concerns, for example?)
  2. What is right with the status quo? How have you (personally or as a member of the Stack Exchange community) benefitted from CC BY-SA 3.0?
  3. What are some specific or hypothetical use cases of code taken from Stack Exchange that we as a community consider abusive and worthy of legal action? (One example per answer, please. Let's vote.)
  4. What are some specific concrete use cases of code taken from Stack Exchange that we as a community want to allow, no strings attached? (Cite one real post per answer.)
  5. What are some specific concrete use cases of code, if any, taken from Stack Exchange that we as a community want to allow, but requiring some attribution at the point of use in a code comment?
  6. What are some specific concrete use cases of code, if any, taken from Stack Exchange that we as a community want to allow, but requiring some attribution in the product's documentation?
  7. Are the problems above solvable through code licensing? Can those goals be achieved within the CC-BY-SA framework, or by adjusting the site's Terms of Use?

Then, depending on the results of those discussions, we may be able to proceed with further discussions, each focusing on a logical next step.

  • 3
    Perhaps even a "why must this be an immediate, sweeping change, rather than a slow, gradual one?" Commented Jan 15, 2016 at 19:53
  • @EBrown What slow gradual form could this take?
    – Jeremy
    Commented Jan 15, 2016 at 19:56
  • 4
    @JeremyBanks I have no idea, but the option was not presented before. It was decided for us that the changes would be forceful and immediate, taking effect on a specific date. The purpose of this meta is to help guide constructive discussion into the best way to handle this change - and that is a very valid concern that should be addressed. Commented Jan 15, 2016 at 19:58
  • 7
    I suggest we gradually scale up from 1% of new posts getting the new license to 100% of new posts getting the license, at random, over a period of months.
    – Jeremy
    Commented Jan 15, 2016 at 20:00
  • 9
    @EBrown: For what it's worth, I do think a sharp cutover is the best way to do things. The problem here is that the proposed cutovers have been abrupt/premature, rather than merely sharply defined. Commented Jan 15, 2016 at 22:27
  • 4
    I upvoted this cause I like all your points, but I think SE's history of using the terms of use to do licensing is very problematic. One of the steps should be to ask the lawyers what the appropriate tool to solve each identified problem is. Licenses and ToS have different purposes! Commented Jan 16, 2016 at 3:22
  • 2
    I'm not sure at what point in your list it belongs, but the premise that there is/should be a code vs. non-code distinction should be considered as well.
    – otus
    Commented Jan 17, 2016 at 14:11
  • I'm putting together the discussion to kick this off, you've got a lot of points here. Are some of them more important than others, in your opinion? (I'm looking at something that is getting absurdly long and I'm trying to make sure I keep the gist of what most people worried about this have been asking)
    – user50049
    Commented Jan 20, 2016 at 13:55
  • 1
    @TimPost My main concern is the clarity of the discussion. Imagine that you've been hired as a facilitator at a workshop. You would probably ask people to post their ideas using sticky notes on separate bulletin boards, right? And then summarize the group sentiment for each board before proceeding to steps that depend on it. Commented Jan 20, 2016 at 16:56
  • 1
    @200_success Okeydokey. I think I can kick this off on Monday. I'm going to post something tomorrow to announce a special tag for anyone interested in following, the timeline we've talked about and a gentle reminder that we're all here to help. I'll then update that timeline with links to the relevant discussions per item, and any solid deliverables that result. In other words the timeline becomes a map to discussions, and everything that results from those discussions gets assembled in plain view. I'm pretty excited about this, thank you for your help.
    – user50049
    Commented Jan 21, 2016 at 17:12
  • 1
    For clarity, the "We're going to do this" post with the timeline / introduction / tag to follow etc will go up tomorrow, we'll start the actual discussions that will eventually link to on Monday.
    – user50049
    Commented Jan 21, 2016 at 17:15
  • Follow up: It's 3:00 AM here, the "We're going to do this" post is actually going to go out tomorrow because I'm not allowed to write important things when I need sleep this badly.
    – user50049
    Commented Jan 22, 2016 at 19:02

No why? No way!

We need to go meta meta. Putting aside your own opinions about licensing itself, can we design a process that is conducive to logical discussion? Please post your meta-meta ideas below.

The problem needs to be stated. And defined. And explained. And clarified. Most users will not understand the problem. This is nearly always true.

I have read most of the meta posts about this proposal and still don't know what the primary problem is with how SE's license works currently.

Maybe it's more obvious to other people. I don't know.

Regardless, people overwhelmingly focus on their solution rather than the problem. If you write a big long blog post that is 95% your solution and only 5% the problem, don't be surprised if you get negativity.

Imagine meta as a courtroom. Instead of jumping to your closing arguments, you need to build a case.

Change is (perceived as) bad

People generally dislike change. They dislike change forced upon them even more. And if it's change they don't see value in, forced upon them? It's a recipe for disaster.

Add in the "we talked with our lawyers" stuff? You have a recipe for disaster.

... especially if it's perceived as unneeded change.

This makes building a case even more important.

Don't generalize away concerns

Stack Exchange can do whatever it wants. If it wants to change the license it has the ability to do so and there is nothing (short of leaving) any of us can really do.

That's fine.

But if that's what is really happening don't try to persuade people that "the community supported it!" unless you can back it up. As is now clear, and to me was before (but apparently not SE), the community was very mixed on this subject - at best.

If SE wants to do this regardless of community support, just do it and don't attempt to pretend that's not what is happening. On the flipside, if that is desired, don't tell a community what they think collectively.

Code Peer review

I would suggest having someone who is:

  1. Very familiar with meta/community culture
  2. As unfamiliar as possible with the whole topic

When making sweeping changes, give that person the post as a draft and ask them to tear it to pieces. I... suspect that there are people within Stack Exchange who would have been able to point out many of the problems with the first and second version and let them be addressed prior to post.

What I would have expected to see for this process

  1. First, a Meta post/discussion talking about "Does CC BY-SA give problems with Stack Exchange?" and then a discussion of why it does/doesn't
  2. A discussion about "how can we resolve the problems presented in (above)" with some potential ideas
  3. A fully synthesized post with a proposal comprehensively addressing the points in (1) and solutions/objections in (2)

The second proposal was a gaffe, which I'd like to explain in a bit more depth. I've said bits of this in various places; it's important to get it down in one place coherently.

The enormity of the project, this giant thing full of so many variables and so much uncertainty had an effect on us - it made us just dumb enough not to realize that it made us a little dumb. When you find yourself in that position all kinds of things stop making sense to you, and you can't really understand why.

We were positive that the first proposal was going to go over splendidly. When it didn't, we didn't ignore any feedback, we just didn't see what was in front of us because those of us working on it were pretty overwhelmed. This was the point where we should have kicked off a bunch of side discussions, but we got lost in a very reactionary endeavor to try and fix things instead.

We're human.

The first version of anything is basically us putting something that we feel is coherent and complete enough together to start a discussion. I don't feel too bad when those bomb as long as I'm sure we did our best not to waste people's time. So what we'd like to do is just throw out the second proposal, and have the discussions we should have had after the first one. And those discussions are happening.

While many agree that the MIT license is a fine and venerable license, some people are warming up to what the Apache License 2.0 could give us. We've also done a better job of explaining why we really want a different license for code as well as explained goals we have to meet when considering one and the rationale behind them.

Iteration the third?

Yes, but we're going to assemble it as we see some consensus around the key pieces and places that didn't go over so well the first time. As we see directions that many seem happy with, we'll work with you to produce whatever will be needed to support those directions (guides, FAQs, etc).

I don't know if it's possible for everyone to be 100% happy with a scheme we can actually move forward with. But, we can get a heck of a lot closer to that than the roughly 0.00% that we're currently sporting.

These are the next major steps that we envision; the minor steps depend largely on the outcome of the major ones. But here's a high-level outline:

  1. We mutually understand the problem that we're solving with a new code license. Not making it worse is a big part of making it better. This will begin with a new discussion.

  2. We decide on a license. MIT was pretty contentious. We as a company are comfortable with any approved license that treats consumers of code on Stack Overflow equally when it comes to their fields of endeavor. You have clear permission to use our code without fear of additional legal complexity in whatever you might be working on as long as you provide attribution. A license can't introduce any additional requirements beyond attribution for us to be behind using it.

  3. We decide what feels sufficient for attribution. These requirements can't be too onerous, or people simply won't do it. I think we'll have more input and feedback here than anywhere.

  4. We've settled on key decisions, we check with the OSI and our counsel for sanity I'm putting this here just to note that we'll keep both involved. If either at any point say we're heading out into the weeds, we'll let everyone know.

  5. We agree that it's time for something to be . It looks good to all of us. We have drafts of any supplemental documentation or guidance that would be required, and any support the scheme would need through changes in our TOS have been pretty well mapped out. At this point anyone that has a stake gets sufficient time to speak up. We need to hear from the folks that will need to comply with what we've made.

  6. We have another discussion if it's needed. At this point I sincerely hope we're just tweaking things people point out, and there's no fundamental deal-breaking mojo on the loose. But we have to make a point to evaluate it.

  7. We fix this for Stack Overflow, first. It's the biggest need. We are open to discussing the possibility of tweaks to account for major per-site complexities, but we have to first optimize this to serve what is by far the largest need. This will be the de-facto license for sites that have code, with possibly one or two exceptions. Fragmentation is bad. We talk to folks that have concerns above and beyond those of Stack Overflow, and then announce the rollout plan.

Timeframe? Well, as long as it takes. We really want to keep this moving forward and if feedback stalls we're going to keep asking for it, but we want folks to have enough time to be comfortable with what we're doing.

What did I miss?

  • 13
    Thanks for posting this — it really helps to reset the tone. I'm still concerned, though, that your proposed next steps skip all of my proposed preliminary steps to clarify the problems with the status quo. Even if they are clear to you, they aren't clear to me, and you still need to convince the community. On top of that, even if we do have a problem, we will want to ensure that the cure is not worse than the disease. So, I recommend proceeding even more methodically, step by step. Commented Jan 20, 2016 at 6:48
  • 5
    @200_success We're pretty actively talking about what's wrong with the status quo now (just, kinda, all over the place), which is why I didn't put it in there, but it probably should be in there so I've fixed it, and we'll kick something off to consolidate everyone's input.
    – user50049
    Commented Jan 20, 2016 at 6:54
  • 1
    A license can't introduce any additional requirements beyond attribution for us to be behind using it. Although I'm OK with MIT or BSD 2-Clause, I'm more in favor of Apache 2.0 or BSD 3-clause because of one additional requirement: not using my name as promotion. This is something that exists for complete posts in CC BY-SA 3.0. Unless I'm reading this wrong, you're explicitly precluding licenses that offer a protection already offered in CC BY-SA. Commented Jan 20, 2016 at 16:01
  • 1
    Especially since you linked to my post as "some people are warming up to what a 2-clause BSD license could give us". There's not much in a BSD 2-Clause that isn't in MIT. BSD 3-clause and Apache both add something over MIT. Commented Jan 20, 2016 at 16:09
  • 5
    "We fix this for Stack Overflow, first." This needs to be re-examined. Yes, SO is the 800 lbs gorilla in the room. But taking an SO-centric approach means that you'll potentially ignore the requirements for other sites (Code Review, Code Golf, ...). And that mistake could (will) derail the third and fourth and ... proposals. Being SO-centric is what allowed those important edge cases to slip through to begin with.
    – user194162
    Commented Jan 20, 2016 at 17:02
  • @GlenH7 If we make deviations from the license that everything else in the network is going to use, we need to do that once we've got that license baked, and then see where we might need to make some changes, or consider a delay in rollout in a couple of places. We have to fix the biggest problem first.
    – user50049
    Commented Jan 20, 2016 at 17:13
  • 9
    @TimPost - I'll go out on a limb and suggest that if you find something that works for all of the other SE sites then there's a very high probability that the proposal will work for SO as well. I think this is a case where traditionally following the 80 / 20 rule bites you. Instead, solve for the 20 (which is thornier to work through) and you'll solve for the 80 as well.
    – user194162
    Commented Jan 20, 2016 at 17:17
  • 1
    @GlenH7 That is a fair point. Let me noodle on that a bit?
    – user50049
    Commented Jan 20, 2016 at 17:21
  • 1
    @TimPost - Absolutely. From my perspective, you had asked "What did I miss?" after acknowledging that the second proposal came about from a less than ideal perspective on how to tackle the challenges. All I'm trying to point out is that it sounds like you're heading down the exact same path again. And you might want to interject a detour this time to see if you get somewhere else instead.
    – user194162
    Commented Jan 20, 2016 at 17:22
  • @TimPost Since you're here, could you clarify or fix up your text / link to my answer, since the text you're using to link to my answer doesn't match what I said in the post at all? Please? Commented Jan 20, 2016 at 17:23
  • 1
    Just an observation: Keeping the numbers sequential in the markdown makes the diff much larger... Commented Jan 20, 2016 at 18:02
  • Can you clarify what you mean by "[attribution] requirements can't be too onerous", and how this will be handled as a separate point after the choice of license? For example, most (perhaps all?) the permissive licenses being suggested define their own rules for attribution, and they are more than just an inline comment. Commented Jan 21, 2016 at 3:49
  • @ThomasOwens - Did the title change, perhaps? Feel free to edit if you want. I'm not quite sure what you mean.
    – user50049
    Commented Jan 21, 2016 at 17:18
  • 1
    @TimPost You linked to my post with the text indicating that people are "warming up to a BSD 2-clause". The bulk of my answer (which is highly upvoted - one of the highest in that question) is why Apache License 2.0 is the best option. Later on, in one paragraph, I indicate that BSD 3-clause License, NTP License, or Microsoft Public License offer a similar advantage as Apache License 2.0 over MIT. I place BSD 2-clause with MIT and ISC as second-best licenses. I'm not sure if you intended to link to something else or if you meant that people supported a BSD 3-clause instead of 2-clause. Commented Jan 21, 2016 at 17:23
  • 2
    @ThomasOwens Good edit, and I stand behind the fix you made (as this is an official-ish looking post)
    – user50049
    Commented Jan 22, 2016 at 18:17

We need a survey

There's an annual survey on SO for how developers use the site, there should have been, and should be, a survey relating to these changes also.

Example questions

  • What do you think the current license for content allows you to do with that content (select all that apply)?
  • Have you copied content from an SE site and used it in your own work?
  • Have you copied code content from an SE site and used it in your own work?
  • Was that work commercial or non-commercial in nature?
  • When you use SE content do you give attribution to where the content originated from? (Always, Sometimes, Rarely, Never)
  • Has the current license on SE prevented you from using SE content in your work? Is so why?
  • If code was changed to be licensed under the MIT license would this change how you contribute to SE sites? Why?
  • If code was changed to be licensed under the MIT license would this change how you use content on SE sites? Why?
  • Etc.....
  • 9
    I suggested a related question in 2013, in 2014 (third highest votes), and in 2015, but it never made it to the survey.
    – unor
    Commented Jan 16, 2016 at 14:22
  • @unor That's a shame :/ Commented Jan 17, 2016 at 12:47
  • 3
    90% community feedback is crap, as per the founder of SO. A survey will not help until we get all the facts right and discuss is extensively. Commented Jan 17, 2016 at 16:11
  • 5
    @ghosts_in_the_code A survey would tell SE how people use content from the site and what their understanding of licensing of content is. That's not asking for suggestions or a debate. Discussing things on meta doesn't really work given the problem of meta voting and the fastest gun problem.
    – kjbartel
    Commented Jan 18, 2016 at 8:04
  • OK, I agree with that. Commented Jan 18, 2016 at 9:49
  • 3
    Funny... Sam really wanted to put a question or two in this year's developer survey, @unor. Got dropped because we couldn't figure out how to make it... Not leading. Survey design is a lot harder than folks give it credit for; way too easy to ask questions that just produce the answers you're looking for. At the point where we're just soliciting free-form answers, we're better off asking here on meta.
    – Shog9
    Commented Jan 18, 2016 at 19:44
  • 2
    "Have you copied content from an SE site…" What does "copied" actually mean? Are we talking only verbatim copying, or copying but changing some details, or just learning how to do something and then writing your own implementation (which could well end up being the same), or synthesizing a solution from several different answers? To me this lies at the heart of the licensing question.
    – Ian Goldby
    Commented Jan 20, 2016 at 8:40
  • 1
    I almost never copy/paste an answer, but what finally ends up in my code can, sometimes even accidentally, end up looking exactly like it. To me, SE is a place where I come to learn things, not to copy/paste, so in my opinion there is no licensing issue, unless we are now somehow required to license knowledge and understanding.
    – Ian Goldby
    Commented Jan 20, 2016 at 8:42
  • 1
    @kjbartel when the current developer survey completes, compare that to the hits/day (or if SE would provide it, unique users/day) for Stack Overflow. I would be very surprised if it even made it to 0.1% of the visitors responded. A survey on such a boring issue as licensing and asking people to indicate if they have infringed on the license would not get a useful feedback rate.
    – user213963
    Commented Jan 20, 2016 at 17:58

You must log in to answer this question.

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