Open Source Licensing for Agencies: What MIT, Apache 2.0, and GPL Mean When You Ship Client Code

A typical React application shipped by an agency in 2026 contains somewhere between 500 and 2000 npm packages when you count the full dependency tree. Each one carries a license. Most developers don’t look at them. Most of the time this doesn’t matter. Sometimes it does.

The three moments when license questions actually surface: a client’s legal team is doing due diligence before an acquisition. A funded startup asks who owns the IP in the codebase you built. An investor’s lawyer runs a license audit and finds an AGPL dependency buried in the stack.

Understanding the major license families takes an hour. The gotchas cost less than they should.

The Three License Families

Open source licenses fall into three categories based on what they require from users.

Permissive licenses let you use, modify, and distribute the software with minimal requirements. Typically: keep the copyright notice, don’t imply the original authors endorse your product. Nothing about your code becoming open source.

Weak copyleft licenses have some sharing requirements, but they’re narrow. They apply to the licensed component itself, not to code that uses it.

Strong copyleft licenses require that software combined with or derived from the licensed code also be released under the same license. This is the “viral” effect.

License	Family	Key requirement
MIT	Permissive	Keep copyright notice
Apache 2.0	Permissive	Keep copyright notice, include patent termination clause
BSD 2-Clause / 3-Clause	Permissive	Keep copyright notice (+no endorsement for 3-clause)
LGPL 2.1/3	Weak copyleft	LGPL modifications must stay LGPL; your app linking to it stays proprietary
MPL 2.0	Weak copyleft	MPL-covered files must stay MPL; can combine with proprietary code
GPL 2/3	Strong copyleft	Entire combined work must be GPL
AGPL 3	Strong copyleft	GPL + network use triggers the sharing obligation

MIT: The Default for a Reason

MIT is the most common npm license and the safest for commercial work. The full text is 175 words. The requirement: include the copyright notice and permission notice in all copies or substantial portions.

In practice for agencies: include the license text in your dependencies (npm and bundlers handle this), and you’re done. The MIT license says nothing about your application code. You can ship proprietary software that uses MIT-licensed libraries, charge for it, and assign all rights to a client.

One misconception: “MIT means free.” MIT means you don’t have to pay for the software or open source your code. You can still sell the application you built with it.

Apache 2.0: Why Large Companies Prefer It Over MIT

Apache 2.0 is also permissive, but it adds an explicit patent grant and a patent termination clause. If you contribute to an Apache-licensed project and later sue a user of that project for patent infringement, your Apache license to that user terminates.

For businesses: this is a meaningful protection. Using Apache 2.0 licensed software means the licensor can’t later assert patents against you for using the software they released under that license.

For agencies shipping client work: Apache 2.0 and MIT are functionally equivalent. The difference matters more for companies contributing back to the ecosystem.

State: keep the license notice, add a NOTICE file if the original has one, include the Apache license text. Bundlers typically handle the notice preservation automatically.

GPL: The One You Need to Check

GPL (General Public License) is a strong copyleft license. The core obligation: if you distribute software that includes or links to GPL-licensed code, the combined work must be distributed under the GPL. Source code must be made available to recipients.

For agencies, this creates a real question: does distributing the finished application to a client count as distribution?

The answer depends on how you deliver the software. Delivering source code to a client: probably yes, GPL applies. Running the software on servers that clients access via a web interface: maybe not, depending on GPL version (see AGPL below). Selling licenses to a compiled desktop application: yes, GPL applies.

GPL on the frontend is unusual because JavaScript source is typically delivered to the browser anyway. The GPL question usually arises with backend libraries or system-level tools.

The fix for GPL conflicts is either: use an MIT/Apache-licensed alternative, obtain a commercial license from the copyright holder (many GPL projects have a dual-license commercial option), or release the affected components as GPL (which may not be acceptable to your client).

# Check licenses in your npm project
npx license-checker --json --out licenses.json
# Or for a summary
npx license-checker --summary

AGPL: The One That Trips Up SaaS

AGPL (Affero General Public License) closes what’s known as the “SaaS loophole” in GPL. Under GPL, running software on a server and letting users access it over the network is not considered “distribution” — so you can run GPL software as a service without releasing your source code.

AGPL adds: using AGPL-licensed software to provide a network service to users triggers the same obligation. If your SaaS uses an AGPL library, your entire application’s source must be made available to your users.

This is why companies like Google, Amazon, and most major enterprises have policies prohibiting AGPL in commercial software without a commercial license.

For agencies: an AGPL dependency in a client’s web application creates a real legal exposure. The question is whether your client is using the library to offer a service to their users. For most web applications, the answer is yes.

AGPL libraries in the wild that agencies encounter: some versions of MongoDB (before they switched to SSPL), some graph database clients, some analytics libraries, some AI/ML tools. Check before including.

LGPL: Probably Fine, Check Carefully

LGPL (Lesser GPL) is weaker than GPL. The sharing requirement applies to the LGPL library itself, not to code that uses it. You can include LGPL libraries in proprietary applications provided you link dynamically (not statically compile them in) and give users the ability to use a modified version of the LGPL component.

For npm packages: JavaScript doesn’t have the same static/dynamic linking distinction as compiled languages. The legal analysis is murkier. The general practice is that using an LGPL npm package without modification is acceptable for proprietary software, but this isn’t universally agreed upon.

If a client’s legal team is strict, avoid LGPL or get a legal opinion. If they’re not, LGPL packages are generally used without incident.

Creative Commons Licenses in Code

Creative Commons licenses are designed for content (text, images, media), not software. Using them on code creates ambiguities.

CC0 (public domain dedication) is fine for code. It’s the most permissive possible option and is used by some software projects.

CC-BY (attribution required) is workable but unusual for software.

CC-BY-SA (share-alike) is viral like GPL. Content released under CC-BY-SA that you incorporate requires your derivative work to also be CC-BY-SA. This is sometimes encountered in documentation or datasets, not usually in code libraries.

Don’t use CC-BY-NC (non-commercial) components in commercial client work. “Non-commercial” explicitly restricts commercial use.

Practical License Checking for Agencies

Before any project ships, run a license audit:

# license-checker for npm projects
npm install -g license-checker
license-checker --production --json > licenses.json

# FOSSA (free tier available) for CI integration
fossa analyze
fossa test

# Snyk Open Source includes license scanning
snyk test --print-deps

In your CI pipeline, block on prohibited licenses:

# Fail build if any GPL or AGPL dependency is found in production deps
license-checker --production --failOn "GPL;AGPL" --excludePackages "your-own-packages"

Create a short allowlist of approved licenses for your agency projects:

• MIT — always allowed
• Apache 2.0 — always allowed
• BSD 2-Clause, BSD 3-Clause — always allowed
• ISC — always allowed (functionally similar to MIT)
• CC0 — always allowed
• LGPL — allowed, flag for review
• GPL, AGPL, SSPL — blocked, requires explicit approval

IP Ownership in Client Contracts

The license of open source dependencies is separate from who owns the code you write. In an agency context, the contract should be explicit:

The work product (code your agency wrote): typically transferred to the client on final payment. The contract should say this.

Open source components: licensed under their respective licenses, which the client receives. The client does not own MIT code from npm — they receive the rights the MIT license grants everyone.

Your agency’s reusable components: libraries, utilities, internal tools you use across projects. If you want to retain these, the contract must say so explicitly. Without a clause, a client could argue that everything you delivered, including your internal tooling, belongs to them.

A typical IP clause might read: “Agency retains ownership of all pre-existing agency tools, libraries, and frameworks (‘Agency IP’). Client receives a perpetual license to use Agency IP incorporated into the deliverables. All work product created specifically for Client under this agreement transfers to Client upon final payment.”

The SSPL Situation

MongoDB switched from AGPL to SSPL (Server Side Public License) in 2018 and other databases have followed. SSPL is not recognized as an open source license by the Open Source Initiative. It’s more restrictive than AGPL: if you offer the software as a service to others, you must release the source of the entire service, including everything that makes the service work.

Valkey (the Redis fork) and Redis 7.4+ are under a different license altogether (RSAL). Check the license version, not just the project name.

For agencies: treating any SSPL or non-standard-license database (MongoDB SSPL, Elastic License, RSAL) the same as AGPL is a safe default. Get a commercial license or use an alternative if your client’s legal team is involved.

The Hour-Long Audit That Saves a Deal

License issues discovered during due diligence have delayed or blocked acquisitions. The fix is usually straightforward — swap an AGPL package for an alternative, obtain a commercial license — but it’s time-consuming and stressful when a deal is on the line.

Running license-checker at the start of a project and adding it to CI takes under an hour. Doing it when a client calls to say their acquirer’s lawyers found something takes much longer.