What is a Permissive license?

What a permissive licence actually grants

The grant is deliberately unconditional. You may use the program for anything, copy it, modify it, merge it into something larger, publish it, distribute it, sublicense it, and sell it. There is no field of use, no non-compete, no source-disclosure, no reciprocity.

What remains is a short list of conditions. Keep the copyright notice. Include the licence text with copies you distribute. And, in Apache-2.0, say which files you changed. That is essentially the whole bargain, and the reason the family is called permissive: nothing you do obliges you to give anything back.

The structural consequence is the important part. A permissive dependency can be linked into a proprietary product, modified, and shipped, and the licence is satisfied. There is no mechanism by which your improvements come back, and no obligation that they should. Everything else on this page is downstream of that fact, including the projects at the end, which chose the licence as a strategy about who contributes rather than as a legal formality.

The members of the family differ less than people expect. MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0, ISC, 0BSD and the Unlicense all sit in the same category, and the practical differences between them are a handful of clauses rather than a different philosophy.

The four differences worth knowing

The boilerplate is close enough that reading the whole licence is usually a waste of an afternoon. These are the parts that change an answer.

The patent grant. Apache-2.0 includes an express patent licence from every contributor, and a clause that terminates that patent licence if you initiate patent litigation alleging that the work infringes. MIT and BSD grant no patent rights at all, which leaves the question to whatever you might otherwise have, and it is the single most substantive difference between the two most common choices. For a company that will ship the software commercially, the absence of a patent grant is a question for the legal team rather than a detail.

Notice of modification. Apache-2.0 requires modified files to carry a notice that they were changed. MIT and BSD-3-Clause do not. This is a housekeeping obligation, and it is the kind of thing that gets lost in a large monorepo with a vendored directory.

The endorsement clause. BSD-3-Clause prohibits using the names of the copyright holders to promote derived products without permission. It is not a restriction on distribution and it is not a field-of-use restriction, but it is a condition, and it is the reason some companies decline BSD-3-Clause for a project they intend to commercialise.

Trademark. Apache-2.0 states explicitly that the licence grants no trademark rights. MIT and BSD are silent, which in practice means the same thing. Either way the name and logo are not licensed to you, and that matters the moment you ship a fork under a similar name.

One more item that is easy to miss: version specificity. A licence that says or any later version lets the project move the terms; a licence that names one version freezes them. A dependency that relicences is only a problem for the second kind.

When permissive is the right choice

The licence is a strategy about who improves the code, and permissive wins on adoption.

Adoption. A permissive licence is the cheapest possible way to be usable by a company that will never send a patch. This is why the libraries everything else depends on are permissive: the maintainers are optimising for the number of users, because users are what makes the project worth maintaining.

Infrastructure with a network effect. When the value is in everyone using the same thing, a reciprocal condition costs you adoption and buys you contribution you would not necessarily get.

Legal time. A permissive dependency raises no reciprocity question, no network clause, no derivative-work analysis for the product that ships it. For a company with a hundred dependencies, that is a meaningful amount of avoided review.

A codebase you do not want to open. If the plan is to modify and keep the change private, permissive is the only category that permits it without a negotiation.

There is a case against it, and it is a real one. Permissive dependencies take improvements and return nothing guaranteed, so a company that depends on one and invests in it has a way to fund a fork instead. The counter-argument is equally real: a licence that scares companies away does not get their investment either. Most successful projects take permissive and rely on governance, funding and reputation rather than on the licence to produce contributions.

The traps

Six, and they are all cases where the licence is not what everyone assumed.

The repository is not the artefact. A permissive licence on a repository says nothing about the model weights, the data, the fonts or the assets it ships. This is the single most common surprise in the current ecosystem, and it applies equally to a permissive code repository with a research licence on the weights and to a permissive repository with a proprietary dataset. Check the second artefact separately.

The name is not licensed. Permissive licences grant copyright, not trademark. Shipping a fork under the original name is a different question from shipping a fork at all, and the answer does not come from the licence.

Notices disappear in the build. Every distribution needs the copyright notice and the licence text for every dependency, including ones you never opened. This is an automated task that fails silently, and it is the most common way a permissive obligation is actually breached.

A dependency you did not modify still needs its notice. Silence about the code is not silence about the attribution.

The hosted version is a separate licence. Projects frequently offer a paid hosted service, a commercial licence, or an enterprise edition under different terms. Reading the repository licence tells you nothing about what the company will sell you.

No warranty. Every licence in this family disclaims warranties, including fitness for a purpose. If a dependency is load-bearing for something regulated, the absence of any warranty from the author is a real limit on what you can rely on, and it is why the code gets reviewed.

How the projects use it

The four projects here show the range of reasons a project picks this family, and they are worth reading as four different strategies rather than four licences.

The dependency everyone has. react/react is the clearest case. Our analysis describes it as a JavaScript library for building user interfaces through reusable, encapsulated components that manage their own state, running on the web and on mobile, and it is MIT licensed. A library at that position takes the permissive route because the strategy is adoption, and a copyleft condition on the UI layer of the ecosystem would be a decision nobody could reverse.

Tools that are installed rather than depended on. affaan-m/ECC is MIT licensed and packages agents, skills and a plan-test-review loop into an installable layer for coding agents; our analysis of ECC describes 68 agents and 286 skills, notes that it works best with one particular coding agent today, and that its adapters for other harnesses are explicitly capability-limited. NousResearch/hermes-agent is the same shape: a free, MIT-licensed self-hosted agent that builds persistent memory across sessions, creates and improves its own skills, runs scheduled tasks and connects to messaging platforms, and our analysis describes it as designed to run unattended on a VPS, a container or serverless infrastructure rather than only during a terminal session. Neither of these is anybody else's dependency, and that is exactly why the licence does not need to be interesting.

The long institutional codebase. freeCodeCamp/freeCodeCamp is the platform and curriculum behind freeCodeCamp.org, and our analysis is explicit that it is the running site rather than a course you download. It is BSD-3-Clause licensed, and it is a reasonable example of a large codebase that has been stable and permissively licensed for years, which is a strategy about trust and longevity rather than about contributions.

In practice

A permissive licence trades reciprocity for adoption, and for most projects that is the right trade, which is why the libraries everything depends on are permissive. When you choose one, look at the two clauses that actually differ: the patent grant, which Apache-2.0 has and MIT and BSD do not, and the notice requirements, which Apache-2.0 extends to modified files. Then check the three things the repository licence does not cover: the weights or data, the trademark, and the licence of the paid offering. And keep the attribution in your build, because that is the one obligation you actually signed up for, and it is the one that is easiest to lose.