Github Finally Agrees Public Repos Should Have Explicit Licenses
WebMink writes "After strong criticism last year, Github has finally accepted the view that public repositories with no open source license are a bad thing. Self-described as the 'world's largest open source community,' a significant number of GitHub projects come with no rights whatsoever for you to use their code in an open source project. But from now on, creators of new repositories will have to pick from a small selection of OSI-approved licenses or explicitly opt for 'no license'. In Github's words, 'please note that opting out of open source licenses doesn't mean you're opting out of copyright law.'"
A quick scan of their new choose a license site reveals at least a few flaws: they present simplicity, caring about patents, and sharing improvements with others as mutually exclusive points when they clearly are not (e.g. the Apache license and the GPLv3 both help with patent concerns, but only Apache is mentioned; and the MIT/X license is listed as the simple license when BSD-style is more prevalent). They also imply it is entirely optional to actually note your copyright in your files, when it is really bad practice not to unless you really want to make it impossible for people to understand the copyright history when e.g. merging your code into another project. Their list of licenses does provide a nice overview of the features of each, but regrettably encourages the use of the GPLv2 (without the "or later version" clause), listing the GPLv3 and all versions of the LGPL in league with seldom used licenses like the Perl Artistic license.
I'm surprised GitHub didn't require one to specify a code license of some kind when publishing code. The default if no license is specified is not "public domain", but private with all rights implicitly reserved for the owner of the code.
I do not fail; I succeed at finding out what does not work.
We've seen what happens with screwball licenses: anyone remember why qmail, djbdns, and daemontools never made it into major software distributions, despite being noticeably better than their alternatives? Because Dan J. Bernstein saddled them with a license where you couldn't publish your modified code or binaries from it, you had to publish *his* source and your diffs against it and let people build their own binaries locally. He finally got a clue and released it all as public domain, but it was too late. Inferior products (such as Postfix, BIND, and systemd) had evolved to the point where it wasn't worth investing any effort in Dan's technically and conceptually superior tools. I was in a stack of meetings where I had to explain that we couldn't get vendor support from those tools on our operating systems because Dan's license prohibited the vendors from shipping the tools.
Hooray for reducing license wackiness!!!!!
I don't think it's "regrettably" that the classic GPL (v2) is featured over v3. Many, many GPL projects have decided v3 is a bad license, so newbies shouldn't be pushed in that direction.
The wording of the patent clause is broader than most of those who participated in the drafting intended, in a way that could be problematic for most companies. The GNU project themselves, the creators of GPL. v3, have had to disavow the plain language of the license, claiming it doesn't say what it does.
I think most people intended that if you release code under GPL, you give up patent rights related to the code you contribute. The wording is broader than that, though. The way GPL3 is actually worded, if a company contributes to any GPL project a third party can use that project to nullify other patents from some other division of the company, arguably. The issue hasn't been tested in court, but it's enough of a risk that many companies won't touch GPLv3 code. It could cost Apple, Samsung, or Google tens of millions of dollars if that loophole allowed competitors to nullify their patents, rather than having to cross-license them.
Not having a license on every file is a colossal pain for people wanting to take part of your code and integrate it into something else. I recently went through this with OpenIndiana: they wanted to take some of my code from another project and include it in their libc. This is fine - the license I'm using is more permissive than their libc so there's no legal problem - but I'd forgotten to include the license text in the file, I'd only put it in a LICENSE file in the repository root. Keeping track of the license for one file that is different from the others in the project imposes a burden for them and, without the copyright in the file, potentially means that others will grab that file and think it's under a different license.
In short: Please put licenses in files. It makes life much easier for anyone wanting to use your code. If you don't want people to use your code, then you can save effort by not publishing it in the first place.
I am TheRaven on Soylent News