Choosing a Product License: MIT, Apache, AGPL, or Closed

A license is a business-model decision wearing legal clothes. Start with the business model, then check ownership, dependencies, and the rights users need.

The previous licensing article covered the licenses you consume — what your dependencies obligate you to do. This one runs the other direction: what license goes on the code you ship.

Teams get this wrong the same way every time. They pick whatever license the last popular project used, then discover a year later it doesn't match how they actually make money. (Usual note: engineering guidance, not legal advice.)

Start from how the code earns

Every licensing question reduces to one: what do you want strangers to be able to do with this code, and what do you sell? Four common answers help narrow the choice; other licensing models are possible.

Client-delivered code: closed, and settled by contract

For client work agreed to be closed, use UNLICENSED in package.json and do not add an open-source license to project-owned code without approval. Set copyright ownership, client use, and reuse rights in the services agreement. Third-party components retain their own licenses.

Slapping MIT on a client deliverable is a real mistake I've seen in delivered repositories. It grants the whole world rights the client paid to have exclusively, and a later contract does not automatically revoke valid licenses already granted. Whether the person adding the header had authority also matters.

For the closed-client-project arrangement discussed here, publishing project code as open source should be a deliberate decision agreed in the contract.

MIT or ISC: when adoption is the product

If the value of a piece of code is that other people build on it — an SDK for your platform, a client library for your API, an integration example — friction is your enemy. MIT, or the functionally identical ISC, is the tool.

MIT and ISC have short terms, including preservation of notices. That can ease adoption, but each company still decides whether the license fits its policies.

Be honest about what you're giving up: anyone may commercialize it, fork it, or embed it in a competing product, with attribution as your only guarantee. For an API client whose entire purpose is driving usage of your paid service, that trade is exactly right.

Apache-2.0: same freedom, explicit patent posture

Apache-2.0 is a permissive license with two provisions that matter as soon as the code is non-trivial: an explicit patent grant from every contributor, and a patent retaliation clause — initiate patent litigation alleging that the work or a contribution infringes a patent, and the patent licenses granted for that work terminate under Section 3. Corporate legal teams prefer consuming Apache-2.0 for precisely this reason, and it's the safer default if you want serious companies contributing to your project.

The rule of thumb I give clients: MIT for small tools and examples, Apache-2.0 for anything with algorithmic depth, outside contributors, or enterprise adoption ambitions. The NOTICE-file mechanics are slightly heavier. The protection is worth it.

AGPL: when you sell the thing you open-source

AGPL-3.0 is the license for one specific business model: the product is open, and the commercial exception is what you sell. A commercial exception gives buyers different terms where they cannot or do not want to comply with AGPL.

AGPL section 13 requires a modified version supporting remote network interaction to offer those users its Corresponding Source. Distribution has separate obligations. Commercial use is allowed under AGPL; a separate paid license is not required just because money changes hands. Assess the combined-work scope of an integration rather than assuming every separate service must be opened.

Selling an exception requires sufficient rights to relicense all code covered by that exception; sole ownership is one way to obtain them. Every outside contribution needs a contributor agreement assigning or licensing rights back to you, or you lose the ability to sell the exception. The full mechanics deserve their own article: dual licensing with AGPL.

What AGPL is not for: libraries you want widely adopted. Its source-sharing obligations can conflict with proprietary integration goals, so assess your intended users before choosing it.

Repo hygiene: make the choice legible

A licensing decision that lives only in your head doesn't exist. Three artifacts make it real.

1. license field in package.json (or the manifest of your ecosystem) — "MIT", "Apache-2.0", "AGPL-3.0-only", or "UNLICENSED" for closed code. Scanners and registries read this field. An empty one reads as "unknown risk" in every audit.
2. A LICENSE file at the repo root with the actual text for open-source code. For closed code, document the reserved rights and contractual terms. The manifest identifies the choice; open-source license text sets the grant's conditions.
3. A NOTICE file when you redistribute third-party code that requires attribution — Apache-2.0 dependencies in particular. Your own license choice never erases obligations you inherited.

Auditing a mixed portfolio

Anyone who has shipped software for a few years holds a mix: client deliverables, internal tools, a public SDK, maybe an open-core product. The audit is mechanical — walk every repository and check that the manifest field, the LICENSE file, and the intended business model agree.

The findings are predictable: client code accidentally carrying a permissive license from a template, public repos with no license at all (which means all rights reserved, so nobody can legally use what you meant to share), and forks whose upstream license was silently dropped. An afternoon of tidying, and every future due-diligence conversation gets shorter.

The takeaway

Closed and contract-settled for client work. MIT or ISC when adoption is the goal. Apache-2.0 when patents or corporate contributors enter the picture. AGPL plus a commercial license when the product itself is what you sell.

Pick by business model, write it into the manifest and the LICENSE file, then keep third-party notices and contributor rights consistent with that decision.