A backend service consumed over HTTP. In the typical case, your code runs entirely on your servers and no binaries are distributed. This means fewer license obligations, with two important exceptions: AGPL, and any scenario where you do distribute code.
If your API code stays on your server, most copyleft conditions (triggered by distribution) do not apply. The exception is AGPL, which treats network access as distribution. But if you ship on-prem versions, provide code or builds to enterprise customers, or share Docker images externally, that counts as distribution, and all standard license conditions apply.
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.
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.
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.
Swift, Kotlin, Dart, Java, TypeScript, Go, Rust, Python, Node.js, C/C++.
No license obligations apply. Compilers transform your code but do not embed themselves in the output. GCC includes a Runtime Library Exception that explicitly permits this. Java’s Classpath Exception permits proprietary applications that use the Java runtime. All major language runtimes are permissive or include exceptions for proprietary code.
If you package a runtime with your binary (e.g. Python via PyInstaller), the runtime ships with your tool. Python’s PSF license is permissive. Check the bundler’s terms too.
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.
Maintain a THIRD-PARTY-LICENSES file in your repository listing framework attribution. Good practice for audits and compliance.
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.
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.
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.
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.
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.
If your API is essentially a managed service wrapper around an open source database or tool, pay attention to SSPL and similar licenses. MongoDB and Elasticsearch adopted these licenses specifically to address this scenario: you cannot offer their software as a service without a commercial agreement.
If your code stays on your server, the formal notice requirements of most licenses are not triggered. If you ship on-prem, deliver builds to customers, or distribute Docker images, treat your API like a distributed product.
Either way, maintaining a license inventory is essential for internal governance, due diligence, and compliance audits. Include:
These licenses impose conditions even without traditional distribution. If your audit reveals AGPL or SSPL dependencies:
Using these dependencies in a hosted service may require you to publish your source code. Do not deploy without understanding the implications.