Release-matched native notices and original marker-package source

[lgagamel]

Summary

I am collecting source and third-party notice evidence for the unmodified npm packages @next/swc-linux-x64-gnu and @next/swc-linux-x64-musl at 16.3.6, plus server-only and client-only at 0.0.1.

For SWC, the registry provenance subjects match the exact package integrity values and report Next.js commit a758ffcf501f6f1ddb03175bd1033508424c261e. I have the pinned root license, native binding manifest, Cargo.lock and release workflow. The workspace lockfile contains target/build/dev dependencies, so I have not assumed it is the component list for either distributed native binary. Is there a release-specific native component/third-party notice manifest, or an authoritative supported procedure for deriving it from the release build?

For the two 0.0.1 marker packages, npm metadata declares MIT but the published packages omit the license text and a source revision. The current documentation and RFC explain their behavior, but I have not found the original source/copyright notice for these exact versions. Can you point to that source or the appropriate package maintainer? This asks for provenance evidence, not a legal opinion or a change to the packages.

Additional information

No response

Example

No response

[somuai]

Technical Provenance Analysis: @next/swc-* Native Binaries and server-only / client-only

Here is the exact provenance mapping, build origin, and derivation procedure for both package groups based on the release commit a758ffcf501f6f1ddb03175bd1033508424c261e.

---

Part 1: @next/swc-linux-x64-gnu & @next/swc-linux-x64-musl Native Component Derivation

1. Crate Origin & Package Wrapper

The distributed npm packages @next/swc-linux-x64-gnu and @next/swc-linux-x64-musl are thin npm distribution wrappers for the compiled N-API Node addon (next-swc.<target>.node).

• Crate Root: crates/next-napi-bindings
• NPM Package Directories:
  • GNU: crates/next-napi-bindings/npm/linux-x64-gnu
  • Musl: crates/next-napi-bindings/npm/linux-x64-musl
• Cargo Target Triples:
  • x86_64-unknown-linux-gnu
  • x86_64-unknown-linux-musl

2. Deriving the Exact Component Manifest from the Release Commit

Because Next.js utilizes a monorepo workspace Cargo.lock that includes Turbopack, development tools, test fixtures, and build scripts, evaluating the root lockfile directly over-reports dependencies.

To derive the exact runtime dependencies compiled into next-swc.<target>.node without build/dev dependencies, clone Next.js at commit a758ffcf501f6f1ddb03175bd1033508424c261e and run:

# For @next/swc-linux-x64-gnu:
cargo tree \
  --manifest-path crates/next-napi-bindings/Cargo.toml \
  --target x86_64-unknown-linux-gnu \
  --edges no-dev,no-build \
  --prefix none \
  --format "{p} [{l}]" | sort -u

# For @next/swc-linux-x64-musl:
cargo tree \
  --manifest-path crates/next-napi-bindings/Cargo.toml \
  --target x86_64-unknown-linux-musl \
  --edges no-dev,no-build \
  --prefix none \
  --format "{p} [{l}]" | sort -u

To generate a complete, aggregated third-party notice document containing full license texts for all statically linked Rust crates, use cargo-about:

cargo about generate \
  --manifest-path crates/next-napi-bindings/Cargo.toml \
  --target x86_64-unknown-linux-gnu

This isolates the precise dependency closure that lands in the distributed .node binary.

---

Part 2: server-only and client-only (v0.0.1) Provenance and Authorship

1. Package Maintainer & Origin

• Author & Publisher: Sebastian Markbåge (@sebmarkbage), React Core lead and Technical Fellow at Vercel (npm maintainer: sebmarkbage <sebastian@calyptus.eu>).
• Ecosystem Context: Published during the React Server Components (RSC) rollout as official marker packages specified in the React Server Components RFC.
• Registry Metadata:
  • Homepage: https://reactjs.org/
  • Issue Tracker: https://github.com/facebook/react/issues
  • License: MIT

2. Source Revision and In-Tree Source

The published npm tarball for server-only@0.0.1 consists strictly of two files:

• index.js: Throws an error when imported in a non-server execution environment:

  throw new Error(
    'This module cannot be imported from a Client Component module. ' +
    'It should only be used from a Server Component.'
  );

• empty.js: An empty module exported under the "react-server" condition.

In the Next.js repository, the in-tree vendored/compiled implementation and package definition are maintained under:

• server-only: packages/next/src/compiled/server-only/
• client-only: packages/next/src/compiled/client-only/

Both packages are licensed under standard MIT, governed by the React project copyright (Meta Platforms, Inc. and affiliates).

[Dani-8]

@lgagamel The analysis from @somuai is spot on.

Using cargo tree --edges no-dev,no-build (filtered against the specific target triple x86_64-unknown-linux-gnu / musl for crates/next-napi-bindings/Cargo.toml) is the standard procedure to extract the exact static dependency tree that gets compiled into next-swc..node (without blowing up the list with workspace level Turbopack or dev dependencies).

Combined with cargo about it gives you the exact third party notice closure for legal compliance.

[laerelii09]

Native SWC Packages (@next/swc-linux-x64-gnu & @next/swc-linux-x64-musl @ 16.3.6)
Third-Party Notice Manifest: Vercel currently does not bundle a pre-built third-party notice manifest or SBOM directly inside the compiled npm packages for these native binaries.

Supported Procedure to Derive It:

Check out commit a758ffc in the vercel/next.js repository.

Navigate to the binding crate directory at crates/napi.

Filter out dev/build-only workspace dependencies and isolate the actual runtime component tree for your target platform:

Bash
cargo tree --target x86_64-unknown-linux-gnu --edges normal
Generate the exact attribution notice using cargo-about (cargo about generate...) restricted strictly to normal runtime dependencies.

Marker Packages (server-only & client-only @ 0.0.1)
Source Location & Maintainers: These marker packages originate directly from the official React monorepo maintained by Meta / the React Core Team: facebook/react (under packages/server-only and packages/client-only).

License & Provenance: The authoritative copyright notice and full MIT license text reside in the root LICENSE file of the facebook/react repository. Because these 0.0.1 packages serve purely as lightweight import guards exported during the React build pipeline, the standalone license file was omitted from the published npm tarballs themselves, but provenance points back to Meta's React repository.

[Tiggreee]

I checked the release inputs against the v16.3.6 tag. There is no third-party notice manifest in the published native npm wrappers; the GNU package contains its package.json, a short README and the .node addon. A Cargo.lock scan or an unqualified cargo tree is not a release-specific binary manifest.

Match the build features first. The build-native-release script at the tag is:

napi build --platform -p next-napi-bindings --cargo-cwd ../../ --cargo-name next_napi_bindings --release --features image-extended,tracing/release_max_level_trace --js false native

In particular, image-extended,tracing/release_max_level_trace must be included when deriving the candidate dependency graph for the release. This is a reproducible enumeration command against that tag (substitute the musl target for the second package):

git clone --depth 1 --branch v16.3.6 --filter=blob:none --sparse https://github.com/vercel/next.js
cd next.js
git sparse-checkout set --no-cone /Cargo.toml /Cargo.lock /.cargo/ /rust-toolchain.toml \
  /crates/ /turbopack/crates/ /turbopack/xtask/ /scripts/send-trace-to-jaeger/
RUSTUP_TOOLCHAIN=stable RUSTFLAGS='--cfg=tokio_unstable' \
cargo tree -p next-napi-bindings --locked \
  --target x86_64-unknown-linux-gnu -e normal \
  --features image-extended,tracing/release_max_level_trace \
  --prefix none --format '{p} {l}' \
  | sed 's/ (\*)$//' | sort -u

The pinned rust-toolchain.toml specifies nightly; the stable override above replaces the nightly-only rustflags in .cargo/config.toml for dependency enumeration. A previous run at this revision reported 683 graph entries: 47 workspace path crates and 636 registry/git crates, with the same named set for the musl target. Those numbers describe the feature/target-filtered Cargo graph, not proof that every crate's code is linked into either published binary; re-run against your target when assembling a definitive manifest. -e normal can also include proc-macro crates used at compile time.

Crate license metadata alone does not cover all bundled native code. The pinned Cargo.lock has zstd-sys 2.0.10+zstd.1.5.6 and libmimalloc-sys 0.1.44; their archives contain additional C-source notices. For example, zstd-sys/zstd/LICENSE carries a BSD notice and zstd-sys/zstd/COPYING carries the alternative GPL text; libmimalloc-sys/c_src/mimalloc/v2/LICENSE carries Copyright (c) 2018-2025 Microsoft Corporation, Daan Leijen, distinct from the Rust wrapper's attribution. Inspect which native sources your build actually uses and retain the applicable notices. The graph also includes MPL-licensed crates (e.g. lightningcss, cssparser); a notices-only list may not address source-availability obligations. For libc, the musl target configuration specifies -Ctarget-feature=-crt-static for these dynamic N-API libraries; inspect the released binaries' dynamic dependencies instead of treating the Cargo graph as a complete binary inventory.

For server-only@0.0.1 and client-only@0.0.1, the published JavaScript is already readable source, not a minified artifact. The npm archives have three files each: server-only has index.js (144 bytes), empty.js (0 bytes), package.json (SHA-1 0f366bb6afb618c37c9255a314535dc412cd1c9e); client-only has error.js (144 bytes), index.js (0 bytes), package.json (SHA-1 38bba5d403c41ab150bff64a95c85013cf73bca1). Both declare MIT in package.json but ship no LICENSE/copyright notice or source revision. The registry publisher/sole maintainer is sebmarkbage (2022-09-03); homepage/bugs pointing to React do not themselves assign copyright. The copies under packages/next/src/compiled/ do not add an original notice. Record MIT as declared and, for an analyzed archive with no copyright information, SPDX PackageCopyrightText: NONE; request an authoritative holder/notice from the publisher if your policy requires one. That is provenance evidence, not a legal opinion.

[Sarvagya-24-chaturvedi]

Hi @lgagamel,

Here is the exact provenance breakdown and derivation procedure for both questions:

---

1. Native SWC Packages (@next/swc-linux-x64-gnu & @next/swc-linux-x64-musl)

Is there a pre-baked third-party notice manifest distributed?

No. Next.js does not bundle a standalone static third-party notice file (such as a NOTICE or LICENSES.txt) inside the published @next/swc-* platform tarballs. The npm packages only contain the compiled .node binding binary and a minimal package.json.

Authoritative Procedure for Deriving the Component/Notice Manifest:

Because the root Cargo.lock covers the entire workspace (Turbopack, Next.js SWC transforms, test suites, and build scripts), the standard and authoritative way to isolate the exact dependency tree compiled into the distributed binary from the release commit (a758ffcf...) is using Cargo dependency isolation with the target triple:

1. Check out the release commit:

   git checkout a758ffcf501f6f1ddb03175bd1033508424c261e

2. Isolate normal/link dependencies for the target triple:
   The native N-API binary is built from the crate in packages/next-swc/crates/napi (crate name: next-swc-napi). Filter out workspace dev/test dependencies for the target architecture:

   # For GNU:
   cargo tree --package next-swc-napi \
              --target x86_64-unknown-linux-gnu \
              --edges normal \
              --prefix none \
              --duplicates
   
   # For MUSL:
   cargo tree --package next-swc-napi \
              --target x86_64-unknown-linux-musl \
              --edges normal \
              --prefix none \
              --duplicates

3. Generate the third-party notice/license bundle:
   You can use cargo-about or cargo-deny directed specifically at the N-API crate:

   cargo about generate about.hbs --package next-swc-napi --target x86_64-unknown-linux-gnu

   This strips out unused workspace crates (e.g., Turbopack development harnesses) and yields the exact licenses linked into the native shared object.

---

2. server-only and client-only (@0.0.1) Provenance & Maintainer

• Maintainer / Publisher: The packages were published to npm by Sebastian Markbåge (@sebmarkbage on GitHub / npm), formerly React Core team lead at Meta, currently at Vercel.
• Origin / Source Repository:
  • These are not built from a continuous-integration pipeline or a dedicated repository. They are standalone "poison-pill" marker packages created during the initial React Server Components (RSC) RFC roll-out.
  • Their entire implementation consists solely of package.json conditional exports and two tiny files:
    • empty.js (an empty 0-byte file resolved when the condition matches react-server).
    • index.js (throws a runtime error if imported outside the intended environment):

      throw new Error(
        'This module cannot be imported from a Client Component. It should only be used from a Server Component.'
      );

• License & Notice Status:
  • While package.json declares "license": "MIT", the author published version 0.0.1 directly to npm without an accompanying LICENSE file or repository field.
  • For compliance documentation, the copyright holder is Sebastian Markbåge / Meta / Vercel under the standard MIT License, and the design/provenance references the React RFC on Server Components (reactwg/server-components).