Walkthrough

REACT-ON-RAILS-PRO-LICENSE.md was updated from version 2.1 to 2.2, introducing a new "Complimentary OSS License" with Section 4.1 establishing eligibility criteria and terms for open-source projects, while revising Section 4 and Section 7 to accommodate this new licensing pathway.

Changes

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A license renewed with open hearts so bright,
Section Four-point-One brings OSS projects light,
Complimentary terms with attribution's might,
Thirty days to comply—fair and right! ✨

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

This PR adds Section 4.1 to the React on Rails Pro EULA, establishing a complimentary "oss" license tier for open-source organizations with public source code and annual revenue under $1M, and updates the Section 4 note to reference this new exception.

• P1 – Section 7 gap: The termination clause carves out only "non-commercial uses explicitly permitted in Section 4," but Section 4.1 grants complimentary Production Use — leaving ambiguity about what obligations apply when a complimentary license is revoked or a paid subscription lapses for an OSS-eligible org.
• The CHANGELOG was not updated, as noted in the unchecked PR checklist item.

Confidence Score: 4/5

The Section 7 termination clause creates a legal clarity gap with the new Section 4.1 that should be resolved before merging.

One P1 legal ambiguity (Section 7 not referencing Section 4.1) could lead to disputes about Production Use obligations upon license termination or revocation. The remaining findings (heading format, missing definition, version bump, CHANGELOG) are all P2.

REACT-ON-RAILS-PRO-LICENSE.md — specifically the Section 7 termination clause and Section 4.1 heading/definition consistency.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Organization wants to use\nReact on Rails Pro] --> B{Use type?}
    B -->|Non-commercial / Educational / Demo| C[Section 4 – Free use\nNo Production Use]
    B -->|Production Use| D{Has paid subscription?}
    D -->|Yes| E[Section 2 – Licensed\nOrganization]
    D -->|No| F{Qualifies for OSS\nlicense? §4.1}
    F -->|Public OSS code AND\nrevenue < $1M AND\napplied via email| G[Section 4.1 – Complimentary\n'oss' License Granted]
    F -->|No| H[Unauthorized Production Use\n→ Section 5 violation]
    G --> I{License active?}
    I -->|Yes – fixed term,\ntypically 1 year| J[Production Use permitted\nAttribution §6 required]
    I -->|Revoked – criteria\nno longer met| K[Must cease Production Use\n⚠️ Section 7 gap: no\nexplicit obligation stated]
    E --> L[Subscription lapses?]
    L -->|No| J
    L -->|Yes| M[Section 7 – Cease\nProduction Use\n⚠️ Gap: §4.1 fallback\nnot mentioned]

_{Reviews (1): Last reviewed commit: "Add Section 4.1: complimentary OSS licen..." | Re-trigger Greptile}

Review Notes

This is a clean, well-scoped policy addition. A few issues worth addressing before merge:

CHANGELOG not updated

The PR checklist item for CHANGELOG is unchecked. Even though this is a license-only change, a brief entry under [Unreleased] documents the new OSS tier for anyone tracking the project's licensing history.

Version number not bumped (line 3)

REACT-ON-RAILS-PRO-LICENSE.md carries Version 2.1 — 2025-09-25. Adding a new production-use tier is a substantive change — the version and date should be updated (e.g. Version 2.2 — 2026-04-12). This line is outside the diff so I can't leave it as an inline comment, but it's worth fixing in the same commit.

Missing definition in Section 1

Section 1 defines Organization and Production Use, but "complimentary oss license" appears throughout Section 4.1 without a definition. A one-liner in Section 1 would make the document self-consistent:

Complimentary OSS License – a license issued under Section 4.1 at no charge to a qualifying open-source Organization.

Section 7 (Termination) interaction

Section 7 requires Organizations to "immediately cease use and remove the Software from all Production systems" upon termination, with the only carve-out being "non-commercial uses explicitly permitted in Section 4." A revoked OSS license holder gets no grace period and no Section 4 carve-out (Section 4 only covers non-production use). The notice-period suggestion on line 60 helps here, but it may also be worth adding an explicit short wind-down period (e.g. 30 days) into Section 7 for complimentary license revocations.

See inline comments for the specific line-level suggestions.

Review Address Summary (1a00e6a)

All substantive review feedback has been addressed in a single commit:

Fixed

• Section 7 fee-payment conflict (P1) — scoped "fees are paid" to paid subscriptions only; added explicit Complimentary OSS License term and revocation language
• 30-day notice period — Section 4.1 now differentiates immediate revocation (breach) from 30-day notice (eligibility loss); Section 7 mirrors with a corresponding wind-down
• "Complimentary OSS License" definition — added to Section 1 for legal self-consistency
• Term precision — changed "typically one year" to "one (1) year from the date of issuance"
• Version bump — updated to Version 2.2 (2026-04-12)
• Heading level — Section 4.1 now uses bold text (matching 9.1 style) instead of ##

Not changed (intentional)

• Email address — [email protected] kept intentionally as sole decision-maker for OSS eligibility
• CHANGELOG — will update separately if needed before merge

Review: License policy update (v2.1 → v2.2)

This is a well-structured license update. The new Section 4.1 OSS tier is a good community initiative. A few issues worth addressing before merge:

Issues

1. Copyright year not updated (line 4)
The copyright notice still reads © 2015–2025 but the document is dated 2026-04-12. Conventional practice is to update the end year when publishing a new version.

2. Personal email for a legal/business process (line 53)
Section 4.1 criterion 3 uses [email protected] as the application contact. A role/team address (e.g. [email protected] or [email protected]) is preferable for a formal contractual process — it survives personnel changes and is auditable by multiple people.

3. Section heading style inconsistency (line 47)
Section 4.1 uses bold text (**4.1 ...**) rather than the Markdown heading style (##) used by all other top-level sections. This makes the document structurally inconsistent and may cause the section to be missed by readers navigating by heading anchors.

4. Inconsistent "oss" / "OSS" casing
Section 1 defines the term as Complimentary OSS License (uppercase), but Section 4.1 refers to the "oss" license type in lowercase and the terms sub-section uses "complimentary oss licenses" in lowercase. The defined term should be used consistently throughout.

5. CHANGELOG not updated
The PR checklist item is unchecked. This is a user-facing policy change (it affects who can use the Pro package for free) and warrants a CHANGELOG entry.

Minor

• Section 4.1 doesn't mention how renewal is applied for — presumably the same email address, but explicit wording would help clarity.
• "total funding received, if pre-revenue" is an unusual threshold; most programs use trailing-12-month funding. Worth confirming this is intentional policy.

Review Address Summary (5dbdef6)

Fixed

• Section 5.7 "active subscription" conflict — broadened to "valid, active license (including a Complimentary OSS License) or subscription" so OSS license holders are not in apparent violation
• Copyright year — updated from 2025 to 2026 to match the document date
• Casing inconsistency — changed "complimentary oss licenses" to "Complimentary OSS Licenses" to match the defined term in Section 1

Declined with rationale

• Heading style for 4.1 — bold text is intentional, matching Section 9.1 style (resolved in earlier review round)
• Personal email address — [email protected] kept intentionally as sole decision-maker for OSS eligibility
• Runtime enforcement of 30-day grace period — valid observation but out of scope for this license-text PR; can be a follow-up
• Duplicate copyright year comment — addressed above

All review threads are now resolved.

Review: EULA v2.2 — Complimentary OSS License (Section 4.1)

The policy intent is clear and the overall structure of the changes is sound. A few issues worth addressing before merging:

Must-fix

CHANGELOG not updated — the PR checklist explicitly marks this unchecked. Per project contributing guidelines this should be filled in, even for non-code changes (e.g., under a "Documentation / License" heading).

Should-fix (policy clarity)

1. Section 4.1 nested under Section 4 (Non-Commercial/Free) — Section 4.1 permits Production Use, which is the exact thing Section 4's opening paragraphs prohibit. Nesting it there creates a logical contradiction for readers who skim section headers. A standalone section or a clearly demarcated heading (e.g., "4A") would avoid confusion. (Inline comment on line 47.)

2. "Total funding received" is ambiguous for pre-revenue orgs — Does it mean cumulative lifetime funding, current runway, or something else? A startup that raised $3M but spent $2.5M could argue both ways. Tightening to "total outside investment raised to date (including grants, equity rounds, and convertible notes)" removes the ambiguity. (Inline comment on line 52.)

3. Personal email in a legal document — [email protected] is a specific person's inbox, not a durable address. A role-based alias ([email protected] or similar) avoids needing a EULA bump if the contact changes. (Inline comment on line 53.)

4. Renewal doesn't require eligibility re-verification — The current wording lets a licensee renew without affirmatively re-confirming they still meet the criteria. Adding a sentence like "Renewal is subject to re-confirmation that all eligibility criteria are met at the time of renewal" closes this gap. (Inline comment on line 58.)

Minor / FYI

• The "oss" license type referenced in Section 4.1 implies a corresponding tier in the license validation system. If that doesn't exist yet at launch, ShakaCode technically can't issue these licenses programmatically — worth coordinating with the Pro implementation before this goes live.
• Section 7's 30-day grace period for eligibility-based revocations (Section 4.1(ii)) is a practical touch that should reduce friction for good-faith licensees. Well done.