Frontend vs Backend

Frontend JavaScript, CSS, and assets are sent to the user's browser. This counts as distribution. Backend code runs on your server and is never distributed. Different licenses have different obligations depending on which side your code lands on.

1 IDE and Tooling No obligations

Your IDE (VS Code, IntelliJ, Xcode, Android Studio), linters (ESLint, Prettier, SwiftLint, clippy, Pylint), formatters (Black, Prettier), build tools (Gradle, Make, Cargo, go build), bundlers (Webpack, Vite, Rollup, esbuild), transpilers (Babel, TypeScript), test runners (Jest, Vitest, pytest, XCTest), and version control (Git). These are all development tools.

No obligations

None of these tools ship with your final product. They run during development and build time, not at runtime. Their licenses impose no conditions on your output.

Bundler runtime snippets

Some bundlers inject a small runtime snippet into your output (e.g. Webpack’s module loader). These snippets are typically released under the same permissive license as the bundler itself (MIT for Webpack, Vite, Rollup). The condition is simply to include the copyright notice, which is usually embedded as a comment in the output.

2 Frontend Framework Obligations apply

React, Vue, Angular, Svelte, Next.js, Nuxt: all use the MIT license.

Permissions

  • Commercial use
  • Modification
  • Distribution
  • Private use

Conditions

  • Include copyright notice
  • Include license text

Limitations

  • No liability
  • No warranty
Your obligation

Include the MIT license text and copyright notice in your source code or in your frontend bundle.

3 Frontend Libraries Obligations apply

npm packages bundled into your frontend JavaScript. These are distributed to every browser that loads your app.

MIT, BSD, Apache — The vast majority of npm packages use these permissive licenses.

Permissions

  • Commercial use
  • Modification
  • Distribution

Conditions

  • Include copyright notice
  • Include license text

Limitations

  • No liability
  • No warranty

GPL in frontend — Your bundled JavaScript is distributed to every user. If a dependency is GPL, GPL’s conditions (source disclosure, same license) apply to your entire distributed bundle.

Permissions

  • Commercial use
  • Modification
  • Distribution

Conditions

  • Disclose source
  • Same license (GPLv2 or GPLv3)
  • Include copyright notice
  • Include license text
  • State changes

Limitations

  • No liability
  • No warranty
Your obligation

Run npx license-checker or npx license-report to audit all frontend dependencies. Use a license bundler plugin: LicenseWebpackPlugin (Webpack), rollup-plugin-license (Rollup), or vite-plugin-license (Vite).

4 Backend Framework Obligations apply

Express (MIT), Django (BSD), Rails (MIT), Spring Boot (Apache 2.0), Laravel (MIT), FastAPI (MIT), NestJS (MIT), Gin (MIT), Actix (MIT/Apache). All use permissive licenses.

Permissions

  • Commercial use
  • Modification
  • Distribution
  • Private use

Conditions

  • Include copyright notice
  • Include license text

Limitations

  • No liability
  • No warranty
Your obligation

Maintain a THIRD-PARTY-LICENSES file in your repository listing framework attribution. Good practice for audits and compliance.

5 Backend Libraries Obligations apply

Server-side packages and libraries. These run on your infrastructure and are never sent to users.

MIT, BSD, Apache — No obligations triggered by server-side use. Good practice: maintain an internal inventory of notices for due diligence.

GPL on the backend — GPL’s conditions are triggered by distribution. If your code stays on your server, source disclosure does not apply. However, if you ship on-prem versions, provide builds to enterprise customers, or share Docker images externally, that counts as distribution, and GPL’s full conditions apply.

AGPL on the backend — AGPL adds a network use condition. If your backend uses an AGPL library and serves users over a network, you must offer your complete server source code to users who interact with it.

Permissions

  • Commercial use
  • Modification
  • Distribution

Conditions

  • Disclose source
  • Same license (AGPLv3)
  • Network use triggers disclosure
  • Include copyright notice
  • State changes

Limitations

  • No liability
  • No warranty
Your obligation

Avoid AGPL on the backend. Many companies maintain a strict “no AGPL” policy. If you must use AGPL software, you will need to release your complete backend source under AGPL. Consult a lawyer.

6 Assets and Resources Obligations apply

Fonts, icons, images, and other media bundled into your product.

Fonts

SIL OFL — Permissive for commercial use and web embedding. Google Fonts and most open source fonts use SIL OFL. Fonts cannot be sold standalone.

Proprietary fonts — Check the specific license. Some require a commercial license for app embedding or web use, and may have pageview limits, seat limits, or domain restrictions.

Icons and Images

License varies by source. Include attribution where required by the license.

Your obligation

Read the font license. If proprietary, verify that your usage tier complies with the license terms.

7 Operating System and Infrastructure No obligations

Linux servers, Docker containers, Kubernetes, AWS, GCP, Azure, Vercel, Netlify.

No license obligations apply. Running proprietary code on Linux (GPL) does not make your code GPL. Your application is a user-space program. Docker (Apache 2.0) does not affect your app. Every major cloud company runs proprietary services on Linux. This is well-established.

Docker base images. When you build a Docker image FROM ubuntu or FROM alpine, your image includes the OS packages. If you distribute that Docker image publicly, you distribute those packages and must provide access to their source code. Your application code inside the container remains independent.

8 Databases No obligations

PostgreSQL, MySQL, SQLite, MongoDB, Elasticsearch, and other databases.

PostgreSQL, SQLite — Fully permissive licenses. No obligations beyond acknowledging the copyright.

MySQL — GPL license. However, MySQL runs on your server and is not distributed to users. GPL’s distribution condition is not triggered. This is the standard practice for all SaaS companies.

MongoDB and Elasticsearch (SSPL) — SSPL is not OSI-approved. Its core condition: if you offer SSPL software as a managed service to others, you must disclose the source code of your entire service stack, not just the SSPL component.

Permissions

  • Commercial use
  • Modification
  • Distribution

Conditions

  • Disclose source if offered as service
  • Same license (SSPL)
  • Include copyright notice
  • Include license text

Limitations

  • No liability
  • No warranty
SSPL edge case

If you use MongoDB or Elasticsearch internally (private servers, not offered as a service), no SSPL obligation applies. If you offer them as a service to others, you must release your entire service stack source code under SSPL.

How to Fulfill Your Obligations

1. Embed Notices in Your Frontend Bundle


Every frontend dependency must be accounted for. Use a build plugin to automate extraction from node_modules.

Alternatively, create a /licenses or /credits route in your app and link to it from your footer. This satisfies the “include copyright notice and license text” condition for MIT, BSD, Apache, and most permissive licenses.

2. Maintain a THIRD-PARTY-LICENSES File for Your Backend


If your backend stays on your server, notice requirements are less strict. But if you ship on-prem versions, provide builds to enterprise customers, or distribute Docker images, all license conditions apply.

Create a THIRD-PARTY-LICENSES file in the root of your repo. List all backend dependencies and their licenses. Update it whenever you add or remove a dependency.

3. Run a Dependency Audit Before You Ship


Identify any GPL or AGPL packages before they reach production.