The BSD License is a family of short, permissive open-source licenses — most commonly the 2-clause and 3-clause variants — that let you use, modify, and redistribute software freely, including in proprietary products, provided you retain the copyright notice, the license conditions, and the warranty disclaimer. Originating with the Berkeley Software Distribution of Unix in the late 1980s, BSD licenses are functionally very similar to the MIT License and are used by projects such as FreeBSD, Nginx (2-clause), and Go's standard library components. The main practical distinction among the variants is a single extra clause about using contributors' names for endorsement.
This article explains the BSD license family in general terms. It is not legal advice — consult a qualified attorney about your specific situation.
The BSD Variants at a Glance
There are three historically significant BSD variants, though only two are in common modern use.
| Variant | Key characteristics |
|---|---|
| BSD 2-Clause ("Simplified" / "FreeBSD") | Requires retaining the copyright notice, the list of conditions, and the warranty disclaimer in source and binary redistributions |
| BSD 3-Clause ("New" / "Modified") | Adds a third clause: you may not use the names of the project or its contributors to endorse or promote derived products without permission |
| BSD 4-Clause ("Original") | Adds an "advertising clause" requiring attribution in advertising material; now discouraged and incompatible with the GPL |
The 2-clause version is essentially MIT with a slightly different wording. The 3-clause version adds a non-endorsement clause that protects the reputation of the original authors — it stops you from implying that they endorse your product. The 4-clause original is largely deprecated because its advertising clause created practical and licensing-compatibility problems; the Berkeley developers themselves retired it in 1999.
What the BSD License Permits and Requires
Across the modern variants, the permission-and-obligation picture is consistent.
| Category | Details |
|---|---|
| Permissions | Commercial use, modification, distribution, private use, and use in proprietary/closed-source software |
| Conditions | Retain the copyright notice, the list of license conditions, and the warranty disclaimer in redistributions; (3-clause only) do not use contributors' names to endorse derived products |
| Limitations | No warranty; no liability; no explicit patent grant; (3-clause) no endorsement rights |
Like MIT, BSD licenses are silent on patents, so they provide no explicit patent protection the way Apache 2.0 does.
Is the BSD License Copyleft or Permissive?
Every mainstream BSD variant is permissive. There is no copyleft obligation: you can take BSD-licensed code, modify it, and ship it inside a closed-source commercial product without releasing your own source. The conditions are limited to preserving notices and, for the 3-clause version, refraining from misusing the authors' names.
Compatibility is generally excellent. The 2-clause and 3-clause BSD licenses are compatible with the GPL, so BSD code can be incorporated into GPL projects. The retired 4-clause version is the exception — its advertising clause is incompatible with the GPL, which is one reason it fell out of favor. For a side-by-side look at how BSD sits relative to MIT, Apache, and the copyleft licenses, see our comparison pages.
What the BSD License Means for Your Project and Compliance
Consuming BSD-licensed dependencies is about as low-risk as open source gets, but there are still real obligations worth encoding into your process.
The universal obligation is attribution: when you redistribute software containing BSD code, you must reproduce the copyright notice, the license conditions, and the warranty disclaimer. For binary distributions, the license explicitly requires that these appear in your documentation or other accompanying materials — so a third-party notices file or an acknowledgments screen is the standard way to comply.
If you use 3-clause BSD code, add the endorsement restriction to your awareness: your marketing must not suggest that the upstream authors back your product. This rarely causes problems in practice, but it is a genuine license term, not a courtesy.
Because BSD variants look almost identical at a glance, the most common real-world issue is misidentification — treating a 3-clause component as 2-clause, or missing that a dependency is actually the deprecated 4-clause form with its GPL-incompatible advertising clause. Accurate detection matters here, and it is exactly the kind of nuance our concepts library helps teams reason about.
How Safeguard Tracks BSD License Compliance
The permissive simplicity of BSD is a trap if it lulls you into skipping inventory. You still owe attribution for every BSD component you distribute, and you still need to distinguish the variants — especially to catch a GPL-incompatible 4-clause dependency before it causes a conflict.
Safeguard's Software Composition Analysis detects every open-source component in your project and resolves its precise license, distinguishing BSD 2-clause from 3-clause and flagging the rare 4-clause form. Because it walks the full transitive dependency tree, it surfaces BSD components buried deep beneath your direct dependencies where manual review never reaches.
That inventory becomes a formal record through SBOM Studio, which emits a CycloneDX or SPDX software bill of materials capturing each component's exact license. From that SBOM you can generate the attribution notices you are obligated to ship and prove compliance during an audit. Policy rules enforce your approved-license list, so a deprecated or incompatible variant is caught automatically rather than discovered late. The academy provides a hands-on path for building this into your release process.
Create a free account to inventory the licenses in your own repository, or read the documentation for setup instructions.
Frequently Asked Questions
What is the difference between BSD 2-clause and 3-clause? The 3-clause version adds a single extra term: you may not use the names of the project or its contributors to endorse or promote products derived from the software without written permission. Everything else — the broad permissions and the attribution and warranty-disclaimer conditions — is the same. The 2-clause version omits that non-endorsement clause and is otherwise nearly identical to the MIT License.
Is the BSD License compatible with the GPL? The 2-clause and 3-clause BSD licenses are compatible with the GPL, so their code can be combined into a GPL-licensed project. The original 4-clause BSD license is not GPL-compatible because of its advertising clause, which is a major reason that variant was deprecated. When combining code, always verify the exact BSD variant in use.
Can I use BSD-licensed code in commercial software? Yes. All mainstream BSD variants are permissive and explicitly allow commercial and closed-source use. You are not required to release your own source code. You must retain the copyright notice, the list of conditions, and the warranty disclaimer in your redistribution, and for 3-clause code you must avoid implying endorsement by the original authors.
Does the BSD License cover patents? No. Like the MIT License, the BSD licenses address copyright but are silent on patent rights. If explicit patent protection is important to your organization, a license with a written patent grant, such as the Apache License 2.0, provides more certainty than BSD does.