The BSD 3-clause license is a permissive open source software license that lets you use, modify, and redistribute code with almost no restrictions, provided you keep the copyright notice, preserve the disclaimer of warranty, and don't use the original authors' names to promote your own derivative product without permission. It's one of the oldest open source licenses still in active use, dating back to the Berkeley Software Distribution project, and it remains common in networking libraries, academic software, and infrastructure projects. If you're pulling dependencies into a commercial product, understanding exactly what the bsd-3-clause license obligates you to do — and what it doesn't — matters for both legal compliance and basic professional courtesy toward the maintainers.
What are the three clauses in the BSD 3-clause license?
The license gets its name from three conditions attached to an otherwise very permissive grant of rights. First, redistributions of the source code must retain the original copyright notice, the list of conditions, and the disclaimer. Second, redistributions in binary form — meaning you've compiled the code into your own product without shipping the source — must reproduce that same copyright notice and disclaimer in the documentation or other materials provided with the distribution. Third, and this is the clause that distinguishes it from the older BSD 4-clause license, neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from the software without specific prior written permission.
That third clause is the non-endorsement clause, and it's the entire reason "3-clause" exists as a distinct license from its predecessor. The original 4-clause BSD license included an advertising clause requiring any advertising material mentioning features of the software to acknowledge the University of California, Berkeley — a requirement that became so unwieldy in practice (imagine every product built on BSD-derived networking code needing an acknowledgment in its ads) that Berkeley itself rescinded it in 1999, and the license was rewritten without it.
How does the BSD 3-clause license compare to MIT and Apache 2.0?
All three are permissive licenses that impose minimal restrictions compared to copyleft licenses like the GPL, but they differ in a few specific ways worth knowing. The MIT license is functionally very close to BSD 3-clause — both require preserving the copyright notice and disclaimer — but MIT doesn't include an explicit non-endorsement clause, since MIT's brevity leaves that concern unaddressed rather than explicitly forbidding it. Apache 2.0 goes further than either: it includes an express patent grant, meaning contributors explicitly license any patents they hold that are necessarily infringed by their contribution, and it requires you to state significant changes made to modified files. Neither BSD 3-clause nor MIT include that patent language, which matters more in patent-heavy industries than most application developers realize.
In practice, this puts BSD 3-clause squarely in the same permissive tier as MIT for day-to-day compliance purposes: attach the notice, don't imply endorsement, and you're compliant. It's a meaningfully lighter compliance burden than the various types of open source license that impose copyleft obligations, where using a library can create requirements to release your own source code under matching terms.
Can you use BSD 3-clause licensed code in a closed-source, commercial product?
Yes. This is precisely what makes it, along with MIT and Apache 2.0, one of the most business-friendly permissive licenses: there's no requirement to release your own source code, no requirement that derivative works carry the same license, and no restriction on commercial use or sale. Companies routinely bundle BSD-licensed components into proprietary products without any obligation beyond the attribution requirement. The catch — and it's a common compliance gap — is that the attribution requirement doesn't disappear just because your product is closed source; you still need to include the copyright notices for any BSD 3-clause components somewhere in your product's documentation, license file, or about screen, even if none of your own source is public.
Why does BSD 3-clause compliance still trip teams up?
The obligations are minimal, but tracking which BSD 3-clause components you're actually shipping — including transitive dependencies pulled in by other packages — is where teams fall short. A project can accumulate dozens of BSD-licensed libraries several layers deep in its dependency tree, and if none of those notices make it into a shipped attribution file, you're technically out of compliance even though the substantive requirement (don't remove the notice, don't imply endorsement) is trivial to meet. This is exactly the kind of gap software composition analysis tooling is built to close — enumerating every open source license across your full dependency graph, not just the packages you added directly, so attribution and license-compatibility questions get answered automatically instead of during an acquisition due diligence scramble. Getting license inventory and open source license management right early is far cheaper than reconstructing it under deadline pressure.
FAQ
Is BSD 3-clause considered a permissive or copyleft license?
Permissive. It imposes no requirement that derivative works be released under the same license or that your own source code be disclosed, unlike copyleft licenses such as the GPL family.
What happened to the BSD 4-clause license?
It included an additional advertising clause requiring acknowledgment of the University of California, Berkeley in promotional materials for any product using the software. Berkeley rescinded that clause in 1999 because it became impractical to track and satisfy across the software ecosystem, giving rise to the 3-clause version now in common use.
Do I need a lawyer to comply with BSD 3-clause?
For straightforward use — keeping the license text and copyright notice with the code, and not implying the original authors endorse your product — most teams handle this without legal review. Complex scenarios, like relicensing a heavily modified fork or large-scale redistribution, are where legal counsel becomes worthwhile.
Does BSD 3-clause require me to publish my modifications?
No. Unlike copyleft licenses, BSD 3-clause doesn't require you to share modifications or your own source code, whether you distribute your product as source or as a compiled binary.