Choosing a License for Your Own Product: MIT, Apache, AGPL, or Closed

Choosing a License for Your Own Product: MIT, Apache, AGPL, or Closed

A license is a business-model decision wearing legal clothes. Decide the business model first, and the license picks itself.

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? There are only four honest answers, and each maps to a license.

Client-delivered code: closed, and settled by contract

Most consulting output should not carry an open-source license at all. Code built for a client under contract is UNLICENSED in package.json, with no LICENSE file. The actual rights — who owns the copyright, what the client may do, what you may reuse — live in the services agreement, where they belong.

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 no contract clause can take back what the license header already gave away.

The default for client work is closed. Anything else is a deliberate, contract-backed exception.

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.

No conditions worth debating. Instant legal approval inside any company. Maximum spread.

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 MIT with two additions that matter as soon as the code is non-trivial: an explicit patent grant from every contributor, and a patent retaliation clause — sue a user over patents in the covered code and your license terminates. 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. Picture a restaurant that posts its recipe on the kitchen wall for anyone to see — you can cook it at home for free, but sell it under the restaurant's name and system, and you pay for the license.

Because AGPL's obligations trigger even when the software is only served over a network, competitors cannot take your code and quietly run it as their own SaaS. They either publish their modifications or buy your commercial license. Ultralytics runs this model; so do Grafana, MinIO, and half the modern infrastructure world.

It only works when you hold the copyright fully. 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 virality is the feature, and adoption-oriented code suffocates under 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. The manifest field declares; the file grants.
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, and the legal layer stays boring — the highest compliment a legal layer can earn.