Deploying SPDX Identifiers in the GNU Toolchain

Proposal to deploy SPDX Identifiers in the GNU Toolchain

Transcript

1. Deploying SPDX Identifiers in the GNU Toolchain David Edelsohn
2. SPDX IDs // SPDX-License-Identifier: GPL-3.0-or-later WITH GCC-exception Use SPDX short-form identifiers to communicate FOSS license information in a simple, efficient, portable and machine-readable manner
3. What are SPDX IDs • SPDX License List is a formal list defined by SPDX legal team ◦ Licenses vetted against matching guidelines to ensure each ID corresponds to a specific license text ◦ License expression operators allow for more complex license scenarios ▪ AND (both license apply) ▪ OR (choice of licenses) ▪ WITH (additional terms to license) ◦ Process for submitting licenses for inclusion • SPDX license IDs provide an easy and precise way to identify the license for each source file ◦ Needs only one new comment line per file ◦ Human-readable and machine readable
4. Why use SPDX IDs • Provides standardized license identification • Determine easily which licenses apply to a file ◦ Decrease confusion by using the SPDX License List ◦ Reduce downstream effort to identify licenses • Machine readable ◦ Eliminate error-prone parsing of license headers • SPDX identifiers are precise ◦ Not “BSD-style License” ◦ AND versus OR GCC and GLIBC are composed of many different files and components / sub-directories with many different licenses. No “third_party” directory. Ensure correct identification of license.
5. Why a separate comment in each file? Avoid ambiguity Avoid confusion if files are separated or copied Machine parsable without dependencies or intervention / understanding
6. Linux kernel placement The SPDX license identifier in kernel files shall be added at the first possible line in a file which can contain a comment. For the majority of files this is the first line, except for scripts which require the '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX identifier goes into the second line.
7. Linux kernel style The SPDX license identifier is added in form of a comment. The comment style 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 the appropriate comment mechanism which the tool accepts shall be used. This is the reason for having the "/* */" style comment in C header files. There was build breakage observed with generated .lds files where 'ld' failed to parse the C++ comment. This has been fixed by now, but there are still older assembler tools which cannot handle C++ style comments.
8. Proposal Adopt SPDX IDs in source files of the GNU Toolchain • Follow (for the most part) the approach and style of the Linux kernel ◦ This could include re-using tooling used in the Linux kernel migration ◦ Incrementally add SPDX IDs • Engage the SPDX-legal community for any questions
9. Backup
10. License format Non-GNU licenses For non-GNU licenses, just add the + operator to the end of the license. For example, the following expression allows recipients to use the file under the Academic Free License v2.0, or any future version of that license: // SPDX-License-Identifier: AFL-2.0+ GNU licenses For GNU licenses, do not use just the bare license ID, such as “GPL-2.0”. Instead, always use either the suffix “-only“ or the suffix “-or-later“ with GNU licenses. For example, the following expression allows recipients to use the file under the GPL v2.0 only: // SPDX-License-Identifier: GPL-2.0-only By contrast, the following expression allows recipients to use the file under the GPL v2.0, or any later version of the GPL published by the FSF: // SPDX-License-Identifier: GPL-2.0-or-later