Linux kernel licensing rules¶
The Linux Kernel is provided under the terms of the GNU General PublicLicense version 2 only (GPL-2.0), as provided in LICENSES/preferred/GPL-2.0,with an explicit syscall exception described inLICENSES/exceptions/Linux-syscall-note, as described in the COPYING file.
This documentation file provides a description of how each source fileshould be annotated to make its license clear and unambiguous.It doesn’t replace the Kernel’s license.
The license described in the COPYING file applies to the kernel sourceas a whole, though individual source files can have a different licensewhich is required to be compatible with the GPL-2.0:
GPL-1.0+ : GNU General Public License v1.0 or laterGPL-2.0+ : GNU General Public License v2.0 or laterLGPL-2.0 : GNU Library General Public License v2 onlyLGPL-2.0+ : GNU Library General Public License v2 or laterLGPL-2.1 : GNU Lesser General Public License v2.1 onlyLGPL-2.1+ : GNU Lesser General Public License v2.1 or later
Aside from that, individual files can be provided under a dual license,e.g. one of the compatible GPL variants and alternatively under apermissive license like BSD, MIT etc.
The User-space API (UAPI) header files, which describe the interface ofuser-space programs to the kernel are a special case. According to thenote in the kernel COPYING file, the syscall interface is a clear boundary,which does not extend the GPL requirements to any software which uses it tocommunicate with the kernel. Because the UAPI headers must be includableinto any source files which create an executable running on the Linuxkernel, the exception must be documented by a special license expression.
The common way of expressing the license of a source file is to add thematching boilerplate text into the top comment of the file. Due toformatting, typos etc. these “boilerplates” are hard to validate fortools which are used in the context of license compliance.
An alternative to boilerplate text is the use of Software Package DataExchange (SPDX) license identifiers in each source file. SPDX licenseidentifiers are machine parsable and precise shorthands for the licenseunder which the content of the file is contributed. SPDX licenseidentifiers are managed by the SPDX Workgroup at the Linux Foundation andhave been agreed on by partners throughout the industry, tool vendors, andlegal teams. For further information seehttps://spdx.org/
The Linux kernel requires the precise SPDX identifier in all source files.The valid identifiers used in the kernel are explained in the sectionLicense identifiers and have been retrieved from the official SPDXlicense list athttps://spdx.org/licenses/ along with the license texts.
License identifier syntax¶
Placement:
The SPDX license identifier in kernel files shall be added at the firstpossible line in a file which can contain a comment. For the majorityof files this is the first line, except for scripts which require the‘#!PATH_TO_INTERPRETER’ in the first line. For those scripts the SPDXidentifier goes into the second line.
Style:
The SPDX license identifier is added in form of a comment. The commentstyle depends on the file type:
C source: // SPDX-License-Identifier: <SPDX License Expression>C header: /* SPDX-License-Identifier: <SPDX License Expression> */ASM: /* SPDX-License-Identifier: <SPDX License Expression> */scripts: # SPDX-License-Identifier: <SPDX License Expression>.rst: .. SPDX-License-Identifier: <SPDX License Expression>.dts{i}: // SPDX-License-Identifier: <SPDX License Expression>If a specific tool cannot handle the standard comment style, then theappropriate comment mechanism which the tool accepts shall be used. Thisis the reason for having the “/* */” style comment in C headerfiles. There was build breakage observed with generated .lds files where‘ld’ failed to parse the C++ comment. This has been fixed by now, butthere are still older assembler tools which cannot handle C++ stylecomments.
Syntax:
A <SPDX License Expression> is either an SPDX short form licenseidentifier found on the SPDX License List, or the combination of twoSPDX short form license identifiers separated by “WITH” when a licenseexception applies. When multiple licenses apply, an expression consistsof keywords “AND”, “OR” separating sub-expressions and surrounded by“(”, “)” .
License identifiers for licenses like [L]GPL with the ‘or later’ optionare constructed by using a “+” for indicating the ‘or later’ option.:
// SPDX-License-Identifier: GPL-2.0+// SPDX-License-Identifier: LGPL-2.1+
WITH should be used when there is a modifier to a license needed.For example, the linux kernel UAPI files use the expression:
// SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note// SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
Other examples using WITH exceptions found in the kernel are:
// SPDX-License-Identifier: GPL-2.0 WITH mif-exception// SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
Exceptions can only be used with particular License identifiers. Thevalid License identifiers are listed in the tags of the exception textfile. For details see the pointExceptions in the chapterLicenseidentifiers.
OR should be used if the file is dual licensed and only one license isto be selected. For example, some dtsi files are available under duallicenses:
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
Examples from the kernel for license expressions in dual licensed files:
// SPDX-License-Identifier: GPL-2.0 OR MIT// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause// SPDX-License-Identifier: GPL-2.0 OR Apache-2.0// SPDX-License-Identifier: GPL-2.0 OR MPL-1.1// SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT// SPDX-License-Identifier: GPL-1.0+ OR BSD-3-Clause OR OpenSSL
AND should be used if the file has multiple licenses whose terms allapply to use the file. For example, if code is inherited from anotherproject and permission has been given to put it in the kernel, but theoriginal license terms need to remain in effect:
// SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT
Another other example where both sets of license terms need to beadhered to is:
// SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+
License identifiers¶
The licenses currently used, as well as the licenses for code added to thekernel, can be broken down into:
Preferred licenses:
Whenever possible these licenses should be used as they are known to befully compatible and widely used. These licenses are available from thedirectory:
LICENSES/preferred/
in the kernel source tree.
The files in this directory contain the full license text andMetatags. The file names are identical to the SPDX licenseidentifier which shall be used for the license in source files.
Examples:
LICENSES/preferred/GPL-2.0
Contains the GPL version 2 license text and the required metatags:
LICENSES/preferred/MIT
Contains the MIT license text and the required metatags
Metatags:
The following meta tags must be available in a license file:
Valid-License-Identifier:
One or more lines which declare which License Identifiers are validinside the project to reference this particular license text. Usuallythis is a single valid identifier, but e.g. for licenses with the ‘orlater’ options two identifiers are valid.
SPDX-URL:
The URL of the SPDX page which contains additional information relatedto the license.
Usage-Guidance:
Freeform text for usage advice. The text must include correct examplesfor the SPDX license identifiers as they should be put into sourcefiles according to theLicense identifier syntax guidelines.
License-Text:
All text after this tag is treated as the original license text
File format examples:
Valid-License-Identifier: GPL-2.0Valid-License-Identifier: GPL-2.0+SPDX-URL: https://spdx.org/licenses/GPL-2.0.htmlUsage-Guide: To use this license in source code, put one of the following SPDX tag/value pairs into a comment according to the placement guidelines in the licensing rules documentation. For 'GNU General Public License (GPL) version 2 only' use: SPDX-License-Identifier: GPL-2.0 For 'GNU General Public License (GPL) version 2 or any later version' use: SPDX-License-Identifier: GPL-2.0+License-Text: Full license text
SPDX-License-Identifier: MITSPDX-URL: https://spdx.org/licenses/MIT.htmlUsage-Guide: To use this license in source code, put the following SPDX tag/value pair into a comment according to the placement guidelines in the licensing rules documentation. SPDX-License-Identifier: MITLicense-Text: Full license text
Deprecated licenses:
These licenses should only be used for existing code or for importingcode from a different project. These licenses are available from thedirectory:
LICENSES/deprecated/
in the kernel source tree.
The files in this directory contain the full license text andMetatags. The file names are identical to the SPDX licenseidentifier which shall be used for the license in source files.
Examples:
LICENSES/deprecated/ISC
Contains the Internet Systems Consortium license text and the requiredmetatags:
LICENSES/deprecated/GPL-1.0
Contains the GPL version 1 license text and the required metatags.
Metatags:
The metatag requirements for ‘other’ licenses are identical to therequirements of thePreferred licenses.
File format example:
Valid-License-Identifier: ISCSPDX-URL: https://spdx.org/licenses/ISC.htmlUsage-Guide: Usage of this license in the kernel for new code is discouraged and it should solely be used for importing code from an already existing project. To use this license in source code, put the following SPDX tag/value pair into a comment according to the placement guidelines in the licensing rules documentation. SPDX-License-Identifier: ISCLicense-Text: Full license text
Dual Licensing Only
These licenses should only be used to dual license code with anotherlicense in addition to a preferred license. These licenses are availablefrom the directory:
LICENSES/dual/
in the kernel source tree.
The files in this directory contain the full license text andMetatags. The file names are identical to the SPDX licenseidentifier which shall be used for the license in source files.
Examples:
LICENSES/dual/MPL-1.1
Contains the Mozilla Public License version 1.1 license text and therequired metatags:
LICENSES/dual/Apache-2.0
Contains the Apache License version 2.0 license text and the requiredmetatags.
Metatags:
The metatag requirements for ‘other’ licenses are identical to therequirements of thePreferred licenses.
File format example:
Valid-License-Identifier: MPL-1.1SPDX-URL: https://spdx.org/licenses/MPL-1.1.htmlUsage-Guide: Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used for dual-licensed files where the other license is GPL2 compatible. If you end up using this it MUST be used together with a GPL2 compatible license using "OR". To use the Mozilla Public License version 1.1 put the following SPDX tag/value pair into a comment according to the placement guidelines in the licensing rules documentation:SPDX-License-Identifier: MPL-1.1License-Text: Full license text
Exceptions:
Some licenses can be amended with exceptions which grant certain rightswhich the original license does not. These exceptions are availablefrom the directory:
LICENSES/exceptions/
in the kernel source tree. The files in this directory contain the fullexception text and the requiredException Metatags.
Examples:
LICENSES/exceptions/Linux-syscall-note
Contains the Linux syscall exception as documented in the COPYINGfile of the Linux kernel, which is used for UAPI header files.e.g. /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */:
LICENSES/exceptions/GCC-exception-2.0
Contains the GCC ‘linking exception’ which allows to link any binaryindependent of its license against the compiled version of a file markedwith this exception. This is required for creating runnable executablesfrom source code which is not compatible with the GPL.
Exception Metatags:
The following meta tags must be available in an exception file:
SPDX-Exception-Identifier:
One exception identifier which can be used with SPDX licenseidentifiers.
SPDX-URL:
The URL of the SPDX page which contains additional information relatedto the exception.
SPDX-Licenses:
A comma separated list of SPDX license identifiers for which theexception can be used.
Usage-Guidance:
Freeform text for usage advice. The text must be followed by correctexamples for the SPDX license identifiers as they should be put intosource files according to theLicense identifier syntax guidelines.
Exception-Text:
All text after this tag is treated as the original exception text
File format examples:
SPDX-Exception-Identifier: Linux-syscall-noteSPDX-URL: https://spdx.org/licenses/Linux-syscall-note.htmlSPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+Usage-Guidance: This exception is used together with one of the above SPDX-Licenses to mark user-space API (uapi) header files so they can be included into non GPL compliant user-space application code. To use this exception add it with the keyword WITH to one of the identifiers in the SPDX-Licenses tag: SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-noteException-Text: Full exception text
SPDX-Exception-Identifier: GCC-exception-2.0SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.htmlSPDX-Licenses: GPL-2.0, GPL-2.0+Usage-Guidance: The "GCC Runtime Library exception 2.0" is used together with one of the above SPDX-Licenses for code imported from the GCC runtime library. To use this exception add it with the keyword WITH to one of the identifiers in the SPDX-Licenses tag: SPDX-License-Identifier: <SPDX-License> WITH GCC-exception-2.0Exception-Text: Full exception text
All SPDX license identifiers and exceptions must have a corresponding filein the LICENSES subdirectories. This is required to allow toolverification (e.g. checkpatch.pl) and to have the licenses ready to readand extract right from the source, which is recommended by various FOSSorganizations, e.g. theFSFE REUSE initiative.
MODULE_LICENSE¶
Loadable kernel modules also require a
MODULE_LICENSE()tag. This tag isneither a replacement for proper source code license information(SPDX-License-Identifier) nor in any way relevant for expressing ordetermining the exact license under which the source code of the moduleis provided.The sole purpose of this tag is to provide sufficient informationwhether the module is free software or proprietary for the kernelmodule loader and for user space tools.
The valid license strings for
MODULE_LICENSE()are:
“GPL”
Module is licensed under GPL version 2. Thisdoes not express any distinction betweenGPL-2.0-only or GPL-2.0-or-later. The exactlicense information can only be determinedvia the license information in thecorresponding source files.
“GPL v2”
Same as “GPL”. It exists for historicreasons.
“GPL and additional rights”
Historical variant of expressing that themodule source is dual licensed under aGPL v2 variant and MIT license. Please donot use in new code.
“Dual MIT/GPL”
The correct way of expressing that themodule is dual licensed under a GPL v2variant or MIT license choice.
“Dual BSD/GPL”
The module is dual licensed under a GPL v2variant or BSD license choice. The exactvariant of the BSD license can only bedetermined via the license informationin the corresponding source files.
“Dual MPL/GPL”
The module is dual licensed under a GPL v2variant or Mozilla Public License (MPL)choice. The exact variant of the MPLlicense can only be determined via thelicense information in the correspondingsource files.
“Proprietary”
The module is under a proprietary license.“Proprietary” is to be understood only as“The license is not compatible to GPLv2”.This string is solely for non-GPL2 compatiblethird party modules and cannot be used formodules which have their source code in thekernel tree. Modules tagged that way aretainting the kernel with the ‘P’ flag whenloaded and the kernel module loader refusesto link such modules against symbols whichare exported with
EXPORT_SYMBOL_GPL().