Code licensing proposal — Point of order!

Question

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:

• Flawed sentiment analysis — and you know it!
• Flawed sentiment analysis, due to the voting system
• This is a very bad idea, and you ignored nearly all the issues
• Generally in favour of the direction, but the proposal is incomplete, and this proposed license isn't right
• Give us the FAQ now!

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:

• What is "code" for the purposes of the proposed MIT license switchover?
• CC-by-SA vs MIT - The 2016 battle
• Add an indicator for the license to code blocks and a tool to copy code with the proper attribution
• How does the proposed MIT license change affect code that comes in part from another site
• Can the new license potentially end existing rights to old content?
• What happens when an answer crosses the threshold of originality, but the code within that answer doesn't?
• Licensing per Site
• Why should the new code license be permissive instead of copyleft?
• What sort of attribution should Stack Exchange members expect for their work?
• A New Code License: the Community Edition
• Why separate code and non-code licensing? (← This is a good initial step)
• Is a license change necessary?
• In the first two relicensing proposals, why did Stack Overflow try to use the Terms of Service to change the license requirements?
• http://meta.codegolf.stackexchange.com/q/7737/9520

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.

Answer 1

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.

Answer 2

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)

Answer 3

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 featured. 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?

Answer 4

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