Skip to content

legal: review repeat and willful violation reinstatement for rc4 #30

Description

@zackees

Note

Preliminary license-policy review for open-source counsel. This issue does not provide legal advice or approve a final license.

Context

PR #29 publishes FastLED Reciprocal License 1.0-rc3. Section 5.1 currently provides:

  • first, non-willful noncompliance: provisional reinstatement on cure;
  • ongoing reinstatement after 60 days without Contributor notice, or when a noticed first violation is cured within 30 days;
  • repeat violation after notice or any willful violation: rights remain terminated until the affected Contributor expressly reinstates them in writing; and
  • reinstatement is prospective and does not release remedies for earlier unlicensed acts.

The final branch text is pinned at 8a92a8739f337c5a47e2ca8409b602d41c8c3d6e.

The repeat/willful rule is materially harsher than the baseline MPL 2.0 and GPLv3 cure models. It can create indefinite debarment when a Contributor is unreachable, refuses to respond, or disputes an undefined willful standard. In a multi-Contributor work, reinstatement may also fragment by Contributor.

Proposal

Review Section 5.1 for rc4 and choose a proportionate reinstatement model. The recommended starting point is the MPL 2.0/GPLv3 structure: cure restores rights provisionally, lack of timely notice converts that status to ongoing, and first-notice cure receives a protected automatic path. Repeat misconduct may give an affected Contributor a right to terminate finally, but should not create accidental permanent limbo solely because no one answers a request.

The review should distinguish prospective permission from historical liability. A fairer cure rule does not need to release damages or other remedies for acts committed while rights were terminated.

Acceptance criteria

  • Compare exact rc3 Section 5.1 language with MPL 2.0 Section 5.1 and GPLv3/AGPLv3 Section 8 using primary license text.
  • Model first, repeat, disputed, inadvertent, and willful violations; cure before notice; cure after notice; no notice; unreachable Contributor; multiple Contributors; and continued conduct after cure.
  • Define or remove willful, define what counts as a repeat violation, and state whose notice controls.
  • Decide whether repeat violations receive provisional reinstatement, whether and when it becomes ongoing, and what affirmative act produces final termination.
  • Prevent indefinite permission limbo caused only by Contributor silence or disappearance.
  • Preserve the rule that reinstatement is prospective and does not automatically release accrued claims.
  • Analyze condition/covenant, waiver, equitable-remedy, and contract-formation consequences in likely defendant forums.
  • Record counsel's recommendation in LEGAL-REVIEW.md and update the canonical termination/cure matter memo and authority links.
  • If rc4 changes the clause, add a focused regression assertion that fails on rc3's selected harsh wording and passes on the approved rc4 state, then update identifiers, notices, hashes, and immutable provenance.

Decisions

  • Treat this as an rc4 blocker because termination controls whether a cured user can safely resume development and distribution.
  • Keep rc3 immutable and perform any policy change in rc4, preserving a reviewable version history.
  • Start from established MPL/GPL cure mechanics because they address the same operational problem and reduce bespoke ambiguity; counsel may recommend a narrower departure with written justification.
  • Keep past-liability treatment separate from prospective reinstatement so proportional cure does not silently waive accrued claims.

Open questions

  • Should a repeat violation be provisionally reinstated on cure unless a Contributor affirmatively terminates within a defined period?
  • Is enhanced treatment needed for fraud or deliberate concealment, and if so, what objective facts replace the undefined willful label?
  • Should one Contributor's final termination affect only that Contributor's grants or the entire multi-Contributor work?

Related issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions