This is version 1.2 of the REUSE practices, released 2017-10-27. It has since been superceded by version 2.0 which you are encouraged to use instead.
Free and open source software licenses are standardised and have standard texts. Regardless of which license you use, you should include the license text in your project. You should also include the license text of any code which may be under a different license, and it’s important you do not change the license text on other software you include.
If your project only includes code licensed under a single license, you
may provide the text of this license in a file in the top level directory
of your repository with the name
COPYING (you may attach some suffix
to the filename as well, such as
LICENSE.md, if relevant).
Since many projects include code under different licenses, it’s often not
feasible to include all licenses in the top level, in which case you should
create a directory at the top level called
LICENSES within which you
include the license text of each license used.
You must include all licenses which are used in your project, and you must never change any license texts even if they are very similar to existing ones.
Some licenses, like the BSD 2 Clause license, must be adapted to include the name of the copyright holder in the license text. Your project may end up including multiple versions of the same BSD 2 Clause license because some parts may be written by Alice and others by Bob, resulting in two different license files, even if the only difference is the copyright holder.
Keep in mind
- Don’t change any license texts, use the verbatim form of the license text.
- Don’t remove any license texts, include the license texts of all software.
- Keep the filename of the licenses consistent, so you can refer to it from the source code files.
You should ensure all files in your project have a license header, and that all license headers files have the same format. Even if your project has a license header which looks different from other projects, it helps to have a consistent style to the header. It’s important you do not remove information in existing headers, though.
Source code files are often reused across multiple projects, taken from their origin and repurposed, or otherwise end up in repositories where they are separate from its origin. Each file should, therefore, have enough information in itself to convey copyright information.
Your license header should contain copyright notices, an
SPDX-License-Identifier following the SPDX standard, and a
License-Filename tag following the REUSE practices.
Copyright notices in a license header should have a consistent format and be sorted by year. They should list the actual copyright holder, which may be an organisation rather than the author. For example:
/* * Copyright (c) 2017 Alice Commit <email@example.com> * Copyright (c) 2009-2016 Bob Denver <firstname.lastname@example.org> * Copyright (c) 2007 Company Example <email@example.com> * * SPDX-License-Identifier: BSD-2-Clause * License-Filename: LICENSES/BSD-2-Clause_Charlie.txt */
License-Filename tag shall be a persistent URL or a filename in
the repository where the actual license text is available. This is more
accurate than the SPDX license identifier and ensures the full license
text is always referenced from the individual source file. The tag can
be repeated if multiple license files are relevant.
You should include information about your project’s practices in the README or similar file.
If your project includes binaries or source code files in which comments can not be placed, you should provide them separately in one of two ways:
FILENAME, include the text file
FILENAME.licensewhich includes a copyright header according to the format you customarily use for headers.
If you wish to be explicit about the license of an output file, which does
not exist in the repository but which will be created at build time, you
may include a
.license file without the corresponding binary file.
You may record information about copyright by relying on the underlying version control system you’re using, but special care must be taken if you do. Keep in mind version control systems typically record authorship, not copyright.
For a project using the version control system to convey information about copyright, you must:
An appropriate header in this case would be:
/* * This file is part of project X. It's copyrighted by the contributors * recorded in the version control history of the file, available from * its original location http://git.example.com/X/filename.c * * SPDX-License-Identifier: BSD-2-Clause * License-Filename: LICENSES/BSD-2-Clause_Charlie.txt */
Keep in mind
- Use a consistent style of your headers throughout the project.
- Don’t remove existing headers, but only add to them.
- Do consider using version control systems to keep a record of copyright holders.
- Do keep your version control system public if you use it.
- Make references to the license text and the SPDX identifier from each source code file.
- Include license and copyright information also for files which can not include a proper header, either in a separate .license file, or using the DEP-5/copyright specification.
Aside from the license files included in the project, and the file level copyright information, you may include a bill of material for your project, but you should only do so if this is generated automatically.
A bill of material can be very complicated and lengthy, making it difficult to maintain. If you do not generate it automatically, it’s very likely someone will forget to update it when making changes. In these cases, it’s best not to have a bill of material, but to rely only on the information coupled with the source code files.
If you do have a way of automatically creating a bill of material, and if you choose to do so, you should generate it automatically from the most reliable information you have about each file in your project. This includes copyright information kept in version control systems and licenses on files which include a standard header, or which includes the header in a separate license file.
You may also choose to include in the bill of material your output files generated when compiling the project, such that you can signal through the bill of material, which license is relevant for the output files depending on the included source code.
The bill of material should be conformant to the SPDX specification and
included in a file in the top level directory of your repository called
Keep in mind
- Don’t create a bill of material if you can’t generate it automatically.
- If you generate one automatically, it’s helpful to include one.
- Make your bill of material conformant to the SPDX specification.
- It doesn’t hurt to run your project through ScanCode or FOSSology, to make sure these tools can parse and understand your project’s licensing.