[NEXT-906] Licensing: 12.2.0 bundles MPL-licensed edge-runtime

[dbjorge]

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"}

_NEXT-906

[mshd]

Wow hats off for catching this!

[leerob]

The two licenses are compatible and can be used together in the same larger program. If you need further assistance with redistributing Next.js code, I’m happy to hear more about your use case and how we can support you (lee@vercel.com).

[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.

[leerob]

@dbjorge Thanks for following up.

To speak to your example of your personal website, and deploying it:

• Vercel interprets Section 3.2 of the MPLv2 as only requiring a release of the source code when the executable itself is distributed.
• Vercel does not consider the use of the executable on the back-end to provide a SaaS offering or website as being a distribution that would trigger the obligations to release the source code under the MPLv2.

That said, I am not a lawyer, and this is not legal advice 😄 If you do have questions, we encourage you to consult with your own legal counsel. This MPL 2.0 FAQ guide was quite helpful for me.

[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.

[dbjorge]

Hi @jankaifer,

Could you please offer any further details about the resolution of the issue? It doesn't appear to have been resolved, and my team remains locked on v12.1.6 today. It appears that:

• The MPL-licensed components are still present in the distribution of the latest release (13.1.2), and
• There is still no documentation about them present in the release, and
• Particularly, there is no documentation present in the release guaranteeing that the components in question can never appear in client-side output, which would trigger new source redistribution requirements on us as users were it to occur

Was this closed in error?

[jankaifer]

Hi, sorry I was cleaning up old issues and shouldn't have closed this one.
Thanks for pinging.

[leerob]

Hey @dbjorge, our stance remains the same as my comment above. I would recommend talking to your legal counsel. I can't provide generalized legal advice, as I am not a lawyer.

[dbjorge]

Hi @leerob , thanks for responding! Yes, the concerns I'm raising are based on the guidance from my team's legal counsel already.

I've reviewed your comment above again. To be clear, the issue is not with "the use of the executable on the back-end" - we are in agreement that if the components in question were only used on the back-end, it would probably not constitute a "distribution" for our purposes. (to be clear for anyone else reading this: like Lee, I am also not a lawyer, and my comments are also not generalized legal advice)

The issue is that when I use Next.js to produce a website, some parts of Next.js end up embedded in front-end JS that does get distributed to end users, not just back-end code. In general, the legal guidance that applies to my team demands that I be able to certify that no part of any MPL component can appear as part of that front-end JS. But Next.js doesn't document or enforce any guarantees that there will never be any part of a client-side JS bundle that happens to use some utility function from @edge-runtime/primitives. As a user, my only realistic option to gain confidence about this is to go through the Next.js source and look at every call chain in which any part of these libraries is imported, and try to reason about whether that could ever appear in client output.

Doing that once is already a lot of overhead and very easy for me to make a mistake with. But it's worse than that; I'd have to do that every time we take a Next.js update, not just once, because Next.js doesn't appear to have any sort of mechanism enforcing that those libraries (including every one of their utility functions/etc) cannot appear in client bundles going forward.

These components being used in unexpected places isn't a theoretical issue; for example, just two weeks ago a usage of a utility class from @edge-runtime/primitives was introduced outside of the server middleware area. It is only a matter of time before some encoding utility function from @edge-runtime/primitives makes its way by accident into a component that can be a transitive dependency of a client-side JS bundle.

---

For next steps that we think would resolve this issue:

• 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.
• If that's not possible in this case, we'd like a reliable assertion that Next.js does not and will not embed any part of the MPL components in client-side output, such as client-facing JS bundles.
  • Preferably this would use a combination of official documentation asserting that intent and also some sort of build-time enforcement mechanism to prevent such a dependency from being introduced by accident in practice.

[nicholasgriffintn]

To note: and add a point on:

Because it is not reported I only found out about this because of this issue, we also have automated License checking compliance tool which thinks that Next is acceptable, but in reality, it isn't (for any License that is not MIT or similar, we need to record our usage internally).

I think what is being asked for here is actually quite simple, and I would agree with it:

Vercel should document all licenses that are a part of the Next.JS bundles.

This goes much further than just to two packages as well, and has caused me issue before, as shown in my hacky script, Next compiles around 124 packages, which if my script works have the licenses: MIT, MPLv2, BSD-3-Clause, Apache-2.0, Unknown (yes there's a compiled package without a license!), ISC, CC0-1.0, BSD-2-Clause

[jeffrafter]

👋 I don't have a solid answer but wanted to note here that we're discussing options here internally and I will report back. Thanks for the persistence on this one.

[nicholasgriffintn]

Any update on this? Since my last check, there are 2 more @edge-runtime packages with the MPL licenses attached: https://github.com/vercel/next.js/tree/canary/packages/next/src/compiled/@edge-runtime

Again, the issue here is that there's no documentation when a package with one of these copyleft licenses is added, in particular, for copyleft, it should really be the case that these are called out, at least in change logs, rather than us having to manually check every time we update Next.JS, which appears to be the expected flow?

For context, whenever a copyleft package is used, we have to log the use of that and why we believe it is permissive, without Next calling this out, we have to check all code changes to see if a new package with an offending license has been added since the last update.

[justinmclean]

The MPL license is incompatible with the Apache license so this is problematic (see https://www.apache.org/legal/resolved.html#weak-copyleft-licenses). We're working on Apache-licensed software that includes a web UI that uses next.js. This change would probably mean we have to use something else.

[leerob]

Hey y'all. Appreciate the feedback here. We've changed the edge-runtime to be MIT licensed and it will be included in Next.js 15.

#67565

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.