REUSE

The REUSE project [14] was created under the auspices of the Free Software Foundation Europe (FSFE) and is based on two pillars: machine-readable copyright files from the Debian project and Software Package Data Exchange (SPDX) [16], a standardized method for exchanging copyright and license information between projects and people [17].

REUSE provides both instructions and the reuse tool [18] to help you ensure that your project has correct licensing information. The project website (Figure 2) compares REUSE with other solutions [19], including ScanCode [20], ClearlyDefined [21], FOSSology [22], and OpenChain [23].

Figure 2: The homepage of the REUSE project. © FSFE e.V.

The installation procedure with pip for the Python reuse command-line tool is fully documented. The software was added to the package sources as a Debian package [24] under Debian GNU/Linux 12 "bookworm."

The reuse tool offers a whole range of useful functions, which are certainly not limited to adding copyright and license information in the header of a file (annotate subcommand) or preparing a project to comply with the REUSE specifications (init). You can also check a project for compliance with the REUSE specifications (lint) and create an SPDX document with all the files from the project (spdx).

Listing 2 shows the reuse check results for the Python cryptography module. Even at first glance, it is clear that several files do not contain copyright and licensing information and that the module therefore does not comply with the REUSE specification.

$ cd cryptography
$ reuse lint
# MISSING COPYRIGHT AND LICENSE INFORMATION
The following files have no copyright and license information:
* .gitattributes
* .github/ISSUE_TEMPLATE/openssl-release.md
[...]
* vectors/cryptography_vectors/x509/wosign-bc-invalid.pem
* vectors/pyproject.toml
The following files have no license information:
* docs/_ext/linkcode_res.py
* src/cryptography/__about__.py
# SUMMARY
* Incorrect licenses: 0
* Outdated licenses: 0
* Licenses without file extension: 0
* Missing licenses: 0
* Unused licenses: 0
* Used licenses: 0
* Read errors: 0
* files with copyright information: 2 / 2806
* files with license information: 0 / 2806
Unfortunately, your project is not compliant with version 3.0 of the REUSE specification :-( $

Selecting a License

Once the licenses for the individual works have been clarified, it is time to choose the license for your own project. Both GitHub and SPDX offer assistance. To begin, select the appropriate SPDX terms [25] and then add them to the license description header or your software. Table 2 lists the most important SPDX identifiers.

After selecting a license, you need to compare it with the licenses of the works you incorporated, check for conflicts, and ensure you are in compliance with the desired standard by trying reuse again. If no conflicts are found, everything is fine. If the check does reveal a conflict, you need to reconsider your choice of license and repeat the check step.

Never Without a License

A software license is simply part of the software. For free software, you can choose from a very wide selection of licenses [26]. OSI, for example, provides an overview [2].

As the author, you choose appropriate license terms that you attach to your work in text form. The license is your way of defining what other people can do with your work in both private and commercial use. Multiple licensing exists if you specify different licenses for the two types of use, as shown in Listing 3 for the Python cryptography module.

This software is made available under the terms of *either* of the
licenses found in LICENSE.APACHE or LICENSE.BSD. Contributions to
cryptography are made under the terms of *both* licenses.
The code used in OpenSSL locking callback and OS random engine is
derived from the same in CPython, and is licensed under the terms
of the PSF License Agreement.

Some traps can later lead to unwanted conflicts (e.g., if you use the Server Side Public License, SSPL [27]). OSI has decided that the license is not consistent with its open source definition. However, it is used in major software projects such as MongoDB, the Elasticsearch search engine, and the Kibana visualization tool.

You can choose a proprietary software license, but with no standards, comparisons are more complicated. Programs licensed in this way can be commercial in the narrower sense, but also shareware or freeware. In the case of public domain licenses, the copyrights are transferred to the general public. The Creative Commons Zero License [11] was created to mark the release of the broadest possible rights of use.

On the other hand, if you do not attach a license to your work at all, any interested party would first have to ask you what kind of use you intend for your software (i.e., what rights you grant and what obligations a user has). The same applies vice versa if you want to use software or libraries to which the author has not attached a license. The onus of clarifying the situation lies with the user.

Although this query method is the standard procedure if you use other people's work, it is a pain and prevents quick decisions often needed nowadays. You have no way to rule out the interested party either using your work without asking for your permission first or choosing some other clearly and unambiguously licensed work instead to avoid a potential dispute. Harald Welte has been documenting this kind of dispute since 2004 in the scope of his GPL Violations [28] project.