ScanCode's release tags name a sub-project, and its requirements pin every package exactly

Six manifests and a build backend of its own

The repository root holds six files whose names differ only in the middle, and each one builds a different artefact: the toolkit, a reduced toolkit, two data packages for licence text and licence index, one for a shared internal library, and one more. The manifest at the root says in a comment that it exists only for development, names the project with a development suffix, and carries a release candidate version, while the other five are what actually produce the wheels and archives. The build backend is not the usual packaging library either; it is a project of the same organisation with a pinned minimum version, and the comment explains that it is the tool that drives the other manifests. That arrangement is coherent for a project that ships several related distributions from one tree, and it means a contributor who edits the root manifest expecting a release has edited the wrong file.

The release tags name a sub-project, not the toolkit

The three newest releases on record are all named after one of the internal libraries rather than after the toolkit, and they carry that library's own version line. The toolkit's own version lives somewhere else entirely: the development manifest in the root declares a release candidate in the low thirties, while the newest release of anything you can see on the page belongs to the shared library and sits several versions lower. The consequence is that the tag list is not a release history for the thing most people install, and a reader who reads the version off a tag will install a different component than they expected. The tree reinforces the arrangement by carrying separate changelog files for the toolkit and for the internal library, which is the honest way to publish several versions at once, and also means the toolkit's own history has to be read somewhere other than the releases page.

The requirements list pins everything, including two patched packages

The install list is about a hundred lines and every one is pinned to an exact version, with no ranges at all. Among them are several of the project's own sibling libraries, each pinned too, which is how the toolkit keeps a set of related packages in step across a release. Two entries have names that announce what they are: one is a patched distribution of a parameter expansion library and another is a patched distribution of a Maven client. A file at the root configures the tool that vendors and patches dependencies, so this is a maintained practice rather than a workaround someone forgot to remove, and the trade is deliberate: an install that cannot drift is an install you can reproduce for an audit, which is exactly what this project is for. The cost is a long list to review, and two entries a reviewer has to go and look up separately.

The image is one architecture and its build trains a model

The container file pins its base image to a single processor architecture, which means the image it produces will not run everywhere the documentation says the software runs, and the repository carries separate dependency lists for a native install and for Linux to compensate. The more surprising part is what the build does. After installing dependencies it runs three preparation commands: one builds the base licence index, one builds the cache of package patterns, and one trains a Markov chain model used for gibberish detection. So building this image is not a packaging exercise, it is a build with training in it, and it will take correspondingly longer and produce a different result each time unless the training input is pinned. Both facts are stated plainly in the file, which is the right way to write it; they are simply the first two things to know before you put the image into a pipeline.

Four badge definitions point at a different organisation

The page has a four cell table of build badges, and the image substitutions that fill them point at continuous integration definitions under a project owned by a company rather than under the organisation that hosts the repository now. All four do, including the release badge, so the badge a reader sees is reporting on a build that may or may not be the same commit as the one they are reading. Two consequences follow. A green release badge is not evidence about this repository's default branch, which is a development branch that the badge definitions do query, so part of it is right and part of it is not. And anyone debugging a failing build from the badge lands in the wrong place, which is a small thing that costs a maintainer an occasional confused issue report.

The claims on the page are superlatives without numbers

Two paragraphs make strong statements and neither gives a measurement. One calls the project the leading tool in scanning depth and accuracy, used by hundreds of software teams, and another calls its licence detection engine the most accurate available, on the grounds that it compares your code against a database of licence texts rather than relying on patterns, edit distance or machine learning. The second claim is the interesting one, because it is a statement about method rather than about a benchmark, and method claims are checkable: you can read how the comparison works and decide whether it suits your situation. The first claim is not checkable at all. Neither is disqualifying, and the method argument is a good reason to try the tool, but a reader evaluating it for a compliance workflow should note which sentences are evidence and which are adjectives.

Two typos and a compound licence in the same page

The licence section is the part to read carefully, because it is not one licence. The project overall is under a permissive licence, the reference datasets are under a creative commons attribution licence, and third-party components and the test suite's code and data carry a set of secondary licences including copyleft ones. There is a notice file, and the project uses per-directory files that document the origin and licence of vendored code, which is a stronger practice than a single notice. The same page that does that has a misspelling in the build status paragraph and another in the sentence offering commercial support. That contrast is the useful part: the licence handling is careful where it has to be, and the prose is not edited to the same standard. Two more files at the root, a roadmap for the toolkit and one for the wider organisation's work, suggest the same split between careful machinery and lightly edited pages.

Editorial conclusion

Use ScanCode Toolkit when you need a defensible inventory of what licences are in a codebase, because its central claim is that it compares against licence texts rather than guessing from patterns, and that claim is the reason to choose it over a regex scanner. Three things to check. The licence is compound, with a different licence for the reference datasets than for the code, so read the data licence before redistributing a scan's reference material. The install is a configure script plus a fully pinned dependency list, which means reproducible and slow, and two of those pinned packages are patched forks you should look at. And the release tags are per internal library, so pinning the toolkit by its newest tag will not work the way you expect; read the changelog rather than assuming the tag you can see is the toolkit.

Frequently asked questions

Official sources

1. aboutcode-org/scancode-toolkit on GitHub
2. Issues
3. Project website
4. README
5. Releases