Release-matched native notices and original marker-package source #99462

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 <[email protected]>).
• 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 [email protected] 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).

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

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.

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 [email protected] and [email protected], 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.

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

Hello maintainers,

This existing discussion already asks about the original source and notices for server-only 0.0.1. Could a project maintainer help route this version-specific question to the original package publisher or an authorized copyright representative? We do not treat an unaffiliated reply, a downstream vendored copy, or a current repository license as confirmation of the exact published release notices.

We are reviewing the exact, unmodified npm archive:
Package: server-only 0.0.1
Version metadata: https://registry.npmjs.org/server-only/0.0.1
Archive: https://registry.npmjs.org/server-only/-/server-only-0.0.1.tgz
Archive SHA-256: 1e4047892103e8f81503c99fb88ad47394b8438088c999e683ae2e6987145271

The reviewed archive contains package.json, index.js and empty.js. Its package.json declares MIT, but the archive does not include a standalone complete license/copyright notice, and the reviewed version metadata does not provide a gitHead establishing an exact source revision.

Could an authorized representative please provide:

1. The full applicable license text and exact copyright notice(s) for this published version, including any additional notices required for its contents.
2. An authoritative source revision or explicit statement connecting those notices to this exact release/archive, rather than only the current React repository license or a downstream vendored copy.
3. Confirmation of where the notices must be preserved when distributing the unchanged archive and its extracted contents, including whether companion documentation is appropriate.
4. Your capacity to confirm these notices, or a referral to the authorized package publisher/copyright representative.

This is a request for version-specific license documentation, not a report of a security vulnerability or a request to change or bypass the server boundary marker.

Thank you.

The @next/swc-* packages are thin wrappers around the N-API addon built from crates/next-napi-bindings in this repo. Check out tag v16.3.6 (matches your provenance commit) and look at the npm wrapper dirs crates/next-napi-bindings/npm/linux-x64-gnu and .../linux-x64-musl. The Cargo.lock there pins the full Rust dependency set, which is what your third-party notice list needs.

For server-only and client-only at 0.0.1 there is no standalone source repo, the published tarball IS the whole source: package.json, index.js (the throw), and empty.js behind the react-server export condition. In-tree copies live at packages/next/src/compiled/server-only and .../client-only. MIT, published by sebmarkbage during the RSC rollout, which is why the metadata points at reactjs.org.

—
More of my work lives here: github.com/Icaro0310 · Website: icaro0310.github.io