I have recently written how licensing is one of the important things to make it easy to contribute code. While I was preparing that blog post, I was also asking Matija if he knew of anything that would validate the presence of license and copyright information in new files. This is because in the past I might have forgotten it myself, and I have definitely merged a pull request or two in which a new contributor forgot to add the headers to the new files — I’m not blaming them, I’m not even blaming myself, I blame the fact that nothing stopped either us!
And indeed, Matija pointed at REUSE, which is a project by FSFE (which I still support, because they are positive!), and in particular at the reuse-tool, which includes a linter, which will ensure that every file in a repository is properly tagged with a license, either inline or (if not possible) through an explicit .license file. I love the idea.
The tool is still a bit rough around the edges, and for instance (because of the spec) it does not have any provision to ignore 0-sized files (or symlinks, as it turns out). Hopefully that can be fixed in the spec and the tool soon. When I started using it, it also didn’t know how to deal with any file that is there to support Autotools, which was clearly something I needed to fix, but that’s a minor issue — clearly the tool has focused on the stuff people care the most about, and Autotools projects are definitely going out of fashion, for good or bad.
I’ve now used reuse-tool to add proper licensing to all the files in most of the repositories that I’ve been actively working on. I say most — I have not touched usbmon-tools yet, because for that one I need to pay more attention, as the copyright not not fully mine. Which means that most likely even the silly configuration files that are unlikely to be copyrightable will have to be licensed under Apache 2.0.
Speaking of the configuration files — the FAQ I linked above suggests using CC0-1.0 license for them. I originally followed that and it took me a moment to remember that I should not do that. The reason is once again found in the previous post: CC0-1.0 is not an OSI-approved license, and that makes it impossible for some people (starting with my ex-colleagues at Google and other Alphabet companies) to contribute to the software, even if it’s just fixing my Travis CI configuration. Instead I selected MIT — which is pretty much equivalent in practice, even though not in theory. Update 2020-05-14: there’s some discussion of alternative recommendations going on right now. Considering that, I have changed my mind and will use Unlicense for configuration files, for the foreseeable future. As I said in the other post, Fedora prefers CC0-1.0, but it does not seem to be outright banned by any organization or project.
I did that for a number of my projects, including those under the python-scsi organization, and included it into a pending pull request I had already open for cachecontrol. Not all of them pass the linter clean yet, because of the 0-sized file issue I noted above. I also didn’t set them up to use pre-commit (despite Carmen adding support for it very quickly), because of that. But at least it’s a step in the right direction, for sure.
Speaking of pre-commit — one of the reasons why I wanted to have this is to make sure that the .license files are not left uncommitted. With the pre-commit check in place, the lint needs to pass for the staged changes rather than for the checked out tree. Once again, yay for automation.
I have to say that this push from FSFE — particularly because I have found myself unable to contribute to one of their projects before, because of missing licensing information on the repository. I also like the fact that they do care about getting people to use this, rather than making a purity tool for the sake of purity, which I’ve seen happening in other organisations. Again, score one for FSFE.
So if you have an open source project, and you want to make sure it’s easy for everyone, including those who may be working for big corporations, to contribute back, give a try to just setting this up with the tool. It should reduce significantly the cost of contribution, and even that of adoption.
