Strategy: project-agnostic GPL/free-software compatibility exception

[zackees]

Note

Preliminary strategy issue for attorney review ? not legal advice.

Scope

This issue is limited to whether the reusable FastLED Reciprocal License should provide a project-agnostic compatibility exception for GPL-family or other free-software combinations. The license-text repository does not own adopter code, grant commercial exceptions for adopters, or require changes to the FastLED software repository.

FastLED source-file markers, vendored dependencies, and migration tooling are separate FastLED adoption work and are out of scope here.

Current text

Rc2 keeps Exhibit B and Section 3.3's Secondary-License restriction. That closes a route by which a recipient could discard the public-availability condition, but it also makes the license incompatible with the named GPL-family Secondary Licenses.

Question for counsel

Can a narrow, non-converting additional permission allow a publicly developed Larger Work under an eligible free-software license without:

1. relicensing Covered Software away from the FastLED Reciprocal License;
2. allowing a token GPL file to bypass Section 11.3;
3. imposing a GPL-prohibited further restriction on downstream recipients; or
4. implying that the canonical license-text maintainer owns or can separately license an adopter's software?

Candidate architecture

Evaluate a Public Combination Exception under which the first distributor of a defined Eligible Combined Work receives additional permission only when the complete corresponding source of the whole combination is Publicly Available by first distribution. Covered Software would remain under this License, and project-specific Contributors would remain the only grantors for their Contributions.

Acceptance criteria

• Primary GPLv2, GPLv3, LGPL, AGPL, MPL, and representative exception texts are analyzed with exact sections.
• The proposal distinguishes an additional permission from conversion or dual licensing.
• It states which actor bears each condition and whether downstream removal is permitted.
• It tests the one-GPL-file proprietary-product bypass adversarially.
• It addresses projects under incompatible licenses such as EUPL separately.
• It never assigns adopter copyrights or commercial-licensing authority to the canonical license repository or its maintainer.
• Any exception preserves the mandatory generic AI Coding Agent Notice in Section 11.7 and Exhibit C.
• Any proposed text remains release-candidate material behind LEGAL-REVIEW.md.

Out of scope

• FastLED code ownership or chain of title.
• Applying headers to FastLED/FastLED.
• Third-party component replacement, including libhelix/minimp3 work.
• Representing the resulting license as OSI-approved or universally GPL-compatible.

Related

• Attorney-review meta issue: META: AI first-pass legal review of FastLED Reciprocal License 1.0 RC — triage, findings & prior-art survey #8
• License-agnostic comparison corpus: docs: build a license-agnostic copyleft enforcement research corpus #17

[zackees]

Primary-source verification pass complete: every load-bearing quote in this strategy (GPLv2 §3(b)/§6, GPLv3 §6(b)/§7 incl. the ¶4 non-survival sentence and ¶2 self-removal parenthetical, GCC RLE 3.1 definitions, Oracle UFE — no termination, no flow-down, categorical OSI/FSF eligibility with outward-only ratchet, MySQL FOSS Exception's five conditions — source-on-same-medium, never public posting, FSF's MPL 2.0 first-distributor doctrine, Debian's recipient-vs-world-scoped line with the 2008 AGPL ruling and 2025 RPL statement) checked verbatim against the primary texts.

One addition from the verification worth folding into the marker plan: the Classpath exception is activated per-file — OpenJDK's LICENSE applies it "only where Oracle has expressly included in the particular source file's header" the designation line. That is established precedent for designating exception applicability file-by-file through the universal per-file marker scheme, should §11.8/§11.9 (or any future carve-out) ever want per-file rather than global scoping.

[zackees]

Update on the libhelix_mp3 open question — the "replace with minimp3" option is NOT viable as a full swap. Technical investigation (FastLED usage audit + minimp3 evaluation against primary sources):

• FastLED's actual Helix use is FileSystem::openMp3() → streaming frame-by-frame decode from SD on-device, in realtime, to drive audio-reactive effects, compiled unconditionally on every platform (the vendored copy has FastLED-added Xtensa/RISC-V/generic-C ports and is in the unity build with no ifdef gate). Only five Helix API functions are used, all in one wrapper (src/fl/codec/mp3.cpp.hpp) — the API migration itself would be trivial (S effort).
• But minimp3's core is float-only with no fixed-point path, plus a ~16KB stack scratch per decode call. The empirical record — including from the maintainer of the exact libhelix fork FastLED vendors (cmorgan.org/2023/10/05) and Schatzmann's ESP32 port (pschatzmann.ch, 2022) — is that minimp3 is not realtime on ESP32 even with FPU, and hopeless soft-float on FPU-less targets (RP2040, ESP32-S2/C3, STM32F1, Teensy 3.x). A swap would keep everything compiling while silently breaking the feature on most hardware it exists for. Helix's fixed-point core is why the entire ESP32 audio ecosystem (ESP32-audioI2S, esp-audio-player) ships it.
• minimp3 IS clean on every other axis: CC0, Layer 1/2/3 superset, better ISO conformance, 1:1 API mapping.

Revised options for resolving the RPSL/RCSL problem:
(a) Opt-in isolation (recommended near-term): keep Helix but gate it behind an explicit build flag so the default FastLED distribution ships no RPSL code — resolves the Debian/eligible-combination claim without a performance regression.
(b) Steer to OGG/Vorbis: stb_vorbis is already vendored (public domain) and the repo's own benchmark comments in mp3.h favor OGG — deprecate on-device MP3 over time.
(c) Hybrid: minimp3 for host/WASM/tests + FPU-rich targets, MP3-on-MCU off elsewhere — more build-matrix complexity for little gain over (a).
(d) Fixed-point alternatives: none with a clean license (MAD is GPL).

No known clean-licensed fixed-point MP3 decoder exists; option (a) or (b) is the realistic path.

[zackees]

libhelix_mp3 resolution path found: #13 — feasibility study (with a compiled numerical prototype) for a fixed-point mode in minimp3, golden-tested against its own float build, using Helix's fixed-point architecture as a clean-room design reference (ideas only; no RPSL expression). Prototype hit 98–140 dB PSNR on the two transform stages with formula-regenerated tables; ~6 person-weeks; result stays CC0 and is upstreamable. If executed to its acceptance gate, the RPSL tree gets deleted outright — superseding options (a)–(d) above with a clean permanent fix.