The BSD license full form is the Berkeley Software Distribution license, named after the University of California, Berkeley, where it originated to cover BSD Unix and its derivatives in the early 1990s. It's one of the oldest permissive open-source licenses still in wide use, and its defining trait is how little it asks of anyone who reuses the code — no requirement to open-source derivative works, no copyleft obligation, just attribution and a liability disclaimer.
What does the BSD license actually require you to do?
At its core, the BSD license requires that you keep the original copyright notice and license text intact when you redistribute the source code, and (in source or binary form) include that same notice and disclaimer with the redistributed copy. Beyond that, it grants broad permission to use, modify, and redistribute the code — including in proprietary, closed-source products — without any obligation to release your own modifications or share your derivative work's source. That's the core distinction from copyleft licenses like the GPL: a BSD-licensed component can be embedded in a commercial closed-source product with essentially no downstream licensing obligation beyond the attribution notice.
What's the difference between the 2-clause and 3-clause BSD license?
The original 4-clause BSD license included an advertising clause requiring any promotional material mentioning features of the software to credit the University of California — a requirement that turned out to be impractical at scale and was officially retracted in 1999. The 3-clause BSD license (sometimes called "New BSD" or "Modified BSD") dropped that advertising clause but kept a non-endorsement clause, preventing the names of the organization or contributors from being used to promote derived products without permission. The 2-clause BSD license ("Simplified BSD" or "FreeBSD License") strips it down further, keeping only the copyright notice and disclaimer requirements and dropping the non-endorsement clause too — making it nearly equivalent to the MIT license in practical effect.
How does the BSD license compare to MIT and Apache 2.0?
All three are permissive licenses with the same basic shape: minimal obligations, no copyleft, safe for use in proprietary software. The 2-clause BSD license and MIT are close enough in substance that the choice between them is mostly a matter of convention within a particular ecosystem or organization's preference. Apache 2.0 adds meaningfully more than either: an explicit patent grant from contributors to users (protecting users from patent claims by contributors over their own contributed code) and a requirement to document any changes made to the original file. For a business evaluating license risk in a dependency tree, BSD and MIT sit in essentially the same low-risk bucket, while Apache 2.0's patent grant is a genuine additional protection some legal teams specifically look for.
Why does the BSD license still matter for modern open-source compliance?
Even though newer projects more often default to MIT or Apache 2.0, BSD-licensed code is still deeply embedded in foundational infrastructure — parts of the Unix and BSD lineage, networking code, and cryptographic libraries that predate the more recent licensing conventions. A dependency scan on almost any non-trivial codebase will surface at least a few BSD-licensed transitive dependencies, and distinguishing the 2-clause, 3-clause, and old 4-clause variants matters because the 4-clause version's advertising clause is genuinely incompatible with the GPL and creates real friction if it shows up in a modern dependency tree. Automated license detection that can tell these variants apart — rather than bucketing everything simply as "BSD" — avoids both false alarms and missed obligations.
How should a team track BSD and other license obligations across a dependency tree?
Manually reading license files across hundreds or thousands of transitive dependencies isn't realistic once a project grows past a handful of direct packages, and license text alone doesn't always make clear which BSD variant applies or whether a bundled NOTICE file adds obligations beyond the license itself. A license scanner that resolves the full dependency graph and classifies each component's license — flagging copyleft licenses like GPL or AGPL for legal review while treating permissive licenses like BSD, MIT, and Apache 2.0 as lower risk — turns this from a one-time manual audit into a check that runs on every build. Safeguard's SCA product includes this license classification alongside vulnerability scanning, so a component that introduces both a known CVE and an unexpected copyleft obligation shows up in the same finding instead of two separate audits catching each half of the problem independently. Pairing that with a documented open source software policy gives engineering and legal a shared reference for which licenses need sign-off before a new dependency ships.
FAQ
Is the BSD license copyleft?
No — BSD is a permissive license. It doesn't require derivative works to be open-sourced or licensed under the same terms, which is the defining difference from copyleft licenses like the GPL and AGPL.
Can BSD-licensed code be used in proprietary commercial software?
Yes, as long as the required copyright notice and disclaimer are preserved in the redistributed source or accompanying documentation — there's no requirement to release your own code's source or use a compatible license for the rest of your product.
What's the most common BSD variant in use today?
The 3-clause BSD license is the most commonly used variant in current open-source projects; the original 4-clause version with the advertising clause is largely historical at this point.
Is BSD license compatible with the GPL?
The 2-clause and 3-clause BSD licenses are generally considered GPL-compatible, meaning BSD-licensed code can be incorporated into a GPL-licensed project. The original 4-clause BSD license, because of its advertising clause, is not compatible with the GPL.