A permissive license is an open-source license that lets you use, modify, and redistribute software with very few conditions — typically just preserving the copyright notice — but "few conditions" is not "no conditions," and treating a permissive software license as consequence-free is where compliance programs quietly break. MIT, BSD, and Apache 2.0 are the licenses most projects mean when they say permissive, and each carries obligations and risks that matter once you ship at scale.
What makes a license permissive
Open-source licenses fall roughly into two camps. Copyleft licenses like the GPL require that derivative works be released under the same license, which can force you to open-source your own code under some conditions. Permissive licenses do not impose that reciprocity: you can take permissively licensed code, modify it, combine it with proprietary code, and ship the result commercially without releasing your source.
That freedom is exactly why permissive licenses dominate modern dependency trees. A typical application pulls in hundreds of MIT- and Apache-licensed packages precisely because they impose minimal friction. But every one of them still carries a license, and every license carries at least one obligation.
MIT, BSD, and Apache 2.0 compared
The three common permissive licenses share a core but differ in important details.
The MIT license is the shortest and most permissive in practice. Its single meaningful condition is that you include the original copyright notice and the license text in copies or substantial portions of the software. It says nothing explicit about patents or trademarks.
The BSD licenses (2-clause and 3-clause) are close cousins of MIT. The 2-clause version is nearly identical in spirit. The 3-clause version adds a non-endorsement clause: you cannot use the names of the project or its contributors to promote your derived product without permission. Both, like MIT, require preserving the copyright notice.
The Apache License 2.0 is longer because it is more explicit, and that explicitness is a feature. It adds an express patent grant: contributors grant you a license to any patents they hold that are necessary to use their contribution, and it includes a patent-retaliation clause that terminates that grant if you sue over patents. It also requires that you state significant changes you make to the files and that you propagate the NOTICE file. MIT and BSD, by contrast, are silent on patents, which means the patent situation is ambiguous rather than granted.
The obligations people skip
The recurring compliance failure is assuming permissive means obligation-free. It does not. Even the most permissive licenses require attribution — you must preserve and distribute the copyright and license text. For a web application shipping compiled JavaScript, or a mobile app, or a container image, satisfying attribution means actually bundling those notices somewhere the user can find them (a licenses screen, a NOTICES file). Teams routinely ship without it and are technically in breach of hundreds of licenses at once.
Apache 2.0 adds two easy-to-miss duties: propagating the NOTICE file and documenting significant modifications. BSD-3-Clause adds the non-endorsement rule. None of these are onerous, but "not onerous" only helps if someone is actually tracking them.
The security angle: permissive is not audited
Here is the risk that catches security teams off guard: a permissive license makes zero statements about the quality, maintenance, or safety of the code. The MIT license, like the others, ships with an explicit "AS IS" warranty disclaimer. Permissive licensing tells you what you are legally allowed to do with the code; it tells you nothing about whether the code is maintained, whether it has known vulnerabilities, or whether its maintainer is still around.
This matters because permissively licensed packages are the ones teams pull in most freely, precisely because the license imposes no friction. Low legal friction encourages low scrutiny, and low scrutiny is how an abandoned, vulnerable, or compromised dependency enters a build. The license and the vulnerability are independent axes: a package can be perfectly MIT-licensed and riddled with CVEs, or GPL-licensed and pristine. You need to evaluate both, and an SCA tool such as Safeguard reports license and vulnerability data side by side for exactly this reason.
License risk you should actually watch for
Beyond attribution hygiene, a few permissive-license risks deserve active monitoring:
- License changes over time. A project that was permissive can relicense a future version under something restrictive (several high-profile projects have moved to source-available or business-source licenses). Pinning versions and tracking license changes in your SBOM protects you.
- License incompatibility. Combining code under different licenses can create conflicts. Permissive licenses are generally compatible with each other and with proprietary code, but mixing in copyleft components changes the calculus for your whole distribution.
- Missing or ambiguous licenses. A dependency with no license file is not "free to use" — absent an explicit grant, default copyright applies and you have no permission at all. These show up constantly in transitive dependencies.
Building license discipline into the pipeline
The durable answer is automation, same as with vulnerabilities. Maintain an SBOM that records the license of every component. Define a policy of allowed, flagged, and forbidden licenses, and enforce it in CI so a new copyleft or unknown-licensed dependency fails the build rather than surfacing during an acquisition due-diligence review. Generate and ship attribution notices as part of your build so you satisfy the one obligation every permissive license actually imposes. For a deeper walk through building this out, the Safeguard Academy covers license and dependency governance.
Permissive licenses earned their popularity honestly: they remove friction and enable the open-source ecosystem most software is built on. The mistake is letting "permissive" slide into "unmonitored." The obligations are light, but light obligations still have to be met, and the license says nothing about whether the code is safe to run.
FAQ
What is a permissive license?
A permissive license is an open-source license that allows use, modification, and redistribution — including in proprietary and commercial products — with minimal conditions, usually just preserving the copyright and license notice. MIT, BSD, and Apache 2.0 are the common examples.
What is the difference between MIT, BSD, and Apache 2.0?
All three require attribution. BSD-3-Clause adds a non-endorsement clause. Apache 2.0 adds an explicit patent grant with patent-retaliation, and requires you to state significant changes and propagate the NOTICE file. MIT and BSD are silent on patents, leaving that situation ambiguous.
Is a permissive software license risk-free?
No. Every permissive license still requires attribution, which many teams fail to ship. The license also makes no claim about code quality or security, so a permissively licensed package can still contain serious vulnerabilities. Evaluate license and security separately.
Can a permissively licensed project change its license later?
Yes. Projects can relicense future versions under more restrictive terms, and several well-known ones have. Pin versions and track license metadata in your SBOM so a downstream license change does not silently affect your product.