From: Josh Boyer Date: Mon, 29 Jun 2026 13:56:18 +0000 (-0400) Subject: docs: address feedback on LICENSE-CRITERIA.md X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=ee726ccf6631b5410205e3fc1004eecdb8c7931a;p=linux-firmware.git docs: address feedback on LICENSE-CRITERIA.md Shorten the document and ensure the criteria and rationale are upfront to avoid checklist scanning. Signed-off-by: Josh Boyer --- diff --git a/AGENTS.md b/AGENTS.md index a895bc7b..ca312e5b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -44,7 +44,7 @@ Upstream lives at . the submitter's commit and `Signed-off-by`. If you don't have it, don't guess. Surface the gap to the user instead. When evaluating whether a license *text* is acceptable, apply the criteria in - [LICENSE-CRITERIA.md](LICENSE-CRITERIA.md) sections 5.1–5.3 — do not guess + [LICENSE-CRITERIA.md](LICENSE-CRITERIA.md) sections 3.1–3.3 — do not guess at acceptability, and do not fabricate the underlying license facts. 3. **Always run `make check` before considering a change complete** (see below). 4. **Preserve the `Signed-off-by` line.** It is a legal attestation of the right @@ -66,8 +66,8 @@ Upstream lives at . but new files should use the `LICENSE.` spelling). Reference it from `WHENCE` with `See LICENSE. for details.` using the bare filename; `check_whence.py` resolves it under `LICENSES/`. The license text must meet - the criteria in [LICENSE-CRITERIA.md](LICENSE-CRITERIA.md) section 5; new - license texts require maintainer review (see section 7). + the criteria in [LICENSE-CRITERIA.md](LICENSE-CRITERIA.md) section 3; new + license texts require maintainer review (see section 5). 4. Run `make check`. 5. Commit with a `Signed-off-by` from someone authoritative on the license, and — if an agent helped produce the change — a trailer noting AI diff --git a/LICENSE-CRITERIA.md b/LICENSE-CRITERIA.md index 8d52e4ef..625eaf06 100644 --- a/LICENSE-CRITERIA.md +++ b/LICENSE-CRITERIA.md @@ -1,10 +1,8 @@ -# Firmware License Requirements for linux-firmware Submissions +# License Requirements for linux-firmware Submissions This document describes the licensing requirements for firmware submitted to the -linux-firmware repository. It is written for hardware vendors and their legal -teams preparing a first submission or drafting a new license text. It explains -which licenses the project accepts, the criteria a license must meet, and how -new license texts are reviewed. +linux-firmware repository. It explains which licenses the project accepts, the +criteria a license must meet, and how new license texts are reviewed. These requirements will be used to evaluate new firmware license submissions or materially changed license terms. Firmware licenses included before this @@ -17,76 +15,34 @@ linux-firmware project. --- -## 1. Why licensing is strict here - -The purpose of this repository is unrestricted redistribution. Anyone may copy -the firmware onward to anyone else — recipients who have no relationship with -your company and have signed nothing. This is not specific to operating systems -or any class of redistributor. - -A license therefore has to grant its rights to *everyone*, automatically, with -no signatures, registration, click-through, or payment. A license that works -for your direct customers but not for an arbitrary downstream recipient cannot -be accepted. This document describes the bar the project applies to keep that -unrestricted redistribution intact. - -## 2. Firmware covered by this policy - -This policy covers firmware images and related device data loaded by the -Linux kernel, a kernel driver, or a device the kernel supports. A submission -should be necessary for hardware support, device operation, or boot, in -service of open-source kernel or driver functionality. - -A submission must be a standalone firmware image or device-data file — not a -host application, shared library, kernel driver, or other userspace or -operating-system component. Those carry their own licensing in their own -projects; this repository is only for the firmware that hardware needs to -function. - -Firmware may be binary-only. Source is welcome whenever the firmware's owner -can provide it, but a binary-only image is acceptable as long as its license -meets the criteria in section 5. - -If firmware is offered under a license requiring source availability — a member -of the GPL family, for example — the submission must satisfy that license's -source-code obligations. Do not label a binary-only image as GPL, or under any -other license requiring source availability, unless the corresponding source is -included (see section 4). - -## 3. Quick checklist for vendors - -Before you submit, confirm all of the following: - -- [ ] The license grants **royalty-free redistribution** of the firmware files - by anyone, whether or not they incorporate the files into a product, - with no further permission required. -- [ ] The license grants **royalty-free use** of the firmware with the - associated hardware. -- [ ] The license includes an **explicit or implicit patent grant** sufficient - for end users to operate the device with full functionality. -- [ ] The license text is **self-contained** — it does not reference or depend - on a purchase agreement, EULA, NDA, support contract, or any document not - included in the repository. -- [ ] There are **no confidentiality terms** anywhere in the license, the - commit, the merge request, or the email used to submit it. -- [ ] There are **no fees, royalties, registration, click-acceptance, audit - rights, or reporting obligations** imposed on redistributors or users. -- [ ] If the firmware is under the **GPL or another copyleft license, the - corresponding source code is included** in the submission. -- [ ] You are **reusing your company's existing license file** in `LICENSES/` - if one exists, rather than introducing a new variant. -- [ ] The commit carries a **Signed-off-by from someone with authority over - the firmware's licensing** (typically within the company that owns or - controls the firmware). -- [ ] The `WHENCE` entry states the license and that the files are - redistributable, and `make check` passes. - -If every box is checked, your submission is routine. If a new or modified -license text is involved, read section 7. - -## 4. Licenses the project accepts - -### 4.1 Existing license texts already in the repository (preferred) +## 1. Purpose and scope of this repository + +The purpose of this repository is to provide standalone firmware images and +related device data files that: + +- is loaded by the Linux kernel, a kernel driver, or a device the kernel +supports. The firmware should be necessary for hardware support, device +operation, or boot, in service of an open source kernel or driver +functionality. Submissions to this repository must be a standalone firmware +image or device-data file — not a host application, shared library, kernel +driver, or other userspace or operating-system component. Firmware may be +binary-only. Source is welcome whenever the firmware's owner can provide it, +but a binary-only image is acceptable as long as its license meets the +criteria. + +- is provided under a license that allows unrestricted redistribution by +everyone, with no signatures, registration, click-through, or payment required. +Anyone may copy the firmware onward to anyone else — recipients who have no +relationship with a company and have signed nothing. This is not specific to +operating systems or any class of redistributor. + +A license that works for your direct customers but not for an arbitrary +downstream recipient cannot be accepted. This document describes the bar the +project applies to keep that unrestricted redistribution intact. + +## 2. Licenses the project accepts + +### 2.1 Existing license texts already in the repository (preferred) The `LICENSES/` directory contains every license text currently in use, both standard open-source licenses (e.g. `Apache-2.0`, `GPL-2.0`, `GPL-3.0-only`) @@ -99,7 +55,7 @@ their `WHENCE` entry. Do not submit per-product or per-file license variants; proliferation of near-identical texts multiplies review burden for everyone who has to evaluate them. -### 4.2 Standard open-source licenses +### 2.2 Standard open-source licenses Firmware offered under a well-known OSI/FSF license (MIT, BSD-2/3-Clause, Apache-2.0, GPL-2.0, etc.) is welcome and is the easiest path through review. @@ -107,15 +63,15 @@ Apache-2.0, GPL-2.0, etc.) is welcome and is the easiest path through review. One important caveat: **copyleft licenses carry source code obligations**, and a submission under such a license should include the corresponding source code. -### 4.3 Proprietary redistributable firmware licenses +### 2.3 Proprietary redistributable firmware licenses Most firmware in the repository is under vendor-specific proprietary licenses. -These are acceptable when they grant the rights in section 5 and confine their -restrictions to those in section 5.2. +These are acceptable when they grant the rights in section 3 and confine their +restrictions to those in section 3.2. -## 5. Criteria a license must meet +## 3. Criteria a license must meet -### 5.1 Required grants +### 3.1 Required grants A firmware license must, at minimum: @@ -144,7 +100,7 @@ A firmware license must, at minimum: and released distribution image retroactively non-compliant and is not acceptable. -### 5.2 Restrictions that are acceptable +### 3.2 Restrictions that are acceptable The project accepts the following restrictions in firmware licenses: @@ -162,7 +118,7 @@ The project accepts the following restrictions in firmware licenses: compliance into an affirmative certification, reporting, or indemnification obligation on redistributors are not. -### 5.3 Terms that will cause rejection +### 3.3 Terms that will cause rejection A license containing any of the following will not be accepted: @@ -170,7 +126,7 @@ A license containing any of the following will not be accepted: redistribution. - Redistribution grants scoped to "as part of" a product, operating system, or distribution. Older license files in the tree contain such language; new - licenses must permit redistribution by anyone, product or not (see 5.1). + licenses must permit redistribution by anyone, product or not (see 3.1). - Fees, royalties, or per-unit accounting of any kind. - **Confidentiality or non-disclosure terms.** Note that this applies to the submission as well as the license: per the project README, a submission @@ -190,12 +146,12 @@ A license containing any of the following will not be accepted: - Choice-of-law/venue or arbitration clauses that impose affirmative obligations on passive recipients. (A simple governing-law statement is usually tolerated; mandatory arbitration with fee-shifting is not.) -- Copyleft-licensed binaries without corresponding source (see 4.2). +- Copyleft-licensed binaries without corresponding source (see 2.2). - Terms that attempt to bind the linux-firmware project or kernel.org to any obligation. The repository is a conduit; it cannot accept duties on your behalf. -## 6. Mechanics: where license information lives in a submission +## 4. Mechanics: where license information lives in a submission Every submission must encode its licensing in the repository's standard structures so that automated tooling and downstream packagers can consume it. @@ -253,7 +209,7 @@ addition to the Signed-off-by. **Submission paths.** Open a merge request on the upstream GitLab project, or send a git binary diff or pull request to `linux-firmware@kernel.org`. -## 7. How new license texts are reviewed +## 5. How new license texts are reviewed This process applies when a submission introduces a license text not already present in `LICENSES/`, or modifies an existing one. @@ -264,7 +220,7 @@ present in `LICENSES/`, or modifies an existing one. 2. **Submit the complete text** as a `LICENSES/LICENSE.` file in the same MR as the firmware it covers, referenced from the `WHENCE` entries. The text must unambiguously identify the copyright holder and licensor. -3. **Maintainer review.** Maintainers review the text against section 5. They +3. **Maintainer review.** Maintainers review the text against section 3. They are applying project policy, not giving your company legal advice; the burden of ensuring the license says what you intend rests with your counsel. 4. **Outside consultation.** For novel terms, maintainers may seek additional @@ -278,10 +234,10 @@ present in `LICENSES/`, or modifies an existing one. reusing it verbatim need no license review. 6. **Relicensing existing firmware.** The firmware is the submitter's intellectual property, and the project does not control its licensing - beyond applying the section 5 criteria. A vendor may relicense their own + beyond applying the section 3 criteria. A vendor may relicense their own firmware whenever their existing license permits, submitting the new text as they would any license change; the project's only requirement is that - the replacement still meets section 5. Two mechanical consequences are + the replacement still meets section 3. Two mechanical consequences are worth being deliberate about: - **One license file governs every firmware that references it.** A diff --git a/README.md b/README.md index 853f00d7..91557d30 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,7 @@ royalty-free, without restrictions beyond those listed in a submission — it describes the grants a license must provide, the restrictions the project accepts, and how new license texts are reviewed. Vendors with an existing license file in `LICENSES/` should reuse it; new license texts require -explicit maintainer review as described in `LICENSE-CRITERIA.md` section 7. +explicit maintainer review as described in `LICENSE-CRITERIA.md` section 5. ### Submission paths