Skip to content

Conversation

AbanoubGhadban
Copy link
Collaborator

@AbanoubGhadban AbanoubGhadban commented Sep 25, 2025

🚨 Critical Security & Legal Fixes

This PR addresses critical vulnerabilities in our freemium licensing model and strengthens legal protections against license circumvention.

🔒 Security Vulnerabilities Fixed

JavaScript Interface Protection:

  • Added explicit protection for MIT-licensed code that imports Pro modules
  • Prevents hackers from modifying interface files to bypass license validation
  • Protected files: clientStartup.ts, serverRenderReactComponent.ts, ReactOnRails.client.ts, ReactOnRails.node.ts

Ruby License Validation Protection:

  • Added protection for Ruby code that generates rails_context and rorPro field
  • Prevents modification of ReactOnRails::Utils.react_on_rails_pro? method
  • Protected files: lib/react_on_rails/helper.rb, lib/react_on_rails/utils.rb

⚖️ Legal Enhancements

LICENSE.md:

  • Added comprehensive anti-circumvention language
  • Explicit prohibition against modifying license validation mechanisms
  • Clear legal basis for enforcement against hackers

REACT-ON-RAILS-PRO-LICENSE.md:

  • Enhanced with stronger anti-hacking clauses (items 4-7)
  • Added detailed audit provisions (Section 9.1)
  • Added standard legal protections (Indemnification, Export Compliance, etc.)
  • Updated version to 2.1

package.json:

  • Updated license field from "MIT" to "(MIT AND Proprietary)"
  • Accurately reflects dual licensing nature of freemium model

📚 Documentation Updates

LICENSING_FAQ.md:

  • Fixed inconsistencies in freemium model description
  • Clarified that Pro features are included but gated behind license validation

🛡️ Impact

  • Prevents license circumvention through code modification
  • Strengthens legal enforcement capabilities
  • Maintains freemium model while protecting Pro features
  • Provides clear legal basis for taking action against violators

⚠️ Note

Some legal provisions (like Indemnification) were copied from the old react_on_rails_pro license.

This PR makes our freemium model legally bulletproof against common hacking attempts.


This change is Reviewable

Summary by CodeRabbit

  • Documentation

    • Clarified licensing structure to distinguish MIT vs Pro components, reorganized license text, added Pro license reference and usage guidance.
    • Expanded Pro license terms (new restrictions, audit provisions) and broadened legal/governance sections (indemnification, export compliance, fees, governing law, miscellaneous, assignment, entire agreement).
    • Updated directory licensing guidance and FAQ to explain Pro feature restrictions and subscription requirement for production use.
  • Chores

    • Updated package metadata to reference consolidated license file.
  • Notes

    • No functional or runtime changes.

…tion requirements

- Enhanced the LICENSE.md to specify that Pro-licensed directories require a valid subscription and outline prohibitions against circumventing license validation.
- Updated package.json to reflect a dual license of MIT and Proprietary.
- Revised REACT-ON-RAILS-PRO-LICENSE.md to include new clauses regarding license validation and compliance.
- Modified DIRECTORY_LICENSING.md to clarify the nature of Pro features in the repository.
- Adjusted LICENSING_FAQ.md to accurately describe the licensing structure and requirements for Pro features.
Copy link
Contributor

coderabbitai bot commented Sep 25, 2025

Warning

Rate limit exceeded

@AbanoubGhadban has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 22 minutes and 1 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between f408946 and 37d1f26.

📒 Files selected for processing (2)
  • LICENSE.md (2 hunks)
  • docs/DIRECTORY_LICENSING.md (1 hunks)

Walkthrough

Split repository licensing into MIT vs Pro scopes in LICENSE.md; introduced SPDX/Pro license marker and Pro directories; upgraded REACT-ON-RAILS-PRO-LICENSE.md to v2.1 with expanded restrictions, audits, and governance sections; updated docs to mark Pro files; adjusted package.json license field to reference LICENSE.md.

Changes

Cohort / File(s) Summary
Root license file
LICENSE.md
Reworked into structured License Scope, added MIT Licensed Code and Pro Licensed Code subsections, added SPDX/Pro license marker and Pro directory list, linked to REACT-ON-RAILS-PRO-LICENSE.md, and retained MIT license text.
Pro license terms
REACT-ON-RAILS-PRO-LICENSE.md
Bumped version 2.0 → 2.1; added new Restrictions (anti-circumvention, anti-reverse-engineering, tooling/patch bans, access restrictions), added 9.1 Detailed Audits, and reorganized/added governance sections (Indemnification; Export Compliance; Attorneys’ Fees; Governing Law; Miscellaneous with Severability/Waiver/Assignment; Entire Agreement renumbered).
Docs: directory licensing
docs/DIRECTORY_LICENSING.md
Marked Pro directories as Pro-licensed with license validation requirements, clarified MIT interface vs Pro implementation distinction, and updated wording about Pro inclusion in the package.
Docs: licensing FAQ
docs/LICENSING_FAQ.md
Changed FAQ framing to "MIT + Pro", added Q&A on modifying MIT-licensed interface files, clarified production use requires a valid Pro subscription and license validation.
Package metadata
package.json
Updated license field from "MIT" to "SEE LICENSE IN LICENSE.md".

Sequence Diagram(s)

(omitted — changes are documentation and license text only; no control-flow or runtime changes to diagram)

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Suggested reviewers

  • justin808
  • Judahmeek
  • alexeyr-ci2

Poem

I nibble clauses, tidy lines anew,
Pro carrots guarded, MIT clover too.
I hop through sections, stamp each tiny clause—
Keep the keys safe, respect the license laws.
A rabbit’s grin on the updated views. 🥕🐇

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title concisely reflects the core updates by addressing licensing vulnerabilities and reinforcing legal protections around the freemium model, matching the PR’s security and legal enhancement goals without unnecessary detail.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.

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.

❤️ Share

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

Copy link

claude bot commented Sep 25, 2025

Code Review Feedback

Critical Legal & Technical Issues

1. LICENSE.md - MIT License Conflict
The added restrictions create a fundamental incompatibility with the MIT license. MIT explicitly grants rights "without restriction, including without limitation the rights to use, copy, modify..." but the new language prohibits modification of interface files. This is legally contradictory.

Recommendation: MIT-licensed code cannot include anti-circumvention clauses. Consider moving interface files to Pro-licensed directories OR restructuring the licensing model. Consult with IP counsel on dual-licensing enforceability.

2. package.json License Field - Invalid SPDX Expression
The change to "(MIT AND Proprietary)" is problematic: "Proprietary" is not a valid SPDX identifier, AND operator means all parts apply simultaneously, and NPM may reject this.

Recommendation: Change to "SEE LICENSE IN LICENSE.md"

3. Legal Enforceability Concerns
Anti-circumvention language may be difficult to enforce because users have explicit MIT rights to modify code, and anti-circumvention laws apply to technological protection measures, not honor-system license checks.

Recommendation: Consider actual technical protection measures rather than license-based restrictions on MIT code.

Best Practices & Code Quality

4. Documentation Inconsistencies
LICENSING_FAQ.md creates confusion by stating Pro features are "included but gated behind license validation" in an MIT repo.

5. Version Bumping Without Changelog
REACT-ON-RAILS-PRO-LICENSE.md bumped from v2.0 to v2.1 without changelog explaining changes.

Security & Performance

6. No Actual Security Improvements
PR claims to fix vulnerabilities but only adds legal language - no code changes to license validation, no technical measures, no cryptographic protections.

7. Missing Test Coverage
No tests verify license validation still works or that there are no regressions.

Minor Issues

8. Formatting

  • Line 17 in LICENSE.md is very long (>500 chars)
  • Ensure all files end with newline (per CLAUDE.md)

9. Redundant Language
Same phrases repeated multiple times.

Positives

  • Clear intent to protect IP
  • Comprehensive Pro license terms
  • Updated documentation

Recommended Actions Before Merging

  1. Legal review - Consult IP attorney about MIT + anti-circumvention enforceability
  2. Fix package.json - Use "SEE LICENSE IN LICENSE.md"
  3. Add tests - Verify no functional regressions
  4. Run linting - Ensure bundle exec rubocop passes
  5. Consider alternative approach - Technical measures > legal language

Rating: Needs significant revision - Legal contradictions must be resolved before merge.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 120bd43 and 6734c2a.

📒 Files selected for processing (5)
  • LICENSE.md (1 hunks)
  • REACT-ON-RAILS-PRO-LICENSE.md (4 hunks)
  • docs/DIRECTORY_LICENSING.md (1 hunks)
  • docs/LICENSING_FAQ.md (1 hunks)
  • package.json (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
{Gemfile,Rakefile,**/*.{rb,rake,gemspec,ru,js,jsx,ts,tsx,json,yml,yaml,md,css,scss}}

📄 CodeRabbit inference engine (CLAUDE.md)

Ensure all committed files end with a trailing newline character

Files:

  • package.json
  • docs/LICENSING_FAQ.md
  • docs/DIRECTORY_LICENSING.md
  • LICENSE.md
  • REACT-ON-RAILS-PRO-LICENSE.md
**/*.{js,jsx,ts,tsx,json,yml,yaml,md,css,scss}

📄 CodeRabbit inference engine (CLAUDE.md)

Let Prettier handle all non-Ruby file formatting; never manually format these files

Files:

  • package.json
  • docs/LICENSING_FAQ.md
  • docs/DIRECTORY_LICENSING.md
  • LICENSE.md
  • REACT-ON-RAILS-PRO-LICENSE.md
🧠 Learnings (5)
📚 Learning: 2025-09-15T21:24:48.207Z
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1781
File: node_package/src/ClientSideRenderer.ts:82-95
Timestamp: 2025-09-15T21:24:48.207Z
Learning: In React on Rails, the force_load feature includes both explicit `data-force-load="true"` usage and the ability to hydrate components during the page loading state (`document.readyState === 'loading'`). Both capabilities require a Pro license, so the condition `!railsContext.rorPro && (isComponentForceLoaded || document.readyState === 'loading')` correctly gates both scenarios.

Applied to files:

  • docs/LICENSING_FAQ.md
  • docs/DIRECTORY_LICENSING.md
  • LICENSE.md
📚 Learning: 2025-02-18T13:08:01.477Z
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1644
File: lib/react_on_rails/helper.rb:190-197
Timestamp: 2025-02-18T13:08:01.477Z
Learning: RSC support validation in React on Rails Pro is handled through a chain of validations:
1. Pro version check in `run_stream_inside_fiber`
2. RSC support check during pack generation via `ReactOnRailsPro.configuration.enable_rsc_support`
3. RSC support validation during component registration
This makes additional validation in the helper methods unnecessary.

Applied to files:

  • docs/LICENSING_FAQ.md
  • docs/DIRECTORY_LICENSING.md
  • LICENSE.md
📚 Learning: 2025-02-12T16:38:06.537Z
Learnt from: Romex91
PR: shakacode/react_on_rails#1697
File: package-scripts.yml:28-28
Timestamp: 2025-02-12T16:38:06.537Z
Learning: The file `node_package/lib/ReactOnRails.full.js` is autogenerated during the build process and should not be present in the repository.

Applied to files:

  • docs/DIRECTORY_LICENSING.md
  • LICENSE.md
📚 Learning: 2025-04-26T21:55:55.874Z
Learnt from: alexeyr-ci2
PR: shakacode/react_on_rails#1732
File: spec/dummy/client/app-react16/startup/ReduxSharedStoreApp.client.jsx:40-44
Timestamp: 2025-04-26T21:55:55.874Z
Learning: In the react_on_rails project, files under `app-react16` directories are copied/moved to corresponding `/app` directories during the conversion process (removing the `-react16` suffix), which affects their relative import paths at runtime.

Applied to files:

  • docs/DIRECTORY_LICENSING.md
  • LICENSE.md
📚 Learning: 2025-09-16T08:01:11.146Z
Learnt from: justin808
PR: shakacode/react_on_rails#1770
File: lib/generators/react_on_rails/templates/base/base/app/javascript/src/HelloWorld/ror_components/HelloWorld.client.jsx:2-2
Timestamp: 2025-09-16T08:01:11.146Z
Learning: React on Rails uses webpack CSS Modules configuration with namedExports: true, which requires the import syntax `import * as style from './file.module.css'` rather than the default export pattern. This configuration enables better tree shaking and bundle size optimization for CSS modules.

Applied to files:

  • LICENSE.md
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
  • GitHub Check: dummy-app-integration-tests (3.4, 22)
  • GitHub Check: dummy-app-integration-tests (3.2, 20)
  • GitHub Check: claude-review
  • GitHub Check: rspec-package-tests (3.4, latest)
  • GitHub Check: rspec-package-tests (3.2, latest)
  • GitHub Check: rspec-package-tests (3.4, minimum)
  • GitHub Check: build
  • GitHub Check: rspec-package-tests (3.2, minimum)
  • GitHub Check: markdown-link-check
🔇 Additional comments (4)
docs/LICENSING_FAQ.md (1)

98-99: Clearer gating note LGTM.

The clarification that Pro features remain gated behind license validation keeps the FAQ aligned with the strengthened licensing language in LICENSE.md.

REACT-ON-RAILS-PRO-LICENSE.md (2)

55-58: Anti-circumvention coverage looks solid.

Explicitly prohibiting tampering with license validation closes the loophole that let MIT consumers shim Pro APIs, which is exactly what we needed for the freemium protections.


92-94: Audit escalation clause checks out.

Section 9.1 adds the necessary audit teeth without overreaching—the cost recovery trigger on material violations is a good balance.

docs/DIRECTORY_LICENSING.md (1)

15-23: Directory exception note is consistent.

Calling out node_package/src/pro/ as bundled-but-gated keeps the structure doc in sync with the updated FAQ and license.

package.json Outdated
],
"author": "[email protected]",
"license": "MIT",
"license": "(MIT AND Proprietary)",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Invalid SPDX expression in license field

(MIT AND Proprietary) is not a valid SPDX expression—Proprietary is not on the SPDX list and will cause npm pack/npm publish to error out. Please switch to a valid SPDX expression (for example, use a LicenseRef- identifier) so the package metadata remains compliant.

-  "license": "(MIT AND Proprietary)",
+  "license": "MIT AND LicenseRef-Proprietary",

Remember to define LicenseRef-Proprietary in the referenced license file per SPDX guidelines.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
"license": "(MIT AND Proprietary)",
"license": "MIT AND LicenseRef-Proprietary",
🤖 Prompt for AI Agents
In package.json at line 121, the current license "(MIT AND Proprietary)" is not
a valid SPDX expression; replace it with a valid SPDX expression such as "MIT
AND LicenseRef-Proprietary" in package.json and then add or update your
repository LICENSE file to include a "LicenseRef-Proprietary" section detailing
the proprietary terms (and an SPDX-License-Identifier header if appropriate) so
the LicenseRef identifier is defined per SPDX guidelines.

- Added a new section in LICENSE.md detailing the proprietary license, usage restrictions, and directories associated with Pro features.
- Updated package.json to specify the proprietary license using the SPDX identifier format.
Copy link

claude bot commented Sep 25, 2025

Code Review: PR #1823 - Licensing Vulnerabilities and Legal Protections

Overview

This PR updates licensing documentation and legal terms. The changes are documentation-only with no functional code changes, which minimizes technical risk.


✅ Strengths

1. Clear Documentation Structure

  • Well-organized changes across LICENSE.md, REACT-ON-RAILS-PRO-LICENSE.md, and supporting docs
  • Consistent messaging about dual licensing model
  • SPDX identifiers properly used (LicenseRef-Proprietary)

2. Legal Completeness

  • Added comprehensive legal protections (Indemnification, Export Compliance, Attorneys' Fees, etc.)
  • Version bump from 2.0 → 2.1 properly tracked
  • Audit provisions (9.1) are reasonable and balanced

3. Alignment Across Files

  • package.json license field correctly updated to "MIT AND LicenseRef-Proprietary"
  • DIRECTORY_LICENSING.md and LICENSING_FAQ.md properly synchronized

⚠️ Issues & Concerns

Critical: License Compatibility & Legal Clarity

1. Potential Legal Contradiction in LICENSE.md (lines 34 + 39-40)

The MIT license section states:

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction...

But then immediately restricts modification:

**Important:** ...Any attempt to circumvent, bypass, modify, or disable 
the license validation mechanisms is strictly prohibited...

Issue: The MIT license grants unrestricted modification rights, but you're trying to prohibit specific modifications. This creates a legal contradiction.

Recommendation: Consider one of these approaches:

  • Option A: Clarify that the MIT portion applies to MIT-only code, and the restriction only applies when interacting with Pro code
  • Option B: Add a carve-out: "...to deal in the Software without restriction, except as explicitly restricted by the React on Rails Pro License for Pro-licensed directories"
  • Option C: Move the anti-circumvention language exclusively to the Pro license (it's already there)

2. SPDX License Identifier Issue

package.json now uses:

"license": "MIT AND LicenseRef-Proprietary"

Issues:

  • LicenseRef-Proprietary is defined in LICENSE.md but the SPDX spec requires LicenseRef- identifiers to reference a specific license document
  • More accurate: "MIT AND LicenseRef-ReactOnRailsPro" or "MIT AND SEE LICENSE"
  • Consider adding a proper LicenseRef-ReactOnRailsPro.txt file for SPDX compliance

3. Enforcement Feasibility

The new restrictions in REACT-ON-RAILS-PRO-LICENSE.md §5 items 4-7 are well-intentioned but may be difficult to enforce:

4. circumvent, bypass, modify, disable, or tamper with any license validation mechanisms
5. reverse engineer, decompile, or disassemble the Software for the purpose of circumventing license restrictions
6. create, use, or distribute any tools, scripts, patches, or modifications designed to enable unauthorized use

Concerns:

  • MIT-licensed code can be freely modified by anyone (even if they shouldn't use Pro features)
  • How do you prove "for the purpose of circumventing" (item 5)?
  • Item 6 might conflict with legitimate debugging or security research

Recommendation: Add a clarifying note that these restrictions only apply to licensees who have accepted the Pro license terms (i.e., paid subscribers who breach terms).


Code Quality Issues

4. Documentation Inconsistency

In docs/LICENSING_FAQ.md:98:

- **react_on_rails** (MIT) - Core functionality, completely free. Pro features are included but gated behind license validation

But the PR description says:

"Added explicit protection for MIT-licensed code that imports Pro modules"
"Prevents hackers from modifying interface files to bypass license validation"

Issue: If the interface files that import Pro modules are MIT-licensed, then by definition they CAN be modified. This creates confusion.

Recommendation: Clarify whether interface files are:

  • MIT-licensed (modifiable by anyone, but using Pro features is prohibited)
  • Pro-licensed (not modifiable)
  • Dual-licensed with specific restrictions

5. Missing Context in LICENSE.md

The new section (lines 6-23) references "license validation mechanisms" but doesn't explain what those are or where they exist.

Recommendation: Add a brief explanation:

**License validation mechanisms** include but are not limited to:
- Runtime checks for valid Pro subscriptions
- Authentication systems in `lib/react_on_rails/utils.rb` and Pro TypeScript modules
- The `react_on_rails_pro?` method and `rorPro` field generation

Best Practices & Suggestions

6. Version Number in Pro License

Good: Version bumped to 2.1
Suggestion: Consider adding a changelog section at the bottom:

## Changelog

### Version 2.1 (2025-09-25)
- Added anti-circumvention restrictions (§5.4-7)
- Added detailed audit provisions (§9.1)
- Added indemnification, export compliance, and legal provisions (§15-19)

7. Audit Costs (§9.1)

If the audit reveals a material unauthorized use, the Organization shall 
reimburse ShakaCode for reasonable audit costs.

Suggestion: Define "material" (e.g., "exceeding 10% of licensed usage" or "more than $1000 in unpaid fees")

8. Missing Files Reference

The PR description mentions protecting specific files:

  • clientStartup.ts, serverRenderReactComponent.ts, ReactOnRails.client.ts, ReactOnRails.node.ts
  • lib/react_on_rails/helper.rb, lib/react_on_rails/utils.rb

Issue: These files aren't mentioned in the actual license documents.

Recommendation: Either:

  • Add these to LICENSE.md as "files that interface with Pro code"
  • Or remove the claim from documentation (since MIT allows modification anyway)

🔒 Security Concerns

No technical security issues - this is documentation only.

Legal security: The anti-circumvention language provides some deterrent value, but enforcement will depend on:

  1. Clear separation of MIT vs Pro code
  2. Ability to detect unauthorized usage
  3. Jurisdiction-specific laws (DMCA 1201 in US, etc.)

✅ Test Coverage

Not applicable - documentation changes only, no code changes.

Recommendation: Verify that existing license validation mechanisms are covered by tests (separate from this PR).


📊 Performance Considerations

No impact - documentation only.


🎯 Final Recommendation

Conditional approval - merge after addressing legal clarity issues:

Must Fix:

  1. Resolve MIT/restriction contradiction in LICENSE.md (Critical)
  2. Fix SPDX identifier to proper format

Should Fix:

  1. Add context about what "license validation mechanisms" means
  2. Clarify which interface files are/aren't modifiable
  3. Define "material" in audit cost clause

Nice to Have:

  1. Add changelog to Pro license
  2. Add specific file references to LICENSE.md if claiming to protect them

💡 Alternative Approach

Consider a cleaner separation:

  • MIT LICENSE applies to lib/react_on_rails/** (except pro/) and node_package/src/** (except pro/)
  • Pro LICENSE applies exclusively to pro/ directories
  • Interface files in MIT code can be modified, but using them to access Pro features without a license is prohibited

This resolves the contradiction while maintaining your freemium model.


Overall assessment: Well-structured legal update with good intentions, but needs legal clarity improvements before merge.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6734c2a and 39bd5bf.

📒 Files selected for processing (2)
  • LICENSE.md (2 hunks)
  • package.json (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
{Gemfile,Rakefile,**/*.{rb,rake,gemspec,ru,js,jsx,ts,tsx,json,yml,yaml,md,css,scss}}

📄 CodeRabbit inference engine (CLAUDE.md)

Ensure all committed files end with a trailing newline character

Files:

  • package.json
  • LICENSE.md
**/*.{js,jsx,ts,tsx,json,yml,yaml,md,css,scss}

📄 CodeRabbit inference engine (CLAUDE.md)

Let Prettier handle all non-Ruby file formatting; never manually format these files

Files:

  • package.json
  • LICENSE.md
🧠 Learnings (4)
📚 Learning: 2025-09-15T21:24:48.207Z
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1781
File: node_package/src/ClientSideRenderer.ts:82-95
Timestamp: 2025-09-15T21:24:48.207Z
Learning: In React on Rails, the force_load feature includes both explicit `data-force-load="true"` usage and the ability to hydrate components during the page loading state (`document.readyState === 'loading'`). Both capabilities require a Pro license, so the condition `!railsContext.rorPro && (isComponentForceLoaded || document.readyState === 'loading')` correctly gates both scenarios.

Applied to files:

  • package.json
  • LICENSE.md
📚 Learning: 2025-02-12T16:38:06.537Z
Learnt from: Romex91
PR: shakacode/react_on_rails#1697
File: package-scripts.yml:28-28
Timestamp: 2025-02-12T16:38:06.537Z
Learning: The file `node_package/lib/ReactOnRails.full.js` is autogenerated during the build process and should not be present in the repository.

Applied to files:

  • LICENSE.md
📚 Learning: 2025-02-18T13:08:01.477Z
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1644
File: lib/react_on_rails/helper.rb:190-197
Timestamp: 2025-02-18T13:08:01.477Z
Learning: RSC support validation in React on Rails Pro is handled through a chain of validations:
1. Pro version check in `run_stream_inside_fiber`
2. RSC support check during pack generation via `ReactOnRailsPro.configuration.enable_rsc_support`
3. RSC support validation during component registration
This makes additional validation in the helper methods unnecessary.

Applied to files:

  • LICENSE.md
📚 Learning: 2025-04-26T21:55:55.874Z
Learnt from: alexeyr-ci2
PR: shakacode/react_on_rails#1732
File: spec/dummy/client/app-react16/startup/ReduxSharedStoreApp.client.jsx:40-44
Timestamp: 2025-04-26T21:55:55.874Z
Learning: In the react_on_rails project, files under `app-react16` directories are copied/moved to corresponding `/app` directories during the conversion process (removing the `-react16` suffix), which affects their relative import paths at runtime.

Applied to files:

  • LICENSE.md
🪛 markdownlint-cli2 (0.18.1)
LICENSE.md

8-8: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
  • GitHub Check: dummy-app-integration-tests (3.4, 22)
  • GitHub Check: dummy-app-integration-tests (3.2, 20)
  • GitHub Check: markdown-link-check
  • GitHub Check: build
  • GitHub Check: rspec-package-tests (3.2, latest)
  • GitHub Check: rspec-package-tests (3.2, minimum)
  • GitHub Check: rspec-package-tests (3.4, minimum)
  • GitHub Check: rspec-package-tests (3.4, latest)
🔇 Additional comments (2)
package.json (1)

121-121: SPDX expression looks good

MIT AND LicenseRef-Proprietary is a valid SPDX expression and aligns with the new proprietary block in LICENSE.md. 👍

LICENSE.md (1)

34-34: Reword anti-circumvention note to avoid contradicting MIT rights

By saying circumvention “constitutes a violation of this license,” we’re effectively claiming the MIT portion forbids conduct that the MIT grant expressly allows, which introduces a compliance conflict. Please scope the prohibition purely to the Pro-licensed code (or refer to contractual terms) so the MIT-licensed files remain unrestricted under MIT.

@AbanoubGhadban
Copy link
Collaborator Author

@claude suggest the changes that will make if you will implement
Alternative Approach
Consider a cleaner separation:

MIT LICENSE applies to lib/react_on_rails/** (except pro/) and node_package/src/** (except pro/)
Pro LICENSE applies exclusively to pro/ directories
Interface files in MIT code can be modified, but using them to access Pro features without a license is prohibited

Copy link

claude bot commented Sep 25, 2025

Claude finished @AbanoubGhadban's task —— View job


Implementation Complete ✅

I've successfully implemented the alternative approach for cleaner license separation.

Changes Made:

1. LICENSE.md - Restructured for Clear Separation

  • Added upfront "License Scope" section clearly defining MIT vs Pro directories
  • MIT License applies to lib/react_on_rails/** (except pro/) and node_package/src/** (except pro/)
  • Pro License applies exclusively to pro/ directories
  • Removed contradictory anti-circumvention language from MIT section
  • Added "Key Points" section clarifying that:
    • MIT code can be modified under MIT terms
    • But using those modifications to access Pro features without a license violates the Pro License

2. DIRECTORY_LICENSING.md - Added Important Distinction

  • Clarified that MIT-licensed interface files can be freely modified under MIT terms
  • Emphasized that using those modifications to access Pro features without a license violates the Pro License
  • Made clear distinction between modification rights (MIT) and usage restrictions (Pro)

3. LICENSING_FAQ.md - Enhanced with New FAQ

  • Updated description from "MIT" to "MIT + Pro" to reflect dual licensing
  • Added new FAQ: "Can I modify the MIT-licensed interface files?"
  • Explains the distinction between MIT modification rights and Pro usage restrictions

Key Legal Improvement:

This approach resolves the fundamental legal contradiction in the previous version where:

  • Before: MIT-licensed code included restrictions on modification (contradicts MIT's "without restriction" grant)
  • After: MIT code can be freely modified (consistent with MIT), but using Pro features without a license violates the Pro License

This maintains strong legal protection for Pro features while honoring the MIT license's grant of modification rights.

Commit:

  • ✅ Committed as: 55c349a
  • ✅ Pushed to: license/update-add-audit-indemnification-export-etc

Branch: license/update-add-audit-indemnification-export-etc | Job Run

Implements cleaner license separation approach:
- MIT License applies to lib/react_on_rails/** (except pro/) and node_package/src/** (except pro/)
- Pro License applies exclusively to pro/ directories
- Removes contradictory language about prohibiting MIT code modification
- Clarifies that MIT code can be modified, but using it to access Pro features without a license is prohibited

Changes:
- LICENSE.md: Restructured to clearly define license scopes upfront
- DIRECTORY_LICENSING.md: Added distinction between MIT modification rights and Pro usage restrictions
- LICENSING_FAQ.md: Added FAQ explaining modification rights vs usage restrictions

This resolves the legal contradiction where MIT-licensed code included anti-circumvention restrictions,
which conflicts with MIT's grant of unrestricted modification rights.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Abanoub Ghadban <[email protected]>
Copy link

claude bot commented Sep 25, 2025

Code Review: PR #1823 - Licensing Vulnerabilities and Legal Protection Updates

Executive Summary: This PR strengthens the freemium model legal framework by clarifying dual licensing, adding anti-circumvention clauses, and enhancing audit provisions.

STRENGTHS:
✅ Clear SPDX identifier for Pro code with explicit directory-based licensing boundaries
✅ Strong anti-circumvention language in Section 5.4-5.7 of Pro License
✅ Well-structured LICENSE.md with clear scope definitions and helpful FAQ additions
✅ Comprehensive legal protections: Audit provisions, Indemnification, Export Compliance, Attorneys Fees
✅ Version tracking (2.0 → 2.1) for license agreement

CRITICAL ISSUES:

  1. package.json License Field Problem

    • Change from "MIT" to "MIT AND LicenseRef-Proprietary" may cause NPM ecosystem issues
    • SPDX custom licenses require proper LicenseRefs documentation
    • NPM tools and license scanners may flag warnings
    • RECOMMENDATION: Use "SEE LICENSE IN LICENSE.md" (standard for dual licensing)
  2. Legal Language Concerns (Section 5.4-5.7)

    • Anti-circumvention clauses are very aggressive and potentially problematic
    • May conflict with legitimate debugging or security research
    • In EU, reverse engineering for interoperability is a legal right
    • Could prohibit legitimate development tools
    • RECOMMENDATION: Consult licensing attorney for enforceability review
  3. LICENSE.md Logical Inconsistency (Lines 75-76)

    • Creates confusion: users can modify MIT code but modifications become violations if they access Pro features
    • This derived work/conditional license boundary may be difficult to enforce
    • RECOMMENDATION: Clarify that Pro feature USE is restricted, not MIT code modifications themselves
  4. Audit Provision Ambiguity (Section 9.1)

    • "material unauthorized use" for cost recovery is undefined
    • RECOMMENDATION: Define "material" explicitly (e.g., "exceeding 10% of licensed usage")
  5. Indemnification Scope Too Broad (Section 15)

    • Could require customers to indemnify even for Software defects
    • RECOMMENDATION: Add carve-outs for "claims arising solely from defects in the Software itself"
  6. Missing License Validation Documentation

    • PR mentions "license validation mechanisms" but does not describe how they work
    • RECOMMENDATION: Add technical documentation about validation process, failure handling, privacy

CODE QUALITY ASSESSMENT:
✅ LICENSE.md: Well-structured, clear language
✅ REACT-ON-RAILS-PRO-LICENSE.md: Comprehensive, professional
⚠️ package.json: License field needs correction
✅ docs/DIRECTORY_LICENSING.md: Clear directory structure
✅ docs/LICENSING_FAQ.md: Helpful Q&A additions
✅ No security issues (documentation only)
✅ No performance impact (no runtime changes)

RECOMMENDATIONS SUMMARY:

Must Fix:

  • package.json license field → Use "SEE LICENSE IN LICENSE.md"

Should Consider:

  • Legal review of anti-circumvention clauses for jurisdiction-specific enforceability
  • Clarify MIT modification vs Pro usage boundary in LICENSE.md
  • Define "material" in audit cost recovery clause
  • Add carve-outs to indemnification clause

Nice to Have:

  • Document license validation mechanism technically
  • Add security research exception in anti-circumvention clauses

CONCLUSION: This PR significantly strengthens the legal framework for the freemium model. Documentation is clear and comprehensive. However, package.json license field needs correction to avoid NPM ecosystem issues, and several legal clauses would benefit from attorney review to ensure enforceability and avoid unintended consequences.

Recommendation: ✅ Approve with changes (fix package.json, consider legal review)

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
LICENSE.md (1)

1-70: LICENSE.md missing trailing newline Add a newline at end of file per repo guidelines and re-run Prettier to format.

🧹 Nitpick comments (3)
docs/DIRECTORY_LICENSING.md (2)

11-20: Add language hints to fenced directory trees

Markdown lint typically requires a language tag; add text to these fences.

-```
+```text
 react_on_rails/
 ├── lib/react_on_rails/           # Core Ruby code (MIT)
 ├── node_package/src/             # Core JS/TS code (MIT)
 │   └── pro/                      # Pro features with license validation (Pro licensed)
 ├── spec/                         # Core tests (MIT)
 ├── docs/                         # Documentation (MIT)
 ├── .github/                      # GitHub workflows (MIT)
 └── [all other directories]       # MIT
-```
+```
-```
+```text
 react_on_rails_pro/
 ├── lib/react_on_rails_pro/       # Pro Ruby code
 ├── packages/node-renderer/       # Pro Node.js renderer
 ├── spec/                         # Pro tests
 ├── .circleci/                    # CircleCI config
 └── [all other directories]       # Pro licensed
-```
+```
-```
+```text
 react_on_rails/ (monorepo root)
 ├── lib/react_on_rails/           # Core Ruby code
 ├── packages/react-on-rails/      # Core NPM package
 ├── spec/ruby/react_on_rails/     # Core Ruby tests
 ├── spec/packages/react-on-rails/ # Core JS tests
 ├── docs/                         # Shared documentation
 ├── tools/                        # Shared development tools
 ├── .github/                      # Unified GitHub workflows
 └── [shared config files]         # Build configs, etc.
-```
+```
-```
+```text
 react_on_rails/ (monorepo root)
 ├── lib/react_on_rails_pro/       # Pro Ruby code
 ├── packages/react-on-rails-pro/  # Pro NPM package
 ├── packages/react-on-rails-pro-node-renderer/  # Pro Node renderer
 ├── spec/ruby/react_on_rails_pro/ # Pro Ruby tests
 ├── spec/packages/react-on-rails-pro/  # Pro JS tests
 └── spec/packages/react-on-rails-pro-node-renderer/  # Pro Node renderer tests
-```
+```

Also applies to: 33-40, 49-58, 63-70


9-16: Avoid “All directories are MIT” phrasing that’s contradicted by the exception

Reword to reduce confusion and align with the exception below.

-All directories in the `react_on_rails` repository are MIT licensed:
+Most directories in the `react_on_rails` repository are MIT licensed. The Pro-licensed exceptions are noted below:
docs/LICENSING_FAQ.md (1)

29-39: Add language hint to fenced directory tree

Add text to satisfy markdownlint and keep formatting consistent with LICENSE.md/DIRECTORY_LICENSING.md.

-```
+```text
 react_on_rails/ (monorepo root)
 ├── lib/
 │   ├── react_on_rails/           # MIT Licensed
 │   └── react_on_rails_pro/       # Pro Licensed
 ├── packages/
 │   ├── react-on-rails/           # MIT Licensed
 │   ├── react-on-rails-pro/       # Pro Licensed
 │   └── react-on-rails-pro-node-renderer/  # Pro Licensed
 └── LICENSE.md                    # Documents which directories use which license
-```
+```
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 39bd5bf and 55c349a.

📒 Files selected for processing (3)
  • LICENSE.md (2 hunks)
  • docs/DIRECTORY_LICENSING.md (1 hunks)
  • docs/LICENSING_FAQ.md (2 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
{Gemfile,Rakefile,**/*.{rb,rake,gemspec,ru,js,jsx,ts,tsx,json,yml,yaml,md,css,scss}}

📄 CodeRabbit inference engine (CLAUDE.md)

Ensure all committed files end with a trailing newline character

Files:

  • LICENSE.md
  • docs/DIRECTORY_LICENSING.md
  • docs/LICENSING_FAQ.md
**/*.{js,jsx,ts,tsx,json,yml,yaml,md,css,scss}

📄 CodeRabbit inference engine (CLAUDE.md)

Let Prettier handle all non-Ruby file formatting; never manually format these files

Files:

  • LICENSE.md
  • docs/DIRECTORY_LICENSING.md
  • docs/LICENSING_FAQ.md
🧠 Learnings (4)
📚 Learning: 2025-09-15T21:24:48.207Z
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1781
File: node_package/src/ClientSideRenderer.ts:82-95
Timestamp: 2025-09-15T21:24:48.207Z
Learning: In React on Rails, the force_load feature includes both explicit `data-force-load="true"` usage and the ability to hydrate components during the page loading state (`document.readyState === 'loading'`). Both capabilities require a Pro license, so the condition `!railsContext.rorPro && (isComponentForceLoaded || document.readyState === 'loading')` correctly gates both scenarios.

Applied to files:

  • LICENSE.md
  • docs/DIRECTORY_LICENSING.md
  • docs/LICENSING_FAQ.md
📚 Learning: 2025-02-12T16:38:06.537Z
Learnt from: Romex91
PR: shakacode/react_on_rails#1697
File: package-scripts.yml:28-28
Timestamp: 2025-02-12T16:38:06.537Z
Learning: The file `node_package/lib/ReactOnRails.full.js` is autogenerated during the build process and should not be present in the repository.

Applied to files:

  • docs/DIRECTORY_LICENSING.md
📚 Learning: 2025-04-26T21:55:55.874Z
Learnt from: alexeyr-ci2
PR: shakacode/react_on_rails#1732
File: spec/dummy/client/app-react16/startup/ReduxSharedStoreApp.client.jsx:40-44
Timestamp: 2025-04-26T21:55:55.874Z
Learning: In the react_on_rails project, files under `app-react16` directories are copied/moved to corresponding `/app` directories during the conversion process (removing the `-react16` suffix), which affects their relative import paths at runtime.

Applied to files:

  • docs/DIRECTORY_LICENSING.md
📚 Learning: 2025-02-18T13:08:01.477Z
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1644
File: lib/react_on_rails/helper.rb:190-197
Timestamp: 2025-02-18T13:08:01.477Z
Learning: RSC support validation in React on Rails Pro is handled through a chain of validations:
1. Pro version check in `run_stream_inside_fiber`
2. RSC support check during pack generation via `ReactOnRailsPro.configuration.enable_rsc_support`
3. RSC support validation during component registration
This makes additional validation in the helper methods unnecessary.

Applied to files:

  • docs/DIRECTORY_LICENSING.md
🪛 GitHub Actions: Lint JS and Ruby
docs/DIRECTORY_LICENSING.md

[error] 1-1: Prettier formatting check failed. File has formatting issues. Run 'prettier --write' to fix. Command: prettier --check .

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
  • GitHub Check: dummy-app-integration-tests (3.2, 20)
  • GitHub Check: dummy-app-integration-tests (3.4, 22)
  • GitHub Check: markdown-link-check
  • GitHub Check: rspec-package-tests (3.2, minimum)
  • GitHub Check: rspec-package-tests (3.4, minimum)
  • GitHub Check: rspec-package-tests (3.2, latest)
  • GitHub Check: rspec-package-tests (3.4, latest)
  • GitHub Check: claude-review
🔇 Additional comments (8)
docs/DIRECTORY_LICENSING.md (3)

22-27: LGTM: MIT-interface vs Pro usage distinction is clear and consistent

This matches the requested separation: MIT permits modification; Pro usage without license remains prohibited.

Please also ensure the same distinction appears (verbatim or close) in LICENSE.md and LICENSING_FAQ.md for consistency.


1-140: Format docs/DIRECTORY_LICENSING.md with Prettier and ensure trailing newline
Run npx prettier --write docs/DIRECTORY_LICENSING.md and confirm the file ends with a single trailing newline.


140-140: Referenced document exists; no update needed. The file docs/MONOREPO_MERGER_PLAN_REF.md is present and the relative link in docs/DIRECTORY_LICENSING.md is valid.

LICENSE.md (2)

20-23: LGTM: SPDX block uses a language hint and avoids markdownlint errors

The fenced SPDX block is now annotated with text and looks good.


73-77: Good: MIT modification rights preserved; Pro misuse called out

Wording avoids restricting MIT rights while clarifying Pro usage limits.

docs/LICENSING_FAQ.md (3)

98-100: LGTM: Clear separation of MIT modification rights vs Pro usage restrictions

This Q&A mirrors the agreed approach and aligns with LICENSE.md.

Also applies to: 111-111, 113-120


1-135: Run Prettier via npx and ensure trailing newline
Run npx prettier --write docs/LICENSING_FAQ.md (or your npm run format script) and commit the changes. Add a newline at the end of the file.


78-79: Verified referenced docs exist and links resolve
MONOREPO_MERGER_PLAN_REF.md and REACT-ON-RAILS-PRO-LICENSE.md are present at expected paths; relative links in docs/LICENSING_FAQ.md resolve correctly.

Comment on lines 12 to 17
The following directories and all their contents are licensed under the **MIT License** (see full text below):

## MIT License for Core React on Rails
- `lib/react_on_rails/` (excluding `lib/react_on_rails/pro/`)
- `node_package/src/` (excluding `node_package/src/pro/`)
- All other directories in this repository not explicitly listed as Pro-licensed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Consistency checks: align metadata and license text with docs

  • Confirm package.json license expression is acceptable to npm tooling.
  • Ensure Pro license text actually contains the “education/personal/non-production” allowance and anti-circumvention language referenced here.

Also applies to: 24-31, 66-77


🏁 Script executed:

#!/bin/bash
set -euo pipefail
# 1) Inspect package.json license fields across the repo
rg -n --type=json -H '"license"\s*:\s*' -C1

# 2) Validate that the Pro license file exists and includes key terms
fd -a '^REACT-ON-RAILS-PRO-LICENSE\.md$' -x realpath
rg -n --heading -C2 -e 'educational|classroom|personal|non-?production|evaluation' \
   -e 'anti[- ]?circumvent|circumvention|bypass|reverse engineer' \
   REACT-ON-RAILS-PRO-LICENSE.md

# 3) Cross-check that directories listed here match docs/DIRECTORY_LICENSING.md
echo "Dirs listed in LICENSE.md (MIT vs Pro):"
rg -n 'lib/react_on_rails/pro/|node_package/src/pro/' LICENSE.md
rg -n 'lib/react_on_rails/|node_package/src/' LICENSE.md
echo "Compare with DIRECTORY_LICENSING.md:"
rg -n 'lib/react_on_rails/pro/|node_package/src/pro/' docs/DIRECTORY_LICENSING.md
rg -n 'lib/react_on_rails/|node_package/src/' docs/DIRECTORY_LICENSING.md

Length of output: 188


🏁 Script executed:

#!/bin/bash
set -euo pipefail

# 1) List Pro license files in the repo
echo "Pro license files:"
fd -e md -g '*PRO-LICENSE.md'

# 2) Search for educational/personal/non-production and anti-circumvention terms in each Pro license file
echo
echo "Key terms in Pro license:"
for file in $(fd -e md -g '*PRO-LICENSE.md'); do
  echo "== $file =="
  rg -n --heading -C2 -e 'educational|classroom|personal|non-?production|evaluation' \
     -e 'anti[- ]?circumvent|circumvention|bypass|reverse engineer' "$file" || echo "  (no matches)"
  echo
done

# 3) Verify LICENSE.md directory listings
echo "LICENSE.md directory entries:"
rg -n -C1 'lib/react_on_rails' LICENSE.md
rg -n -C1 'node_package/src' LICENSE.md

# 4) Verify docs/DIRECTORY_LICENSING.md directory listings
echo
echo "docs/DIRECTORY_LICENSING.md directory entries:"
rg -n -C1 'lib/react_on_rails' docs/DIRECTORY_LICENSING.md
rg -n -C1 'node_package/src' docs/DIRECTORY_LICENSING.md

Length of output: 3429


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "1) License field context in package.json:"
rg -n -C2 '"license"\s*:' package.json || echo "license field not found"

echo
echo "2) Presence of custom license file reference:"
rg -n '"licenseFile"\s*:' package.json || echo "no \"licenseFile\" key"
rg -n '"licenseFilename"\s*:' package.json || echo "no \"licenseFilename\" key"

Length of output: 321


Sync package.json and LICENSE.md with SPDX expression and docs

  • Add "licenseFile": "REACT-ON-RAILS-PRO-LICENSE.md" to package.json so npm tooling resolves LicenseRef-Proprietary.
  • In LICENSE.md’s Pro section, replace lib/react_on_rails/pro/ with lib/react_on_rails_pro/ and add packages/node-renderer/ and packages/react-on-rails-pro/ to match docs/DIRECTORY_LICENSING.md.

@AbanoubGhadban
Copy link
Collaborator Author

@claude

  • Fix package.json License Field Problem
  • give examples of type of modifications at MIT files that cause pro code to run such as modifications of Licence Validation mechanisms:

License validation mechanisms include but are not limited to:

  • Runtime checks for valid Pro subscriptions
  • Authentication systems in lib/react_on_rails/utils.rb and Pro TypeScript modules
  • The react_on_rails_pro? method and rorPro field generation

Copy link

claude bot commented Sep 25, 2025

Claude finished @AbanoubGhadban's task —— View job


Implementation Complete ✅

Tasks Completed:

  • Read current package.json and LICENSE.md files
  • Understand the package.json license field issue from reviews
  • Fix package.json license field to use "SEE LICENSE IN LICENSE.md"
  • Add examples of license validation mechanisms to LICENSE.md
  • Commit and push changes

Changes Made:

1. package.json

  • Changed license field from "MIT AND LicenseRef-Proprietary" to "SEE LICENSE IN LICENSE.md"
  • This provides better compatibility with npm tooling while still directing users to the proper license documentation

2. LICENSE.md

  • Added new section "License Validation Mechanisms" with:
    • Clear description of what license validation mechanisms are (runtime checks, authentication systems, react_on_rails_pro? method, rorPro field generation)
    • Specific examples of prohibited modifications that would constitute unauthorized Pro feature use:
      • Modifying lib/react_on_rails/helper.rb to bypass react_on_rails_pro? checks
      • Altering lib/react_on_rails/utils.rb to change the rorPro field generation logic
      • Tampering with Pro feature detection in MIT-licensed interface files (clientStartup.ts, serverRenderReactComponent.ts, ReactOnRails.client.ts, ReactOnRails.node.ts)
      • Removing or bypassing license validation calls before accessing Pro features
    • Clear statement reinforcing that MIT modifications are allowed under MIT terms, but using them to access Pro features violates the Pro License

Commit:

  • ✅ Committed as: a22230b
  • ✅ Pushed to: license/update-add-audit-indemnification-export-etc

Branch: license/update-add-audit-indemnification-export-etc | Job Run

…xamples

- Changed package.json license field to 'SEE LICENSE IN LICENSE.md' for better npm tooling compatibility
- Added 'License Validation Mechanisms' section to LICENSE.md with:
  - Description of what license validation mechanisms are (runtime checks, authentication systems, etc.)
  - Specific examples of prohibited modifications (helper.rb, utils.rb, interface files)
  - Clear statement that MIT modifications are allowed but using them to access Pro features violates the Pro License

Co-authored-by: Abanoub Ghadban <[email protected]>
Copy link

claude bot commented Sep 25, 2025

Code Review - PR #1823

This PR strengthens the legal framework with important additions. However, I've identified several issues:

Critical Issues

1. Invalid package.json License Field

Location: package.json:121
The value "SEE LICENSE IN LICENSE.md" is not a valid SPDX license identifier and will cause issues with NPM registries, automated license scanners, and corporate compliance tools. Recommend using proper SPDX syntax like "(MIT AND LicenseRef-LICENSE)".

2. Potential MIT License Conflict

Location: LICENSE.md:75-76
The statement "Modifying MIT-licensed interface files is permitted under MIT terms, However, using those modifications to access Pro features without a valid license violates the Pro License" creates a legal gray area. The MIT license grants unrestricted modification rights without limitation. Attempting to restrict how MIT-licensed code is used may not be legally enforceable. Consider: (A) Moving all Pro-calling logic into Pro-licensed files, (B) Dual-licensing the interface files, or (C) Consulting an IP attorney for stronger legal language.

Medium Priority Issues

3. Hardcoded File References

Location: LICENSE.md:88-91
Specific filenames (clientStartup.ts, etc.) in legal text create maintenance burden. Files may be renamed/moved. Recommend generic language instead.

4. No License Version Changelog

Version bumped from 2.0 to 2.1 without documenting what changed. Organizations need to track legal obligation changes.

5. Undefined "Material" in Audit Costs

"Material unauthorized use" is undefined and could lead to disputes. Recommend defining threshold (e.g., exceeding 10% of capacity or 000).

Positive Aspects

  • Anti-circumvention clauses (Section 5, items 4-7) are strong
  • Audit provisions (9.1) are standard and reasonable
  • Indemnification and export compliance strengthen enforceability
  • Clear separation of MIT vs Pro code
  • Helpful examples of prohibited modifications

Recommendations

  • Do not merge until fixing critical package.json issue
  • Strongly recommend consulting IP attorney on MIT/Pro boundary before merging
  • Consider adding tests to verify license validation mechanisms work
  • Add license version changelog

The direction is sound and additions are professional. Would you like me to propose specific fixes?

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
package.json (1)

88-90: Include Pro license files in published npm package
Add both LICENSE.md and REACT-ON-RAILS-PRO-LICENSE.md to the files array in package.json to ensure the Pro license text is shipped and avoid broken references:

 "files": [
-  "node_package/lib"
+  "node_package/lib",
+  "LICENSE.md",
+  "REACT-ON-RAILS-PRO-LICENSE.md"
 ],
🧹 Nitpick comments (1)
package.json (1)

121-121: License field change is acceptable; verify tooling compatibility

Switching to "SEE LICENSE IN LICENSE.md" resolves the invalid SPDX issue and is accepted by npm. Please verify that publint and your release pipeline don’t warn on this format. If you need SPDX compatibility, consider the alternative below.

Alternative SPDX option (only if required by your tooling):

-  "license": "SEE LICENSE IN LICENSE.md",
+  "license": "MIT AND LicenseRef-Proprietary",

If you adopt the SPDX option, add an SPDX marker to REACT-ON-RAILS-PRO-LICENSE.md (it likely already exists) and keep LICENSE.md as the canonical explainer.

Run locally to confirm no warnings:

  • npx publint
  • npm pack --dry-run
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 55c349a and a22230b.

📒 Files selected for processing (2)
  • LICENSE.md (2 hunks)
  • package.json (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
{Gemfile,Rakefile,**/*.{rb,rake,gemspec,ru,js,jsx,ts,tsx,json,yml,yaml,md,css,scss}}

📄 CodeRabbit inference engine (CLAUDE.md)

Ensure all committed files end with a trailing newline character

Files:

  • LICENSE.md
  • package.json
**/*.{js,jsx,ts,tsx,json,yml,yaml,md,css,scss}

📄 CodeRabbit inference engine (CLAUDE.md)

Let Prettier handle all non-Ruby file formatting; never manually format these files

Files:

  • LICENSE.md
  • package.json
🧠 Learnings (3)
📚 Learning: 2025-09-15T21:24:48.207Z
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1781
File: node_package/src/ClientSideRenderer.ts:82-95
Timestamp: 2025-09-15T21:24:48.207Z
Learning: In React on Rails, the force_load feature includes both explicit `data-force-load="true"` usage and the ability to hydrate components during the page loading state (`document.readyState === 'loading'`). Both capabilities require a Pro license, so the condition `!railsContext.rorPro && (isComponentForceLoaded || document.readyState === 'loading')` correctly gates both scenarios.

Applied to files:

  • LICENSE.md
📚 Learning: 2025-02-18T13:08:01.477Z
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1644
File: lib/react_on_rails/helper.rb:190-197
Timestamp: 2025-02-18T13:08:01.477Z
Learning: RSC support validation in React on Rails Pro is handled through a chain of validations:
1. Pro version check in `run_stream_inside_fiber`
2. RSC support check during pack generation via `ReactOnRailsPro.configuration.enable_rsc_support`
3. RSC support validation during component registration
This makes additional validation in the helper methods unnecessary.

Applied to files:

  • LICENSE.md
📚 Learning: 2025-02-12T16:38:06.537Z
Learnt from: Romex91
PR: shakacode/react_on_rails#1697
File: package-scripts.yml:28-28
Timestamp: 2025-02-12T16:38:06.537Z
Learning: The file `node_package/lib/ReactOnRails.full.js` is autogenerated during the build process and should not be present in the repository.

Applied to files:

  • package.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
  • GitHub Check: dummy-app-integration-tests (3.4, 22)
  • GitHub Check: dummy-app-integration-tests (3.2, 20)
  • GitHub Check: claude-review
  • GitHub Check: rspec-package-tests (3.4, latest)
  • GitHub Check: rspec-package-tests (3.2, latest)
  • GitHub Check: rspec-package-tests (3.2, minimum)
  • GitHub Check: rspec-package-tests (3.4, minimum)
  • GitHub Check: markdown-link-check
  • GitHub Check: build
🔇 Additional comments (6)
LICENSE.md (6)

3-7: Clear dual-licensing intro — LGTM


20-22: Pro SPDX marker block — LGTM


29-33: Pro usage statement — LGTM


80-85: License validation mechanisms list — LGTM


86-94: Prohibited modifications + MIT clarification — LGTM; keep this ordering

Examples are concrete and the concluding clarification resolves prior MIT-rights conflict.

Optionally add the same SPDX marker (“SPDX-License-Identifier: LicenseRef-Proprietary”) at the top of REACT-ON-RAILS-PRO-LICENSE.md for tooling consistency.


71-77: Confirmed free-use allowances match Pro license
REACT-ON-RAILS-PRO-LICENSE.md includes the same educational, personal, and non-production use provisions, so terms are aligned.

AbanoubGhadban and others added 2 commits September 25, 2025 17:09
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
@AbanoubGhadban
Copy link
Collaborator Author

@claude fixing package.json licence issue

Copy link

claude bot commented Sep 25, 2025

Claude finished @AbanoubGhadban's task —— View job


Package.json License Issue - Already Fixed ✅

Summary:

The package.json license field issue has already been resolved in commit a22230b.

Current Status:

  • package.json license field: "SEE LICENSE IN LICENSE.md" (line 121)
  • LICENSE.md includes comprehensive dual-licensing documentation
  • ✅ License validation mechanisms documented with specific examples
  • ✅ Clear distinction between MIT modification rights and Pro usage restrictions

What Was Fixed:

  1. package.json (commit a22230b):

    • Changed from invalid SPDX expression to "SEE LICENSE IN LICENSE.md"
    • This format is npm-compatible and directs users to the proper license documentation
  2. LICENSE.md (commits a22230b, c98118b, f408946):

    • Added clear license scope section distinguishing MIT vs Pro directories
    • Included SPDX identifier for Pro code: LicenseRef-Proprietary
    • Added "License Validation Mechanisms" section with specific examples
    • Listed prohibited modifications (helper.rb, utils.rb, interface files)
    • Clarified that MIT modifications are allowed but using them to access Pro features violates the Pro License

No further action needed - the issue identified in code reviews has been fully addressed.


Branch: license/update-add-audit-indemnification-export-etc

Copy link

claude bot commented Sep 25, 2025

Code Review: Licensing Vulnerability Fixes and Legal Protections

I've reviewed PR #1823 which addresses licensing vulnerabilities and strengthens the freemium model's legal protections.

✅ Strengths

1. Comprehensive Legal Coverage

  • Added strong anti-circumvention language in both LICENSE.md and REACT-ON-RAILS-PRO-LICENSE.md
  • Specific enumeration of prohibited modifications (items 4-7 in Section 5) provides clear legal boundaries
  • Detailed audit provisions (Section 9.1) enable enforcement
  • Standard commercial license provisions strengthen enforceability

2. Clear Documentation

  • LICENSE.md now clearly distinguishes MIT vs Pro scope with explicit directory listings
  • Added concrete examples of prohibited modifications
  • LICENSING_FAQ.md and DIRECTORY_LICENSING.md updates improve clarity

3. Correct package.json License Field

  • Changed to 'SEE LICENSE IN LICENSE.md' accurately reflects dual licensing
  • This is the correct SPDX-compliant way to reference a custom/dual license file

4. Formatting Compliance

  • All files end with newline characters as required
  • Markdown formatting appears consistent

Copy link

claude bot commented Sep 25, 2025

⚠️ Concerns & Recommendations

1. Legal Enforceability Concerns

The anti-circumvention language may have limited practical enforceability:

  • Technical Reality: License validation in open-source code can be bypassed by determined actors regardless of legal language
  • MIT License Conflict: LICENSE.md states modifying MIT-licensed interface files is permitted but then restricts using those modifications - this creates legal tension
  • Enforceability: Cost/benefit analysis for small-scale violations may not be favorable

Recommendation: Consider whether technical solutions (runtime license verification, server-side validation) might be more effective than purely legal restrictions.

2. Inconsistency: Pro Code Location

LICENSE.md lists lib/react_on_rails/pro/ as Pro-licensed. Does this directory actually exist in this repository?

3. SPDX Identifier Issue

LICENSE.md uses SPDX-License-Identifier: LicenseRef-Proprietary in a fenced code block. SPDX identifiers should typically be in file headers, not in LICENSE documentation.

4. Version Bump Rationale

REACT-ON-RAILS-PRO-LICENSE.md was updated from v2.0 to v2.1. Are existing subscribers automatically bound by v2.1? The additions are material changes to subscriber obligations.

Recommendation: Consider grandfathering existing subscribers under v2.0 and requiring explicit acceptance of v2.1 for renewals.

Copy link

claude bot commented Sep 25, 2025

5. Redundancy in LICENSE.md

Lines 80-94 list License Validation Mechanisms and Examples of prohibited modifications in great detail. This level of specificity might:

  • Create an exhaustive list problem (hackers find methods not listed)
  • Require frequent updates as codebase evolves
  • Be better suited for documentation than a license file

Recommendation: Consider more general language like 'any attempt to circumvent license validation' rather than specific file examples.

🔍 Security Considerations

1. Security Through Obscurity

This PR attempts to prevent license circumvention through legal threats rather than technical measures. This is fundamentally security through obscurity, which is generally considered weak.

Recommendation: Consider:

  • Server-side license validation that cannot be bypassed
  • Online license key validation (like many commercial software)
  • Feature flags controlled by backend services
  • Obfuscation or code signing for Pro features

2. Threat Model

The PR description mentions preventing hackers but the actual threat model seems to be legitimate users trying to avoid paying for Pro features, not external attackers or actual security vulnerabilities.

Recommendation: Be clear about the threat model - this is anti-piracy, not security hardening.

Copy link

claude bot commented Sep 25, 2025

🎯 Final Recommendations

  1. Legal Review: Have an attorney specializing in software licensing review v2.1 before deployment
  2. Transition Plan: Define how existing subscribers transition to v2.1
  3. Technical Enforcement: Complement legal protections with technical measures
  4. Simplify LICENSE.md: Remove overly specific examples of prohibited modifications
  5. Clarify Pro Code Existence: Verify all listed Pro directories actually exist
  6. SPDX Cleanup: Either use SPDX correctly or remove the identifier

✅ Approval Status

Conditionally Approve pending:

  1. Legal counsel review of v2.1 changes
  2. Clarification on whether lib/react_on_rails/pro/ exists in this repo
  3. Decision on how existing subscribers are affected
  4. Resolution of MIT vs Pro modification conflict

The changes are well-intentioned and improve license clarity, but some legal and practical considerations need addressing before merging.

📊 Summary

  • Performance Impact: None (documentation only)
  • Test Coverage: No tests needed (documentation only)
  • Code Quality: Excellent documentation quality
  • Security: Addresses anti-piracy via legal language; recommend complementing with technical measures
  • Breaking Changes: Potentially for existing Pro subscribers (v2.1 license changes)

Note: I'm providing technical and structural feedback. For legal advice, please consult with a licensed attorney.

…line the document and focus on the core licensing terms.
Copy link

claude bot commented Sep 25, 2025

Code Review - PR #1823

Summary

This PR addresses licensing concerns for the freemium model. Important intent, but several issues need resolution before merging.


Critical Issues

1. package.json License Field - NPM Standards Violation (line 121)

Current: "SEE LICENSE IN LICENSE.md"
Should be: Valid SPDX expression like "(MIT AND LicenseRef-ProLicense)"

NPM tooling expects valid SPDX identifiers. The current format is deprecated and may cause package manager warnings.

2. Legal Language Enforceability Concerns (LICENSE.md:84-89)

The PR lists MIT-licensed files (clientStartup.ts, etc.) then prohibits their modification. This contradicts MIT license terms which explicitly grant unrestricted modification rights.

Legal Risk: Cannot add restrictions to MIT code that contradict the MIT license itself.

Recommendation: Consult IP counsel, or move interface files to Pro license, or rely solely on Pro directory protection.

3. Missing Trailing Newline (LICENSE.md:92)

File lacks trailing newline - violates CLAUDE.md requirement and will fail CI.


Major Concerns

4. No Test Coverage
PR modifies critical licensing docs but includes no tests for license validation mechanisms.

5. Overly Broad Anti-Circumvention (REACT-ON-RAILS-PRO-LICENSE.md:55-58)
New restrictions could prohibit legitimate debugging and testing. Add exceptions for good-faith development activities.

6. Audit Rights Undefined Terms (REACT-ON-RAILS-PRO-LICENSE.md:92-93)

  • "Material unauthorized use" undefined
  • No cap on audit costs
  • No dispute resolution

Strengths

  1. Clear license scope (LICENSE.md:8-27)
  2. Educational use provisions
  3. Proper versioning (2.0 to 2.1)
  4. Comprehensive legal sections
  5. Consistent documentation

Pre-Merge Checklist

  • CRITICAL: Fix package.json SPDX format
  • CRITICAL: Add trailing newline to LICENSE.md
  • CRITICAL: Run bundle exec rubocop
  • Legal review of MIT+Pro interaction language
  • Define materiality threshold for audits
  • Add anti-circumvention exceptions
  • Add test coverage
  • Verify cross-references

Recommendation

DO NOT MERGE until critical issues resolved:

  1. package.json SPDX compliance
  2. Trailing newline added
  3. Legal review of MIT/Pro interaction
  4. Linting passes

Generated with Claude Code

Copy link

claude bot commented Sep 25, 2025

Code Review: Licensing Updates

I've reviewed PR #1823 and have the following feedback:

Strengths

  1. Clear License Separation: The updated LICENSE.md does an excellent job of clearly delineating MIT vs Pro-licensed code with specific directory paths.

  2. Improved Documentation: The FAQ additions (lines 113-119 in LICENSING_FAQ.md) effectively address the "can I modify interface files?" question, which is crucial for the freemium model.

  3. Proper NPM Compatibility: Changing package.json license to 'SEE LICENSE IN LICENSE.md' is the correct approach for dual-licensed packages.

  4. Comprehensive Legal Protections: The Pro license updates add important protections (items 4-7 in Section 5, audit provisions in 9.1, indemnification, export compliance).

⚠️ Potential Issues & Concerns

1. Legal Clarity - MIT License Conflict (CRITICAL)

The LICENSE.md contains a potential legal contradiction:

  • Lines 73-74: "Modifying MIT-licensed interface files is permitted under MIT terms"
  • Lines 78-84: Describes "License Validation Mechanisms" and prohibits modifications to access Pro features

Issue: The MIT License explicitly grants "without restriction" modification rights. You cannot add restrictions to MIT-licensed code. This creates enforceable legal ambiguity.

Recommendation: Consult with IP counsel. Consider either:

  • Making the interface files proprietary (but this breaks OSI compliance)
  • Accepting that MIT code can be modified freely, and rely solely on copyright protection for the Pro code itself
  • Using a different open-source license (e.g., LGPL) that better supports your model

2. Enforcement Practicality

Lines 78-84 mention specific files (utils.rb, rorPro field) but the PR description claims these were removed for "streamlining" (commit 37d1f26). This inconsistency could create confusion.

Recommendation: Either keep specific examples or remove them entirely - but be consistent.

3. Version Bump

REACT-ON-RAILS-PRO-LICENSE.md bumps from 2.0 to 2.1, but there's no changelog or migration guide for existing Pro customers.

Recommendation: Add a changelog section or migration notes explaining what changed and whether existing customers need to re-accept terms.

4. Audit Provision Scope

Section 9.1 allows "in-person visits during regular business hours" which may be too invasive for some organizations, especially startups or remote teams.

Recommendation: Consider limiting to electronic audits unless fraud is suspected.

5. Missing Trailing Newlines (Per CLAUDE.md)

According to your CLAUDE.md, all files must end with a newline. Verification needed.

📋 Test Coverage

N/A - These are documentation-only changes. However, consider adding:

  • Automated license header checks in CI
  • Script to verify directory classifications match LICENSE.md
  • Test that verifies package.json license field

🔒 Security Concerns

No immediate security issues, but:

  • Ensure license validation code itself is well-tested and secure
  • Consider obfuscation or server-side validation to prevent trivial bypasses
  • Monitor for public discussions about circumvention

🎯 Best Practices

  • ✅ Comprehensive legal language
  • ✅ Clear directory structure
  • ⚠️ Legal review strongly recommended before merging
  • ⚠️ Consider customer communication plan for license changes

📝 Minor Issues

  1. DIRECTORY_LICENSING.md line 15: Says node_package/src/pro/ is "Pro licensed" but the structure suggests lib/react_on_rails/pro/ might also exist - ensure consistency
  2. Formatting: Verify all files pass bundle exec rubocop per CLAUDE.md requirements

Recommendation

Do not merge without legal review - The MIT license restriction issue is a significant legal concern that should be addressed by qualified IP counsel before release.

Otherwise, the documentation improvements are excellent and the Pro license enhancements are comprehensive.

@AbanoubGhadban AbanoubGhadban merged commit 58d7404 into master Sep 25, 2025
16 checks passed
@AbanoubGhadban AbanoubGhadban deleted the license/update-add-audit-indemnification-export-etc branch September 25, 2025 14:23

- **MIT-licensed interface files** (outside `pro/` directories) can be freely modified under MIT terms
- **Using those modifications to access Pro features** without a license violates the Pro License
- **Pro-licensed files** (inside `pro/` directories) require a Pro license to use in any way
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"in any way."
@claude can we change this to add:

"Note, ShakaCode offers FREE licenses for educational and demonstration purposes."

Copy link

@claude claude bot Sep 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude finished @justin808's task —— View jobclaude/pr-1823-20250925-2106 • [Create PR ➔](https://github.com/shakacode/react_on_rails/compare/master...claude/pr-1823-20250925-2106?quick_pull=1&title=PR%20%231823%3A%20Changes%20from%20Claude&body=This%20PR%20addresses%20pr%20%231823%0A%0AGenerated%20with%20%5BClaude%20Code%5D(https%3A%2F%2Fclaude.ai%2Fcode)


✅ Task Completed

  • Read docs/DIRECTORY_LICENSING.md to understand context
  • Add the educational/demonstration license note at line 28
  • Commit and push the change

Summary

Successfully added the note about free educational and demonstration licenses to docs/DIRECTORY_LICENSING.md at line 28. The text now reads:

Pro-licensed files (inside pro/ directories) require a Pro license to use in any way. Note, ShakaCode offers FREE licenses for educational and demonstration purposes.

This clarification helps users understand that while Pro features require a license, ShakaCode offers free options for educational and demonstration use cases.


Branch: claude/pr-1823-20250925-2106 |

**A:** We maintain two separate repositories:

- **react_on_rails** (MIT) - Core functionality, completely free except pro directories as stated in LICENSE.md
- **react_on_rails** (MIT + Pro) - Core functionality is MIT-licensed and completely free. Pro features (in `pro/` directories) are Pro-licensed and require a subscription for production use
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing period.

Add:

Note, ShakaCode offers FREE licenses for educational and demonstration purposes.

@justin808
Copy link
Member

@AbanoubGhadban added a couple super minor comments. GREAT JOB!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants