Licensed and the part of licence compliance that can be automated

A cache and a check, not a compliance programme

Licensed caches the licences of dependencies and checks their status, and it is available as a Ruby gem. The project states its own limits in the second paragraph of the README, which is a good sign about the documentation and a useful one for the reader.

Licensed is not a complete open source licence compliance solution. The disclaimer at the bottom expands on that: the tool is intended to provide automation around documenting the licences of dependencies and whether they are configured to be allowed by the user of licensed, in other words to surface the most obvious licensing issues early. It is not a substitute for human review of each dependency, and it is not the goal of the project or of GitHub, Inc. to provide legal advice about licensing or any other issues. The README tells you that if you have questions about licensing compliance, it is up to you to do further research or consult a professional.

The underlying idea is straightforward and still worth having. A dependency's licence is a fact about that dependency, and it does not change between builds. Fetching it, or reading it, once and caching it removes an enormous amount of repeated work, and comparing the cached result against a list of what your organisation permits turns an annual audit into a build failure.

The audience is an organisation that has decided what licences it will accept and wants that decision enforced mechanically on every pull request. The people who run the tool are not lawyers but they are the people who can make a build go red.

Low maintenance mode is stated before anything else

The Current Status section of the README is short and unambiguous. Licensed is currently in low maintenance mode, and at this point the maintainers are only looking to maintain the repository for security fixes.

That sentence changes how a project like this should be evaluated. A licence checker has a long tail of dependency sources to keep up with, because every package manager, every framework and every lockfile format changes, and a tool that stops adding sources slowly stops covering the ecosystem it was built for. The configuration option to enable and disable dependency source enumerators is documented, and the sources documentation lists what is currently available, and that list is the true scope of the tool.

The release record is consistent with the status. v5.1.0 was published on 2026-04-28, v5.0.6 on 2026-03-16 and v5.0.4 on 2025-05-06, so patch releases between minor ones. The repository is not archived, and the last push was on 2026-10-02, so work of some kind continues.

For an adopter the practical reading is that this is infrastructure you adopt, not a project you depend on for new features. If your dependency graph uses a source the tool does not enumerate, nothing in the tool will tell you, and nothing in the tool will change until someone adds that source.

Version 4 removed the self-contained executable

The README carries three version notes, and the newest one is a removal rather than a feature.

Licensed v4 no longer provides a self-contained executable build of licensed, and the README links to the deprecation notice in the repository's issue tracker for more context. Before v4, the tool could be shipped as one binary with a Ruby runtime inside it, which is how you would distribute a licence check to a team or put it in a container without installing Ruby at all. That route is closed.

Version 3 has a narrower breaking change. It applies if both of the following are true, a project uses bundler to manage Ruby dependencies and a project uses the self-contained executable build of licensed. All other usages should not encounter major changes migrating from the latest 2.x build to 3.0, and the v3 migration documentation under docs/migrations covers it in more detail.

Version 2 is the one that shaped the data on disk. It brought many internal changes intended to make licensed more extensible and easier to update, and while not much changed externally, v2 is incompatible with configuration files and cached records from previous versions. The migration is easy, using the licensed migrate command, or licensed help migrate to see what it does.

The pattern across the three notes is consistent, and useful for planning an upgrade: the v4 removal is the change to plan around, and only v2 needed a migration command.

Installation starts with cmake and pkg-config

The dependency story is the first practical hurdle, and it is not the usual Ruby one. Licensed uses the libgit2 bindings for Ruby provided by rugged, and rugged requires cmake and pkg-config, which you may need to install before you can install Licensed.

# Ubuntu
sudo apt-get install cmake pkg-config

# macOS
brew install cmake pkg-config

That is a build toolchain dependency for a tool whose own job is to inspect other people's dependencies, which is an irony worth naming. It comes from the licence cache, since a licence is read from a git repository and reading git repositories without shelling out to the git binary means libgit2.

After that, the two installation routes are the familiar ones. In a Gemfile, as a development group dependency:

gem 'licensed', :group => 'development'

followed by bundle. Or on macOS, a Homebrew formula:

brew install licensed

The repository also carries a Brewfile, a .ruby-version file and a licensed.gemspec, so the development environment is pinned in the usual Ruby fashion. The practical advice for a team is to install the system packages once on the machine or in the CI image, and then the gem itself is ordinary.

A configuration file is required, and sources can be switched off

Two configuration facts determine whether the tool does anything useful for you.

The first is that a configuration file is required for most commands. The configuration documentation describes the format and the available options, and the getting started guide covers using Licensed as part of a developer workflow. Without a configuration that says which licences you permit, the checker has nothing to check against, so this file is the actual specification of your policy and it deserves the same review as any other compliance artefact.

The second is that Licensed can enumerate dependencies for many languages, package managers and frameworks, and that sources can be explicitly enabled and disabled as a configuration option. That is a more interesting capability than it first appears. A source is an enumerator that knows how to read one ecosystem's manifest and lockfile, and the set of enabled sources decides which parts of your dependency graph get looked at.

Turning a source off is occasionally necessary. A project with a vendored directory that looks like a dependency, or a source that misreads a lockfile format, produces findings that are noise, and noise in a licence report is how real findings get ignored. The option exists, and it is worth knowing about before you spend an afternoon chasing a false positive.

The command list itself is discoverable, either in the commands documentation or by running licensed -h, and the three paths through the repository are the documentation, the sources documentation and the configuration file documentation.

The cache lives in .licenses/ and migrate rewrites it

The repository layout shows what the tool persists. There is a.licenses/ directory, which is the cache of licence documents, and two configuration files,.licensed.yml for the project and.licensed.test.yml for the test fixtures. There is also a script/ directory for the development commands and an exe/ directory for the command line entry point.

The cache is the point of the design. A licence is a document that lives in a dependency's repository, and fetching it on every build would be slow, would need network access in CI, and would produce different results as the upstream repository changes. Caching it makes the check deterministic, which is what lets it live in a pull request check rather than in a periodic report.

That caching is also what the version 2 change hit hardest, since v2 is incompatible with configuration files and cached records from previous versions, and the licensed migrate command exists to rewrite them. A team that has been running this for years will have a cache on disk and a configuration file that has to move together, and the migration command is the supported way to do it rather than deleting the cache and re-fetching, which would work but would also quietly change the results of the check.

The development workflow in the README is the usual Ruby one, with a bootstrap script, a setup script for the test fixtures, a cibuild script for the tests, and a console script for an interactive prompt. The setup script takes a -f flag to force a clean test fixture environment, and the gem installs locally with bundle exec rake install.

MIT, a GitHub project, and a deliberately narrow promise

The gem is open source under the MIT licence, which for a tool you run inside a build pipeline is about as low friction as it gets, and there is a LICENSE file at the root of the repository. The contributing guidance points at GitHub, the project describes itself as a safe and welcoming space for collaboration, and the code of conduct is the Contributor Covenant.

The interesting part of this project is the boundary it draws. A full compliance solution would need to know which licence obligations actually apply, which notices you must reproduce, which files to ship, whether a dependency is used in a way that triggers copyleft, and whether your distribution model changes the answer. Licensed does none of that. It fetches the licence of a dependency, caches it, and tells you whether it is in the set you said you allow.

That is a small promise, and it is one a tool can keep. A dependency with a forbidden licence is caught on the pull request that introduces it, while the change is still small, which is the point the project makes when it says licensing issues are far cheaper to fix if found early.

The cost is that the tool tells you nothing about obligations. A permissive licence in the allowed list still carries attribution and notice requirements, and a copyleft licence in the allowed list still has conditions about how you distribute the work. Licensed automates the question it was built to answer, which is whether a licence is permitted, and the disclaimer makes clear that the rest of the problem is still yours.

Editorial conclusion

Adopt Licensed if you ship software and want a build step that fails when a dependency carries a licence your organisation does not permit, since that catches the obvious cases cheaply. Do not adopt it as a compliance programme or as a replacement for legal review, which the project explicitly disclaims, and do not adopt it if you need the self-contained executable, which version 4 removed. Verify three things first: which dependency sources your stack needs, because sources can be enabled and disabled and a missing one means a dependency nobody checked, that your configuration file lists the licences you actually permit rather than a copy of a permissive list, and whether the project in low maintenance mode still fits your roadmap. The last push was on 2026-10-02 and the newest release is v5.1.0 from 2026-04-28.

Frequently asked questions

Official sources

1. Issues
2. licensee/licensed on GitHub
3. License: MIT
4. README
5. Releases