AI legal review — license architecture & MPL-2.0 interaction (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 — Modified-versions compliance (MPL §10.3, not §10.4) and retained Mozilla references

Rating: HIGH

Analysis

First, a citation correction that matters for the memo: the modified-versions clause is §10.3, not §10.4. §10.4 is the Exhibit B / Incompatible-With-Secondary-Licenses attachment rule (relevant to Q4). §10.3 reads:

"If you create software not governed by this License, and you want to create a new license for such software, you may create and use a modified version of this License if you rename the license and remove any references to the name of the license steward (except to note that such modified license differs from this License)."

Three sub-questions:

(a) Is incorporation-by-reference-plus-appended-terms a "modified version of this License"? Functionally yes, and the drafter should assume a court treats it as one. The combined instrument changes the legal effect of the MPL text as applied to FastLED code, which is the substance §10.3 addresses. The formal device — leaving MPL-2.0.txt byte-identical and bolting terms on in a wrapper — is a distinction without a difference in effect, and arguing "we didn't modify it, we referenced it" invites the worse outcome: if the wrapper is not a modified version, then the only instrument governing the code is the unmodified MPL, and the Additional Terms are a separate contract that a recipient never accepted (see Q2). The drafter cannot win both ways.

(b) Is there any other permission to reproduce the MPL text verbatim? MPL 2.0 contains no verbatim-copying grant for the license document itself — unlike GPL, which has the "copying and distribution of this license document ... verbatim ... is permitted" preamble. §10.3 is the only express permission in the four corners of the document to build on the text. Counsel should verify Mozilla's separately published policy on the copyright status of the license text rather than rely on the document alone. Practical risk of Mozilla suing is near zero; reputational risk of being publicly called out by Mozilla for misuse of the MPL is not.

(c) Are the retained Mozilla references permissible? §10.3 requires removal of references to "the name of the license steward" — i.e. "Mozilla Foundation" (§10.1), not every occurrence of the word "Mozilla." The wrapper's §1 sentence — "The Mozilla Foundation is not the steward of this combined license; FastLED is its steward" — is a textbook use of the §10.3 parenthetical exception. That part is well drafted.

The fatal problem is elsewhere: the incorporated MPL-2.0.txt retains §10.1 and §10.2 verbatim, which say Mozilla Foundation is the steward and:

"You may distribute the Covered Software under the terms of the version of the License under which You originally received the Covered Software, or under the terms of any subsequent version published by the license steward."

Because the whole MPL text is incorporated and the wrapper says "All provisions of MPL 2.0 apply," a licensee has a colorable argument that §10.2 lets it redistribute FastLED code under MPL 3.0 if Mozilla ever publishes one — an instrument that will not contain FastLED §2.3. The wrapper's steward sentence and the incorporated §10.1 directly contradict each other on who the steward is, so the §10.2 "subsequent version" pointer is genuinely ambiguous. This is precisely the failure mode §10.3's removal requirement exists to prevent.

Recommendation

1. Stop incorporating by reference. Produce a single self-contained license file containing a modified copy of the MPL text with §10.1–10.2 rewritten:
   • §10.1: "FastLED is the license steward. Except as provided in Section 10.3, no one other than the license steward has the right to modify or publish new versions of this License."
   • §10.2: limit "subsequent version" to versions published by the FastLED steward, and consider dropping the automatic-upgrade option entirely.
   • Add a §10.3 attribution note: "This License is a modified version of the Mozilla Public License, Version 2.0, and differs from it. The Mozilla Foundation is not the steward of this License and does not endorse it."
2. If the two-file structure is retained, the wrapper must expressly disapply MPL §10.1 and §10.2 by number and substitute replacements, and must pin MPL-2.0.txt by canonical URL and SHA-256 with a fallback clause. A bare relative filename is not a license text.
3. Strip "Mozilla" from the title line of any per-file notice you ship, keeping it only in the attribution note.

---

Q2 — "This License" is ambiguous; the Additional Terms probably do not run with the code

Rating: CRITICAL

Analysis

Three independent defects converge here.

(i) The referent of "this License." MPL §1.8: "'License' means this document." Inside MPL-2.0.txt, "this document" is MPL-2.0.txt — an unmodified MPL 2.0. §3.1 then says:

"All distribution of Covered Software in Source Code Form ... must be under the terms of this License. You must inform recipients that the Source Code Form of the Covered Software is governed by the terms of this License, and how they can obtain a copy of this License. You may not attempt to alter or restrict the recipients' rights in the Source Code Form."

A downstream distributor reads §1.8 + §3.1 and concludes its pass-through obligation is satisfied by shipping MPL-2.0.txt. Worse, the final sentence of §3.1 arguably prohibits it from passing on the Additional Terms, since imposing a public-disclosure-on-sale condition is an attempt to "restrict the recipients' rights in the Source Code Form" as those rights are defined by "this License" = the MPL. The wrapper never amends §1.8. This is a self-executing leak: after one hop of redistribution the code is plausibly plain MPL, and FastLED §2.3 evaporates.

(ii) The Exhibit A / "Covered Software" gap — the more serious bug. MPL §1.4:

"'Covered Software' means Source Code Form to which the initial Contributor has attached the notice in Exhibit A, the Executable Form of such Source Code Form, and Modifications of such Source Code Form..."

Exhibit A is the notice "This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0..." The combined license instead prescribes SPDX-License-Identifier: LicenseRef-FastLED-Reciprocal-1.0 (wrapper §3). If FastLED attaches the SPDX line and not the Exhibit A notice, then under the incorporated definitions nothing is Covered Software. Cascading: §1.3 "Contribution" = "Covered Software of a particular Contributor"; §2.1 grants run only to "its Contributions." The incorporated grants have an empty referent, and every operative section (§2, §3, §5) is about "Covered Software." The license arguably grants nothing.

Conversely, if FastLED does attach the literal Exhibit A notice to source files, the files say on their face that they are "subject to the terms of the Mozilla Public License, v. 2.0" — an unconditional offer of plain MPL that a recipient may accept and rely on, again defeating §2.3. The wrapper is caught between grant-nothing and grant-everything.

(iii) Is FastLED §2.3 a condition of the copyright grant, or a bare covenant? MPL §2.7 is exhaustive on its face:

"Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted in Section 2.1."

FastLED §2.3 is not among them, and the wrapper's own §1 self-label ("appended conditions of this combined License") is contradicted by the incorporated §2.7's closed enumeration. If §2.3 is held a mere covenant rather than a condition, breach sounds in contract, not copyright infringement — no §5.1 automatic termination, no injunction as of right, no statutory damages or fee-shifting, and enforcement requires proving contract formation against a party that merely downloaded a repo. That guts the entire commercial theory of the license.

Compounding this, MPL §9 is an integration clause sitting inside the incorporated text: "This License represents the complete agreement concerning the subject matter hereof." A defendant will cite it to argue the Additional Terms are extrinsic and excluded.

Recommendation

1. In the single merged file, amend §1.8 to: "License" means this document, comprising the terms below and the FastLED Additional Terms in Section 11, together as a single instrument.
2. Amend §1.4 and Exhibit A together. New Exhibit A: This Source Code Form is subject to the terms of the FastLED Reciprocal License, v. 1.0. If a copy was not distributed with this file, You can obtain one at <URL>. Add to §1.4: A file bearing the SPDX identifier LicenseRef-FastLED-Reciprocal-1.0 is deemed to have the Exhibit A notice attached.
3. Amend §2.7 to read: Sections 3.1, 3.2, 3.3, 3.4, and 11.3 are conditions of the licenses granted in Section 2.1. This is the single most important edit in the document.
4. Amend §9 to: This License represents the complete agreement concerning the subject matter hereof, including the FastLED Additional Terms.
5. Amend the last sentence of §3.1 to: You may not attempt to alter or restrict the recipients' rights in the Source Code Form, except that You must pass on this License in full, including Section 11.
6. Renumber the Additional Terms. They currently occupy §2.1–2.4 and §3, colliding head-on with MPL §2.1–2.7 and §3.1–3.5 inside one instrument with a conflict-resolution rule keyed to section content. Move the Additional Terms to §11.1–11.4 and cross-reference by full number everywhere.

---

Q3 — The conflict clause, and the §5.1 cure window vs. "no post-sale grace period"

Rating: HIGH

Analysis

Determinacy of the clause. Two words carry all the weight and neither is defined: "expressly" (a conflict is a relationship between provisions, not something a provision states expressly — the word does no work and invites the argument that only a conflict the drafter labeled qualifies) and "minimum extent" (unmeasurable without an ordering rule). Order-of-precedence clauses of this shape are routinely enforced in commercial contracts, so the clause is not void — but as the sole reconciliation mechanism in a license where the conflicts are structural rather than incidental, it will not resolve the disputes that matter.

Express conflicts actually present:

#	MPL provision	FastLED term	Nature
1	§3.1 "You may not attempt to alter or restrict the recipients' rights"	§2.3 disclosure condition	Direct
2	§2.3 (MPL) "only rights granted" + §2.7's closed list of conditions	§2.3 as an "appended condition"	Direct — MPL closes the condition set
3	§3.3 Secondary License relicensing	§2.3	Direct and dispositive — see Q4
4	§10.1/§10.2 (Mozilla steward, subsequent versions)	Wrapper §1 (FastLED steward)	Direct — see Q1
5	§9 integration clause	Existence of Additional Terms	Direct — see Q2
6	§5.1 reinstatement	"There is no post-sale grace period"	Contested — below
7	§3.5 "Application of Additional Terms" (limited to fee-based warranty/support)	The Additional Terms generally	Framing conflict

None of these is flagged in the wrapper, so under a strict reading of "expressly conflicts," arguably none triggers the override and MPL controls throughout.

§5.1 vs. "no post-sale grace period." MPL §5.1 terminates rights automatically on non-compliance but reinstates them (a) provisionally on cure, and (b) on an ongoing basis if no Contributor notifies within 60 days of cure, plus a first-notice 30-day cure path. Do they conflict? They address different subjects, and on the better reading they do not conflict — which is the outcome the drafter does not want. §2.3 fixes the time of performance; §5.1 governs reinstatement after termination. Both can operate: a seller who ships without publishing is in breach on day 0 and terminates, but §5.1(b) reinstates it if it publishes later and no Contributor sends notice within 60 days. In practice that is a de facto unlimited grace period policed only by whether a Contributor happens to notice. Note also reinstatement is per-Contributor. Applying the wrapper's own rule mechanically, the "minimum extent" of any conflict is the timing duty, which does not displace §5.1's remedial machinery. The sentence "There is no post-sale grace period" is therefore, as drafted, legally inert against §5.1 — a statement about when the duty accrues, not a waiver of cure.

Recommendation

1. Replace the vague conflict clause with an explicit order of precedence plus an itemized override list naming sections: the FastLED Additional Terms control over Sections 1.8, 2.3, 2.7, 3.1, 3.3, 3.5, 5.1, 9, 10.1, and 10.2 of the MPL text to the extent of the inconsistency.
2. Decide the §5.1 question deliberately and say so in text. If no cure is truly intended: Section 5.1 does not apply to a failure to comply with Section 11.3... — but counsel may push back; a no-cure copyleft term is unusually harsh, a live "is this still free software" question, and a litigation gift for unconscionability/copyright-misuse defenses.
3. The softer, probably better commercial option: keep §5.1 but shorten and condition it — e.g. a failure to comply with Section 11.3 may be cured only within 30 days of the First Sale, and only once.
4. Delete "There is no post-sale grace period" or make it operative; as a bare declarative it creates ambiguity without effect.

---

Q4 — The Secondary License escape hatch is open, and it is a complete bypass

Rating: CRITICAL

Analysis

MPL §1.5 defines "Incompatible With Secondary Licenses" as (a) Exhibit B attached by the initial Contributor, or (b) MPL 1.1-era availability. Neither is true here. FastLED code under this instrument is therefore not Incompatible With Secondary Licenses, and §3.3 applies in full: a Larger Work combining Covered Software with a Secondary-Licensed work may additionally distribute the Covered Software under the Secondary License (GPLv2/LGPLv2.1/AGPLv3 or later, §1.12), and the recipient may further distribute under either.

The exploit, in four steps: (1) add one trivial GPLv2-or-later file to your product tree, making it a Larger Work; (2) additionally distribute the modified FastLED code under GPLv2; (3) your customer receives the FastLED code and may elect GPLv2; (4) GPLv2 imposes no First Sale duty and no public disclosure duty — a source offer to your own paying customers fully discharges it. FastLED §2.3's public disclosure requirement is gone. MPL §3.3's final sentence limits only the patent expansion; it does not close the copyright relicensing route.

This is not a marginal loophole. It is a one-file, zero-cost, textually authorized bypass of the license's entire commercial purpose. The wrapper's §1 affirmatively makes it worse by declaring "All provisions of MPL 2.0 apply," which imports §3.3 wholesale.

Is the combined license GPL-compatible at all? Through the §3.3 hatch: yes — but only by discarding the Additional Terms. As a standalone instrument: no. GPLv2 §6 forbids further restrictions; GPLv3 §7's list of permissible non-removable additional terms is exhaustive and a public-source-disclosure-on-sale obligation is not on it, so a GPLv3 recipient may simply remove the FastLED term as a "further restriction."

The unavoidable trade-off, stated plainly: attaching Exhibit B closes the bypass and makes the license definitively GPL-incompatible — FastLED could no longer be used in GPL/LGPL/AGPL projects at all, a real cost for an Arduino/embedded library with a GPL-adjacent ecosystem. Leaving Exhibit B off keeps GPL reach but makes §2.3 optional at the licensee's election. There is no drafting that gets both. This is a client business decision, and it should be documented.

Recommendation

1. Make the choice explicit and record it in LEGAL-REVIEW.md.
2. If closing the hatch (recommended if §2.3 is the point): attach the Exhibit B notice to source files as the initial Contributor, and state it in the Additional Terms: The Covered Software is Incompatible With Secondary Licenses as defined in Section 1.5. Section 3.3 does not permit distribution of the Covered Software under any Secondary License.
3. If keeping GPL reach: add an express carve-out preserving §2.3 through relicensing — and accept that this term is itself a "further restriction" that GPLv2 §6 / GPLv3 §7 will strip downstream. The weaker option.
4. Add a plain-English FAQ entry on GPL interaction. Registry and distro reviewers will ask this first.

---

Q5 — Duration of the source-availability duty and the third-party-issue-tracker dependency

Rating: HIGH

Analysis

Premise correction: MPL 2.0 §3.2(a) contains no "for as long as" language — unlike GPLv2 §3(b) (three-year offer) or GPLv3 §6(b), MPL sets no express duration. The duty is structural: a §2.7 condition running to each recipient, phrased in the continuing present ("must also be made available"), with no safe-harbor sunset — real but judicially undefined in duration, which makes any one-shot compliance act risky.

Does a one-time bug-report patch satisfy it? Distinct problems:

1. No informing of recipients. §3.2(a) has two limbs — availability and informing "recipients of the Executable Form" how to obtain source. §2.3(b) satisfies neither directly: a diff on FastLED's issue tracker tells the seller's customers nothing. A distributor who does only §2.3(b) is still in breach of §3.2(a). The Additional Terms never say §2.3 substitutes for §3.2; the wrapper says MPL "applies unchanged," so both duties stack.
2. Compliance depends on infrastructure controlled by the licensor. FastLED can disable issues, delete the issue, archive the repo, block the user, or migrate hosts. A licensee whose compliance can be unilaterally destroyed by the licensor has strong impossibility/waiver/unclean-hands arguments and an equitable defense to termination. MPL §4 does not cover this (limited to "statute, judicial order, or regulation").
3. If the repo owner deletes the issue, the licensee has performed and cannot re-perform, but the source is no longer available — the §3.2(a) duty is breached by an act of the licensor. Nothing allocates that risk.
4. Mutability. GitHub issue bodies are editable/deletable; attachments expire. A diff in an issue body is not an archival artifact. §2.3(b)'s reconstruction standard silently assumes the upstream commit SHA remains reachable — a force-push, history rewrite, or repo transfer upstream breaks every previously-filed patch retroactively.
5. Practical: platform limits on issue body length and abuse detection on very large pastes make "regardless of size" unrealistic on GitHub specifically.

Option (a) (public fork) avoids most of these and is much the better mechanism — but it too states no persistence duty ("Publish" is instantaneous; nothing forbids deleting the fork the next day).

Recommendation

1. Add an express duration term to both options: publicly available for no less than 3 years after the last First Sale, and in any event as long as the Executable Form is distributed.
2. Add a licensor-caused-impossibility safe harbor: if the official repo rejects or later removes a submission, compliance by the fork method within 30 days of awareness, no termination in the interim.
3. Add a permanence requirement for (b): fixed-content posting (attached file, or mirrored to a public Git repo/archival service) plus licensee retention of its own public copy.
4. State the relationship to §3.2 explicitly — substitution or stacking; right now silence makes stacking the default.
5. Consider deleting option (b) entirely. It saves the licensee one git push in exchange for a third-party dependency, a mutability problem, and an upstream-SHA-stability assumption.

---

Q6 — Patent grant interaction

Rating: MEDIUM (drafting), HIGH (unintended severity if fixed as recommended)

Analysis

MPL §2.1 grants are made conditional only by §2.7. This makes Q6 turn entirely on the Q2(iii) issue, and it cuts both ways:

• As currently drafted: FastLED §2.3 is not in §2.7's list, so it conditions neither the copyright grant nor the patent grant. The patent grant is unaffected — safe, but only because the term is toothless.
• If §2.7 is amended as recommended in Q2: §2.7 conditions "the licenses granted in Section 2.1" as a whole — copyright at 2.1(a) and patent at 2.1(b) — so adding §11.3 to §2.7 automatically conditions the patent grant on the disclosure obligation. A manufacturer that ships 100,000 units without publishing loses its patent license from every Contributor, retroactively, across every unit — patent-infringement exposure on the entire product line, potentially treble damages, from a failure to post a diff.

That escalation may be the leverage the drafter wants, but it must be a conscious choice, with two side effects: (1) it converts every FastLED contributor's patent portfolio into an enforcement instrument they never agreed to wield — a CLA/contribution-policy issue; (2) it materially raises the proportionality question in an unconscionability or misuse defense.

§5.2 patent-litigation termination is unaffected — no risk. MPL §2.3 (Limitations on Grant Scope) is FastLED-favorable (forecloses implied licenses) but reinforces the reading that the MPL grant/condition structure is closed. Two smaller points: MPL §2.3(b) denies a patent license for the licensee's own modifications anyway (coherent with the disclosure duty attaching to exactly that code); §5.3 preserves end-user licenses on termination, limiting damage to the manufacturer itself — a good outcome to keep and to FAQ ("will my customers' devices stop working?" — no).

Recommendation

1. Decide explicitly whether §11.3 should condition the patent grant. If not, split §2.7: Section 11.3 is a condition of the license granted in Section 2.1(a) only. Copyright teeth without arming contributor patents.
2. If patent conditioning is intended, say so affirmatively and prominently, not by cross-reference inference. Add it to the FAQ.
3. Either way, update contributor policy/CLA and CONTRIBUTING to disclose the patent consequence — existing contributors licensed under MIT never consented to this structure.
4. Leave §5.2 and §5.3 unmodified; note §5.3's end-user survival in the FAQ.

---

Additional issues spotted

A1 — The MIT history makes §2.3 trivially avoidable (CRITICAL, business-level). Anyone can fork the last MIT-licensed commit and continue development from there, never touching the reciprocal license. Combined with the relicensing-consent question, the practical reach of §2.3 is limited to new code added after the switch, and a competitor's incentive is simply to avoid that code. The single largest gap between what the license says and what it will accomplish. Not fixable by drafting — only by contribution-policy/CLA strategy and by making post-switch code genuinely valuable. Flag to the client before spending more on legal review.

A2 — "First Sale" has three large loopholes (HIGH). (i) SaaS/network use — never "transfer," no duty accrues (contrast AGPL §13); (ii) free-of-charge distribution — give firmware away, monetize hardware/ads/subscriptions separately; (iii) internal corporate use at any scale. Also unaddressed: intra-group transfers (MPL §1.14 "You" includes controlled entities), and free-beta-then-paid sequencing. If the target is commercial hardware vendors, consider triggering on "distribution of the Executable Form in or with a product offered commercially" rather than on monetary compensation.

A3 — "FastLED" is defined by reference to an "official repository" the license never identifies (HIGH). No URL, no owner, no successor provision; "official" does trademark work while MPL §2.3 expressly disclaims trademark rights. If the repo moves or forks contentiously, the definition breaks — and §2.3(b) points at nothing. Fix: name the canonical URL, add a successor-designation mechanism, and handle the FastLED mark separately.

A4 — C++ header/template reality vs. the Larger Work boundary (MEDIUM–HIGH). FastLED is heavily header-based and template-heavy, and MPL §1.10(b) defines a Modification as "any new file in Source Code Form that contains any Covered Software." Amalgamated/single-header builds, vendored copies, macro expansion into user files, and copy-paste all produce files that literally contain Covered Software and therefore are Modifications. Wrapper §2.2's reassurance is broader than MPL supports in those cases — an overbroad reassurance in a license is a liability. Also note the Executable Form of Covered Software is itself Covered Software (§1.4), so §3.2 duties attach to shipped binaries even when application source stays proprietary.

A5 — SPDX / package-registry practicalities (MEDIUM). LicenseRef-FastLED-Reciprocal-1.0 is valid SPDX but rejected/downgraded to "unknown" by many ecosystems' tooling and corporate whitelist gates. Expect adoption friction independent of the legal merits. Mitigation: LICENSE + LICENSE.spdx, clear FAQ, consider SPDX List submission; expect Debian/Fedora to run their own freeness analysis.

A6 — No governing-law or venue substitution (LOW–MEDIUM). MPL §8 sends litigation to the defendant's home forum under the defendant's law — a deliberate MPL design favoring defendants that may be wrong for an instrument whose point is enforcement against commercial sellers, plausibly offshore manufacturers.

A7 — No definition of "publicly discoverable" or acceptance mechanics (LOW–MEDIUM). Does an unlisted repo with a known URL qualify? Also, the license nowhere states how a licensee accepts — MPL relies on the copyright-condition structure, which works only if §2.3 is a genuine condition. If §2.3 ends up a covenant, FastLED needs a contract-formation story it currently lacks.

A8 — AI-agent instructions referenced from inside the license (LOW). The "legally non-remedial" disclaimer is well-drafted and the right call. Residual points: (i) a document that reads as a license condition can support promissory-estoppel or deceptive-practices arguments regardless of the LICENSE's disclaimer; (ii) referencing a non-binding behavioral document from inside the license muddies the §9 "complete agreement" position — better referenced from README, keeping the license clean.

A9 — LEGAL-REVIEW.md gate is well-designed; keep it (positive finding). Recommend adding: the reviewing attorney should confirm, on the record, the Q4 GPL trade-off decision and the Q6 patent-conditioning decision, since both are client business choices rather than legal conclusions.

[zackees]

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