MIT vs Apache-2.0: how I chose a license for my open-source project

I’m in the process of open-sourcing nanomux, a tiny chat-to-AI agent harness I’ve been building. I assumed picking a license would be an easy task. Pick MIT, copy the standard text, push the commit, move on.

It turned into deep research. And it changed how I think about what an OSS license is actually for.

I want to share what I found, because most license advice I read online stops at “pick MIT, you’re fine.” I think that misses the more interesting question.

I’d also like input from people who have shipped or used open-source projects extensively before, because I’m not 100% sure I made the right call. In particular, what options would you prefer and why?

The starting point

In the JS/TS ecosystem I live in (Vite, Vue, Express, React, Lodash, Astro, Hono), MIT is the convention. The shortest license file. The lowest friction. Anyone can read it in 30 seconds.

That was my plan. Then I asked one more question: What is the difference between MIT and Apache-2.0? When would you pick one over the other?

That question changed the framing for me.

The realistic options

For a primitive that other people will embed in their own products, the realistic choices narrow to a few buckets.

Permissive (good for adoption):

MIT. Most permissive. No explicit patent grant.
Apache-2.0. Permissive plus an explicit patent grant and a NOTICE-file requirement.
BSD-3-Clause. MIT-equivalent in practice, plus a “no endorsement” clause.

Weak copyleft (middle ground):

MPL-2.0. Modifications to MPL files must be shared back, but you can link MPL code into a proprietary product without infecting it. (Firefox uses this.)

Strong copyleft (restricts commercial embedding):

LGPL-3.0, GPL-3.0, AGPL-3.0. Anything that links to them must also be GPL. AGPL adds a network-use trigger, so SaaS counts as distribution. These will scare off most commercial adopters.

Source-available (not OSI-approved):

BSL, Elastic, SSPL, FSL. Time-delayed open source or commercial-restriction licenses. Useful if you want to monetise hosting later. Won’t show as “open source” on GitHub. Some orgs auto-block them.

For a project I want others to embed freely as a neutral primitive, the strong copyleft and source-available buckets are out. So the real choice was between MIT and Apache-2.0.

MIT vs Apache-2.0: the real differences

Both let anyone use, modify, sublicense, and ship in closed-source or commercial products. Both are OSI-approved, GPL-compatible, and treated as “permissive.” The differences are narrow but matter at scale.

1. Patent grant (the big one).

MIT is silent on patents. You implicitly get a patent license under most legal theories, but it’s not written down. If a contributor holds a patent on something they contributed and later sues a user over it, the user has weaker defences.

Apache-2.0 has an explicit grant. Every contributor grants users a perpetual, royalty-free patent license to their contributions. It also has a “patent retaliation” clause: if you sue an Apache project (or its users) for patent infringement on the project, your own grant terminates automatically.

This is why most enterprise legal teams prefer Apache-2.0 for anything they depend on heavily. It’s predictable.

2. NOTICE handling.

MIT: copy the ~10-line license and copyright into your distribution. Done.

Apache-2.0: copy the LICENSE, and if the project ships a NOTICE file, you must propagate that NOTICE in your distribution too. More paperwork for redistributors. Tools like license-checker and SBOM generators handle this fine. Humans find it tedious.

3. Trademark.

MIT is silent on trademarks.

Apache-2.0 is explicit: the license does not grant trademark rights. So someone forking your Apache-2.0 project can’t call their fork by your project’s name without permission. With MIT, trademark is governed by separate trademark law (similar outcome, less crisp).

4. Length and friction.

MIT is ~170 words. Anyone can read it in 30 seconds.

Apache-2.0 is ~3,000 words across 9 sections. Reads like a contract because it is one. Some hobbyist contributors find it intimidating.

5. Compatibility quirk.

Apache-2.0 is incompatible with GPL-2.0 (but fine with GPL-3.0). MIT is compatible with both. In practice, this matters for almost no one. GPL-2.0-only projects are a shrinking set.

Which one has more adoption?

MIT wins on raw count. From what I found, MIT covers roughly 45% of all licensed repos on GitHub, Apache-2.0 around 18%, the GPL family around 15%, everything else trailing.

But that count is dominated by small projects. If you weight by stars, downloads, or enterprise dependency graphs, the picture shifts:

Solo devs and hobbyist projects skew heavily MIT.
Mid-size frontend and JS ecosystem skews MIT (Vite, Vue, Astro, Hono, Express, React, Lodash).
Infrastructure, languages, protocols, CNCF-tier projects skew Apache-2.0 (Kubernetes, Rust, TypeScript, Swift, Terraform, Helm, Envoy, gRPC, Spark, Kafka).
Big-company-backed OSS skews Apache-2.0 (Go, Angular, TensorFlow, most AWS projects).

So the honest answer: MIT has more projects. Apache-2.0 has more enterprise weight per project.

Is MIT actually friction for enterprise?

This is the question I think most posts get wrong. MIT is not friction for enterprise adoption. Big companies install MIT-licensed packages every day. Their license-scanning tools have an MIT allowlist; it just sails through.

Where MIT can be friction:

Patent-sensitive domains. Companies with large patent portfolios (or who get sued a lot) prefer Apache-2.0 for anything touching protocols, ML, crypto, distributed systems.
Strategic, load-bearing dependencies. If a company plans to build their entire platform on top of your project, their legal review is more thorough than for a random utility.
Contributing back. Apache-2.0 is friendlier for corporate contributors. The explicit patent grant means their lawyers don’t have to construct one from scratch under their CLA. Some enterprises won’t contribute to MIT projects without the project also adopting a CLA, because of the patent ambiguity.

For everything else (solo devs, startups, mid-market), MIT is fine.

What I picked, and why

For nanomux, I picked Apache-2.0. Three reasons.

1. Adoption shape. nanomux is positioned as a primitive that other people embed in their own products (third-party harnesses, channels, providers). That’s enterprise-shaped adoption, the kind of users who care about patent grants.

2. Brand split. I have a deliberate split: nanomux is the neutral infrastructure, nanogent.ai is the product. Apache-2.0’s explicit trademark clause reinforces that. If someone forks nanomux into “nanomux-pro” or “nanomux-cloud”, I have a written hook to push back.

3. Vibe. This is the one cutting the other way. Today the project is solo-maintained, plugin-friendly, hacker-aesthetic. MIT is the convention in that world. Apache-2.0 can read as “this project takes itself seriously,” which is either a feature or a turn-off depending on the audience. This argued for MIT, but I think the structural reasons above are stronger than the aesthetic one.

The patent grant and trademark clause are exactly the two things that protect the “neutral primitive” positioning long-term. The friction cost (longer license file, NOTICE discipline) is one-time and trivial.

But I might be wrong.

Where I’d appreciate your input

If you’ve shipped or used an open-source project extensively before, here are the specific things I’m still uncertain about.

Did you ever regret picking MIT or Apache-2.0? What was the signal that flipped the regret?
For projects positioned as primitives (libraries, frameworks, harnesses), did the license choice meaningfully change what kind of adopter showed up?
For solo-maintained projects that aspire to enterprise adoption later, is there a real case for starting MIT and migrating to Apache-2.0 once the project finds its shape (or vice versa)? Or is the migration cost too high in practice once you have downstream forks?
NOTICE files in practice. If you ship Apache-2.0, do you actually maintain a NOTICE file, or do you ship just the LICENSE and call it a day?

I read a lot of articles and a lot of license texts. The cleanest signal, I think, comes from people who have lived with the consequences of the choice. If that’s you, drop a comment or DM.

I’ll share what I learn back here.

#OpenSource #SoftwareDevelopment #AI #StartupLife #BuildInPublic