How to Fix: LGPL-3.0 license usage of sharp dependencies blocks us from using Next 15

Next.js 15 can appear to introduce a licensing blocker because the framework now pulls in sharp more visibly in production image optimization workflows, and legal review tools may flag its dependency tree before engineering teams understand whether that code path is actually required. The practical fix is usually not “remove Next.js,” but to choose the right image optimization strategy, verify how sharp is installed and used, and document the licensing position with your legal team.

Understanding the Root Cause

The issue is not that Next.js 15 suddenly forces every application to ship forbidden code into production. The real problem is that software composition analysis and legal compliance scanners often detect sharp and its native dependency chain at install time, then classify the result as a licensing risk before checking whether your app truly depends on that functionality.

Historically, Next.js image optimization has relied on sharp in self-hosted production environments because next/image needs a high-performance image transformer. In newer releases, package relationships and installation behavior can make that dependency more explicit, which causes organizations with strict open-source review policies to stop upgrades until they understand the legal impact.

Technically, this happens in three layers:

• Framework layer: next/image may use sharp for server-side image processing.
• Package manager layer: your lockfile records all transitive dependencies, even optional or environment-specific ones.
• Compliance layer: automated scanners may flag the dependency tree without evaluating whether the package is executed, bundled, or deployable in your actual runtime.

That means your path forward depends on how your application uses image optimization:

• If you do not need built-in image optimization, you can disable it.
• If you use an external image CDN, you can offload optimization entirely.
• If you do need local optimization, you must validate the exact dependency chain and align with your legal team on acceptable usage.

In other words, this is usually a dependency governance problem, not a generic framework failure.

Step-by-Step Solution

The safest implementation approach is to decide whether you actually need local image optimization. Start there, then configure Next.js accordingly.

1. Confirm whether your app uses next/image

Search the codebase for image components and optimization settings.

grep -R "from 'next/image'" src app pages components .

If your project does not use next/image, the licensing concern may be limited to dependency presence rather than runtime usage.

2. Disable built-in image optimization if you do not need it

If your team serves static images directly or already uses a CDN, disable optimization in next.config.js or next.config.mjs.

/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    unoptimized: true,
  },
}

module.exports = nextConfig

This tells Next.js to stop performing server-side image transformation for next/image. It is often the cleanest fix for teams blocked by compliance review.

3. If possible, move image optimization to a remote loader or CDN

If you need optimized images but do not want local processing, use a hosted image provider. For example:

/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    loader: 'custom',
    loaderFile: './src/lib/image-loader.js',
  },
}

module.exports = nextConfig

Create the loader file:

export default function imageLoader({ src, width, quality }) {
  const q = quality || 75
  return `https://example-cdn.com/optimize?url=${encodeURIComponent(src)}&w=${width}&q=${q}`
}

With this setup, the transformation workload moves outside your application server.

4. Audit whether sharp is being installed directly, transitively, or optionally

Use your package manager to inspect the dependency graph.

npm ls sharp

pnpm why sharp

yarn why sharp

This helps you distinguish between:

• a direct dependency you explicitly added,
• a transitive dependency introduced by Next.js, or
• an optional dependency that your environment may not require.

5. Review your production usage path

Check whether your deployment actually invokes image optimization endpoints. In many apps, legal concern is triggered by install-time scanning, but runtime traffic never touches the code path.

Look for image requests to /_next/image. If your app does not use that endpoint, you have strong technical evidence that local optimization is unnecessary.

6. Lock the configuration and document it for compliance

Once you disable or externalize optimization, commit the configuration and add a short internal note stating:

• why image optimization was disabled or moved,
• where image processing now happens,
• how dependency scanning should be interpreted.

Example internal note:

Next.js image optimization is disabled via images.unoptimized = true.
The application does not rely on local sharp-based transformation.
Images are served directly from static storage or a remote CDN.
Compliance review should evaluate runtime usage, not only lockfile presence.

7. If your organization requires removal from the dependency tree, test and pin a compatible strategy

Some organizations require stricter controls than simply disabling runtime usage. In that case:

• test whether your exact Next.js version allows operation without local optimization,
• avoid importing next/image where not needed,
• use plain <img /> tags or a remote image layer for affected pages,
• track upstream changes in the Next.js issue tracker.

If legal policy is absolute, your engineering resolution may be architectural rather than package-level: remove the feature path that needs the dependency.

8. Validate the application after the change

npm run build
npm run start

Then verify:

• images render correctly,
• no requests hit /_next/image unexpectedly,
• your scanner output matches the intended dependency posture.

Common Edge Cases

1. images.unoptimized is set, but scanners still flag sharp

This is common. Disabling optimization changes runtime behavior, but it does not always remove the package from the lockfile. If your compliance process evaluates only dependency presence, you may need a formal exception, an upstream package update, or a design change that avoids the related feature entirely.

2. A remote loader is configured, but some routes still call /_next/image

This usually means part of the app still relies on default Next.js image behavior, or older components were not migrated. Search for mixed usage across the codebase.

3. The app works locally but fails in production

Local development may behave differently from production builds. Always test with next build and next start, especially when changing image configuration.

4. Another package also pulls in sharp

Next.js may not be the only source. Run a full dependency trace and identify all introducers before concluding that the framework alone is responsible.

5. Teams switch from next/image to plain <img /> and regress performance

This resolves the dependency concern, but you may lose responsive sizing, optimization, and lazy loading benefits. If performance matters, use a remote image CDN instead of abandoning optimization entirely.

FAQ

Does Next.js 15 always require sharp at runtime?

No. It depends on whether you use built-in server-side image optimization. If you disable optimization or use a remote image pipeline, your app may not rely on that runtime path.

Can I keep using next/image without local sharp-based optimization?

Yes. Setting images.unoptimized = true allows continued use of the component in many cases, but images will not be transformed by the local server. A custom loader or CDN is often the better long-term solution.

Is this a bug in Next.js or a compliance policy conflict?

Usually it is a policy and dependency interpretation conflict. The framework exposes functionality that may bring in flagged packages, while compliance tooling may treat all detected dependencies as blockers regardless of runtime usage. The engineering fix is to reduce or eliminate the feature path, then document that behavior clearly.

Bottom line: if sharp blocks your Next.js 15 adoption, first decide whether you truly need local image optimization. In most affected teams, disabling optimization or moving it to a remote service solves the practical problem without abandoning the framework.