Request: cleanly separate Enterprise Edition code from the MIT core (plugin or ee/ boundary)

[sheikh-chili]

Summary

First, thank you for Medusa. The v2 architecture (modules, workflows, the module SDK) is excellent, and I fully understand the need to fund the project through commercial offerings. This request is not about whether Enterprise features should exist, but about how they are packaged, so the MIT core stays something the community can install, fork, and contribute to with confidence.

Since v2.19.0 (#16110), the repository is dual-licensed: MIT except for the Enterprise Materials listed in ENTERPRISE-LICENSE.md. Thank you for publishing an explicit path list and for stating that earlier versions remain under MIT — that transparency is appreciated. The concern is that the Enterprise Materials are interleaved with the MIT core rather than separated from it.

Observations

1. Enterprise files live inside core packages. The list has more than 40 paths spread across packages/core/framework, core-flows, types, utils, js-sdk, packages/medusa, and packages/admin/dashboard, not only in packages/modules/rbac and packages/modules/providers/auth-oidc.

2. MIT entry points re-export Enterprise files. For example, on develop:

   MIT file	Re-exports (Enterprise)
   packages/core/framework/src/index.ts	./policies
   packages/core/framework/src/http/middlewares/index.ts	./check-permissions
   packages/core/utils/src/modules-sdk/index.ts	./define-policies, ./policy-to-types
   packages/core/core-flows/src/index.ts	./rbac
   packages/core/core-flows/src/user/workflows/index.ts	assign-user-roles, get-assignable-roles, …
   packages/core/types/src/index.ts	./rbac
   packages/core/js-sdk/src/admin/index.ts	RbacRole, RbacPolicy

   Removing the Enterprise paths therefore breaks the MIT build.

3. No MIT-only npm artifact exists. Because compiled forms of Enterprise files are also Enterprise Materials, and the core packages bundle them, installing @medusajs/framework, @medusajs/utils, @medusajs/core-flows, @medusajs/types, or @medusajs/js-sdk (≥ 2.19) appears to deliver Enterprise code to every user, including users who never enable an Enterprise feature.

4. License enforcement is moving into MIT code paths. The open PR chore(medusa,utils,modules-sdk,rbac,auth-oidc,test-utils,types): add license key checks #16678 adds license-key verification (including a remote check) to packages/core/utils, the modules-sdk loader, and the medusa build / medusa start commands.

Why this matters to the community

• Forking and self-hosting: a fork that wants to stay MIT-only must filter files one by one and patch MIT entry points on every upstream release.
• Contributing: contributors to core packages must check, file by file, which license applies, and whether a fix to an MIT file that imports Enterprise code is still MIT-only work.
• Compliance: license scanners used in procurement and audits flag the core packages ("license": "SEE LICENSE IN LICENSE"), even for MIT-only usage.
• Ambiguity: it is unclear whether shipping the published packages with Enterprise features disabled requires a commercial agreement, since the notice also covers reproduction and distribution.

Proposed options (any of these would resolve most concerns)

Option A — Enterprise as separate plugin/module packages (preferred).
Medusa's module and plugin system seems designed for exactly this. For example, @medusajs/rbac and @medusajs/auth-oidc would ship as Enterprise packages, and the admin RBAC routes would ship as an admin extension. Core would keep only small, MIT-licensed, documented extension points (for example, a permission-check hook interface, a policy-registration API, and a login-provider slot). Then core installs, builds, and runs with zero Enterprise code, and Enterprise users simply add the packages.

Option B — A single ee/ boundary in the monorepo.
If keeping Enterprise code in-repo is important, place all of it under one top-level ee/ directory (an established open-core convention). Add a CI job that deletes ee/ and verifies that the core builds and tests pass, so the boundary cannot erode.

Option C — MIT-only published builds.
Ensure the published core packages contain no Enterprise code (Enterprise code ships only in Enterprise packages), so npm install of the core is unambiguously MIT.

Option D — Keep licensing mechanics out of MIT code paths.
Keep license verification (#16678) inside the Enterprise packages only. Define behavior for offline and air-gapped deployments, and ensure MIT-only installs never perform remote license checks.

RBAC code from v2.18.0 and earlier

RBAC existed in the repository under MIT up to and including v2.18.0. Some clarifications would help users who depend on that code:

1. Status of the MIT code: please confirm that the v2.18.0 (and earlier) RBAC code remains MIT permanently and may be forked, modified, and maintained by the community.
2. Security fixes: if a security issue is found in Enterprise RBAC that also exists in the v2.18.0 MIT RBAC, will it be disclosed (for example, via a GitHub Security Advisory) so MIT users can patch their copies?
3. Maintenance branch: would Medusa accept, or at least not object to, a community-maintained MIT branch or package of the v2.18.0-era RBAC, with bug fixes contributed independently of the Enterprise implementation?
4. Earlier community contributions: how are community contributions made to RBAC files while they were MIT treated going forward?
5. Possible middle ground: a basic MIT RBAC (roles and permissions) in core, with advanced RBAC (field-level filtering, policy authoring, etc.) as Enterprise. Many open-core projects draw the line this way.

Clarifications requested

• Is installing the published core packages (≥ 2.19) without enabling any Enterprise feature permitted without a commercial agreement?
• Will future additions to the Enterprise path list be announced in release notes or a changelog, so downstream users can track the boundary?
• Will the MIT integration points ("register, configure, export, or display availability") remain MIT and stable, so third parties can build alternative RBAC/SSO modules?

Closing

Clean separation would make the core easier to adopt and contribute to, make Enterprise easier to reason about and buy, and remove any perception that the MIT core is "open only on paper". Thank you for considering it. I am happy to help test a separation proposal if useful.

[al-gerasimov]

Following up, since this request received no response and the opposite direction has shipped since.

#16678 (license key checks) was merged on 16 Oct and released in v2.22.1 on 23 Oct. Concretely, in the published 2.22.1 packages:

• @medusajs/modules-sdk is still published as "license": "MIT", yet its module loader now hard-codes a list of packages that are refused unless a license covers them (dist/loaders/utils/load-internal.js, lines 12–27 and 122–132: Modules.RBAC, @medusajs/auth-oidc, @medusajs/medusa/auth-oidc). The enforcement mechanism for proprietary features lives inside an MIT package, exactly what Option D asked to avoid.
• The verifier itself, with an embedded public key, ships in @medusajs/utils (dist/license/index.js, MEDUSA_LICENSE_KEY / MEDUSA_LICENSE_PUBLIC_KEY). @medusajs/utils, framework, core-flows, types, js-sdk and medusa are all "SEE LICENSE IN LICENSE": every project that runs npm install on Medusa ≥ 2.19 receives proprietary code, whether or not it ever uses an Enterprise feature.
• The effect for existing users: RBAC, which was MIT up to v2.18.0 and is what makes route policies such as capture:create mean anything, no longer loads without a key. Upgrading from 2.20 to 2.22 removed a security control from an MIT install with no deprecation path, migration note or MIT alternative.

To be clear, nobody here disputes Medusa's right to sell Enterprise features. The problem is twofold.

RBAC is not an Enterprise feature. Separating "who may view orders" from "who may capture a payment" is basic hygiene for any shop with more than one admin. A store with two staff members needs it as much as a corporation does. SSO and advanced policy authoring can be Enterprise; basic roles and permissions belong in the core every Medusa store runs on.

The packaging is inadequate. Shipping licensed code and license enforcement inside packages the community installs as its MIT core is not an adequate way to do open core:

• Compliance teams can no longer approve a plain Medusa install without legal review.
• A fork cannot stay MIT-only without patching core entry points on every release.
• Contributors cannot tell which license their changes to core packages fall under.

Our options today are buying a license for a basic security control, re-implementing permissions ourselves, or freezing at 2.18. None of these is what "MIT core" led us to expect.

We'd ask the team to answer the original questions, in particular:

1. Is installing the published core packages without enabling any Enterprise feature permitted without a commercial agreement?
2. Will license enforcement move out of modules-sdk and the other MIT and core packages into the Enterprise packages (Option A or D)?
3. Will v2.18-era RBAC remain usable and maintainable as MIT, or will a basic MIT RBAC return to core?

A clear boundary (separate Enterprise packages, or an ee/ directory with a CI check that core builds without it) would resolve this for everyone.