Licensing: 12.2.0 bundles MPL-licensed `edge-runtime`

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

❯ npx --no-install next info

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Enterprise
Binaries:
  Node: 16.15.1
  npm: 8.13.2
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 12.2.1-canary.5
  eslint-config-next: 12.2.0
  react: 16.14.0
  react-dom: 16.14.0

What browser are you using? (if relevant)

n/a

How are you deploying your application? (if relevant)

n/a

Describe the Bug

#37024 introduced new bundled dependencies on edge-runtime and @edge-runtime/primitives, which are both licensed under MPLv2. This is a breaking change; it introduces new required work and legal review for anyone redistributing Next-generated code which includes elements of these dependencies.

Expected Behavior

Next.js shouldn’t bundle dependencies with more copyleft encumbrances than Next.js itself claims to have - it’s misleading.

If it must bundle these dependencies and the dependencies can’t be licensed more permissively, it should:

• Document clearly that it’s doing so
• Include the full text of the relevant license somewhere in the bundle
• Hold the addition of the dependencies for a breaking change release

Link to reproduction

n/a

To Reproduce

> cat node_modules/next/dist/compiled/@edge-runtime/primitives/package.json
{"name":"@edge-runtime/primitives","version":"1.1.0-beta.10","main":"./index.js","license":"MPLv2"}

> cat node_modules/next/dist/compiled/edge-runtime/package.json
{"name":"edge-runtime","main":"index.js","license":"MPLv2"}

[dbjorge]

Hi Lee,

Thanks for looking into this issue! With respect, I’d prefer to keep this discussion in the public issue tracker; it affects all Next.js users, not just me or my team.

The issue is not related to the compatibility of the MIT and MPLv2 licenses with one another; I agree that they can be used together in the same larger program.

The issue is that the possibility of MPLv2-licensed code appearing in the output we distribute imposes new legal requirements on us as users, regardless of whether most of the project is MIT licensed, and the new licensing requirements:

• Were not communicated as part of the release notes for 12.2.0
• Are not clearly communicated in as part of Next.js’s documentation, license.md, or the outer package’s package.json
• Represent a breaking change (because we must make changes to our consuming project to meet the new requirements), but were released outside of a major version bump

Specifically, if I were publishing a personal site based on Next.js, my personal interpretation of the MPL’s section 3.2 is that I would now need to add a notice to my website with a link to where users can find the edge-runtime source code. For my team at work, company lawyers are responsible for license interpretation, not me as an engineer, so it requires that we explain our usage of Next.js to a company lawyer every time we consume a new update of Next.js, plus spend engineering time implementing their recommendations.

The components in question look like they probably aren’t relevant to our usage, but we can’t realistically rely on Next.js to never happen to use them - maybe some default middleware starts getting used as an implementation detail tomorrow, who knows?

Ideally, we’d prefer if Next.js features that require other licenses to use could be contained to an optional secondary package that a user could choose explicitly whether to install or not.

[dbjorge]

Unfortunately, as a user of Next.js, I have no guarantee that the code in question will only appear in the back-end - as soon as Next.js happens to bundle any part of any of the components in question into any client js bundle, now I’m distributing an executable form of it.

Even if you were to tell me today that Next.js doesn’t include those components in client js in any circumstance today, it would be unsafe for me to assume that would remain true in future patches. This issue is a good demonstration that we wouldn’t be able to trust that future release notes would capture any such change.