Software, Licenses and Machines
Can a machine read the licensing model of my software?
Can software licenses be described in an unique way?
Well, let's see.
People in software development know that all open source/free (as in freedom) software are usually released through some licensing model.
This means that the author generally decides which kind of license to apply to the software and add some kind of note and license file about that.
This decides how other people can interact with such software.
I don't want to describe here the huge list of possible licenses for free or open source (or even proprietary) software, but actually the way developers are using those licenses.
As an author, I want to apply a license to my software so that people can understand how to possibly use it.
Solution 1 – Dummy-level
Grab a more or less random license somewhere, add it to the repository of my project. I'm happy.
Solution 2 – Basic-level
Let's follow GitHub-like guidelines.
Choose a license for the project from a list, write some possibly-related stuff into the
Spam the world about my wonderful project.
And I can go on forever with many different surely wrong solutions to the problem.
A Correct Way
I don't want to be unpolite, saying that this is the correct way. It's just a reasonably good way to properly apply a license to your software.
First, remember that the software is usually composed by multiple (many, more often than not) files: configurations, executables, examples, documentation, tests, ...
All these files must have an associated license.
Simply because you might even want to apply different licenses to different files: I don't care if people modify my
.hgignore file, but probably I do care if they change the server URL in some configuration file, or things like that.
Second, in my opinion a free (or open source) software should also be distributed with its project configuration, possibly even with the IDE configurations, the building rules and all the things needed to create a working version of the software, starting from its source. These will help contributors and more tech-savvy users. Often these files are automatically generated or depending on some libraries or tools. For these reasons they are generally not created by the same author of the software, so probably they need to have a different license.
Third, this licensing model management should, in my opinion, be independent from the development platform or repository or tools used to create such software. Why? Because maybe GitHub is the de facto standard for public software repositories, but developers might want to have a more general and portable way of dealing with these things. A few years ago there was SourceForge, then it was BitBucket, now it's GitHub. But tomorrow? There might be a new kid on the block, and developers just don't want to waste time on porting things: they (the things) just have to work right from the start.
So, what about choosing conventions and standards?
Well, as said, GitHub has its own way to describe project licensing.
BitBucket has another one, then there are the coding (and project structure) conventions from GNU (like the
COPYING file), ... And many many others.
Let's think in these way:
- files have to have their own license.
- For text files that I created as software author, I can just add a specific header in the file.
- For all other files and resources that I also created but cannot have a header, a property or other kind of metadata, I can either have an external license file or license descriptor associated to each of them, or create a sort of “bill of materials” containing the whole list of files, and the associated license for each.
- And I can do the same thing for all files belonging to the project, that I, as software author, have not created directly (I do not own the copyright) but I need for the project itself.
Automatically created files like JavaDoc or RDoc,
*.lockfiles and so on.
- Then, I need a place to collect all the licenses I use or refer to, so that users can read and possibly accept them.
- And I also need a unique way to refer to those licenses.
Well, do we have something here?
The way to manage those “bill of materials” or to associate licenses files (information/metadata) to each file belonging to the project, regardless of the fact I'm the copyright owner author or not, is called REUSE and it's a way to make licensing information available and readable to both humans and machines.
It's a project from FSF Europe that, with few simple conventions and even a
linting tool, allows to create and apply licenses to your software in a standard, uniform and easy to read way, that can be explored also by automatic tools.
It can check the status of the licenses file by file, it can check the content of a “BoM” in Debian's
dep5 format, it can even download all the referred licenses for you, putting them in a
Do take a look, use it for your projects, spread the word!
The unique way to refer to a license is called SPDX, that is basically a file format that documents the licenses associated to a software. There's even an associated Working Group that manages and updates the known licenses list.
It's associated to a list of well-known free/open source licenses with their specific full name and a short, unique tag/identifier that is also used by REUSE to properly identify and download those licenses on a per needed basis.
At the moment I'm “working” on three simple projects: two Ruby APIs (
wwwjdic) and one LibreOffice Calc spreadsheet with personal Kanban metrics (
All these three projects (their tip commit, actually) are REUSE-compliant (official releases will be soon available!) so that every user or other contributors can understand how licenses are applied to each single file of those projects.
- AAMfP: https://savannah.nongnu.org/projects/aamfp
- Gravaty: https://rubygems.org/gems/gravaty
- WWWJDic: https://rubygems.org/gems/wwwjdic
I think that if all public free/open source projects would follow this simple licensing standard, also licensing models and licenses differences would be better understood.