When it comes to licensing, the three most prominent problems are identifying the license, how to declare the license and copyright information, and how to make sure other developers can easily reuse the code and adhere to your chosen license.
The current solution to these problems are automatic and manual scanning of files. The results are then typically stored in some form of proprietary database or spreadsheet. The solution for REUSE is to handle the problem at the source. It asks developers to do some steps to make life easier for the compliance people. It’s a set of formalized best practices.
REUSE consists of three steps.
It doesn’t reinvent the wheel, e.g. it reuses SPDX.
The first step is for developers to choose a license for their project, and to store the full license text in a directory called LICENSES. The file names in the LICENSES directory should use the SPDX license identifiers. REUSE’s assumption is that typical projects have more than one license: because of different parts (e.g. documentation licenses), or because it reuses code from somewhere else.
The second step is to add copyright and licensing info in every file.
/* * SPDX-License-Identifier: ... * * SPDX-FileCopyrightText: year Name <email> */
The license identifier can use SPDX expressions. The copyright text can be anything, not even the SPDX-FileCopyrightText is mandated.
For binary files, e.g.
foo.jpg, add a seprate file
foo.jpg.license that contains the license info.
For large volumes of files, the licenses can be collected in one single file,
/.reuse at the top level.
It uses Debian’s DEP-5 format and allows wildcards.
License information must be added for every single file, even for configuration files etc.
The last step is to confirm REUSE compliance.
reuse lint tool checks all files in the repo.
It tells you what is missing.
Also if there is too much, e.g. a file in LICENSES which is not used.
Components are added to REUSE to make life easier for the developers.
This includes a FAQ and a tutorial.
reuse can also generate the copyright headers, and it can generate a BoM.
It can be used in CI to verify that the code stays REUSE compliant.
The latter can be used to receive a REUSE badge: by pointing https://reuse.software to the public git repo, it can run the tool independently and generate the badge.
The next step is that projects need to adopt REUSE. FSFE started with their own code repositories. More than 120 projects funded by the European Commission will also be made REUSE-compliant. Also the kernel has started to become REUSE compliant, by adding the SPDX license identifiers to each file. It’s still an ongoing project however.
For dependencies: REUSE only checks your repository. So if they’re not bundled, they will not be checked. Also everything in .gitignore is ignored.
Files which have different licenses for different pieces are problematic. You’ll need some comments or something like that to handle such a case. It wouldn’t be machine-readable.