The BSD license is one of the oldest permissive open source licenses still in active use, originating in 1988 at the University of California, Berkeley, to cover releases of BSD Unix. Unlike copyleft licenses such as the GPL, BSD imposes almost no obligations on downstream users: preserve the copyright notice, preserve the disclaimer, and — in most variants — don't use the original authors' names to promote a derived product. That simplicity is why BSD-licensed code turns up everywhere: FreeBSD, OpenBSD, and NetBSD, Go's standard toolchain, nginx's core, and for several years, React, before Facebook swapped its custom BSD+Patents grant for plain MIT in September 2017. But "permissive" does not mean "obligation-free." The four BSD variants — 0-, 2-, 3-, and 4-clause — carry different requirements that trip up legal and engineering teams during audits, acquisitions, and SBOM reviews. Here are the questions security and compliance teams ask most often about the BSD license.
What Is the BSD License?
The BSD license is a short, permissive software license that grants anyone the right to use, copy, modify, and redistribute source or binary code — including inside closed-source commercial products — provided they retain the copyright notice and a warranty disclaimer. It was written at UC Berkeley's Computer Systems Research Group to accompany releases of the Berkeley Software Distribution, with the first BSD Unix tape shipped in 1978 and the license text itself formalized around 1988–1990 as Berkeley began separating its own code from AT&T-licensed Unix source. The license has no "share-alike" or copyleft requirement, so a company can take BSD-licensed code, modify it, and ship it without ever publishing the changes. The Open Source Initiative has approved several BSD variants, and SPDX assigns each its own identifier — 0BSD, BSD-2-Clause, BSD-3-Clause, and BSD-4-Clause — which is what shows up in a software bill of materials (SBOM) or go.mod/package.json license field when a scanner flags a BSD dependency.
What's the Difference Between BSD-4-Clause, BSD-3-Clause, and BSD-2-Clause?
The variants differ by exactly one or two clauses, and the history is a direct response to a licensing dispute. The original 1988 BSD license had four clauses, the third of which was an "advertising clause" requiring that any promotional material mentioning the software display the credit: "This product includes software developed by the University of California, Berkeley and its contributors." That clause became notorious because every derivative product theoretically had to keep stacking attribution lines from every contributing organization — a real problem once BSD code was reused across dozens of projects. The University of California's Office of Technology Licensing formally rescinded the advertising clause on July 22, 1999, at the request of BSD developers and after lobbying from the FSF, which considered it incompatible with the GPL. That produced the 3-clause license (also called "New BSD," "Modified BSD," or BSD-3-Clause), which replaces the advertising clause with a narrower non-endorsement clause: you can't use the university's or contributors' names to promote derived products without written permission. The 2-clause license (BSD-2-Clause, also called the "Simplified BSD License" or "FreeBSD License") drops the non-endorsement clause too, leaving only the copyright notice and disclaimer — it's functionally almost identical to MIT. In 2019, the OSI approved a 0-clause version (0BSD), written by Rob Landley for the toybox project, which removes even the attribution requirement and is close to a public-domain dedication.
How Does BSD Compare to the MIT License?
BSD-2-Clause and MIT are nearly interchangeable in practice: both are short, non-copyleft, and require only that you keep the copyright notice and disclaimer when redistributing. The MIT License text runs about 171 words and grants rights explicitly, including the right to sublicense; BSD-2-Clause runs about 145 words and reaches the same result through slightly different phrasing. The one meaningful divergence is BSD-3-Clause's non-endorsement clause, which MIT has never included — meaning a MIT-licensed dependency never restricts how you describe your product in marketing, while a BSD-3-Clause one technically does. Both licenses are OSI-approved, both are on the FSF's list of GPL-compatible free software licenses, and both let a company relicense a modified version under closed terms, which is why they dominate npm, PyPI, and Go module ecosystems: as of recent Sonatype and Synopsys OSSRA supply-chain reports, MIT and the BSD family together typically account for a majority of permissively licensed open source components scanned in commercial codebases, with Apache-2.0 close behind.
How Does BSD Compare to the GPL?
The core difference is copyleft: the GNU General Public License — first published in 1989 (GPLv1), revised in 1991 (GPLv2), and again in 2007 (GPLv3) — requires that any distributed derivative work be licensed under the same GPL terms and that its corresponding source code be made available, while BSD imposes no such requirement at all. That distinction has shaped major engineering decisions. Apple's Darwin operating system, the open-source core of macOS and iOS, incorporates a BSD userland derived from FreeBSD and NetBSD precisely because BSD's terms let Apple ship a mostly proprietary OS on top of it; Sony's PS4 and PS5 system software is likewise built on a modified FreeBSD kernel, with no obligation to publish Sony's changes. Under the GPL, doing the equivalent — embedding GPL code in a closed firmware image — has triggered real enforcement, including the Software Freedom Conservancy's 2021 lawsuit against Vizio over GPL/LGPL source-code requests for its SmartCast TV firmware. BSD's permissiveness is exactly why it's the license of choice for infrastructure code that vendors expect hardware and cloud partners to embed without giving anything back.
What Compliance Obligations Does BSD-Licensed Code Actually Carry?
BSD-licensed code carries two real, enforceable obligations: reproduce the copyright notice and license text in your distribution (typically in a LICENSE file, NOTICE file, or "about" screen), and — for 3-clause and 4-clause variants — don't use the contributors' names to endorse or promote your product without permission. Enforcement of these terms is rare compared to GPL litigation, but it isn't hypothetical: the 1992–1994 lawsuit UNIX System Laboratories, Inc. v. Berkeley Software Design, Inc. forced Berkeley to strip several files with disputed AT&T provenance out of its 4.3BSD release, and the settlement (finalized January 1994) directly shaped the cleaned-up 4.4BSD-Lite release that became the ancestor of FreeBSD, NetBSD, and OpenBSD. For a modern engineering org, the practical risk isn't a lawsuit — it's an audit finding: acquirers, enterprise customers, and government contracts increasingly require an accurate SBOM under frameworks like Executive Order 14028 and NTIA minimum elements, and a missing attribution notice for a BSD dependency is a documented compliance gap even when the underlying legal exposure is low. Multiply that across a dependency tree with hundreds of transitive packages and manual license tracking stops being feasible.
What Well-Known Software Uses the BSD License?
Some of the most widely deployed infrastructure software in the world ships under a BSD variant. The FreeBSD, OpenBSD, and NetBSD operating systems are BSD-licensed at their core; Go's compiler, runtime, and standard library are released under BSD-3-Clause by Google; nginx, which powers roughly a third of the world's top web servers according to long-running Netcraft and W3Techs surveys, uses a BSD-2-Clause-style license. React is a instructive edge case: Facebook originally released it under BSD-3-Clause with an additional "Patents" grant that terminated your patent license if you sued Facebook over patents — a term the Apache Software Foundation flagged as non-compliant with its own license policy in 2017. After public pressure, Facebook relicensed React, Jest, and related projects to plain MIT on September 23, 2017, removing the patents clause entirely. The episode is a good reminder that "BSD" isn't always just BSD — vendors sometimes bolt on extra clauses, and those custom terms are exactly what a license scanner needs to catch rather than assume away.
How Safeguard Helps
Tracking BSD variants and their custom riders across a modern software supply chain isn't a one-time legal review — it's a continuous scanning problem, because every go.mod update or npm install can pull in a new transitive dependency under a different clause count or a modified grant like React's old Patents addendum. Safeguard's SBOM generation and ingest pipeline identifies the exact SPDX license identifier for every direct and transitive component — distinguishing 0BSD from BSD-2-Clause from BSD-3-Clause — so compliance teams get an accurate, audit-ready inventory instead of a best-guess spreadsheet. Griffin AI cross-references those license findings against actual code usage, and Safeguard's reachability analysis tells you whether a flagged BSD component is even loaded on an exploitable code path, which matters just as much for a vulnerable BSD-licensed library as it does for a licensing question when you're deciding what to prioritize. When a fix or an attribution gap is identified, Safeguard can open an auto-fix pull request that updates the dependency and the corresponding NOTICE file in the same change, so license hygiene doesn't become a separate backlog item that never gets done.