License issue by indirectly depending on nodebox via sandpack

[mauricedoepke]

MDX editor integrates sandpack within the main package and sandpack dependes on nodebox:
https://github.com/Sandpack/nodebox-runtime?tab=License-1-ov-file

Nodebox has a proprietary custom license which forbids commercial use.

The problem is nodebox allways gets installed when installing mdx editor. Tree shaking will probably kick it out when not used, but thats not 100% sure.

This can theoretically lead to possible legal issues for everyone using it commercially.

[petyosi]

Agreed. The right way to handle that would be to break the editor plugins into multiple packages, which is quite the effort (monorepo setup, etc).

Apart from that, I am not a lawyer, but my guess is that, unless you use the plugin, you should not be under a trouble. Still, not a good thing.

[Puneet3125]

MDX editor depends on Sandpack, which installs nodebox—a package with a proprietary license that forbids commercial use. Since nodebox is always installed, this could cause legal issues.

What’s the recommended way to avoid installing or using nodebox with MDX editor?
Which features or functionality will be lost if nodebox is removed or excluded?

[mauricedoepke]

@Puneet3125

We created a fork of it where we deleted all functionality that directly or indirectly referenced nodebox.

[jazeee]

I'll upvote this issue.
I'd need to also address this risk.
Forking works, but then we'd have to keep it in sync. Meh, but not great for long term commercial use.

Another option could be to use resolutions with https://www.npmjs.com/package/noop-package or similar like https://www.npmjs.com/package/invalid-syntax

  "resolutions": {
    "sandpack": "npm:invalid-syntax@1.0.0"
  }

As far as this repo is concerned, it doesn't look hard to remove sandpack, and it seems like it should be moved to a separate repo as an isolated plugin.

[jazeee]

I'll add another aspect. This mdx-editor package is licensed as MIT, which obscures the sandpack license specifications and appears to cause a conflict.
This package's license would likely have to be changed to explicitly state that it contains code with this conflicting license, and also inform users that the conflicting license are subject to non-commercial usage.

I wonder if, instead, the offending package (@codesandbox/sandpack-react) can be moved from dependencies to peerDependencies with peerDependenciesMeta. Doing so could help reduce the risk for commercial usage, since only those who use the sandpack package can opt-in.

  "peerDependencies": { 
    "@codesandbox/sandpack-react": "^2.20.0",
  },
  "peerDependenciesMeta": {
    "@codesandbox/sandpack-react": {
      "optional": true
    }
  }

peerDependenciesMeta Documentation

[jazeee]

#904 may be the right solution for this, without a major refactor.

• Move package from dependencies to peerDependencies, and add to devDependencies
• Make it optional via peerDependenciesMeta

[johan-bytecat]

MDX editor depends on Sandpack, which installs nodebox—a package with a proprietary license that forbids commercial use. Since nodebox is always installed, this could cause legal issues.

What’s the recommended way to avoid installing or using nodebox with MDX editor? Which features or functionality will be lost if nodebox is removed or excluded?

It being installed is enough of a problem because you end up distributing the package. In our project we use a "overrides" in our package.json to point to a local "stubbed out" version:

  "overrides": {
    "@codesandbox/nodebox": "$@codesandbox/nodebox"
  }

We had to stub a couple of things but the core is really just throwing an exception if MDXEditor tries to instantiate the plugin:

'use strict';

class Nodebox {
    constructor() {
        throw new Error(
            '@codesandbox/nodebox is stubbed in this build; the Sandpack node runtime is disabled.',
        );
    }
}

exports.INJECT_MESSAGE_TYPE = '@codesandbox/nodebox/inject';
exports.PREVIEW_LOADED_MESSAGE_TYPE = '@codesandbox/nodebox/preview-loaded';
exports.Nodebox = Nodebox;

We didn't have any problems (yet), but we didn't rely or actual this plugin.