27

The rationale for the license change proposals is at least somewhat clear: i.e. to reduce legal concerns of using code from answers in software that may use incompatible licenses. However, what seems to be missing is a justification for why the distinction between code and non-code was or should be made.

From my point of view there are clear disadvantages to having separate licensing: additional complexity, the difficulty of defining code, as well as the fact that you then would have the same concerns (such as they are) if you wanted to include some of the explanation in code comments, rather than just copying code.

Therefore I would like to hear the reasons Stack Overflow (the company) and the community have for this separation of licensed material, and am posting this as a new question as suggested here by Tim Post. That is: Why not use the same terms, whatever they may be, for all content?

Improve this question
4
  • 4
    I suspect many people will disagree with using a “permissive” (i.e. non-share-alike) licence for complete posts. Many more people than when it’s about code, that is.
    – chirlu
    Commented Jan 18, 2016 at 23:33
  • 6
    There is some precedent for separating code and non-code content. Google's developer docs are CC-BY for content + Apache 2.0 for code samples: developers.google.com/site-policies.
    – David Fullerton
    Commented Jan 19, 2016 at 16:12
  • 1
    I'd just like to point out that, to the best of my knowledge, O'Reilly cookbooks don't have a separate code license.
    – 200_success
    Commented Jan 19, 2016 at 16:46
  • @200_success Don't they have bulk reprint licensing and other stuff available as an add-on? I think you're right in that they don't have separate licenses, but I think their business model keeps them pretty far from even having to think about it, it's just not a problem for them.
    – user50049
    Commented Jan 19, 2016 at 16:53

1 Answer 1

Reset to default
13
+250

tl;dr version:

  1. CC-BY-SA is fantastic for collaborative prosaic content, or content that's intended to be read and interpreted by human beings.
  2. CC-BY-SA isn't a software license. It's not the best license for content that's intended to be read and interpreted mostly by machines.
  3. Software licenses aren't really as good as CC-BY-SA when it comes to prosaic content. The clear attribution requirements of CC-BY-SA help us stay ahead of bad actors, like SEO scrapers - but don't get in the way of people legitimately (and honestly) re-using our content. The goal for code was to be a bit more permissive, but there's no reason to be more permissive when it comes to prosaic content - we already have a great balance there.
  4. We don't think there's a 'universal' license that could serve us as well as two very specific licenses, one for prosaic content and one for code. As we burned through a ton of ideas, we kept landing on separation of concerns being the best path forward. We could have been wrong, but I'm just explaining how we arrived there.

Now, Tim rambles introspectively for a bit:

The biggest reason for going in this direction is that it makes our job as custodians of your contributions much easier if we transition into a more permissive code license. Any change can't weaken our stance in a never-ending war against SEO scrapers that started in late 2009.

How permissive all of you want the code license to be is something you're currently discussing. I'm just narrating our thinking and position at the time we reached it, with the MIT license in mind.

Put aside for a moment the complexities of trying to define code. Simplified, you end up with is content that is prosaic in nature - or meant to be read. You also have content that is non-prosaic, which can be read, but is mostly meant to be interpreted by machines. We want much tighter restrictions on what folks can do with prosaic content, and separating the concerns is the only way to achieve that. We don't need to make it any easier for people to just read stuff, essentially. That's easy enough.

CC-BY-SA is a fantastic license for prosaic content, and we definitely want to keep it. The attribution requirements help to ensure that 'mirror' sites don't outrank the original because the links back help search engines to identify them.

I'm not sure if all of you noticed, but we tossed in a proposed change to our terms of service at the same time that we added the proposed option for folks not to carry the MIT license (neither change is yet in effect). We put ourselves in a position where we can better enforce the terms of both licenses on your behalf (upon request of the copyright holder, or Stack Overflow, Inc.)

We're not the copyright holder - you are, you just give us a perpetual license to distribute your contributions. But, we're also the people folks look to for enforcement. I'm pretty sure we're going to want to close that gap in whatever scheme we ultimately end up with.

So let's say purely for the sake of discussion that the community broadly supports a 2 or 3 clause BSD-ish license. Just like CC-BY-SA isn't so ideal for software, BSD-ish licenses aren't so ideal for prose (though, it's generally okay for documentation). CC-BY-SA has everything we want on that side.

We should have been much more forward about this because we are doing some really good things to help ensure that we take good care of what you give us. The enormity of all the moving parts we were dealing with just .. well, never mind - we're talking about it now.

Improve this answer
20
  • Thanks for explaining. Could you clarify why a more permissive license would hinder going after scrapers? E.g. CC-BY has exactly the same attribution requirements as CC-BY-SA, so wouldn't you be able to demand the same backlinking? The only real difference is that the scraping site currently needs to use the same license, but I wouldn't think they'd mind.
    – otus
    Commented Jan 19, 2016 at 9:20
  • @otus, I don't think this answer ever claimed that every more-permissive license will necessarily hinder going after scrapers. The answer seems to be making some weaker claims: CC-BY-SA is great for what they want; some of the most natural candidate licenses for code (e.g., BSD-ish licenses) are not great for prose. Anyway, the original question was about why separate licenses for code and prose might make sense, and I think this gives a clear and plausible explanation of why one might want separate licenses for them.
    – D.W.
    Commented Jan 19, 2016 at 10:49
  • 2
    @D.W., I have to disagree about it being clear. The reasons stated here are "going after scrapers" (why would it help in that?) and "because we want to keep prose BY-SA". The reasoning that some code licenses are not good for prose makes sense, but that only rules out those licenses, it does not explain why BY-SA would be the ideal.
    – otus
    Commented Jan 19, 2016 at 12:32
  • 1
    @otus I edited in a 'tl;dr;' version. As much as I tried to avoid rambling while recalling the massive amount of work that led us to the decision, I ended up rambling a bit. Is that any better? I don't mean to stammer, there's just a lot of depth to how we arrived there.
    – user50049
    Commented Jan 19, 2016 at 12:36
  • @TimPost, thanks, yes especially 3. and 4. in the list explain the reasoning more clearly.
    – otus
    Commented Jan 19, 2016 at 13:02
  • @TimPost, "The clear attribution requirements help us stay ahead of bad actors, like SEO scrapers - but doesn't hinder 'good faith' remix-and-reusing endeavors." I don't understand what you intend this sentence to mean. Please could you edit it for clarity, at least specifying what it is referring to? (E.g. "The clear attribution requirements of CC-BY-SA..." or "The clear attribution requirements of attribution-required software licenses...")
    – user136089
    Commented Jan 19, 2016 at 14:11
  • @TimPost, "we tossed in a proposed change to our terms of service at the same time... We put ourselves in a position where we can better enforce the [license terms] on your behalf (upon request of the copyright holder, or Stack Overflow, Inc.)" I am in favour of licensors receiving the support of Stack Overflow, Inc, in upholding the license terms, because licensors might not possess awareness of a violation or might not possess resources to pursue enforcement, whereas SO might possess both. Putting this in the ToS is probably a Good Thing, as it makes explicit that possibility of support.
    – user136089
    Commented Jan 19, 2016 at 14:52
  • 1
    @sampablokuper (1) Take a look at the edit, I think I made it clearer and (2) I'm leaning toward putting that modification of the TOS in place regardless. I want to see if we can get close to another implementation that everyone feels good about over the next few weeks and just modify the terms once, but if it looks like it's going to take longer than that, it might be a good idea to get that in on its own.
    – user50049
    Commented Jan 19, 2016 at 15:05
  • @TimPost, thanks. I think it's unlikely any good faith user of SE would have a valid objection to that ToS change (your (2) above) on its own merits; & of course, I'd be in favour of that ToS change as I've expressed above. Even so, I would encourage you not to go ahead with a ToS change without first making the case clearly & checking the community is OK with it. A good place to start might be by asking on meta.SE if users support this particular proposed change, & by answering this question with an answer pointing to that new meta.SE question.
    – user136089
    Commented Jan 19, 2016 at 15:16
  • @TimPost, "Take a look at the edit, I think I made it clearer". Thanks for trying, but it's still ambiguous. "The clear attribution requirements" of what?
    – user136089
    Commented Jan 19, 2016 at 15:21
  • @sampablokuper Edit: Take 2 :) Better now?
    – user50049
    Commented Jan 19, 2016 at 15:27
  • @TimPost, yes, thank you. That makes your meaning much clearer :)
    – user136089
    Commented Jan 19, 2016 at 15:43
  • 2
    @TimPost, "'not a great idea at all and here's some reasons why' would very likely delay any implementation while we fix it." I think I am, along w/at least some other SE users, asking something slightly different of you. Rather than wanting you to be willing to "delay and fix" yr proposed changes if the community dislikes them, we want you to be willing to abandon yr proposed changes if the community dislikes them. That's the difference. Maybe by "fix" you really did mean "fix or abandon". If so, great; & say so :) If not, then it's not miscommunication, it's difference of opinion ;)
    – user136089
    Commented Jan 19, 2016 at 19:10
  • 8
    "Put aside for a moment the complexities of trying to define code." Alright, I put it aside, and it's been a moment. Now it's back. This is a very important piece that cannot be handwaved away.
    – Shelvacu
    Commented Jan 19, 2016 at 21:50
  • 1
    @TimPost "We're going to be digging into this more" Don't worrry, I already got it figured out
    – Shelvacu
    Commented Jan 22, 2016 at 19:22

You must log in to answer this question.

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