Developer best practices for expressing license and copyright information in Free and Open Source Software projects

Best practices on adding license information in ways which not only humans can read, but computers as well. Machine readable copyright and license information, simply put!

© 2017 FSFE e.V.

Theme based on Hugo SP-Minimal and Minimal, licensed MIT license. The content of the website, the best practices, are licensed under Creative Commons Attribution-ShareAlike 4.0.

Make Copyrights and Licenses Computer Readable!

We’re working to make managing copyrights and licenses in free and open source software easier. These best practices are meant to demonstrate how to add copyright and license information to a project in ways which allow for more automation. We know you want to focus on coding, but here are a few simple steps to take to make the copyright and license of your project more easily understood.

There’s still work to do, but we hope you’ll help us by adopting these practices and leaving your feedback.

Download the entire best practices as a convenient PDF.

Best practices

1. Provide the exact text of each license used, in verbatim form, without removing any existing license texts. [read more]
2. Include a copyright notice and license in each file, with a consistent style, with a reference to the license text and an appropriate SPDX License Identifier. [read more]
3. Provide an inventory for included software, but only if you can generate it automatically! [read more]

Sign up to hear more

If you'd like to receive updates about these best practices and our work with them, you can sign up below and we'll keep you updated.

I agree to the privacy policy.

Best practices

1. Provide the exact text of each license used

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 the license you use is included in the SPDX License List1, you should download and copy the text representation of the license directly from the SPDX repository2. Doing so ensures that unless you modify the license text, the checksum of the license file will be identical across all projects using the same license.

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 “LICENSE” (you may attach some suffix to the filename as well, such as, 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.

This is how your source code tree can end up looking regarding the license files included:


Keep in mind:

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.

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 that version control systems typically record authorship, not copyright. When using metadata in a version control system, you may end up having more accurate information, but you increase the risk of the information being separated from the source code.

For a project using the version control system to convey information about copyright, you must:

An appropriate header could 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
  * SPDX-License-Identifier: BSD-2-Clause
  * License-Filename: LICENSE/BSD-2-Clause_Charlie.txt

If the project is not using a version control system to convey copyright information, the same information should be included in the source code file. Notices 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.

  * Copyright (c) 2017 Alice Commit <>
  * Copyright (c) 2009-2016 Bob Denver <>
  * Copyright (c) 2007 Company Example <>
  * SPDX-License-Identifier: BSD-2-Clause
  * License-Filename: LICENSE/BSD-2-Clause_Charlie.txt

The “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. We recommend one of two ways:

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.

Keep in mind:

3. Provide an inventory for included software

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 “LICENSE.spdx”.

Keep in mind:

Leaving Feedback

We’d love to hear what you think of these practices, how to improve them, or how to work together on some of the future challenges we’ve identified.

Fork us on and send us your pull requests for changes you’d like to see!

To get in touch with us, just shoot a mail to and we’ll get back to you right away! You can also look at our contact information for FSFE for some other ways in which to reach out to us.

If you want to reach a human right away, or send encrypted e-mail (GnuPG style), this project’s loving caretakers are:

  1. [return]
  2. [return]
  3. Establish project governance committed to public access, vet material added to project to protect against vulnerability to takedown, only include material under a free and open source license so it can be copied and archived freely and ensure project is archived by institutions dedicated to long-term preservation of software code, eg. Software Heritage. [return]