Software licenses definitely aren’t something that get developers very excited. In fact, in my experience the most common response is to look for a sandy spot to bury one’s head. Legally and morally, however, getting it right is kind of a big deal.
At Media Suite we’ve aimed for a fluid and adaptive approach that ensures we’re managing our use of open source libraries responsibly, while freeing us up to do what we enjoy most – writing great code. The goal is to strike a balance between managing compliance without disrupting development within a Sprint.
Open Source Licensing at Media Suite
The first thing we start with is a general guide to software licensing within the company, which lists out our process to follow for tracking software licences.
In a nutshell it comes down to:
- Knowing when to flag or escalate a licence choice (both internally, but also potentially to a client if the licence is more restrictive than we are comfortable with or has ongoing costs associated with it).
- Tracking licences used in the project in a way which gives us clarity and context.
Having a reasonably consistent approach at a project level enables us to better manage the legal (and moral) risks of getting this wrong.
Knowing When to Flag or Escalate a Licence Choice
To decide when a license choice needs to be escalated we manage three lists to help:
- “Safe” Licences
- Approach with Caution / Escalate
- Probably not OK / Escalate
“Safe” licences make up the vast majority of open source licences you encounter today (think MIT, Apache, BSD, and friends). What we are looking for here are the most permissive terms (perpetual, royalty free, allowing unfettered reuse modification & reselling). We effectively “pre approve” these with our clients and so if you encounter one in a library you’d like to use, go right ahead. Given the popularity of these licences having a “pre approved” approach frees us up to focus on development.
Approach with caution licences are typically fine to use, but may have a potential problem or an obligation that warrant flagging to the project lead or even out for a legal review so someone can double check the specifics and consider that the license is indeed OK for the contemplated use in this particular project.
Probably not OK are ones that are generally problematic enough that they shouldn’t be used in a commercial context but can still be escalated to double check as they may be acceptable depending on specific circumstances (or with the informed consent of the client).
Our general guidelines have a good starting point for these lists but as every project is its own unique snowflake of contractual joy they really do need review and tailoring to match the requirements of a specific project.
Tracking Licences That Are Pulled Into the Project
To track the licences that are used, we create a register, which is a spreadsheet of the libraries along with their licence (including version). This is regularly updated during the course of the project to represent the current state of the codebase.
This is the arduous part of the process but luckily something that is easily automated (a must given the dependency tree sizes of Javascript projects).
Here are some tools we’ve used to generate registers in our most common language choices.
Javascript / Node
The Node Licence Finder (nlf) package is a great little tool to use for NPM packages. You can simply install it and run it in the same directory as your package.json file.
For example, to generate CSV with package and licence information, you can use:
nlf -c
Note, that this can take some time to run. You can adjust the level of dependencies to follow with the -r flag, e.g.
nlf -r 1 -c
See nlf –help for the full list of options, but it has a couple of other useful features like adding a -d flag to exclude dev dependencies.
Some other useful tools:
- licence-checker – similar package for querying licences
- https://npm.anvaka.com/#/ – visualise package dependencies
- yarn licences – built in Yarn tool for listing licences
Python
For pip installed dependencies we’ve written a script (MIT licensed :D) that wraps around setuptools pkg_resources module. You can give it the path to the requirements.txt file and have it output CSV information about the packages and their licences.
list-licenses.py requirements.txt
Some other useful tools:
- Pipdeptree – As the requirements.txt file is flat, sometimes it’s useful to see which library is pulling in other dependencies, for that pipdeptree is very useful.
Final Word
This is an evolving process and as we encounter different languages, package managers and licences in our work we’ll obviously continue to grow our guidelines and improve our toolkit.
Some other handy resources:
- tl;dr Legal – Software Licences in Plain English
- Open Source Initiative – lots of information including OSI-approved licences
Banner image: Photo by Javier Allegue Barros on Unsplash
