Learn. Grow. Thrive. Save 30% Sitewide! SAVE NOW

Search

    Join

    SPDX License Identifier

    The SPDX license identifier, or short form identifier, is a critical first step to making open source license compliance both easy and accurate.

    Using SPDX license IDs:

    • One new comment line per file
    • Human & machine readable
    • Uses the SPDX License List
    • Add to every file!

    Example source code comments in a file header:

    // SPDX-License-Identifier: MIT
    /* SPDX-License-Identifier: MIT OR Apache-2.0 */
    #  SPDX-License-Identifier: GPL-2.0-only

    For Linux Foundation projects we strongly recommend, that all source files have an SPDX license identifier in the file header.

    Software composition analysis (SCA) tools that scan source code for license info report far more accurate results when SPDX license IDs are present, compared to typical license text that has often been copy and pasted into a file header. The license ID is much more precise and unambiguous than most other methods to specify an open source license.

    More info on using SPDX license IDs: https://spdx.org/ids

    Reference list of licenses and their short form ID: https://spdx.org/licenses/

    Choosing Your License

    When choosing which license to use for your own projects, you should consider each of these points as you select the license that meets your needs:

    • Standard / OSI Approved
      • For source code, if possible use an OSI approved license (https://opensource.org/licenses), so that others will recognize it and already know what their rights and responsibilities are.
    • Project / OSPO Policy
      • Does your project or organization have an existing policy that determines which license you should use? For example, if you have an OSPO or a charter there may be a policy in place with a mandatory or recommended license.
    • Permissive or Copyleft
      • Consider what type of open source license aligns with the goals for your project and community. A permissive license typically allows more flexibility when being combined with other open source code, as well as with closed source code (e.g. commercial proprietary code). A copyleft license requires that your code will always stay under that license, no matter how it is combined with other code.
    • The right license for the file
      • Choose the correct type of license for the file. Most open source licenses were created with source code in mind. But these licenses often won’t make sense for other things like documentation, data, or a specification. Select the license that corresponds to the type of file you are creating. See below for some common examples.
    • Copyright Notice ≠ License
      • Remember that a copyright notice is important, but it is not a license. You should include both, the copyright notice does not indicate that the code is open source.
    License Type Example
    Source Code      Apache-2.0
    Documentation  CC-BY-4.0
    Specification Community-Spec-1.0
    Data CDLA-Permissive-2.0

     

    Don’t use a source code license for docs, specs, or data!

    Open Source License Basics

    There are several things which almost all open source licenses have in common. The OSI definition of “Open Source” (https://opensource.org/osd) describes what is necessary to define code as open source. Here are some of the key concepts:

    • Use, copy, and modify the source code
      • An open source license gives you the rights to use, make copies of, and modify the source code, without any restrictions. Remember that restrictions are not the same as obligations (more on that below).
    • Redistribute and create derivative works
      • An open source license allows you to redistribute the source code with or without your own code, and to create derivative works. Different open source licenses have obligations that may vary depending on the way you distribute and/or combine the code with other code.
    • Typically NO warranty
      • Many, if not most, open source licenses explicitly disclaim a warranty for the source code. This means that you use the code at your own risk. Many projects welcome reports or contributions that fix bugs, and address potential security vulnerabilities, but there is no guarantee about the quality of the code. That being said, open source is often higher quality than closed source, for the very reasons that make it open in the first place.
    • Usually required to give attribution
      • Many licenses require that you give attribution when using the code in your own project. At a minimum, never remove any copyright notice or license information from third party source code you are using.
      • If you are copying and pasting a code fragment, add a comment immediately before the copied code with the copyright notice and license ID from the original file header. Some licenses may require adding a notice in your project’s documentation as well.
    • Copyleft license terms extend to derived works
      • Most copyleft licenses require that, when you create a derivative or combined work, the terms of that license now apply to the new work. This is highly dependent on the exact type of license in effect for the open source, and how you make use of the code. Some general rules are described here, but if you have any doubts be sure to consult your own legal counsel before using or redistributing the code.
      • A weak copyleft license will extend to derived works in most cases where the source code is combined in the same file, or in many cases where distinct source files are compiled into a single object or binary file. Most weak copyleft licenses give exceptions for separate modules or libraries, but be aware that they may be treated differently in the case of static vs dynamic linking. There may also be differences for interpreted vs. compiled languages, and for languages that use class loading as opposed to dynamic libraries.
      • A strong copyleft license will extend to derived works in most cases where source code, separate modules, and libraries are combined into an executable or application.

    Not Open Source

    Some licenses may look similar to open source licenses, but they have conditions or restrictions that do not meet the definition of open source. It’s important to remember that just because the source code is available and you can read it, this alone does not make it open source. True open source cannot have any limitations on how, when, and where you can make use of the code.

    Obligations (see below) from an open source license are not considered limitations or restrictions.

    The following are examples of license types with restrictions or limitations which are not considered open source:

    • Source Available
      • Source available licenses allow the source code to be publicly visible, but typically include limitations on how you can use or distribute the code. They may also have conditions designed to prevent perceived competition with the original authors and their products.
      • Another category of source available licenses are those referred to as “ethical source” licenses, which prohibit use of the software by particular individuals or organizations, or for particular uses, that the licensors view as immoral or unethical.
    • Fair Source
      • Similar to Source Available, ”Fair Source” is another more recent term used by some proprietary software vendors to describe software where the code is available now under a non-open source license prohibiting certain uses, and where it will be made available under an open source license at a later date.
      • This later release under an open source license is sometimes referred to as “delayed open source publication.”
    • Has Use Restrictions
      • Use restrictions state that the code cannot be used in specific circumstances. For example, there may be a restriction preventing using the code in a commercial setting or prohibiting reverse-engineering. Use restrictions are present in many source available / fair source and proprietary licenses.
    • Closed Source (even if viewable)
      • Often referred to as proprietary or commercial code, closed source may be unavailable in source code form. It may also be available as source code, but subject to a specific license that you must purchase.
      • “Freeware” licenses, which permit use of software for any purpose without charge, may still not be open source licenses if the source code is not actually available.
    • No License Specified
      • If no license is stated for some code, you should not assume that it is open source just because the code is available. If a license is not specified, by default the original author typically still maintains all rights to the code, even if the code is published and readable.

    License Obligations

    Most open source licenses have certain obligations. These are requirements that you must fulfill if you are to use the code. The obligations do not prevent you from using the code in any way, but you still must satisfy them in order to comply with the license. Not all licenses have all of these obligations, so be sure to read and understand the license(s) that apply to the code you are using. These are some of the most common examples of license obligations.

    • Attribution
      • Attribution means that you must acknowledge where the code comes from when you make use of it.
      • Specific requirements vary for each license, but generally they may require retaining and making available copies of the copyright notice and license text. Some licenses may also require notices in your documentation or source code about use of or modifications to the code.
    • Redistribution
      • Most licenses’ obligations are triggered when you redistribute the code (or a derivative work) to third parties.
      • Some licenses’ obligations may additionally be triggered by particular uses of the code, such as making it available for interaction over a network.
    • Allow Reverse Engineering
      • Some licenses require when combining the code with closed source, that you allow an end user to reverse engineer your code, in order to make it possible to swap one API compatible library with another one, or to debug a library if it isn’t working.
    • Make Source Code and Modifications Available
      • Some licenses require that, if you have made modifications to the code and distribute it in object code or binary form, that you also make those same modifications available separately to anyone in source code form.
    • Release Under Same License
      • Typically for copyleft licenses, if you redistribute the code (including as part of a derivative work), then all of the code must be released under that same copyleft license.

    Common License Conflicts

    When mixing or combining code under different licenses, you need to be aware of how those licenses may interact.

    Not all open source licenses are compatible with one another. Some licenses are compatible, meaning that it is possible to comply with both of the licenses at the same time. In other cases, two licenses could have a direct conflict in a particular context, meaning that it is not possible to comply with both of them in that context.

    License compatibility is a complex and context-specific topic, and one about which members of the broader community may disagree. You will want to discuss your particular use case and specific license questions with your legal counsel.

    In general, most permissive licenses are compatible with other permissive licenses. Some permissive and copyleft licenses are compatible with each other, but many are not. Some copyleft licenses are compatible with other copyleft licenses, but some are not.

    • Copyleft with Permissive Source (some cases)
      • In some cases it can be possible to combine permissively licensed code with code under a copyleft license. This is the case if it is possible to comply with both licenses, by providing the required notices (to satisfy the permissive license requirements) as well as licensing the combination as a whole under the copyleft license’s terms.
      • However, there are other situations where a permissive license may have requirements that are viewed as conflicting with a copyleft license. For example, some participants in the broader community view Apache-2.0 (a permissive license) as having requirements that are not compatible with GPL-2.0 (a copyleft license).
    • Copyleft with Closed Source (most cases)
      • In most cases, mixing copyleft open source with closed source will result in the combination (including the closed source) being required to be released under the copyleft license. This is more likely for a strong copyleft license, while there are some exceptions granted with a weak copyleft license.
      • If the redistributor is unwilling or unable to make the closed source code available under the copyleft license, then they likely would not be able to comply with the copyleft license’s terms.
    • Use Restrictions (e.g. non-commercial)
      • For code with a restricted use license, incorporating it into an open source project will prevent the project as a whole from being used under fully open source terms.
      • For example, for code under a license which forbids commercial use, it might or might not violate the license to combine it with open source code. But unlike open source code, the combination could not be used in a commercial setting due to the component’s use restrictions.
    • Source Available with Open Source
      • Similarly, incorporating code under a source available license into an open source project will likely cause a conflict and prevent you from using the combination in situations that would violate the source available license.

    Important Tips

    Remember these important tips when using open source software.

    • Do not copy code with an unknown license
      • If you cannot determine the license, you can’t be sure if it’s open source or not, or whether you have the right to incorporate it into an open source project.
    • Don’t remove others’ copyright or license info
      • Always respect others’ work and keep all third party copyright notices and license texts intact.
    • Consider a DCO for your project
      • For all contributions to your open source project, consider using the Developer Certificate of Origin (DCO). The DCO sign-off process requires contributors to explicitly confirm their rights to contribute code to the project under the license indicated in the file.
      • https://developercertificate.org
    • Your OSPO is your friend, talk to them
      • If your organization has an Open Source Program Office, take advantage and ask for guidance and support when using and contributing to open source. That is why they are there.
    • Add an SPDX License ID to every file possible
      • We are repeating this because it’s really important! Add to every source file, and every text file format that supports file comments.
      • For situations where it is not possible to include an SPDX license ID, consider other mechanisms to clearly communicate the applicable license. The REUSE Software specification at https://reuse.software/ is one community-developed format for this.

    Policy Best Practices

    Follow these best practices for your open source projects and your organization.

    • Set a clear policy for both inbound & outbound open source code
      • An “outbound” license specifies the terms under which the project makes available the project code to downstream users.
      • An “inbound” license specifies the terms under which contributors make their contributions available to the project. It may be the same as the project’s outbound license (often together with a DCO sign-off attestation), or may be different terms specified under a Contributor License Agreement (CLA).
    • Use an SCA tool to find & track all licenses
      • Scan your code with a software composition analysis tool which is designed for identifying and tracking applicable open source licenses. Many of these tools can also be set up to detect potential license conflicts.
    • Scan both Source & Dependencies
      • You need to know which licenses are present in both your project’s source code, as well as in third party (external) dependencies, for a complete license compliance picture. One without the other is only half of the story.
    • Comply with all License Obligations including Attribution requirements
      • Be sure to follow all obligations. Attribution is sometimes easy to overlook but it is still required by many licenses.
    • Generate a Build SBOM in your CI/CD pipeline
      • Generating an SBOM for your project is key for both your own use as well as that of your downstream users. It’s useful not only for license compliance. It can also help to track known security vulnerabilities in your dependencies.
      • Using a tool that integrates with your CI/CD pipeline is often helpful, as build time is the most accurate time to generate your SBOM.

    External Resources

    Follow these links for additional resources and guidance in open source license best practices:

    Disclaimer

    This is not legal advice, please consult your own legal counsel.
    Information provided here is a summary, please follow the links for additional information.

    SPDX-License-Identifier: CC-BY-4.0
    SPDX-FileCopyrightText: © 2025, The Linux Foundation
    SPDX-FileContributor: Jeff Shapiro

    Stay Connected with the Linux Foundation