Licensee

What we look at

Licensee works by taking a detected license file, and comparing the contents to a short list of known licenses.

Detecting the license file

Licensee uses a series of regular expressions to score files in the project’s root as potential license files. Here’s a few examples of files that would be detected:

• LICENSE
• LICENCE
• license.md
• COPYING.txt
• LICENSE-MIT
• COPYRIGHT
• UNLICENSE

:warning: If the project has multiple license matches (e.g. a package file match, a file named license or similar that matches the regular expressions) that don’t only match one well known license (see below), Licensee won’t return a license for the project, but all matches are returned in the licenses array.

Known licenses

Licensee relies on the crowdsourced license content and metadata from choosealicense.com.

What it doesn’t look at by default

• The licensing of a project’s dependencies
• References to licenses in README, README.md, etc.
• Every single possible license (just the most popular ones)
• Compliance - multiple tools and human review are needed to address all aspects

Huh? Why don’t you look at X by default?

Because reasons.

Why not just look at the “license” field of [insert package manager here]?

The LICENSE file is platform-agnostic, and most popular licenses today require that the license itself be distributed along side the software. Simply putting the letters “MIT” or “GPL” in a configuration file doesn’t really meet that requirement. Those files are designed to be read by computers (who can’t enter into contracts), not humans (who can).

From a practical standpoint, every language has its own package manager (some even have multiple). That means that if you want to detect the license of an arbitrary project, you’ll have to implement 100s of package-manager-specific detection strategies.

However, licensee does optionally look at license metadata of a handful of package manager files.

License metadata in package manager files can complement detection from LICENSE files through license expressions (e.g., is a GPL-3.0 license -only or or-later-versions, or do multiple LICENSE files indicate disjunctive choice) but licensee currently does not parse these expressions.

What about looking to see if the author said something in the readme?

There are lots of ways of saying a project or some portion of it is under a license in natural language, and that’s what is often found in a README file. Licensee can’t reliably parse natural language.

However, licensee does optionally look for license indicators in README files. Just don’t expect that it will detect most statements found in such files, and expect to review any that it finds.

What about checking every single file for a copyright header?

It’s a lot of work, as there’s no standardized, cross-platform way to describe a project’s license within a source file comment. (Adding a SPDX License Idenfifier to source code comments can clarify what license applies to a single source file, but licensee reports on licenses at a project level.)

Scanning every source file for potential legal notices is a useful part of a license compliance program, but there are other tools that specialize in that.

This site is open source. Improve this page.