In a previous article, I discussed the complaints that have been leveled against GitHub during the past year and a half concerning the purported problem of public, seemingly-FLOSS code repositories with no explicit licensing. Here I will address the actions GitHub took in July, which were undoubtedly in response to this criticism.
Noting that "sharing your code isn't everything... it's also important to tell people how they can use that code" and that "choosing an open source license can be confusing," GitHub created an informational website to aid developers: choosealicense.com. At the same time, GitHub added a new license picker to the user experience of initializing a new repository with a README file. The user is presented with a drop-down list of 10 or so open source licenses (with the default or top element being "None"). If the user selects a particular license from the list, the new repository will be populated with a copy of the corresponding license text.
While I have some criticisms of choosealicense.com, I wish first to commend GitHub for making it an open source, forkable GitHub-hosted project.
choosealicense.com is not some new genre. It shows the influence of the earlier tl;drLegal. Creative Commons introduced the idea of "deeds," said to be "human-readable," that are intended to aid understanding of the actual "legal code" of the license. Creative Commons has also for some time provided a simple web service to help content authors select an appropriate CC license. John Cowan has long maintained a FLOSS license selection wizard. There have been other such efforts over the years.
For those who don't know, most of the open source software released by GitHub has been placed under the MIT license. This is not surprising, given the popularity of that license in the Rails community from which GitHub sprang. But it is not a license choice made without reflection or resulting from mere trend-following. GitHub's CEO and co-founder Tom Preston-Werner provided a well-reasoned argument for why he prefers the MIT license in his influential 2011 essay Open Source (Almost) Everything.
Preston-Werner's essay provides good insight into the worldview of proprietary web application developers who are active in releasing libraries, tools, and frameworks under permissive open source licenses. (For a critical analysis of this phenomenon, see Chris Webber's A Field Guide to Copyleft Perspectives.) Preston-Werner repeated his pitch for the MIT license (coupled with a critique of the GPL) in his recent OSCON keynote, which among other things covered the launch of choosealicense.com. Many of my colleagues at Red Hat would question Preston-Werner's assumption that if code is "core business value" it is not sensible for it to be open source. I myself find GitHub's involvement in open source, including its approach to licensing, a refreshing change from the now-dying world of cynical, copyleft-based business models with which many earlier web services startups experimented.
Nevertheless, the view articulated by Preston-Werner is a political preference. With knowledge of this view, it is difficult not to see the presentation of information on choosealicense.com as reflecting that ideology. On the front page of the site, there is a column display of three featured license choices, associated with some policy that "best describes your situation," naturally viewed from left to right. The first choice is the MIT license. Oddly, the Apache License 2.0, one of the most permissive open source licenses, is presented as though it were a middle-ground choice (when a weak copyleft license such as EPL, MPL, or LGPL might have sensibly been included instead). And the GPL is then thrown in on the right, perhaps in a forced attempt to provide balance or because failure to highlight the GPL would diminish the credibility of the site.
One puzzling aspect of the choosealicense.com front page is the recommendation that the Apache License be used by those who are "concerned about patents." While the patent provisions of the Apache License are important and distinctive, there are copyleft open source licenses that do much more to address patent issues (notably MPL and the GPLv3 family). I am not suggesting that the Apache License is a bad choice—on the contrary, during my years at Red Hat we have opted to release an extensive amount of code under that license. I merely consider it odd to single it out as the license an open source legal novice ought to be looking at if his or her foremost concern is patents.
The choosealicense.com front page includes a couple of examples of errors introduced by the attempt to summarize. The favored MIT license is said to require "attribution back to you," but in fact it requires preservation of copyright notices, which is not the same thing. More bothersome is the assertion that GPLv3 departs from GPLv2 in "further restrict[ing] use in hardware that forbids software alterations," the phrase "further restrict" echoing a key condition of both GPL versions. GPLv3 does not make any such use restriction; rather, GPLv3 requires distributors of some types of hardware to provide certain information to users to enable them to install altered software, under some circumstances.
A page linked to from the front page provides summary information on the three "featured" licenses (with the GPL specified as GPLv2), followed by a list in apparently arbitrary order of various other open source licenses, most of which are reasonably mainstream. This list also includes "No License" as though it were one type of license to choose. Each license has a one or two-sentence summary, a link to the full license text, and some bullet points listed for three categories of information ("Required," "Permitted," and "Forbidden"). In this list too one can find errors. This is most notable for the "No License" case, which GitHub insists on presenting as a first-class option. The summary sentences accurately give GitHub's take on what unlicensed code repositories ought to signify legally. The accompanying bullet points, however, suggest that with "No License" one must preserve the (nonexistent) license and (for GitHub repos, likely nonexistent) copyright notice but that private and commercial use are somehow permitted.
I am not too critical of the GitHub license picker for new repository initialization, particularly because it currently offers a broad range of license choices. The selected license may prove to be in conflict with the code in the repository as it evolves (for example, if it incorporates third-party code), though this is as likely to occur in any case where a developer designates a particular license at the earliest stages of project development.
It will be interesting to see what effects, if any, the license picker will have on the licensing of GitHub-hosted projects. If we see a marked reduction in 'POSS' for new GitHub repositories, and evidence of continued or increased preference for simple permissive licenses like the MIT license, it will support the view that unlicensed code on GitHub is generally a naive attempt at maximally permissive open source licensing. Extensive use of the "No License" option will suggest that developers are being deliberate in avoiding explicit licensing, though the significance will probably remain unclear.
3 Comments