AGPL vs Apache — the license decision that ships or sinks your product

Why licenses matter — even when nobody is looking

Open-source licensing is the most boring part of a startup, right up until it’s the most expensive part. I’ve watched teams ship a feature, take diligence calls from acquirers six months later, and learn at the table that a single library in their bundle obligated them to open-source the whole codebase. The deal terms shift in that moment. Sometimes the deal evaporates.

The other failure mode is quieter: you ship a clean product, no acquirer in the picture, and a copyleft compliance complaint arrives by email. Pulling the library out is a multi-week rewrite. Publishing your source — the alternative the license demands — was never something you agreed to. The team did, the moment one developer ran npm install on a dependency nobody had vetted.

License is a structural property of your shipping product. It travels with every dependency, every fine-tuned model, every static link. The cost of getting it wrong is paid in rewrites and lawyers. The cost of getting it right is one license check at the right moment in your workflow. This lesson is about installing that check.

The story

The first time I really took licensing seriously was when I almost picked the wrong library for a shipping product. I was deep in evaluation mode — comparing two open-source options that did roughly the same job. One had more stars, better docs, a more active community. I was 15 minutes from running npm install. I checked the license at the bottom of the README out of habit.

AGPL-3.0.

Reading the actual license text took 10 minutes. The summary: I could absolutely use this library. I could even modify it. But the moment a user interacted with my product over a network — which, by definition, they would — I owed the world my modified source code. Not just the library. The modifications. Which, for a real integration, meant a meaningful chunk of my product’s internals.

The other library was Apache 2.0. Same job, slightly less polish, explicit patent grant. I picked the Apache one and never thought about it again. That ten-minute license read saved a future me a multi-week rewrite, or worse, a forced open-source disclosure I had not agreed to make.

The story isn’t dramatic. That’s the point. The decision was small at the time and irreversible by the time it mattered. Most licensing damage is exactly this shape: a missed check at the cheap moment that becomes a structural problem at the expensive moment. The fix is to make the check unavoidable.

Two families, one network clause

Every open-source license falls into one of a few families. You don’t need to memorize the long tail — you need to know the two families that actually decide whether you ship.

Permissive: MIT, Apache 2.0, BSD, ISC

You can use, modify, and distribute the code inside a closed-source commercial product. You generally have to keep the copyright notice and (for Apache) ship a NOTICE file. That’s the entire compliance cost.

Apache 2.0 carries one feature MIT does not: an explicit patent grant.Every contributor to an Apache-licensed project grants you a patent license for their contributions. If they later try to sue you over a patent that covers their own contributed code, they lose the patent license automatically. For anything you’re going to depend on long-term, Apache 2.0 is the safer permissive choice — the patent grant is real protection.

Strong copyleft: GPL, AGPL

Viral. If you incorporate a GPL library into your product, your entire product is now GPL — and you must publish your full source code under GPL terms.One library, one link, your whole codebase opens. That’s not a rhetorical exaggeration; that’s the actual mechanism in the license.

Standard GPL has a loophole companies used for years: the obligation triggers on distribution. If you never shipped binaries — if you only hosted the code on your servers and let users interact with it over a network — you didn’t trigger the disclosure clause. SaaS companies built whole stacks on top of GPL code this way.

The AGPL (Affero GPL) was written specifically to close that loophole. Under the AGPL, network interaction counts as distribution. If you modify AGPL code and let users hit it over HTTP, you must publish the modified source. Hosting is the trigger. There is no SaaS exemption.

This is why Google bans AGPL outright internally. The rule is not ambiguous — it’s very clear — and the compliance cost (publish everything you touched) is structurally incompatible with running closed-source SaaS. Most commercial AI shops follow the same rule.

Restrictive: BUSL, SSPL, custom commercial

A newer family. Not technically open-source under OSI definitions, but you’ll see them on real projects. HashiCorp moved Terraform from MPL 2.0 to the Business Source License (BUSL) to restrict competing commercial use. The community forked the last MPL version into OpenTofu within weeks. OpenObserve switched from Apache 2.0 to AGPL specifically to stop hyperscalers from reselling their software as a managed service.

Both moves are legal and increasingly common. The implication for you: a library you depended on under permissive terms can change license under you. If the upstream relicenses to AGPL or BUSL, your old version is still under the old terms — but every update from that point forward is under the new license. The fork ecosystem (OpenTofu being the canonical example) exists precisely for teams that want to keep shipping under the old permissive terms.

The model layer is the same problem, harder

For AI shops, the license trap that bites hardest is at the model layer. Fine-tuned weights are a derivative work of the base model and inherit the upstream license. If the base model is Apache 2.0, the fine-tune is essentially Apache 2.0 too — ship freely. If the base is non-commercial, the fine-tune is non-commercial too — you cannot ship it in a paid product without violating the license. If the base is AGPL-style, the network clause comes with you.

Picking the base model is therefore a license decision, not just a quality decision. The teams that get this right pick a permissive open-weight base before training. The teams that get it wrong only learn at exit diligence that their flagship feature is encumbered.

Three ways teams sink

The most common license failures I see. None of them are about understanding licensing — they’re about not running the check at the right moment. Hover any card to see the diagnosis.

The pattern across all three: the check happens too late or not at all. The fix is the same — move the license check upstream, into dependency selection and model selection, and gate it mechanically so future-you cannot skip it.

The license-check prompt

The diagnostic that should fire on every new dependency, every base-model selection, and (at least once) on your existing dependency tree.

Walk every dependency in this project — top-level AND transitive.
For each, report:
- Name and version
- License (SPDX identifier)
- Family: permissive (MIT/Apache/BSD), weak copyleft (LGPL/MPL), strong
  copyleft (GPL/AGPL), or restrictive (SSPL/BUSL/non-commercial)
- Risk for a closed-source commercial product served over a network

Sort by risk. Flag anything strong-copyleft or restrictive at the top.

For every flagged item, answer:
- Is this dependency actually linked into the shipping product, or
  only used in dev/build/test? (Dev-only is usually safe.)
- Is there a permissive equivalent we could swap in?
- If we keep it, what compliance steps are required (publish source,
  attribution, network-accessible source link)?

Same prompt applies to model selection: for any open-weight base
model in the project, run the same check on the model card license.

What this catches:

• Transitive copyleft. The clean-looking permissive parent that pulls GPL three layers down.
• Relicensing surprises. A dependency that was Apache last year and is BUSL now.
• Non-commercial base models. The fine-tuning candidate that locks your derivative.
• Restrictive custom licenses. The library with a friendly-looking license file that turns out to forbid your exact use case.

Run it once on your existing project as a baseline. Then add a CI gate so it runs on every new dependency before merge. The cost is one initial audit and a config file. The payoff is that license is a property you maintain on purpose instead of discover by accident.

Annotated transcript

A real walkthrough: pick between two libraries, understand why AGPL disqualifies one of them, learn how the network clause works, then audit the transitive tree and the base-model layer. Click any pinned annotation for the “why this turn matters” commentary.

The decision rule — paste this into your CLAUDE.md

The whole lesson collapses to one checklist. Use it on every dependency, every base model, every fork-vs-stay decision.

# License decision rule

Before any new dependency or base model enters the shipping path:

1. Identify the license. Read the actual LICENSE file, not memory.
2. Classify the family:
     - Permissive (MIT, Apache-2.0, BSD, ISC) → safe to ship.
     - Weak copyleft (LGPL, MPL) → safe in most cases; dynamic
       linking and isolated modifications usually OK. Read terms.
     - Strong copyleft (GPL, AGPL) → assume disqualifying for
       any closed-source product. AGPL is disqualifying even for
       SaaS — the network clause closes the hosting loophole.
     - Restrictive (BUSL, SSPL, non-commercial, custom) →
       case-by-case. Read the actual terms.
3. If the license is permissive, prefer Apache 2.0 over MIT for
   anything load-bearing. The explicit patent grant is real
   protection.
4. Walk the transitive tree. Copyleft underneath a permissive
   parent still applies to your linked product.
5. For AI base models: same check, applied at model selection.
   Fine-tunes inherit the base license. Pick the base
   deliberately.
6. Block the disallowed licenses in CI. Don't rely on memory
   or vigilance. Mechanical enforcement.

When in doubt: pick the Apache 2.0 alternative and move on.
The cost of the safer choice is small. The cost of the wrong
choice is a rewrite or a forced disclosure.

The rule isn’t complicated. The discipline is in actually running it at the cheap moment — dependency selection, model selection — instead of discovering the answer at the expensive moment.

Prompt kit

Three prompts for auditing the tree, reviewing new dependencies, and gating model selection. Drop them into your CLAUDE.md or a personal snippets file so future sessions fire them automatically.

Walk every dependency in this project — top-level AND transitive.
For each, report:
- Name and version
- License (SPDX identifier)
- Family: permissive (MIT/Apache/BSD), weak copyleft (LGPL/MPL), strong
  copyleft (GPL/AGPL), or restrictive (SSPL/BUSL/non-commercial)
- Risk for a closed-source commercial product served over a network

Sort by risk. Flag anything strong-copyleft or restrictive at the top.

For every flagged item, answer:
- Is this dependency actually linked into the shipping product, or
  only used in dev/build/test? (Dev-only is usually safe.)
- Is there a permissive equivalent we could swap in?
- If we keep it, what compliance steps are required (publish source,
  attribution, network-accessible source link)?

Same prompt applies to model selection: for any open-weight base
model in the project, run the same check on the model card license.

I want to add this new dependency: <package@version>.
Before I run the install:

1. What's the license? Confirm against the package metadata, not memory.
2. What's the family — permissive, weak copyleft, strong copyleft,
   or restrictive?
3. Does it have a patent grant? (Apache 2.0 yes; MIT no; GPL family
   has its own structure.)
4. Walk one level deep into its transitive dependencies. Any
   copyleft underneath the permissive top?
5. If we're shipping this in a closed-source network product, is
   this safe to merge?

Output: a one-line verdict (safe / safe-with-conditions / blocked)
plus the reasoning. If safe-with-conditions, list the conditions
(attribution, NOTICE file, link to source, etc.).

I'm about to fine-tune <base model name> for <use case>.
Before any training run:

1. What's the upstream license on the base model weights?
   Read the model card, not training data.
2. Is it permissive (Apache 2.0, MIT-style open weights),
   restricted commercial use, non-commercial only, or copyleft?
3. What does the license say specifically about derivative
   works (fine-tunes, LoRA adapters, distilled models)?
4. Does the license restrict redistribution of the fine-tuned
   weights? Restrict commercial use of model outputs?
5. If we ship a product feature built on this fine-tune, what
   compliance steps are required?

Output: verdict plus the specific clauses we'd need to comply
with. If non-commercial or AGPL-style, recommend a permissive
alternative at similar quality before any compute is spent.

Apply this — audit your tree today

15-minute exercise. The license-tree scan takes minutes. Reading the output and deciding what to do takes longer. The CI gate is a one-time setup that pays back forever.