FreeBSD Licensing Policy


FreeBSD is a registered trademark of the FreeBSD Foundation.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the “®” symbol.

1. Preferred License for New Files

The rest of this section is intended to help you get started. As a rule, when in doubt, ask. It is much easier to receive advice than to fix the source tree. The FreeBSD Project makes use of both explicit licenses (where the verbatim text of the license is reproduced in each file) and detached licenses (where a tag in the file specifies the license, as described in this document).

The FreeBSD Project uses this text as the preferred license:

 * Copyright (c) [year] [your name]
 * SPDX-License-Identifier: BSD-2-Clause

The FreeBSD project does not allow using the "advertising clause" in new code. Due to the large number of contributors to the FreeBSD project, complying with this clause for many commercial vendors has become difficult. If you have code in the tree with the advertising clause, please consider switching to a license without it. New contributions to FreeBSD should use the BSD-2-Clause license.

The FreeBSD project discourages completely new licenses and variations on the standard licenses. New licenses require the approval of to reside in the main repository. In the past, non-standard licenses have generated more problems than standard ones. Poor drafting of non-standard licenses often causes more unintended consequences, so they are unlikely to be approved by The FreeBSD project is standardizing on the BSD-2-Clause license, as published by SPDX.

In addition, project policy requires that code licensed under some non-BSD licenses must be placed in specific sections of the repository. For some licenses, compilation must be conditional or disabled by default. For example, code in the static part of the GENERIC kernel must be licensed under the BSD or substantially similar licenses. GPL, APSL, CDDL, etc, licensed software must not be compiled into the static GENERIC kernel. Code with these licenses may be used in pre-compiled modules, however.

Developers are reminded that, in open source, getting "open" correct is just as important as getting "source" correct. Improper handling of intellectual property has serious consequences. Any questions or concerns should immediately be brought to the attention of

2. Software License Policy

The following sections outline the project’s Software License Policies in detail. For the most part we expect developers to read, understand and utilize the sections above this one to apply appropriate licenses to their contributions. The rest of this document details the philosophical background to the policies as well as the policies in great detail. As always, if the text below is confusing or you need help with applying these policies, please reach out to

2.1. Guiding Principles

The FreeBSD Project aims to produce a complete, BSD-licensed operating system allowing consumers of the system to produce derivative products without constraint or further license obligations. We invite and greatly appreciate the contribution of both changes and additions under the two-clause BSD license, and encourage the adoption of this license by other open source projects. Use of the BSD license is key to encouraging the adoption of advanced operating system technology, and on many notable occasions has been pivotal to widespread use of new technology.

We accept however that compelling reasons exist to allow differently-licensed software to be included in the FreeBSD source tree.

We require software licensed under some non-BSD licenses to be carefully isolated in the source tree so that it cannot contaminate BSD-only components. Such cautious management encourages licensing clarity and facilitates the production of BSD-only derivative products.

Unless a special exception is made, no existing BSD-licensed components may be replaced with more restrictively licensed software. We encourage FreeBSD and third party developers to seek the relicensing, dual-licensing, or reimplementing of critical components under the BSD license instead. Such would ease their more integral adoption into the FreeBSD operating system.

2.2. Policy

  • The import of new software licensed under any licenses other than the BSD license and BSD-Like Licenses (as defined below) requires the prior approval of the FreeBSD Core Team. Requests for import must include:

    • A list of features or bug fixes that the new version or patches contain, along with evidence that our users need those features. PRs or references to mailing list discussions are ideal forms of evidence.

    • This process should be used for all software imports, not just those that require Core Team review. The mere existence of a new version does not justify an import of software to source or ports.

    • A list of FreeBSD branches that may be affected. Expansions of scope require a new request to and approval from the FreeBSD Core Team.

  • The Apache License 2.0 is acceptable for use in some cases. The Core Team must approve the import of new Apache License licensed components or the change of license of existing components to the Apache License.

    • This license is approved for the following components:

      • LLVM toolchain and (with LLVM Exceptions) runtime components.

  • The BSD+Patent License is acceptable for use in some cases. The Core Team must approve the import of new BSD+Patent License licensed components or the change of license of existing components to the BSD+Patent License.

    • This license is approved for the following components:

      • EDK2 derived code related to UEFI functionality

  • The Common Development and Distribution License (CDDL) is acceptable for use in some cases. The Core Team must approve the import of new CDDL licensed components or the change of license of existing components to the CDDL.

    • This license is approved for the following components:

      • DTrace

      • ZFS filesystem, including kernel support and userland utilities

  • Historically, the phrase 'All Rights Reserved.' was included in all copyright notices. All the BSD releases had it, to comply with the Buenos Aires Convention of 1910 in the Americas. With the ratification of the Berne Convention in 2000 by Nicaragua, the Buenos Aires Convention — and the phrase — became obsolete. As such, the FreeBSD project recommends that new code omit the phrase and encourages existing copyright holders to remove it. In 2018, the project updated its templates to remove it.

  • Initially, many items in the FreeBSD tree were marked with BSD-2-Clause-FreeBSD. However, SPDX has obsoleted the license as a variant; and the SPDX text of the obsolete tag differs enough from the standard FreeBSD license that it shouldn’t be used. A review of its current use is ongoing.

2.2.1. Acceptable licenses

The following licenses are considered to be acceptable BSD-Like Licenses for the purpose of this Policy. Deviations or the use of any other license must be approved by the FreeBSD Core Team:

  • The 2 clause version of the BSD license

 * Copyright (c) [year] [your name]
 * SPDX-License-Identifier: BSD-2-Clause
  • The 3 clause version of the BSD license

 * Copyright (c) [year] [your name]
 * SPDX-License-Identifier: BSD-3-Clause
  • The ISC License

 * Copyright (c) [year] [copyright holder]
 * SPDX-License-Identifier: ISC
  • The MIT License

 * Copyright (c) [year] [copyright holders]
 * SPDX-License-Identifier: MIT

3. Software Collection License

The FreeBSD Project licenses its compilation of software as described in COPYRIGHT under the BSD-2-Clause license. This license does not supersede the license of individual files, which is described below. Files that do not have an explicit license are licensed under the BSD-2-Clause license.

4. License File Location

To comply with the REUSE Software standard as much as possible, all license files will be stored in the LICENSES/ directory of the repository. There are three subdirectories under this top level directory. The LICENSES/text/ subdirectory contains, in detached form, the text of all the licenses that are allowed in the FreeBSD software collection. These files are stored using the SPDX-License-Identifier name followed by .txt. The LICENSES/exceptions/ subdirectory has the text of all exceptions that are allowed in detached form in the FreeBSD software collection. These files are stored using the exception identifier name followed by .txt. The LICENSES/other/ contains, in detached form, the license files references in SPDX-License-Identifier expressions, but aren’t otherwise allowed as detached licenses. All such files must appear at least once in the FreeBSD software collection, and should be removed when the last file that references them is removed. Licenses that have no adequate SPDX matching license must be in LICENSES/other/ and have a filename that starts with LicenseRef- followed by a unique idstring. No such files have currently been identified, but if they are, a full list will appear here.

The FreeBSD Project currently does not make use of the DEP5 files described in the REUSE Software standard. The FreeBSD Project has not marked all the files in the tree yet in accordance with this standard, as described later in this document. The FreeBSD Project has not yet included these files in its repositories since this policy is still evolving.

5. Individual Files License

Each individual file in the FreeBSD software collection has its own copyright and license. How they are marked varies and is described in this section.

A copyright notice identifies who claims the legal copyright to a file. These are provided on a best effort basis by the project. Because copyrights may be legally transferred, the current copyright holder may differ from what is listed in the file.

A license is a legal document between the contributor and the users of the software granting permission to use the copyrighted portions of the software, subject to certain terms and conditions set forth in the license. Licenses can be expressed in one of two ways in the FreeBSD software collection. Licenses can be explicit in a file. When a license grant is explicit in the file, that file may be used, copied, and modified in accordance with that license. Licenses can also be expressed indirectly, where the text of the license is elsewhere. The project uses the Software Package Data Exchange (SPDX) license identifiers for this purpose, as described in the following subsections. SPDX license identifiers are managed by the SPDX Workgroup at the Linux Foundation, and have been agreed on by partners throughout the industry, tool vendors, and legal teams. For further information see and the following sections for how the FreeBSD Project uses them.

Entities that contribute fixes and enhancements to the software collection without an explicit license agree to license those changes under the terms that apply to the modified file(s). Project policy, in line with industry practice, only includes a copyright notice from significant contributors to the files in the collection.

There are four types of files in the FreeBSD software collection:

  1. Files that have only an explicit copyright notice and license.

  2. Files that have both an explicit copyright notice and license, and a SPDX-License-Identifier tag.

  3. Files that have only a copyright notice and an SPDX-License-Identifier tag, but no explicit license.

  4. Files that lack any copyright or license at all.

Many files in the FreeBSD software collection have both a copyright notice and an explicit license contained in the file. In these cases, the license contained in the file governs.

Some files in the FreeBSD software collection contain a copyright statement, an SPDX-License-Identifier tag and an explicit license. The explicit license takes precedence over the SPDX-License-Identifier tag. The SPDX-License-Identifier tag is the project’s best effort attempt to characterize the license, but is only informative for automated tools. See SPDX-License-Identifier Expressions for how to interpret the expression.

Some files in the tree contain detached licenses. These files contain only a copyright notice and an SPDX-License-Identifier expression, but no explicit license. See SPDX-License-Identifier Expressions for how to interpret the expression. Note: the expressions allowed for detached licenses by the project are a subset of the expressions used informationally or that are defined by the standard.

The license for files containing only the SPDX-License-Identifier should be construed to be

  1. Start the license with the copyright notice from the file. Include all the copyright holders.

  2. For each sub-expression, copy the license text from LICENSE/text/id.txt. When exceptions are present, append them from src/share/license/exceptions/id.txt. SPDX-License-Identifier expressions should be construed as described in the SPDX standard.

Where id is the SPDX short license identifier from the Identifier column of SPDX Identifiers or license exception. If there is no file in LICENSE/, then that license or exception cannot be specified as a detached license under this section.

When reading the license text that is detached from a file, a number of considerations must be taken to make the detached license make sense.

  1. Any reference to a copyright notice shall refer to the copyright notice constructed from the licensed file, not from any copyright notice in the license text file itself. Many SPDX files have sample copyright notices that are understood to be examples only.

  2. When names of entities are referred to in the license text, they shall be construed to apply to the list of all copyright holders listed in the copyright notices of the licensed file. For example, the BSD-4-clause license contains the phrase "This product includes software developed by the organization". The phrase 'the organization' should be replaced by the copyright holders.

  3. When the SPDX offers variations of the license, it is understood the license in the LICENSE/ file represents the exact version of the license selected. The SPDX standard exists to match families of licenses and these variations help match similar licenses that the SPDX organization believes to be legally identical.

For licenses that have slight variations in text, the SPDX has guidelines to match them. These guidelines are not relevant here. Contributors wishing to license under a variant of a SPDX license not contained verbatim in LICENSE/ cannot use the detached option and must specify the license explicitly.

Some files cannot have suitable comments added to them. In such cases, a license may be found in file.ext.license. For example, a file named foo.jpg may have a license in foo.jpg.license, following the REUSE Software conventions.

Files created by the project that lack a copyright notice are understood to fall under the blanket copyright and licensing in COPYRIGHT. Either the file is a mere recitation of facts, not protectable by Copyright Law, or the content is so trivial as to not warrant the overhead of an explicit license.

Files that lack marking and have more than a trivial amount of copyrightable material, or whose author believes them to be improperly marked, should be brought to the attention of the FreeBSD core team. It is the strong policy of the FreeBSD Project to comply with all appropriate licenses.

In the future, all such files will be marked explicitly, or follow the REUSE Software .license convention.

5.5. SPDX-License-Identifier Expressions

An 'SPDX License expression' is used in two contexts in the FreeBSD software collection. First, its full form is used for files that have explicit license statements contained within the file as well as a summarizing SPDX-License-Identifier expression. In this context, the full power of these expressions may be used. Second, in a restricted form described above, it is used to denote the actual license for a given file. In the second context, only a subset of this expression is allowed by the project.

An SPDX License sub-expression is either an SPDX short form license identifier from the SPDX License List, or the combination of two SPDX short form license identifiers separated by "WITH" when a license exception applies. When multiple licenses apply, an expression consists of keywords "AND", "OR" separating sub-expressions and surrounded by "(", ")" . The full specification of expressions spells out all the details and takes precedence when it conflicts with the simplified treatment of this section.

Some license identifiers, like [L]GPL, have the option to use only that version, or any later version. SPDX defines the suffix -or-later to mean that version of the license or a later version. It defines -only to mean only that specific version of the file. There is an old convention to have no suffix (which means what the new '-only' suffix means, but which people confuse for -or-later). In addition, affixing a + suffix was meant to mean -or-later. New files in FreeBSD should not use these two conventions. Old files that use this convention should be converted as appropriate.

      // SPDX-License-Identifier: GPL-2.0-only
      // SPDX-License-Identifier: LGPL-2.1-or-later

WITH should be used when a license modifier is needed. In the FreeBSD project, a number of files from LLVM have an exception to the Apache 2.0 license:

      // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception

Exception tags are managed by SPDX. License exceptions can only be applied to certain licenses, as specified in the exception.

OR should be used if the file has a choice of license and one license is selected. For example, some dtsi files are available under dual licenses:

      // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause

AND should be used if the file has multiple licenses whose terms all apply to use the file. For example, if code has been incorporated by several projects, each with their own license:

      // SPDX-License-Identifier: BSD-2-Clause AND MIT

Last modified on: July 22, 2023 by Minsoo Choo