AI legal review — First Sale trigger, remedies, MIT relicensing & AI-agent instructions (Opus cluster)

[zackees]

Note

AI-generated first-pass legal review — not legal advice. Produced by Claude (Fable 5 coordinator; Opus agents for hard legal-analysis clusters, Sonnet agents for drafting/ecosystem clusters and prior-art research) against the repo at HEAD of main on 2026-08-24. This is input material for the human attorney review gated by LEGAL-REVIEW.md. Severity ratings: CRITICAL / HIGH / MEDIUM / LOW.

Q1 — "First Sale" as a defined term vs. the statutory exhaustion doctrine

Rating: HIGH (naming risk alone is MEDIUM; the defect the naming conceals is HIGH)

Analysis

Term-of-art collision. Capitalized defined terms generally control over background doctrine, and MPL §9 (incorporated) waives contra proferentem, so a court would apply the §2.1 definition rather than 17 U.S.C. §109. The collision is therefore unlikely to be outcome-determinative. It is nonetheless costly: the phrase invites every licensee's counsel to open the analysis in exhaustion-land, it will be mis-summarized in SCA tool databases and secondary commentary, and it makes the license read as if it were regulating resale (which it is not, and constitutionally could not).

The real defect the name is hiding. "First Sale" means "the first sale, lease, or other transfer for monetary compensation of Modified FastLED." "Modified FastLED" is defined as a class ("FastLED containing Modifications"), not as a particular version. Read literally, the trigger is a single historical event: once a licensee has made any first sale of any Modified FastLED and published once, no later sale of any later, different modification is ever "the first sale" again. A vendor could publish a trivial one-line diff on day one and then ship a decade of proprietary forks without ever re-triggering §2.3. This is the most serious drafting bug in the instrument, and it is squarely a product of borrowing the "first sale" frame.

Does exhaustion undermine enforcement? Partly, in a way that shapes the remedy rather than defeating it:

• §109(a) exhausts the distribution right in "a particular copy lawfully made under this title." Units the vendor manufactured while still licensed are lawfully made, so neither the vendor's sale of that inventory nor any downstream reseller's resale can be attacked as distribution infringement. §117(a) independently protects the purchaser's essential-step copying. EU law is at least as protective: UsedSoft (C-128/11) exhausts the distribution right even for downloaded copies sold with a perpetual right of use.
• What exhaustion does not reach is reproduction. Under MPL §5.1 the license terminates automatically on the non-compliant sale, so every unit manufactured after that moment is an unlicensed reproduction. That is the enforcement hook, and it is a good one — injunction against continued manufacture, damages for the reproduction, and a defective chain of title that customers and acquirers will care about in diligence.
• Two consequences: the license should stop conditioning the sale and start conditioning the reproduction and distribution (see Q2); and §2.3's obligation must never land on a downstream reseller, who is exhaustion-immune and has manifested no assent (see Q3(d)).

Recommendation

1. Rename the term: "Triggering Transfer" (or "Commercial Transfer"). Never use "First Sale" anywhere in the instrument.
2. Make the trigger per-version and recurring:

   "Triggering Transfer" means any transfer to a third party, for monetary or other valuable consideration, of a given version of Modified FastLED, or of software, firmware, or hardware embodying that version. This Section applies separately to each version You transfer; publication of an earlier version does not satisfy this Section for any later version.

3. Add an express non-interference clause so the license does not appear to regulate resale.
4. FAQ/README note (not license): the obligation runs to the party that makes copies, not to purchasers or resellers.

---

Q2 — Condition vs. covenant, and what remedy a missed deadline actually produces

Rating: HIGH

Analysis

Current state. LICENSE §1 says the Additional Terms are "appended conditions" — a real signal (Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008)), but undercut three ways:

1. MPL §2.7 is a closed enumeration ("Sections 3.1, 3.2, 3.3, and 3.4 are conditions") and §2.3 is not in it. The minimum-extent-of-conflict rule probably resolves this, but only after a judge first finds a conflict — avoidable litigation.
2. The MDY nexus problem is live because the trigger is a sale. MDY Indus. v. Blizzard, 629 F.3d 928 (9th Cir. 2010), requires a nexus between the violated condition and the licensor's exclusive rights. A defendant will argue: the condition is triggered by a commercial act not itself within §106 as to lawfully-made copies, and the obligation (publish a diff) is an affirmative business obligation, not a limit on copying — therefore covenant, therefore contract damages only. Colorable enough to survive a motion, and entirely a drafting artifact. GPL-style source obligations survive the nexus test because they are framed as conditions on the act of conveying copies. Frame yours the same way.
3. §2.1(b) patents are not addressed — even a successful condition argument may terminate only the copyright grant.

What remedy actually follows from a missed same-day publication? Much less than "no post-sale grace period" implies, because MPL §5.1 is incorporated unchanged: rights terminate automatically at the non-compliant transfer, are provisionally reinstated the moment the vendor publishes, become permanent if no contributor notifies within 60 days, and a first-ever notice carries a 30-day cure. §5.3 preserves end-user licenses. Net: the operative sanction is "publish, or eventually lose the right to keep manufacturing," plus infringement exposure limited to the transfer-to-cure window. "There is no post-sale grace period" is at best a statement about the deadline and at worst an implied, undeclared attempt to disable §5.1 — leaving the most consequential mechanic ambiguous. A short infringing window still matters: with timely registration it supports statutory damages and fee-shifting, which is where actual settlement leverage lives.

Recommendation

1. Express amendment at the head of §2.3:

   Notwithstanding MPL 2.0 Section 2.7, this Section 2.3 is a condition of, and a limitation on the scope of, the licenses granted in MPL 2.0 Sections 2.1(a) and 2.1(b). Rights not exercised in compliance with this Section are not granted.

2. Re-anchor the condition to the exclusive rights, with the transfer as a timing trigger only:

   You may reproduce and distribute a version of Modified FastLED only if, on or before the date of the earliest Triggering Transfer of that version, the Source Code Form of that version is Publicly Available as defined below.

3. Delete "There is no post-sale grace period"; replace with language that keeps §5.1 deliberately:

   MPL 2.0 Section 5.1 applies to any failure to satisfy this Section. Publication after the deadline does not retroactively authorize reproduction or distribution occurring before publication, but may reinstate Your rights prospectively under Section 5.1.

4. Register the copyright in each FastLED release with the U.S. Copyright Office within the §412 windows. Without registration the condition/covenant fight is largely academic.

---

Q3 — Scope gaps in the trigger (and the §2.3 / MPL §3.2 interaction)

Rating: HIGH

(b) first — the central design question, premise corrected

§2.3 is purely additive to MPL §3.2; it never subtracts. In the gratis case the licensee still owes full MPL §3.1/§3.2 compliance, so the copyleft is nowhere weaker than MPL — it is exactly MPL plus an enhancement in the paid case. The correct question is: what is the marginal value of the enhancement, and is it worth a bespoke non-OSI license?

The genuine delta between MPL §3.2 and §2.3:

	MPL §3.2	§2.3
Audience	recipients only	the world
Timing	"timely manner"	on or before transfer date
Discoverability	"reasonable means" (a written offer suffices)	publicly discoverable, cloneable, forkable
Price	up to cost of distribution	free
Upstream visibility	none	fork identifies base commit, or issue filed on the official repo

Narrower than it looks: any §3.2 recipient receives source under this License and §3.1 lets them redistribute publicly — one motivated customer converts recipient-only disclosure into public disclosure anyway. §2.3's actual contribution: (i) removing "someone has to know to ask" friction, (ii) compressing time-to-visibility to zero, (iii) — most valuable — routing disclosure to the upstream project in mergeable form.

Two interaction bugs regardless:

• §2.3(b) does not satisfy MPL §3.2(a) — §3.2(a) independently requires informing recipients of the Executable Form how to obtain source. A licensee reading §2.3 as a menu will comply with (b) and still breach MPL. Say so expressly.
• §2.2 vs. the trigger. §2.2 lists "products" as Larger Work while the trigger reaches "hardware that includes Modified FastLED" — reconcilable but a licensee will quote §2.2 as an exemption. Add a cross-reference.

(a) SaaS / network use. No transfer, no duty — a small hole for a hardware LED library, but not zero given FastLED's WASM/browser path: serving a compiled WASM build is distribution of Executable Form (MPL §3.2 bites), and a paid hosted service delivering it is plausibly a §2.3 transfer. Silence reads as ambiguity, not decision.

(c) Intra-corporate, contract manufacturing, lease.

• Intra-corporate: MPL §1.14 sweeps >50%-controlled affiliates into "You," but the trigger's "transfer for monetary compensation" doesn't exclude affiliates — a transfer-priced intra-group sale can be argued to trigger. Unintended.
• Contract manufacturing: a CM flashing a customer's firmware and invoicing per unit literally makes a transfer for monetary compensation of hardware including Modified FastLED. The CM didn't author the modification, may be under NDA, and would be compelled to publish its customer's code. A serious, foreseeable trap.
• Lease: a stage-lighting rental house renting fixtures triggers publication. Almost certainly unintended.
• Evasion path: ship the device with stock firmware, offer the modified firmware as a free download. §2.3 never fires; MPL §3.2 fires only to recipients on request. The cheapest lawful workaround — a sophisticated vendor finds it in ten minutes.

(d) Wrong-party obligation. §2.3 binds whoever makes the transfer. A distributor/retailer/CM that never modified anything can be the entity making the first monetized transfer — a party that (i) may not possess the source, (ii) is exhaustion-protected, (iii) never assented, (iv) cannot cure. Meanwhile the modifier, who never sold, walks. This inverts the intended incidence.

Recommendation

1. Bind the modifier, not the seller:

   If You create a version of Modified FastLED and that version is the subject of a Triggering Transfer by You or by any person to whom You made it available, You must ensure that version is Publicly Available on or before the date of that Triggering Transfer.
   plus: "A person who neither creates nor commissions the creation of Modified FastLED incurs no obligation under this Section by reason of transferring copies made available to it by another."

2. Define consideration and carve-outs: include non-monetary consideration; exclude (i) MPL §1.14 intra-"You" transfers, (ii) contract manufacturers delivering exclusively to the commissioning party, (iii) leases/rentals that convey no copy.
3. Close the free-download evasion: "…or of any version of Modified FastLED made available at no charge in connection with a product, device, or service for which You receive consideration."
4. Decide SaaS explicitly, one sentence either way. Silence is the worst option.
5. State the additive relationship on the face of §2.3: "This Section is in addition to, and does not replace or satisfy, Your obligations under MPL 2.0 Sections 3.1 and 3.2."
6. Add a commercial-license escape valve. Today a licensee under NDA, export control, or a defense contract has no compliant path at any price: "…unless You have obtained a separate written license from the Licensor." Both the humane fix and, presumably, the business model.

---

Q4 — Relicensing feasibility over a decade of MIT contributions with no CLA

Rating: MEDIUM (the relicensing theory is sound; the header-rewrite tooling is a HIGH sub-issue)

Analysis

The legal mechanism works, with a precise limit. MIT expressly permits sublicensing, so FastLED may distribute the combined work — including contributors' MIT code — under FRL-1.0. What FastLED cannot do is change the contributors' underlying grants: each contributor's code remains simultaneously available under MIT from that contributor, forever. §2.4 states this correctly and is one of the better-drafted provisions in the instrument.

Practical consequences:

• No consent needed from historical contributors for new releases; no retroactive CLA required. Same path as many MIT→Apache-2.0 relicensings for the combined-work case.
• The MIT notice condition is load-bearing and is where risk concentrates. MIT's sublicense right is granted "subject to the following conditions" — the notice must be included in all copies or substantial portions. LICENSE-MIT-LEGACY is a project-level notice ("Copyright (c) 2013 FastLED") that does not name individual contributors. If tools/license_headers.py rewrites a contributor-authored file's header and thereby removes or supersedes that contributor's MIT notice, FastLED breaches the one condition MIT imposes — arguably unwinding the very sublicensing authority relied on. header-policy.toml sets old_license_ids = [] and exclusions limited to src/third_party/** — that is a vendored-code audit, not an ownership audit. Highest-priority operational item.
• A licensee can always fork the last MIT release — and can also extract any still-present MIT-origin file from a current release under MIT directly from its author.

Enforcement footprint over time. Thin at adoption, thickening fast. At T=0 the FRL-only surface is "whatever is new since adoption" — close to nothing a determined forker needs. But the code people want to modify commercially is the code that churns hardest: parallel-IO channel engines, per-MCU drivers (ESP32 PARLIO/LCD_CAM/I2S, FlexIO, ObjectFLED), SPI paths, new chipset support, the WASM toolchain — largely post-2023 and heavily attributable to the maintainer. Realistically the license bites on the commercially valuable parts within 12–24 months, while a frozen MIT snapshot degrades quickly (a 2026 snapshot will not support 2028 silicon). Weak in theory, adequate in practice — the normal outcome for this kind of transition.

Recommendation

1. Run a real ownership audit before running apply — per-file provenance map (git blame by author, weighted by surviving lines); treat files with material third-party authorship as dual-noticed rather than replaced.
2. Adopt an additive header convention for MIT-origin files:

   // SPDX-License-Identifier: LicenseRef-FastLED-Reciprocal-1.0
   // Portions Copyright (c) 2013-2025 FastLED contributors, originally licensed
   // under the MIT License; see LICENSE-MIT-LEGACY. Those portions remain
   // available under the MIT License from their respective authors.
   

   Make the header tool fail-closed on any file lacking ownership classification; make "replace an MIT notice" require an explicit per-file allowlist entry with provenance.
3. Institute inbound=outbound now, before adoption: DCO sign-off plus a CONTRIBUTING.md statement that contributions are offered under FRL-1.0. Otherwise post-adoption contributions have no clear inbound license and the problem regenerates.
4. Optionally, email the top ~20 historical contributors by surviving-line count for written consent. Not required, but converts the strongest available attack (a contributor publicly objecting) into a non-event.
5. Keep LICENSE-MIT-LEGACY in every distributed artifact — including binaries and package tarballs, not just the git repo.

---

Q5 — The AI-agent instructions file

Rating: MEDIUM overall. Sub-ratings: (a) LOW-MEDIUM, (b) LOW as a legal matter, (c) HIGH (trade-secret / authorization inducement), (d) MEDIUM-HIGH (reputational and enterprise-adoption).

(a) Is the "not a condition" disclaimer effective?

Mostly yes, and it is well drafted. Two residual problems, one sharp:

• Internal contradiction. "Behaviorally mandatory" three lines above "does not create… any other legal claim or remedy" is an oxymoron with no legal referent — exactly the drafting a court reaches for when constructing an ambiguity.
• MPL §3.4 backdoors the instructions into stickiness. NOTICE-TEMPLATE.txt places the AI lines inside the same comment block as the SPDX identifier — inside the file's license notice. MPL §3.4 forbids removing or altering "the substance of any license notices." A downstream party who strips the two AI lines has, on a plain reading, altered a license notice — a §3.4 breach, which is a §2.7 condition, which terminates under §5.1. The AI instructions acquire condition-like consequences through the notice-integrity rule even though §3 says they are not conditions. A genuine internal conflict against the project's own stated intent.

(b) Can the instructions bind an agent or its operator?

No, on no contract theory. An LLM has no legal personality, capacity, or ability to manifest assent; no principal-agent relationship arises from a model reading a file. The only possible addressee is the operator, and the browsewrap analogy is fatal, not helpful: Specht v. Netscape, 306 F.3d 17 (2d Cir. 2002) and Nguyen v. Barnes & Noble, 763 F.3d 1171 (9th Cir. 2014) require conspicuous notice plus affirmative assent. Cloning a repo, or a model ingesting a file, is neither. No consideration, no offer-and-acceptance.

The honest value of the document is threefold, none contractual:

1. Norm-setting / social signal — the register of robots.txt or CONTRIBUTING.md. Legitimate and worth doing.
2. Willfulness evidence — a conspicuous machine-readable instruction that a vendor's tooling ingested and ignored is useful evidence on willfulness under 17 U.S.C. §504(c)(2) and on injunction equities. Argues for keeping the document factual and conspicuous rather than imperative.
3. Practical compliance plumbing — telling an agent how to produce a compliant §2.3(b) submission genuinely reduces accidental non-compliance.

(c) GitHub ToS, agency, spam/CFAA

• CFAA: essentially nil. Van Buren v. United States, 593 U.S. 374 (2021) forecloses the policy-violation theory.
• GitHub Acceptable Use: LOW-MEDIUM, self-inflicted. Instructing every agent that touches FastLED to file an issue on the official repo points a firehose at the project's own tracker; a tracker full of machine-generated diffs destroys triage capacity.
• Unauthorized disclosure / inducement: HIGH — the sharpest item in Q5. §2 tells the agent to publicly post a complete diff first; §3 addresses the "lacks authorization" case only as a fallback. An agent operating inside a company, on a private branch, following these instructions would publish the employer's unreleased modifications publicly. That is potential trade-secret destruction (unrecoverable once public), breach of employee duties, possible NDA breach, and export-control exposure — induced by FastLED's own instruction. This is the scenario that gets FastLED added to enterprise deny-lists, and it is trivially avoidable by reordering two sections.

(d) Prompt-injection framing

Imperative second-person instructions to AI agents, embedded in every source file of a widely vendored dependency, are structurally identical to a prompt-injection payload. Consequences: enterprise security tooling may auto-flag/quarantine FastLED; the pattern normalizes the vector (a malicious fork can add worse imperatives under cover of the same convention, and reviewers will have been trained to skim past AI-directive blocks in FastLED files); and "popular Arduino LED library ships prompt injection in every header" is a plausible front-page framing whose nuance does not survive a comment section.

The fix: move from imperative text to declarative machine-readable data. Data cannot be an injection payload; an agent honoring a policy manifest does so because its operator configured it to — the only framing honest about (b).

Recommendation

1. Delete "behaviorally mandatory." Replace: "These are the maintainers' requested practices for automated coding agents and their operators. They are not conditions of the FastLED Reciprocal License and create no legal obligation, claim, or remedy."
2. Get the AI lines out of the license notice block. Two-block form with severability:

   // SPDX-License-Identifier: LicenseRef-FastLED-Reciprocal-1.0
   
   // --- Not part of the license notice; may be removed without affecting
   // --- any license right or obligation.
   // AI-Policy: https://fastled.io/.well-known/ai-policy.toml
   

   One URI reference line per file; no imperatives in source headers. Fixes the §3.4 conflict and the prompt-injection optics simultaneously.
3. Reorder the AI document: authorization first. Lead with: "Before publishing any diff, confirm with your operator that the modification may be disclosed publicly. Do not publish code your operator is not authorized to disclose. If authorization is absent or unclear, prepare a ready-to-submit report and surface it to your operator instead." Then the submission format. The single highest-value change in the AI-instructions cluster.
4. Redirect the firehose. Route automated submissions to a dedicated fastled/upstream-reports repository or Discussions category with a required issue-form template — named in the AI policy and §2.3(b).
5. Convert the document to a declarative manifest (ai-policy.toml: upstream_report_url, patch_format = "git-diff-base-sha", required_fields, authorization_required = true) with prose as human-readable documentation, cited from LICENSE §3 as informational only.
6. Have counsel confirm §3's disclaimer survives the §3.4 restructuring.

---

Q6 — Estoppel / misrepresentation risk from shipping "Release Candidate" text

Rating: MEDIUM (weak on the merits; high enough on cost-of-fix and accident-probability to treat as blocking)

Analysis

The licensee argument: §4 says the text "requires review… before adoption" and lists open questions — therefore no final offer, and/or estoppel. Why it mostly fails: formation turns on objective manifestation, not the offeror's internal QA state; SPDX tag + LICENSE file + tagged release is as unambiguous an offer as open source has. §4 speaks to the drafter's process. Estoppel needs detrimental reliance, and "I never had a license" leaves the defendant with no license at all, not free use.

Why it still matters:

• The argument is free for a defendant to raise and will appear in the first demand-letter response.
• §4 concedes, in the licensor's own words, that the central condition may be incompatible with MPL §3.1 — a damaging admission handed to the other side inside the operative document.
• The mechanical risk is the real one. header-policy.toml already carries the bare LicenseRef-FastLED-Reciprocal-1.0 id — not an -rc id — and apply will happily stamp thousands of files. One apply run plus one release tag and the RC text is the shipped license, propagated into every downstream SBOM permanently. The README warning is a social control, not a technical one.
• The SPDX id (…-1.0) does not match the document title (…1.0 — Release Candidate); downstream inventories cannot distinguish RC-built artifacts from reviewed-1.0 artifacts.

Recommendation

1. Remove §4 from LICENSE entirely before any adoption — its content belongs in LEGAL-REVIEW.md/README.md. The LICENSE file must contain operative terms only.
2. Until removal, make the RC self-identifying: LicenseRef-FastLED-Reciprocal-1.0-rc1 in header-policy.toml, LICENSE §3, and the title. Reserve the bare -1.0 id for the reviewed text.
3. Make the gate technical, not advisory: a check in tools/license_headers.py and CI that refuses apply and release builds while LEGAL-REVIEW.md reads Status: **PENDING** and the configured id lacks -rc. Wire the review status into the existing zccache fp fingerprint.
4. On adoption, publish a short, dated adoption statement for the named release — clean objective manifestation that closes the theory entirely.

---

Additional issues spotted

1. "Official FastLED repository" is undefined and mutable — CRITICAL for §2.3(b). A licensee whose GitHub account is banned literally cannot comply, and MPL §4's impossibility relief covers only statute/judicial order/regulation. Fix: define by URL with a successor clause ("…or the successor location identified in the LICENSE file of the version You received") and add a catch-all: "…or by any other means that makes the base commit identifier and complete diff publicly and durably accessible without payment or registration."
2. GPL/LGPL/AGPL compatibility is silently destroyed. §2.3 is an "additional restriction" GPLv2 §6 / GPLv3 §7 forbid, so the MPL §3.3 Secondary License path is unusable in practice even though textually incorporated. Decide and state explicitly; if closing the path, attach Exhibit B and say so plainly.
3. No commercial-license alternative — arguably the biggest strategic omission. No compliant path exists for licensees bound by NDA, ITAR/EAR, or defense contracts. See Q3 Rec. 6.
4. No carve-out for compelled non-disclosure beyond MPL §4's statute/order/regulation scope — export-control classifications and contractual confidentiality are not clearly covered.
5. "Monetary compensation" is undefined — barter, ad-supported, bundled services, transfer pricing, crowdfunding, "free device, paid subscription" all unaddressed. Broaden to "monetary or other valuable consideration" plus carve-outs.
6. No time-zone rule for "on or before the date" — add "measured in the time zone of Your principal place of business."
7. Trademark friction. MPL §2.3 grants no trademark rights, yet §2.3(a) steers licensees toward publishing a fork that necessarily uses the FastLED name. Add express nominative/descriptive-use permission so compliance does not require infringement.
8. Package-registry and enterprise-SCA friction is a first-order adoption risk. LicenseRef- ids default to "unknown"/deny in Black Duck, FOSSA, Snyk, and corporate policy engines. Budget for a plain-language FAQ, an SPDX license-list submission, and SCA-vendor outreach.
9. Anti-circumvention holds for the obvious move, not the patient one. Relocating modified logic into a licensee's own file does not escape (MPL §1.10(b): any new file containing Covered Software is a Modification). A clean-room reimplementation does escape — unavoidable; accept explicitly rather than drafting around it.
10. ARTIFACTS.sha256 / immutable-tag discipline is a genuine strength — extend it to implement the Q6 technical gate.
11. Consider whether the whole design should instead be MPL-2.0 plus a published upstreaming norm. Given the Q3(b) delta analysis, the thin 12–24-month enforceable surface (Q4), destroyed GPL compatibility (item 2), and SCA friction (item 8), counsel should be asked to price the alternative: ship unmodified MPL-2.0 (OSI-approved, SPDX-standard, GPL-compatible, zero SCA friction, zero stewardship burden) and pursue the upstreaming goal through the AI-policy manifest, a CONTRIBUTING norm, and a commercial license for those who want to avoid §3.2 disclosure entirely. That combination captures most of §2.3's practical value at a small fraction of its ecosystem cost. If the maintainers still want the same-day public-fork condition after seeing that comparison, the recommendations above make it defensible — but the comparison should be made deliberately rather than by default.

[zackees]

Tracked by meta issue #8 (AI first-pass legal review — triage, consolidated findings & prior-art survey).