GitHub Open Source licensing tool

Best practice

GitHub Open Source licensing tool

GitHub, the online home of over 20 million developers, have open-sourced “Licensed” – their own, internal tool for managing Open Source licenses.

What does it do?

This tool is aimed at helping developers work towards compliance with the license terms of Open Source dependencies (an external software package used in an application) within their programs.

It finds, caches and checks the license metadata of dependencies and works across multiple languages and package managers across multiple projects. Using a project called “Licensee”, it automates the reading of license files and attempts to determine the license type. This will flag up if the license appears to be:

• Explicit copyright
• An exact match to an existing license
• X% similar to an existing license i.e. 95% similar to the MIT license

Licensed will store the dependency data in a source control repository, which helps make checking this data part of the development workflow. Whenever dependencies change, the license data must be updated which helps things remain compliant.

Typically, the license terms of an Open Source dependency will require that a copy of the license is distributed with future applications that contain it. Licensed helps automate this process and can also be used to create a “Bill of Materials” that enables users to see all the Open Source components used within the application.

Will it help?

A tool like this certainly looks to be useful for organisations trying to get a handle on their Open Source usage and compliance. Something that fits into the development workflow will help flag any issues as soon as possible and, with GitHub being familiar to so many developers around the world, the chances of it being adopted should be quite high.

However, perhaps that is also a flaw. Will the developer style nature of Licensed mean that ITAM departments stay away from it as they don’t understand it? If usage of this tool is left to the developers, there is an element of “who will watch the watchers?” If it can’t be managed centrally alongside existing SAM tools and as part of existing processes, perhaps organisations will be averse to adopting it?

Further Reading

Licensee – https://github.com/benbalter/licensee

Licensed – https://github.com/github/licensed

Licensed Documentation – https://github.com/github/licensed/blob/master/docs/configuration.md

More Licensed info – https://githubengineering.com/improving-your-oss-dependency-workflow-with-licensed/

Can’t find what you’re looking for?