Adding Creative Commons Licenses

[jmburges]

Adds all six permutations of the creative commons license.

We also added an attribution rule to the the required section and a Non-Commercial rule to the forbidden section.

[benbalter]

Can you expand on your reasoning here? Otherwise, I'm afraid this is a duplicate of #33 and has already been hashed out.

[jmburges]

woops

[ashleygwilliams]

so- with the growing use of github for content, i think it is a good idea.

additionally: we are looking into open sourcing our curriculum, a unique blend of software and content and we believe that some permutation of creative commons is the most appropriate license for that. given that a lot of learning materials are developed on github (i'm thinking of the sinatra-recipes as a decent non-school example) creative commons should be offered.

so the question is: is choose a license only for software-only projects? should it be? if no: creative commons should be an option.

[ashleygwilliams]

the fact that choosealicense itself uses creative commons is a good argument, as well.

[ashleygwilliams]

also: scott chacon's PDF presentation "The Revolution will be Forked"

[jmburges]

+1 to @ashleygwilliams

Also, almost every jekyll/gh-pages website out there needs a content license (such as CC) and a software license.

[benbalter]

Ahh. Hey @ashleygwilliams!

All for educating around CC for not-code and think this is a great idea. You don't have to sell me. 😄 A few things:

• I don't know that we need to include every CC license. As the site goals state, the goal is not to be comprehensive, but to simplify. Same should hold true for non-code licenses.
• I think this is a bigger pull request then just adding the licenses. I'd love to rethink some of the UI to ask "are you sharing something other than code? Great. Use CC."
• I think this would be a great candidate for something like Collapse license families on the licenses page. #29. Both CC and GPL (and BSD) are license families. Would love not to just throw a bunch of licenses at the user.

@haacked any thoughts?

[ashleygwilliams]

heeeeyyyy @benbalter. i figured you'd recognize my silly mug at some point 😆

point 1: sure. though i think the 6 permutations are not all that difficult to understand, given the modularity of the license, so it's not that overwhelming, sans the base quantity of them. let's talk about which we would want and why? (this may be made irrelevant by point 3)

point 2: totes agree. but i think they should be added and then we can talk UI. i'm super into helping with that, it's a convo that @jmburges and i had when we first were talking about this situation.

point 3: +1. yes yes yes. though, like point 2, i think - get them in there. and then let's iterate.

[jmburges]

Also dealing with license families and content v. software licenses has interesting implications when thinking about the LICENSE dropdown when creating projects. I don't think that should stop us, and I'm behind what @ashleygwilliams says. Let's get something out there and raise the issue and then go back and perfect it.

Hint: I'm currently sitting behind @ashleygwilliams so I just agree with everything she says.

[tekkub]

The fact that this keeps coming up seems like proof that we need to help people understand what the CC licenses are and are not for. I have to say, @ashleygwilliams makes a damn good case for why we should be talking about more than just software licenses here.

I'd love to rethink some of the UI to ask "are you sharing something other than code? Great. Use CC.

I really like this, and we could actually do it fairly easily, just slip it in after "What if I don't want to choose a license?" Something like:

What if I need a license for content that isn't source code?
Creative commons offers many licenses that are designed to bring the OSS spirit to non-code content.

[haacked]

@tekkub I like that! Send another PR?

[ashleygwilliams]

hey @haacked i don't think we're done here... having the CC licenses in choosealicense is useful. just adding a single line doesn't make much sense when all the work for content developers to simply select CC on github has been done.

what do you anticipate the new PR would be? adding the UI sounds great but closing this PR doesn't make sense. the license content and the UI are different...

[haacked]

Hi @ashleygwilliams. Sorry about that. I liked @tekkub's idea so much I was a bit overzealous.

I'll need more time to noodle on this a bit, but in the meanwhile let me explain my hesitation.

One essential goal for choosealicense.com is to reduce the anxiety for developers choosing a license. As the Paradox of Choice highlights, too many choices leads to more anxiety, not less.

This is why the site, up till now, has focused on choosing a software license among a small curated set of choices. If someone wants to choose a more obscure software license, they can simply copy the text into a LICENSE file. It's not too hard.

And for those creating content, there's already a great resource to help users choose a license: http://creativecommons.org/choose/ I don't want to duplicate that effort.

That being said...

You raise a very good point about GitHub's growing usefulness for non-code content. And we don't want to discourage that at all! We want to reduce the friction of creating such content.

I can see the value in having CC licenses available in the license picker. However, I don't think merely adding a big flat list is necessarily the right approach. It helps content producers at the cost of adding more confusion to software developers who just want to pick a code license.

This might require some changes to GitHub.com to do well. For example, perhaps a simple solution is to render the list with two groupings: software and content. That way all the content licenses are grouped together and the average developer can safely ignore them.

Likewise, it might require changes to choosealicense.com. For example, I'd rather people use the CC website to walk through how to pick a license and have that site continue to be the canonical source for CC licenses. So I'd rather not display the CC licenses on the licenses page: http://choosealicense.com/licenses/ but instead have the blurb on the home page that @tekkub suggested. We could do that, and still have the CC licenses available in the picker.

So this is where I'm at in my thinking about this now, but I do welcome additional feedback.

And sorry for being so quick to the close button! Here's a Bruce Lee thumbs up to your idea:

[ghost]

I think -ND contradicts the terms of use, which allow to fork the repository, and implicitly to modify while the fork is publicly available.
The other CC licenses fit, but -ND is unexpected.

[iamnewton]

Any more progress on this?

[jni]

Just want to add my vote to this. I love just choosing a license from a drop-down menu for my code, but for my content I have to go hunting. Yeah, it's not a massive hurdle, but if it's 3 minutes per project instead of instant, that adds up. Couldn't we have an "other" option in the menu where the user could search for common licenses? So typing "CC" would bring up all the CC licenses?

[bkeepers]

#89 added content to the homepage to link to creative commons.

What if none of these work for me?
My content isn’t code.
Check out Creative Commons.

Is that good enough for now? Should we still consider adding Creative Commons?

[jni]

@bkeepers I still would prefer an option in the dropdown. I'm perfectly aware of where to find CC licenses, I would just like the ability to add them quickly.

[benbalter]

I still would prefer an option in the dropdown.

Are you talking about the dropdown on GitHub.com? To be clear, CC0 is already listed.

To clarify, based on the discussion over in #33 (comment) where it was noted that CC licenses other than CC0 don't really make sense for software, it sounds like you'ld like to add other CC licenses to the dropdown on GitHub.com to make it easier to license non-code content?

[jmburges]

heyhey! I'm still of the opinion that an option for the non-code content that is making it on GitHub would be super cool. It gets a bit tricky because of all the different CC options, and that dropdown is wonderfully simple.

[jni]

@benbalter Thanks to GitHub Pages, GitHub hosts tons of non-code content. This is what I think should be easily licensable with CC licenses.

And, to clarify, I'm talking about the dropdown "Add a license" menu when creating a new repo on github.com.

[benbalter]

@bkeepers any strong opinions here? The question on the floor is whether to include non-code CC licenses in the dropdown. My gut says no for three reasons:

1. More choices increses the risk of the paralysis of choice. The fewer options we present, the less friction there is to license code.
2. Without a long explanation presented to the user, it'd be very easy to license code under a non-code license (e.g., CC-BY), making matters worse.
3. GitHub should be optimized for developers. Other uses are supported and encouraged, but the core use case is code. We should build for the 80%+ of uses.

[philsf]

@benbalter OTOH,

• the user should not be educated on such important issues about which license to choose by a dropdown list
• whatever license one chooses for code or content, the information should be considered beforehand, not during the process

In summary, IMHO in most cases this should already have been decided by the time the repo is created.

Alternatively, the dropdown could be used to add/change the license after the repository creation.

[bkeepers]

@benbalter I'm pretty sympathetic to your perspective, but I also understand the argument for using it for pages sites and other content.

I'm sure there are ways we could make the license available in the dropdown without it being overwhelming (like have all hidden licenses behind a "View More…" link, or only show them if someone uses the filter option). The question is more: do we want to do that, and I don't know the answer to that. This might be a question for our product teams.

[benbalter]

Sounds like I'm in the minority on this one, which I can respect. If someone would like to get this PR or a similar one up to date, glad to merge with licenses other than CC0 as hidden, to at least get the metadata set, and can work with @bkeepers to address things from a product perspective. To note, since this PR was created, licenses moved to the _licenses folder, and we've got a bunch of new metadata tests.

[artob]

@benbalter Sounds like the crux of the matter is that the GitHub license drop-down currently in fact serves two functions, which conflict to some degree:

1. List of recommendations for newbies. You really wouldn't want all CC licenses listed here--after all, how is a newbie to grok the jungle of possible BY, SA, ND, NC permutations, without considerable further help. Not to mention the paralyzing effect of the paradox of choice, which the drop-down already suffers from a wee bit. CC0 is the single best possible default from the prescriptive point of view, what with it enabling maximum sharing and remix.
2. Convenience in creating a new repository. Here, of course, you're dealing with the long tail, which means it's a bikeshed problem. So, the petitions will keep coming until every 0.01%+ license variation is included. I noticed that you recently found a way to somewhat cope with that in the case of choosealicense.com itself.

Now, I don't have any particularly bright solution to suggest, other than to note that this kind of proliferation and interminable headache is exactly why you guys, same as Creative Commons, should want to be promoting the public domain as the default for everything--as you indeed are, of course, with CC0 and the Unlicense prominently included. (Thanks for that.) Life's too short, let's get back to coding...

[haacked]

Just to throw some historical context here, the reasons we didn't include CC licenses are pretty much along the lines that @benbalter suggested.

1. We had a laser focus on the needs of developers writing software.
2. We didn't want a giant license list in the repository creation drop down that contained a bunch of options that didn't pertain to the task the user is trying to accomplish (if I'm creating software, I don't want a bunch of CC options in the list).
3. It wasn't a priority at the time to get someone from the github.com team to solve the second item in this list.

I'm fine with adding CC licenses to choosealicense.com in a manner that they're hidden from github.com in the short run. But I think the metadata should probably have more information than just "hidden" or not. For example, a license type like "code" or "content".

That way in the short run, github.com could filter out "content", but in the long run, if we can get someone interested in providing a better experience, we could use the metadata to do that.

For example, one idea is the drop down has tabs. So by default, it has the "Code" licenses selected and only lists those, but you could click the "Content" tab and see the content licenses. However, I'm sure our product team will come up with even better ideas if they put their minds to it. 😄

[benbalter]

I'm fine with adding CC licenses to choosealicense.com in a manner that they're hidden from github.com in the short run. But I think the metadata should probably have more information than just "hidden" or not. For example, a license type like "code" or "content".

I like the way you think.

[jni]

I don't think it's necessarily that long a tail. I do sympathise with the argument that you can't have every possible license in there, but I wouldn't be surprised if CC-BY was more popular than many of the licenses currently on the list.

I do like both ideas of (1) separating code and content lists, and (2) making some licenses appear on the list only when searching. I'm quite happy not having CC-BY suggested, but it would be great if typing "CC" or "creat" would surface the CC list.

GitHub can have more than one mission, and its support for GitHub Pages demonstrates that it's interested in hosting content as well as code. It's probably better if one of those missions is not half-assed.

[bhuga]

@benbalter's focus on product simplicity is, I think, what has to win out here. Please don't think yourself outvoted. But @bendiken has made a good point about convenience vs guidance.

I wonder how we'd think about this if we made "personalized license tails" for the dropdown. So if you have a CC0 repo, CC0 is on the dropdown for you. By default, there's just the 8-ish that we're encouraging, but we add licenses you've already picked for your other projects.

The same way that this is coming up for different flavors of PD, it might also be helpful for people who fret about different versions of the GPL. It also sidesteps worrying about metadata for "content" and "code". If you're using a different license for non-code content, we'll help you out. Individual dropdowns would grow, but the product as a whole doesn't.

As a disclaimer when brainstorming about github.com in public, I doubt anyone has time to hop on a feature like this soon. But would that hypothetical feature solve this problem better? If so, does it change how we think about moving forward on a pull like this?

[mlinksva]

This PR includes several non-open CC licenses that aren't eligible per our new explicit criteria, uses old 3.0 versions and would require various other minor tweaks. I think better to start fresh; more in #33. Thanks!