Pick a peck of license pickers
An in-depth look at efforts to make choosing a license easy
Are interactive tools like choosealicense.com or the Creative Commons license chooser effective? What about noninteractive guides like the Free Software Foundation's situational license recommendations? Do these tools have agendas, and if so, are these agendas made explicit and are they in line with the interests of the developers who use them? Can we find ways to make them better, or do we need a brand new tool?
There's of course many free software and free culture licenses out there, and some commonly used standard nonfree ones as well. The problem of "license proliferation" has been and continues to be identified as a problem in our world. Especially when starting a new project, choosing which one of the licenses to use can be daunting and conflict-prone, and these choices are not what developers typically want to spend their time on. As one solution to this problem (or coping mechanism), some companies and nonprofits have developed tools and guides aiming to narrow the set of options based on plain language statements about what the developer would like her project's license to achieve in practice.
Two of the most popular interactive tools are Github's choosealicense.com and Creative Commons' license chooser. Then there are the noninteractive guides, like the Free Software Foundation's best practice license recommendations, a subset drawn from its full list of free licenses. Some of these tools claim to be "objective", while others are explicit about their connection with specific missions or agendas.
I'll do a survey of these tools and guides, along with a bit about their history, then assess their usefulness for developers and possible impacts on things like license usage counting surveys. I'll highlight the ways in which the most prominent ones either intentionally or possibly unintentionally further a particular agenda. That will involve a look at the language choices we make when trying to describe license terms in "plain language," such as whether we call a provision a "restriction" or a "protection," and the implications of those choices.
I'll invite discussion along the way, and maybe together we'll come away with some productive next steps to improve license culture and education for everyone, such as pull requests for existing tools, or an outline for a new, ideal tool for someone (the FSF?) to implement.