Open Source License Types: The Obligations You Already Shipped
Choosing the right open-source license is vital as it affects legal protection, compliance, community engagement, & the project's long-term viability.

Finite State Team
A connected product carries hundreds or thousands of open source components. Upstream maintainers selected most of them, a chipset vendor selected more, and a board support package supplier dropped in the rest. Nobody on your team reviewed those licenses, and in most cases nobody knows the full list. The obligations attached anyway, at the moment you distributed the device.
What follows covers both sides. First the four families of open source license types and the SPDX identifiers that name them, then a matrix of what each license requires you to produce. After that, how linking and compatibility change the answer in a firmware build, why the license list you hold is a claim rather than evidence, and what enforcement looks like at a hardware company. Last, the components that stopped being open source between 2023 and 2026, and what protects a commercial business if you publish rather than consume.
"Which license should we pick" has a large literature. "What did we already agree to" has almost none, and it is the one with a deadline attached. The obligations arrived with the code.
The Four Families of Open Source License Types
An open source license is a copyright grant conditioned on your compliance. You may copy, modify, and distribute the code only while you meet the conditions attached to it. A compliance failure is not a policy violation. It is a loss of the permission itself.
The Open Source Initiative's Open Source Definition draws the boundary of what counts, and it has not been rewritten despite pressure from AI regulation, cybersecurity law, and public-sector procurement policy. Four families cover essentially all the types of open source licenses you will find in a firmware image.
- Permissive. Keep the notice, do what you like. MIT, ISC, BSD-2-Clause, BSD-3-Clause, Apache-2.0, Zlib, 0BSD, and Unlicense. The legacy BSD-4-Clause, with its advertising clause, was superseded in practice by the 3-Clause form.
- Weak copyleft, bounded at the file or the library. MPL-2.0, EPL-2.0, CDDL-1.0, LGPL-2.1-only, LGPL-2.1-or-later, LGPL-3.0-only, and LGPL-3.0-or-later. The boundary is what makes them weak. How that boundary gets drawn in a statically linked build is the subject of the section after next.
- Strong copyleft, bounded at the whole work. GPL-2.0-only, GPL-2.0-or-later, GPL-3.0-only, and GPL-3.0-or-later. GPLv2 section 2 requires that a distributed work containing or derived from the program be licensed as a whole under GPL terms.
- Network copyleft. AGPL-3.0-only and AGPL-3.0-or-later. Section 13 adds a trigger that fires when users interact with modified code over a network, with no distribution required.
One SPDX detail earns more attention than it gets. SPDX deprecated the bare GPL-2.0 and GPL-3.0 identifiers in favor of the explicit -only and -or-later suffixes, because whether the code permits later license versions materially changes what it can legally be combined with. The bare forms survive only as deprecated legacy identifiers. If your SBOM still emits GPL-2.0, it is recording an ambiguity rather than a license.
There is a fifth bucket, and it is not open source. Source-available licenses like SSPL-1.0 and BUSL-1.1 appear on the SPDX license list because SPDX indexes licenses regardless of OSI status, and neither is OSI approved. The relicensing wave below covers how they arrived in production stacks.
The family tells you which shelf a license sits on. It does not tell you what the license asks you to do.
Open Source License Comparison: What Each License Requires You to Do
Take your component list, find each identifier in column one, and read across. That row is the set of artifacts and duties you owe for that component. Sorting components into permissive and copyleft buckets does not give you that, which is why this open source license comparison goes clause by clause instead. Linking obligations are the one thing the table only points at, and the next section owns them.
| License (SPDX ID) | Family and scope | Source disclosure trigger | Notice duty | Express patent grant | Clause to watch |
|---|---|---|---|---|---|
| MIT | Permissive | None | Copyright and permission notice in all copies or substantial portions | None, silent on patents | Nothing beyond notice retention |
| ISC | Permissive | None | Copyright and permission notice in all copies | None | Functionally identical to MIT |
| BSD-3-Clause | Permissive | None | Notice, conditions, and disclaimer in source; reproduced in binary documentation | None express | Clause 3: no use of contributor names to endorse |
| Apache-2.0 | Permissive | None | Section 4(d): reproduce NOTICE attributions in derivative works | Yes, section 3 | Patent license terminates if you sue over the work |
| MPL-2.0 | Weak copyleft, file level | Section 3.2: distributing Covered Software in executable form | Preserve Exhibit A notice in each covered file | Yes, section 2.1 | Section 3.3 permits a Larger Work under your own terms |
| EPL-2.0 | Weak copyleft, module or file oriented | Section 3.1: distributing the Program in any form | Reproduce EPL terms, no NOTICE mechanism | Yes, section 2(b) | Secondary License mechanism for GPL-2.0-or-later flow |
| LGPL-2.1-only | Weak copyleft, library boundary | Distributing a work that uses the Library | Section 6: prominent notice that the Library is used, plus license text | None express | Section 6(a) static option requires your work as object or source |
| LGPL-3.0-only | Weak copyleft, library boundary via Combined Work | Conveying a Combined Work | Section 4(a) to (c): notice, GPL and LGPL text, copyright in displayed notices | Yes, via GPLv3 section 11 | Section 4(d) recombination or shared library; 4(e) Installation Information |
| GPL-2.0-only | Strong copyleft, whole work (section 2) | Section 3: distributing object code or executable form | Section 1: pass on the license, keep notices intact | None express; section 7 is a patent-conflict clause, not a grant | Section 4: violation terminates rights, no cure period |
| GPL-3.0-only | Strong copyleft, whole work via Corresponding Source | Conveying the covered work | Sections 4 and 5 notice preservation | Yes, section 11 | Section 6 Installation Information; section 8 gives a 60 day cure |
| AGPL-3.0-only | Network copyleft, GPLv3 mechanics | Section 13: remote network interaction, no distribution required | Same as GPLv3 | Yes, GPLv3 section 11 | Section 13 is the only substantive addition over GPLv3 |
Two licenses can sit in the same family and do materially different work. MIT is silent on patents, with no grant and no disclaimer beyond the warranty text. Apache-2.0 section 3 grants an express, irrevocable patent license to make, use, sell, and import the work, then terminates it as of the filing date if you institute patent litigation alleging the work infringes. Both are permissive, and only one changes your patent position.
The same holds inside copyleft. GPL-2.0-only section 4 terminates your rights automatically on violation, with no cure mechanism in the text. GPL-3.0-only section 8 provisionally reinstates them, and permanently reinstates them if you cure within 60 days of the copyright holder's notice and it is the first such notice from that holder. Same family, materially different exposure when something goes wrong.
For permissive components, the day-to-day cost is notices, not source. Open source IP lawyer Heather Meeker's assessment is that the sheer number of notices makes the process very hard for humans to manage without automation, and that products carrying more than 20 to 30 notices become effectively unmanageable by hand. She flags container images as a historical weak point, where teams pulled an image and inherited its notice obligations without registering it.
The question to carry forward is not whether a component is permissive or copyleft. It is which row of that table your legal team will have to satisfy, and with which artifact.
How You Combine the Code Decides the Obligation
Somewhere this week an approval went through because LGPL is weak copyleft and the team only links against it. Embedded C and C++ builds link statically by default, and LGPL's lighter path is written for the dynamic case.
LGPL 2.1 section 6, option (a), requires you to "accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work... and, if the work is an executable linked with the Library, with the complete machine-readable 'work that uses the Library', as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library." That means object code or source for your own application. A deliverable, not a footnote.
Option (b) is the lighter path: a shared library mechanism that at run time uses a copy already on the user's system rather than copying library functions into the executable, and that works with a user-installed modified version if it stays interface-compatible. A single-image firmware build satisfies neither half.
LGPL 3.0 section 4 restates the split through its Combined Work concept. Your terms must, taken together, effectively not restrict modification of the Library portions or reverse engineering to debug them. Subsection 4(d) offers the same two options; 4(e) adds GPLv3 section 6 Installation Information, conditionally.
MPL-2.0 behaves better here. Section 3.3 lets the surrounding image be a Larger Work under your own terms, so the file-level boundary does not expand to cover the binary.
One point is genuinely unresolved. The FSF holds that linking with other modules either way makes a combined work, and that "dynamic vs. static linking never makes any difference on the outcome of the analysis." That is the FSF's position, not settled law.
No US court has definitively ruled on whether linking creates a derivative work, Larry Rosen argued the opposite in 2003, and a 2011 analysis found the question open. The GCC Runtime Library Exception 3.1 and the GPLv2 Classpath exception exist because of that ambiguity.
Compatibility between open source license types runs one way. Permissive into copyleft works, and the Linux kernel does it routinely with BSD and MIT files under an overall GPL-2.0-only license. The reverse fails: you cannot redistribute GPL code under bare MIT or Apache terms and drop the obligations it attaches.
The failure case to memorize: Apache-2.0 into GPL-2.0-only. The FSF has never treated Apache 2.0 as GPLv2-compatible, holding its patent-termination and indemnification provisions to be further restrictions GPLv2 section 6 bars. The Apache Software Foundation reports the same conclusion.
GPLv3 fixed it, so Apache-2.0 into GPLv3 works. GPL-2.0-only plus GPL-3.0-only does not, absent an or-later grant.
How you linked is a licensing decision.
License Metadata Is a Claim, the Binary Is the Evidence
Black Duck's 2026 OSSRA report audited 947 codebases and found license conflicts in 68%, up from 56% the year before and the largest single-year jump in its 11 year history. Narrow that to conflicts directly affecting the ability to distribute, the number that matters to a manufacturer, and it is 59%.
Two findings from the same report explain most of it. Applications average 1,180 components, and 64% of open source components are transitive, pulled in automatically by a direct dependency rather than chosen by anyone. Nobody reviewed the license on two thirds of what you ship.
Only 54% of organizations evaluate AI-generated code for license risk before integrating it, a pattern OSSRA calls license laundering.
Embedded C and C++ have no standard package manager, so components arrive as vendored trees, copied files, supplier blobs, and generated code. A build system records what it was told to fetch, not what a developer pasted into a directory in 2019.
Declarations can also be false. In one M&A audit, a component declared MIT was a line-for-line fork of GPL code with the LICENSE file swapped, undetected until a manual review. In another, a high-end sewing machine shipped with a working open source Tetris clone in its firmware, left from display testing years earlier.
The license fields carry nuance most teams skip. SPDX separates licenseDeclared (what the authors stated) from licenseConcluded (what the SBOM producer determined), with licenseInfoInFiles as an unresolved file-level inventory. NOASSERTION means the creator could not conclude, made no attempt, or chose not to say, which is not the same as NONE, asserting no license is present, or a blank field in a non-conformant SBOM.
CycloneDX uses components[].licenses, accepting an SPDX identifier, an unvalidated free-text name, or a full expression. In an expression, AND means comply with both, OR is a choice, WITH attaches an exception, + means that version or later.
Practitioners report missing and unreliable license fields as the most common SBOM problem. No rigorous public study quantifies how often, so we will not put a number on it.
Neither the EU Cyber Resilience Act nor FDA Section 524B regulates licensing. The CRA requires technical documentation including a machine-readable SBOM covering at least top-level dependencies (Article 31 and Annex VII), on the schedule the CRA milestone dates for 2026 and 2027 set. Section 524B(b)(3) requires an SBOM covering commercial, open-source, and off-the-shelf components, part of the premarket cybersecurity shift for medical devices. Identifying open source license types rides on that same inventory.
Your manifest records what the build intended. The binary records what shipped. These disagree routinely.
What Open Source License Enforcement Looks Like Against a Shipped Device
Enforcement against device makers does not open with a lawsuit. It opens with a letter asking for source.
Software Freedom Conservancy v. Vizio sits in Orange County Superior Court. SFC bought a SmartCast television, requested the complete GPL and LGPL source for its Linux-based firmware in August 2018, got incomplete responses, and filed suit in October 2021. The theory is third-party beneficiary breach of contract, not copyright infringement, and it tests whether an ordinary purchaser, not just a copyright holder, can enforce the GPL.
Two rulings in December 2025 framed the trial that followed.
- On December 4, Judge Sandy Leal's tentative rulings treated the dispute as contract law rather than copyright, found that Vizio had made a binding source offer (buried in a television menu), that SFC accepted it, and that Vizio therefore carries a contractual duty to provide the complete source code. The broader question of whether GPL recipients are intended third-party beneficiaries went to trial rather than being decided there.
- On December 23, the judge granted Vizio's motion on a narrower point: GPLv2 and LGPLv2.1 do not require a manufacturer to supply installation keys or other information enabling modified firmware to be reinstalled on the original hardware and keep working. That duty was added deliberately in GPLv3 section 6. SFC's response was that the motion resolved a position it had never taken.
Trial began on January 12, 2026. Confirm the outcome before relying on the standing question either way.
The decided part is already usable. Ship GPL-2.0-only code and no GPLv3 code, and that clause does not require you to preserve the ability to flash modified firmware. The part that should worry you is the part Vizio lost. A source offer buried in a menu was still a binding offer, and answering it incompletely was still a breach.
GPLv2 section 3(b) permits a written offer, valid at least three years, to give any third party a complete machine-readable copy of the source for no more than the cost of physically performing the distribution. Common failures: a lapsed offer, restrictions on who may request it, charging above distribution cost. A compliant response is the corresponding source as shipped, including the scripts controlling compilation and installation, not a link upstream.
The precedent runs two decades deep. In 2007 the Software Freedom Law Center filed the first US GPL suits over BusyBox, against Monsoon Multimedia, Xterasys, High-Gain Antennas, and Verizon. The FSF sued Cisco over Linksys firmware on December 11, 2008 and settled on May 20, 2009, the remedy being a named Cisco director responsible for license compliance. In Germany, gpl-violations.org won a Munich judgment against D-Link on September 6, 2006 and a temporary injunction against Fortinet in 2005.
GPL code reached the Linksys WRT54G through a Broadcom chipset supplier's firmware, unknown to both companies. Heather Meeker: Cisco would have had to do diligence through three levels of product integration, "which anyone in the mergers and acquisitions trade can tell you is just about impossible."
The question is not whether anyone will ask. It is whether you could assemble the corresponding source for a 2021 SKU inside 30 days.
When the License Changes Under You: The 2023 to 2026 Relicensing Wave
A license is a property of the version, not of the project. Pin a component before a relicensing and it stays under the license it shipped with. The upgrade crosses the line, so a routine version bump can change what your company is permitted to do.
- MongoDB, AGPLv3 to SSPL, October 2018. Debian, Red Hat Enterprise Linux, and Fedora removed the packages because SSPL is not OSI or DFSG compliant, and that removal persists.
- HashiCorp Terraform, MPL-2.0 to BUSL-1.1, August 2023. The OpenTofu fork followed immediately and is now Linux Foundation hosted. Terraform remains under BUSL-1.1, not an open source license.
- Redis, BSD-3-Clause to a dual RSALv2 and SSPLv1 arrangement on March 20, 2024, effective with Redis 7.4. Valkey forked, kept BSD-3-Clause, and joined the Linux Foundation. Redis then released Redis 8 under AGPLv3 on May 1, 2025 to regain open source standing.
- Elastic, Apache-2.0 through Elasticsearch 7.10, then SSPL and the Elastic License from January 2021, then AGPLv3 added as a third option announced August 29, 2024. OpenSearch continues as an independently governed fork.
Source-available is not open source, and that is OSI's position rather than ours. Its 2021 statement that the SSPL fails the Open Source Definition still stands, and BUSL and Functional Source License style delayed-open licenses are treated the same way. Sentry introduced the FSL on November 20, 2023 and later rebranded the model as Fair Source. OSI vice chair Thierry Carrez called it "proprietary gatekeeping wrapped in open-washed clothing."
The cost is measurable on both sides. Before Redis's March 2024 change, 12 non-employee contributors accounted for 54% of commits; after the fork, no non-employee had more than five commits to Redis itself. OpenSearch reached 496 contributors and over 100 million downloads in its first year. One practitioner's summary of the Elastic reversal: teams that ported to OpenSearch "have zero motivation to move back."
Every one was a commercial decision by a company that once faced the question the next section covers.
Choosing an Open Source License to Publish Under, and What Actually Protects a Commercial Business
The received advice: permissive licenses for commercial projects, copyleft for community projects. The outcome data does not support that cleanly, and the open source licensing models that protect a business do more than the license text alone.
- AGPL-3.0 plus a commercial exception. Section 13 closes the hosting gap that ordinary GPL leaves open, since a provider who only runs modified code as a service never distributes anything. The counterweight: Google maintains an aggressively broad ban on all AGPL software, covering checked-in code and employee devices, because case-by-case review is infeasible at its scale.
- Dual licensing, which requires a CLA. You can sell proprietary terms for the same code only if you hold the rights, which requires a contributor license agreement. The cost is contributor trust, because contributors expect their work resold without their say.
- Open core. A real free tier with revenue features reserved, except that "core" is an unstable boundary. GitLab is the worked example: Pages, contribution analytics, and merge request approval workflows were held to Enterprise Edition, and GitLab.com's free tier runs Enterprise Edition, so a user moving to self-hosted Community Edition loses features they already had.
The venture data deserves a caveat. Tomasz Tunguz at Theory Ventures found Apache-licensed projects were 16% of the studied set and took over 50% of venture dollars, MIT projects 20% of projects and under 1% of dollars, GPL-family projects 42% of projects and 37% of dollars. GPL-licensed exits produced over $6B in liquidity (Sourcefire $2.4B, Novell $2.1B, MySQL $1.0B) against $2B for Apache exits. His own conclusion: license choice correlates weakly with outcome, and market timing explains more of the variance.
The relicensing wave above priced the cost of changing your mind. IP lawyer Kate Downing notes that copyleft representations appear in NVCA stock purchase agreements to test whether a startup's proprietary code claims are illusory because of unknowingly incorporated GPL-family code. Open Core Ventures' Open Charter is the market answer: a legal commitment against relicensing. The license is a term sheet you cannot renegotiate cheaply.
Key Takeaways and Where to Start
- Four families, not two. Permissive plus three copyleft license types (weak, strong, network), plus source-available licenses like SSPL-1.0 and BUSL-1.1 that are not open source at all.
- Obligations differ inside a family. MIT is silent on patents where Apache-2.0 section 3 grants one; GPL-2.0-only terminates with no cure where GPL-3.0-only section 8 gives 60 days.
- Static linking is where LGPL stops being the easy option. Section 6(a) requires enough of your own work, as object code or source, for a user to relink.
- Whether linking creates a derivative work is the FSF's position, not settled US law. Plan for the obligation rather than relying on the ambiguity.
- The December 2025 Vizio rulings put GPLv2 outside the Installation Information duty and inside a contractual duty to supply source. A source offer buried in a menu was still binding. Trial on consumer standing began January 12, 2026.
- Neither the CRA nor 524B regulates licensing. Both require the component inventory license identification depends on.
One first move, and it costs a build cycle: generate the license manifest your build system already knows how to produce. In Buildroot, make legal-info writes output/legal-info/manifest.csv, one license per package. In Yocto, license.manifest lands under the deploy licenses directory with package, version, recipe, and license, in entries reading like busybox 1.31.1 under GPLv2 & bzip2.
Set LIC_FILES_CHKSUM in your recipes so the build fails when upstream license text changes, which catches a relicensing before it ships. That manifest describes what the build system selected, and it will not show vendored source, copy-pasted code, a swapped LICENSE file, or anything a supplier's BSP dropped into the image.
Three questions worth putting to your team this month:
- Which SKUs contain GPL-2.0-only code versus GPL-3.0-only code, and does anyone know the difference in what we owe?
- Is our GPLv2 written offer still valid, and who answers it when a request arrives?
- For every LGPL component in the image, was it linked statically or dynamically, and can we prove which?
Finite State derives the component and license inventory from the shipped firmware image rather than the build manifest, with no source code required. It exports SPDX and CycloneDX with the license fields populated. To see that against your own firmware, request a walkthrough.
FAQ
What are the different categories of open source software licenses?
Four: permissive (MIT, Apache-2.0, BSD-3-Clause), weak copyleft (MPL-2.0, LGPL-2.1-only, EPL-2.0), strong copyleft (GPL-2.0-only, GPL-3.0-only), and network copyleft (AGPL-3.0-only). Source-available licenses such as SSPL-1.0 and BUSL-1.1 form a fifth category and are not OSI approved, so they are not open source at all.
What is the difference between permissive and copyleft licenses?
Permissive licenses impose notice retention and little else. Copyleft licenses condition distribution on making corresponding source available under the same terms. The split tells you less than the specific license does: Apache-2.0 and MIT differ on patents, and GPL-2.0-only and GPL-3.0-only differ on termination, despite sharing a family in each case.
Does using an LGPL library mean I have to release my firmware source code?
Not the whole image, but static linking is not free. LGPL 2.1 section 6(a) requires the Library source plus the "work that uses the Library," as object code or source, at the level a user needs to modify the Library and relink. Dynamic linking through a suitable shared library mechanism satisfies section 6(b) instead.
Which open source license should a startup choose to protect its commercial interests?
There is no consensus protective license. Commercial open source vendors gravitate to AGPL-3.0 plus a contributor license agreement so they can dual license, because AGPL section 13 closes the hosting gap. Two counterweights: some buyers, Google included, ban AGPL outright, and venture outcome data shows license choice correlating weakly with outcome.
Is a source-available license like BUSL or SSPL an open source license?
No. OSI's position since 2021 is that the SSPL fails the Open Source Definition, and BUSL-1.1 restricts commercial use until a future conversion date. Both appear on the SPDX license list because SPDX indexes licenses regardless of OSI status, so an SPDX identifier is not evidence of open source status.
Do I have to disclose source if I only use GPL code internally?
For ordinary GPL, no, because the triggering event is distribution outside your organization. AGPL-3.0 is the exception practitioners miss. Its section 13 triggers when users interact with your modified version remotely over a network, with no distribution required, which is why many companies police AGPL separately.
What does a GPLv2 written offer for source code have to include?
Section 3(b) requires an offer valid for at least three years, open to any third party, to supply a complete machine-readable copy of the corresponding source for no more than the cost of physically performing the distribution. Corresponding source includes the scripts controlling compilation and installation, not just a pointer upstream.
Does the EU Cyber Resilience Act or FDA 524B require open source license compliance?
No. Neither regulation addresses licensing. The CRA requires a machine-readable SBOM in technical documentation (Article 31, Annex VII), and FDA 524B(b)(3) requires an SBOM covering commercial, open-source, and off-the-shelf components. Both compel the accurate inventory that open source license compliance depends on, which is the only real connection.