Originally published on Code Curmudgeon in August 2016. Substantially rewritten September 2026. What I got wrong the first time is at the end.
Everybody knows you’re supposed to check the license before you pull an open source component into your product. Almost nobody checks it again afterward. Since 2018 that second part has been costing people real money, and it’s what this article is mostly about.
Open source projects come with a wide variety of license types, and some of them conflict with each other. They carry restrictions against commercial use, requirements to distribute source code, attribution obligations, and more. If you’re pulling in several projects at once, staying in compliance across all of them turns into an administrative headache. Some projects even offer multiple license choices, and you need to understand which one you’re taking and which you can ignore.
So you do the sensible thing. You review a license type once, decide whether it’s acceptable, and then clear every component that carries it. MIT is fine, Apache is fine, GPL needs a conversation, and once that’s settled you go back to work.
That worked for about twenty years. It stopped working in 2018, and not because somebody drafted a tricky new license. It stopped working because the license stopped being a fixed property of the thing you adopted.
The license can change after you adopt it
Most of us treat a component’s license the way we treat its API, as something that’s settled once we pick the thing up. That hasn’t been true for a while now, and here are four examples that show the pattern. It runs the same way each time. A project with a single commercial owner finds somebody else making money from it, often a cloud provider but not always, and the owner responds by relicensing the next release. The owner does the relicensing every time. Nobody else can.
- October 2018. MongoDB moves Community Server to the Server Side Public License. Red Hat pulls it from the RHEL 8 beta, Fedora bans SSPLv1 outright, and Debian drops the package. (MongoDB)
- January 2021. Elastic moves Elasticsearch and Kibana off Apache 2.0 to a dual SSPL / Elastic License. AWS forks 7.10.2 into OpenSearch three months later. (Elastic)
- August 2023. HashiCorp moves Terraform, Vault and Consul to BUSL 1.1. OpenTofu forks within weeks, and OpenBao follows. (HashiCorp)
- March 2024. Redis leaves BSD 3-clause for dual RSALv2 / SSPLv1, saying plainly that “Redis is no longer open source under the OSI definition.” Valkey launches at the Linux Foundation eight days later, forked from 7.2.4. (Redis, Linux Foundation)
Confluent, Mapbox and Lightbend (Akka) ran versions of the same play between 2018 and 2022. Grafana, Sentry and Cockroach Labs get lumped in with them and shouldn’t be. Grafana moved to AGPLv3, which is still an OSI-approved license. Sentry’s move shortened its conversion clock rather than lengthening it. Cockroach Labs retired a free tier without relicensing code that was already under BSL. Those are all worth knowing about, but they aren’t this.
And it doesn’t only run one direction, either. Elastic and Redis have both since added AGPLv3 back, in 2024 and 2025, and they’re tri-licensed now.
Which raises the obvious question. If everybody hated the SSPL that much, why did MongoDB adopt it? Because users were never the target. MongoDB CTO Eliot Horowitz said so pretty plainly at the time: “once an open source project becomes interesting, it is too easy for cloud vendors who have not developed the software to capture all of the value while contributing little back to the community.” CEO Dev Ittycheria put a number on what they were defending, roughly $300 million of R&D over the preceding decade. That’s an understandable grievance, and every relicensing in the list above is some version of it.
Whether it actually works is another matter. AWS announced DocumentDB on January 9, 2019, less than three months after the SSPL move, and they built it from scratch to emulate the Apache-2.0-licensed MongoDB 3.6 API rather than use MongoDB’s code at all. So the license change didn’t stop the competitor it was aimed at, but it did get the package pulled from Red Hat, Fedora and Debian. (AWS)
That’s the part worth remembering. The shot gets fired at a competitor, usually a big one, and the people who reliably get hit are the ones who had the component sitting in their dependency tree.
Notice that none of them is a case of anybody picking the wrong license. In every one of these, whoever made the call did exactly the review-it-once check I described above, cleared the component correctly, shipped it, and then had the terms change underneath them.
Look at what that cost the people downstream.
Apache Flink pinned to the last Apache-licensed Akka, then opened FLINK-32468 to replace it entirely, and they said why right in the ticket: “Akka 2.6.x will not receive security fixes from September 2023 onwards.” That’s not a licensing task, it’s a serious engineering project, and they didn’t really have a choice about it either. The alternative was to keep running a core subsystem that had stopped getting security patches, and good luck explaining that one to a customer or an auditor. The community’s answer was to fork Akka’s last Apache-licensed release into Apache Pekko, which became a top-level Apache project in May 2024. Forking a library and standing it up as its own Apache project is a lot of work to do because somebody else changed a license.
Elasticsearch fragmented, in several directions at once. Some shops accepted the new terms and stayed with Elastic. Some moved to AWS’s fork, which became OpenSearch and now runs as its own Linux Foundation project with AWS, SAP and Uber as premier members. Some pinned an old version and stopped upgrading. Some used the disruption as their excuse to leave the category altogether. Then in late 2024 Elastic added AGPLv3 back and announced that Elasticsearch was open source again, which turned out to be a narrower opening than it sounded. When Platform.sh customers asked for a free build under that option, its engineers found that “the code to build the OSS flavor of Elasticsearch has been removed,” and passed on rebuilding it themselves. (Upsun, Linux Foundation, Elastic)
I can’t tell you the proportions, and neither can anybody else with a straight face. What I can tell you is that adopters who used to have a default now have a decision.
And Fedora 41 just replaced Redis with Valkey outright. The valkey-compat package carries Obsoletes: redis, migrates your config and data, and aliases the systemd units, so the whole substitution is “mostly transparent to users,” which is Fedora’s own description of it. (Fedora) If Redis was in your dependency chain by way of a distro package, your supply chain changed and nobody on your team ever filed a ticket. That one has consequences for your SBOM that are worse than they look at first, and I’ll come back to it.
So license review isn’t a gate you pass once at adoption. It’s something you keep watching for as long as the dependency is in your product. Checking the license when you adopt a component and never again is like checking the oil when you buy the car. It tells you something true on that day and nothing at all about the next hundred thousand miles. That’s a different job than the one most of us set up, and it needs tooling that almost nobody has.
What the source-available licenses actually say
Two of these licenses account for most of the confusion, the Business Source License and the SSPL, and both of them get described sloppily almost everywhere. For each one there are really only two things you need to know: what it forbids, and whether that ever lapses.
Business Source License 1.1. In plain terms, you can use it for anything you like, production included, as long as you’re not selling it as a hosted service that competes with the vendor’s own paid product. And the restriction has an expiration date on it. Each release converts to a normal open source license on its own Change Date, which can be up to four years after that version shipped, and the conversion happens automatically. The license spells it out: on that date the licensor “grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.”
That promise is finally testable, because the first conversions are coming due, and the early results aren’t encouraging. Akka went BSL in late 2022 on a three-year clock, so Akka 2.7 should have turned back into Apache 2.0 sometime in late 2025. Go look at the license file for that release, though, and there’s no date in it. Where the Change Date belongs, it says “TBD ( 3 years after 2.7.0 release ),” and I can find no announcement that the date ever arrived. A formula is not a date. If you’re counting on a Change Date to get you out of a BUSL component someday, you may end up working out for yourself whether it has passed, using a document that declined to tell you. (Akka 2.7.0 LICENSE)
The other catch is that the license never defines “compete.” It leaves a blank called the Additional Use Grant and lets the vendor fill it in. (Yes, the one term that decides whether you’re in violation is the one term the license hands to the party you’d be violating it against.)
You can go read Terraform’s and try to work out what it means, but it’s rough going. It opens with “You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work…” and carries on in that vein for about 380 words across six paragraphs, stopping along the way to define what counts as a “competitive offering,” what counts as a “Product,” what counts as “Embedded,” and which internal uses inside your own company and its affiliates don’t count against you.
Go read it anyway. I’m not going to summarize it for you, because the summary is where you get in trouble, and because every BUSL component in your stack has a different one. It’s the only part of that license somebody wrote specifically about you.
Then notice whose name is on it now. The Licensor field reads “International Business Machines Corporation (IBM).” IBM completed its acquisition of HashiCorp on February 27, 2025, so the terms telling you what you may not do with Terraform are written by a different company than the one you originally adopted it from. (BSL 1.1, Terraform LICENSE, IBM)
SSPL. This is MongoDB, and Redis from 7.4 onward. It differs from BUSL in two ways, and both of them cut against you.
First, nothing expires. There’s no Change Date and no conversion, so the obligation is permanent.
Second, what sets it off is broader than most people assume, and it isn’t just “are you a cloud provider.” Section 13 says that “If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.”
And if it does trigger, you don’t just owe your changes to the database. Service Source Code is defined to include “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software,” enough that somebody else could stand up your service from whatever you published. In practice that’s your deployment tooling and your whole operational stack, not just the component you adopted. Whether “available to third parties as a service” describes your own internal platform is a question worth asking out loud, preferably before somebody else asks it for you. (SSPL)
Functional Source License. This is Sentry and Codecov. It’s the same shape as BUSL but with a shorter fuse and no blank for the vendor to fill in, so each release converts to MIT or Apache 2.0 two years after it publishes. If you have to carry one of these in your stack, this is the friendliest version of it. (fsl.software)
None of the three is open source under the OSI definition, and the OSI has been blunt about it, calling SSPL “fauxpen source” and saying that claiming otherwise “is deception, plain and simple.” Whether that’s the right label is a fight for another time and place. It isn’t the issue here. The issue is that every license in your software has to be assessed and addressed properly, whatever anybody calls it.
The pitfalls, revisited
Ambiguity. Some licenses are ambiguous because they’re drafted without the benefit of professional legal advice, so get legal advice before you adopt one. The standard advice is that this is a one-time cost per license type, and half of that still holds, since you don’t re-review MIT every time you add an MIT component. What’s changed is that you now have to review on update as well as on adoption. And the ambiguity that costs you money isn’t in MIT’s 170 words. It’s in the Additional Use Grant, where the vendor writes their own meaning for “compete,” and where every new release can carry a different one, because BUSL applies separately to each version.
Jurisdiction. Still a real pitfall, and it turned out to matter for a reason I didn’t see coming in 2016. Entr’ouvert v. Orange spent more than a decade in the French courts over Lasso, a GPLv2 SSO library that Orange built into a French government portal without publishing its modified source. Watch the sequence, because it is the whole point. In March 2021 the Paris Court of Appeal ruled that Entr’ouvert could not even bring an infringement claim, since French law generally makes you pick between suing on the contract and suing in tort. The Cour de cassation overturned that on October 5, 2022, holding that a copyright holder stays entitled to sue for infringement even though a license contract exists, because a contract claim would not give them the enforcement remedies that EU Directive 2004/48 provides. On remand, a differently composed Paris Court of Appeal found on February 14, 2024 (case 22/18071) that Orange had infringed, and awarded €500,000 for economic harm, €150,000 for the profits Orange made and €150,000 for moral prejudice, plus €60,000 in costs. Around €860,000, against the €4 million Entr’ouvert had asked for. I’m not aware of a larger monetary award in a GPL case, and it happened in a jurisdiction that reasons about the copyright-versus-contract question differently than US courts do. (Legalis, DLA Piper, Heather Meeker)
Unintended open source. The GPL still requires derivative works to carry the same terms, but what’s changed is where this bites you. In 2016 the GPL question was about shipping binaries. Today the sharper question is AGPL, which extends the source obligation to network use, and which now sits under Grafana, Loki, Tempo, Elasticsearch, Redis 8 and a growing pile of other infrastructure. Plenty of large engineering organizations ban AGPL outright in their dependency policies. If yours does, and you also have a policy of taking whatever the distro package manager hands you, those two policies are in conflict right now and nobody has told you about it.
Patent rights. Most developers have never had this one explained to them, so here it is. A license that gives you the code doesn’t automatically give you the right to do what the code does. Copyright covers the code itself. Patents can cover the technique the code implements. So somebody can hand you their software under a perfectly good open source license and still hold a patent that you infringe by running it. An express patent grant closes that gap. The contributors license you the patents covering their own contributions along with the code, so they can’t turn around and sue you for using the thing they just gave you.
Whether a license does that depends on the version more than the family. GPLv3 grants patent rights in section 11 and Apache 2.0 in section 3. GPLv2 grants none at all.
Both Apache 2.0 and GPLv3 also take rights away if you sue claiming the software infringes your patents, and they take different amounts. Apache terminates your patent license and leaves you free to keep using the code. GPLv3 treats that suit as a license violation, which reaches termination of the whole license. Apache takes away your shield. GPLv3 can take away the code.
That’s as far as I’m going to take it here. If patents matter to your business this is a conversation with counsel, and the sections to put in front of them are 10 and 11 of GPLv3, section 3 of Apache 2.0, and section 7 of GPLv2, which grants nothing but can stop you distributing at all.
Enforcement. Jacobsen v. Katzer (Fed. Cir. 2008) established that violating an open source license is legally actionable in the United States, and for years that was the case everybody cited. It’s still good law, and it’s also now the least interesting thing you can say on the subject, because the question has split into two: enforceable by whom, and on what theory.
On theory, Artifex v. Hancom (N.D. Cal. 2017) got a court to hold that the GPL can form an enforceable contract without anybody signing anything. It settled before trial, so it’s persuasive rather than binding, but it opened a door.
On who, Software Freedom Conservancy v. Vizio is the live one, and it’s the one that should interest you. SFC bought TVs and sued in contract as an alleged third-party beneficiary of the GPLv2 and LGPLv2.1, asking for source code rather than damages. In December 2023 the court denied Vizio’s summary judgment motion, finding triable issues and observing that third-party enforcement is “not only consistent with the GPLs’ objectives; it is both essential and necessary to achieve these objectives.” In December 2025 Vizio won a narrower point, that the GPLs don’t require you to enable reinstalling modified software back onto the device. Trial was set for August 2026 and no decision has been reported as of this writing. If that theory holds up, the people who can come after you over a copyleft component include your own customers. (SFC, LWN)
A lot of coverage has already announced that “courts have ruled consumers can enforce the GPL.” No court has held that. A California trial court found the question triable, which is a state trial court order with no precedential weight, in a case that hasn’t finished yet.
Meanwhile the quieter case is the one worth copying into your compliance runbook. Sebastian Steck, a German software developer, sued the router maker AVM in the Landgericht Berlin in July 2023, because the firmware source AVM shipped left out the scripts used to control compilation and installation for LGPL-2.1 libraries. AVM never took it to judgment. It handed over complete source for the FRITZ!OS versions at issue, including the missing installation information, covered Steck’s legal costs of €7,500, and the parties ended the case by agreement in 2024. So there’s no precedent to cite here. What there is instead is a manufacturer who looked at the claim and decided complying was cheaper than arguing, which for your purposes is arguably more informative than a ruling. The same theory is one of the live claims against Vizio, and there’s a lesson in it for anybody shipping a device with copyleft code inside. What trips companies up is rarely the source code itself, which they usually do hand over. It’s everything that has to come with it: the scripts and instructions somebody needs to actually build that code and get it onto the device.
New pitfall: provenance you can’t see. Every tool your organization uses for license compliance works the same way. It reads the files where your project lists the outside components it depends on, then looks up what license each one carries. That’s what software composition analysis is. AI-generated code never shows up on that list. It arrives as ordinary code inside your own files, checked in under your own developer’s name, with nothing anywhere declaring where it came from. So it’s invisible to the tooling you bought for exactly this problem, and not because the tooling is bad. It’s invisible because there’s nothing for the tooling to look at.
How often that turns into a real license problem, nobody credibly knows. What’s documented is that it happens. In July 2021 Copilot autocompleted Quake III’s fast inverse square root implementation and then autocompleted a BSD-2 license header naming the wrong copyright holder. GitHub’s own 2021 study found roughly one recitation event per ten user-weeks at a 60-token threshold. GitHub’s product claim is that matches turn up in “less than one percent” of suggestions, and that number comes with some important qualifiers: the matching only runs against public GitHub repos, over roughly a 150-character window, against an index that’s refreshed every few months. So it’s a floor on a narrow definition, not a measure of your exposure. (GitHub, The Register)
The legal question is live and a lot narrower than the headlines suggest. In Doe v. GitHub, the DMCA claims over stripped copyright management information were dismissed on an “identicality” reading of section 1202(b) and certified for interlocutory appeal, and the Ninth Circuit heard argument in February 2026. But the breach-of-contract claims based on the open source license terms were never dismissed and they’re still live in the district court. Anyone telling you the Copilot suit got thrown out is reading the wrong half of it.
Vendors have responded with indemnity rather than provenance, and indemnity is a contract term they control. Microsoft’s Customer Copyright Commitment used to require customers to run the duplicate-detection filter to stay covered. As of April 3, 2026, Microsoft dropped that requirement for GitHub offerings and the filter is optional now. That’s a loosening in your favor, which is exactly why it’s worth noticing, because the condition moved once and it can move again. (Microsoft)
License types
GNU GPL. Currently v3. This is called “copyleft” to differentiate it from copyright. If you distribute a work based on GPL code, you distribute your source under the same terms. GPLv3 includes an express patent grant in section 11 and GPLv2 includes none at all. GPLv3 also added a cure provision in section 8, so if you stop violating, your license is reinstated provisionally, and permanently if the copyright holder doesn’t notify you within 60 days or if you cure within 30 days of a first notice. Used by Bash and GIMP. Works fine if you don’t distribute, or if you don’t mind open-sourcing your own work.
GNU LGPL. Like the GPL, but it distinguishes “based on” from “uses.” If you merely use the library you don’t have to publish your code. The trap in practice isn’t the distinction, it’s the obligations that attach even when you’re on the right side of it. You still owe the build scripts, and for static linking you still owe whatever a user needs to relink against a modified library. See the AVM case above.
GNU AGPL. This is the one to watch. It closes the software-as-a-service gap by treating network interaction as distribution, so if you run a modified AGPL program and let users interact with it over a network, you owe them the source. It’s an OSI-approved license, unlike SSPL, and its recent growth is mostly commercial vendors relicensing rather than new projects picking it. Grafana actually moved to it, off Apache 2.0, in 2021. Elastic and Redis didn’t move so much as add it, in 2024 and 2025, alongside the source-available licenses they already had. Both are tri-licensed now, and that matters to you, because when a project offers you three licenses you get to pick which one you’re taking.
Apache 2.0. Permissive. Do pretty much what you want, don’t hold the contributors liable, keep the attribution, and it carries an express patent grant in section 3, so contributors can’t sue you over patents covering the code they contributed, and that grant terminates if you file patent litigation alleging the work infringes. Used by Android and most of the Apache Foundation, and it’s the default for corporate-originated open source for exactly that patent reason.
MIT. About 170 words. Attribution and a liability disclaimer, and that’s it. Used by jQuery and Rails. Still the most common license by most measures, with a caveat about what “most common” means that I’ll get to shortly.
BSD and ISC. Effectively MIT with different wording. ISC is enormously common in the npm transitive dependency graph and almost invisible if you count repositories instead, which is that same caveat again.
The source-available family: BUSL, SSPL, Elastic License 2.0, FSL, Confluent Community and their relatives. Not open source, not proprietary in the shrink-wrap sense, and not interchangeable with each other. Treat each one as a bespoke commercial agreement, because that’s what it is. The generalization that holds up is that each one exists to stop a specific competitor from doing a specific thing, and you’re almost certainly not that competitor. But “almost certainly” is a different risk posture than “MIT,” and it belongs in a different bucket in your inventory.
Two sites worth bookmarking: the OSI license list and choosealicense.com, though note that the second one is built for people picking a license for their own project rather than for people consuming somebody else’s.
What “most popular” actually means
This is worth a short detour, because it’s the number everybody quotes and almost nobody reads correctly.
Black Duck’s 2026 OSSRA report, drawn from 947 commercial codebases audited between November 2024 and October 2025, lists MIT at 95%, Apache-2.0 at 93% and BSD-3-Clause at 88%. Those figures are the percent of codebases containing at least one component under that license. Add up the ten licenses on that list and you get about 670%, which tells you they were never shares of anything. So “MIT is 95%” doesn’t mean MIT is 95% of the code, or of the components, or of anything else. It means 95% of commercial codebases (almost every one) have at least one MIT component somewhere in them, which you already knew. (OSSRA 2026)
Count packages instead and you get a different picture. An MSR 2024 study across 33.7 million versioned packages in Maven, npm, PyPI, RubyGems and Cargo found permissive licenses at 91% of usage, with MIT around 56% of all packages. (MSR 2024)
Count what’s actually deployed and it shifts again. RedMonk’s 2026 analysis found that GPL-2.0 is 34 times more common on GitHub than in the deps.dev dependency graph, while ISC is 31 times more common in deps.dev than on GitHub. Same software universe, opposite rankings, and the only thing that changed was what got counted. GPL concentrates in standalone repositories that nothing depends on, and ISC concentrates in npm’s transitive graph, where nobody chose it deliberately. RedMonk also points out that a large majority of public repositories carry no license at all and get silently excluded from every analysis above. (RedMonk)
So what developers choose when they publish and what enterprises ingest when they build are two different populations, and every license popularity chart is measuring one of them without telling you which. If you’re setting policy you want the second one, and most published charts give you the first.
One thing I’m not going to tell you is which way the permissive-versus-copyleft trend is running. RedMonk reports permissive peaking around 2022 and declining since. GitHub’s own quarterly licenses dataset, which is public and which you can go compute yourself, shows the opposite over the same window. They use different populations and different bucketing, so anybody stating that trend confidently is picking whichever dataset agrees with them.
For what it’s worth, that same GitHub dataset does show AGPL-3.0 roughly doubling as a share of pushing developers between early 2020 and early 2026, with the sharpest movement in the most recent quarters. People reach for the Elastic and Redis relicensings to explain that, and I’d be careful with it, because both of those projects added AGPL alongside other licenses rather than switching to it, and it isn’t obvious how a tri-licensed repository even registers in a dataset that files each project under one license. Something is moving. I couldn’t tell you what.
And the honest answer on how common source-available licenses are in dependency trees is that nobody knows. RedMonk’s assessment is that these licenses “are not measurable in a statistically significant way.” GitHub’s Innovation Graph tracks 30 SPDX licenses and BUSL, SSPL and the Elastic License aren’t among them. Neither instrument can see them at all, so any percentage you get shown for BUSL or SSPL dependency prevalence is made up. Not estimated. Made up.
Who’s asking now
In 2016 nobody outside your legal department cared what licenses you shipped. Plenty of legal departments weren’t paying much attention either. For a sense of how much has moved since then, the NTIA multistakeholder process that eventually produced the SBOM minimum elements hadn’t even been convened when the first version of this article ran. It was announced in June 2018 and first met that July. (Federal Register)
That’s changed, though not as cleanly as the compliance vendors would like you to think.
The EU Cyber Resilience Act (Regulation 2024/2847) entered into force 10 December 2024, and if you sell software in the EU, you are the manufacturer it’s talking about. Reporting obligations for actively exploited vulnerabilities applied to manufacturers from 11 September 2026, and the substantive requirements apply from 11 December 2027. The open source sitting inside your product is inside the thing you’re now answerable for.
It also creates a lighter category, the open source software steward, for foundations and similar entities that sustain projects used commercially. Those obligations start later, in December 2027, and they land on the steward rather than on you. If you personally maintain something you aren’t monetizing, or you contribute to a project you don’t run, the CRA doesn’t reach you at all. (European Commission)
The CRA does require an SBOM, in Annex I, “covering at the very least the top-level dependencies.” Three things most coverage gets wrong about it: it doesn’t name SPDX or CycloneDX, top-level is the legal floor rather than transitive depth, and there’s no publication requirement. It also doesn’t require license data.
Which brings me to the uncomfortable part. I wrote years ago that the license management some SCA tools do is an important issue, but it isn’t a security issue, it’s a business problem. Let me be precise about how narrow that claim is, because SCA and SBOMs are largely about security and should be. Knowing which of your components carries a known vulnerability, and being able to find every copy of it across everything you ship so you can chase it down and fix it everywhere, is exactly what they’re good for. Anybody who spent December 2021 trying to work out where all their log4j was knows precisely what that’s worth. That’s real security work. Getting a license wrong is a different kind of trouble. Nobody gets breached because you shipped AGPL code. You get sued, or you lose a deal in diligence, or you rip something out on somebody else’s deadline. That distinction is worth holding onto here, because the artifact everybody now points to for license data was built by people solving the security problem. If you assumed SBOMs were going to solve license compliance for you, go check the field list. The 2021 NTIA minimum elements had seven fields and license wasn’t among them, it showed up as a “recommended” field. SPDX 2.2 made license fields mandatory and then SPDX 2.3 relaxed them back to optional. CycloneDX has always treated license as optional. OpenSSF documented what that produces in the real world: generators emitting absent license fields, invalid placeholders like NULL and UNKNOWN instead of the specified NOASSERTION, and malformed expressions like "MIT, LGPLv2, BSD". (NTIA, OpenSSF)
CISA’s 2026 minimum elements, released in July 2026, finally fix this. The list grew from seven fields to eighteen, and Component License is now one of them: “the identifier(s) for the license(s) under which the software component is available,” conveyed “in a machine-processable fashion, such as by using System Package Data eXchange (SPDX) license identifiers.” Nothing in that document is marked optional, and where you don’t know something you mark it unknown rather than leaving the field out. That’s the first major SBOM baseline to require license at all. (Five years after the NTIA minimum elements came out, which tells you roughly where license compliance has been sitting on everybody’s priority list.) Read it alongside OMB M-26-05, though, which rescinded the federal secure-software attestation mandates and left agencies “permitted, but not directed” to ask for SBOMs at all.
There’s a second problem sitting underneath the field list, and that Fedora example from earlier is the cleanest way to see it. CISA’s rule for when to regenerate is producer-triggered: “when a component producer issues a new build or release, they (or the SBOM author) should also generate a new SBOM to reflect the changes.” That’s the right trigger for the case everybody designs around, which is your own software changing. It’s the wrong trigger for what happened to Redis users. Fedora issued the build, your producer did nothing, a component got removed from the running system and a differently-named component from a different upstream project took its place, and no event in your pipeline ever fired.
Notice which way the license moved, too. Redis 7.4 was source-available and Valkey is BSD 3-clause, so a license policy scan run after that swap reports an improvement. Nothing escalates, because nothing looks wrong.
The reassuring answer here is that disciplined shops pin everything, so this can’t reach them. I sat on the NTIA working groups that produced the original SBOM minimum elements, and later on the CISA effort that inherited the program, and I wouldn’t lean on that answer. The bar it describes gets failed more often than it gets met, and being in a regulated industry doesn’t clear it for you. Validation is a statement about a process and an intended use, and it isn’t a guarantee that the build is reproducible. A build that resolves dnf install at build time, or that names a base image by tag instead of by digest, inherits whatever the distro decided that week, and plenty of validated products are assembled exactly that way and then patched in the field for years afterward. The artifact you filed and the system you fielded drift apart, and you can’t see the drift, precisely because nothing in the pipeline reported a change.
What actually closes the gap is narrower than “have good change control.” Pin by digest. Generate the SBOM from the built artifact rather than from a manifest that describes your intentions. Regenerate on any input change instead of only on your own release. All three of those are ordinary engineering, and all three are rarer in practice than the compliance conversation assumes.
So here’s where the pressure actually comes from today. The EU is tightening while the US is loosening, the tightest real constraint on most teams is a vendor indemnity condition rather than a regulation, and the SBOM you generate isn’t a license compliance artifact unless you went and configured it to be one.
What to actually do
“Take the time before committing to a project” is the usual closing advice, and it isn’t something anybody can act on. So here’s the replacement.
- Inventory by license, including transitive dependencies, and make it machine-readable. Not a PDF. Queryable is the floor: you should be able to ask “what do we have under BUSL” and get an answer in under a minute. But the whole direction of this tooling, from static analysis through SCA to SBOM, has been toward artifacts a machine reads instead of a person. So use SPDX identifiers, keep the output structured, and let the pipeline do the work. Pull every license on every build, compare it to the last build and to whatever policy you’ve actually written down, and flag what moved. More and more, the thing reading that file isn’t a person at all, and it can only act on what it can parse.
- Make license delta a gate on version bumps, and track the support clock on your last acceptable version. Relicensing almost always lands on a new release rather than retroactively, as with Terraform 1.6.0, Akka 2.7, Elasticsearch 7.11, Redis 7.4 and Mapbox GL JS 2.0. So your pinned version is safe, and the exposure shows up the moment something upgrades you. Your dependency bot opens a PR showing a version diff and a changelog, and it doesn’t show you that the license changed inside that bump. Meanwhile the clock on the last version you can accept is running, because the vendor stops backporting security fixes to it. That second part is what forced Flink’s hand, and it’s the one to put a date on.
- Classify into three buckets instead of two. Permissive, copyleft, and source-available. That third bucket isn’t really a licensing question, it’s a commercial one, and it needs a named owner and a renewal date rather than a one-time legal sign-off.
- Read the Additional Use Grant on every BUSL component you depend on. It’s the only part of the license the licensor wrote, and it’s the part that can get rewritten for you when the company gets acquired.
- For anything copyleft you ship on a device, make sure you can produce the build scripts, and for LGPL static linking, the relinkable objects. That’s the gap in every embedded enforcement action I could find, including the two that are currently live.
- Decide your position on AI-generated code before somebody asks you in diligence. You’ve got three real options: rely on vendor indemnity and document its conditions, run a code-similarity check independent of the suggestion tool, or accept the exposure on purpose. Doing nothing while assuming your SCA tool has it covered isn’t one of the three, because structurally it doesn’t.
- Add license to your SBOM configuration explicitly, and then validate the output. Don’t assume the generator populated it. The failure mode here is a field that’s present, empty, and wrong.
What I got wrong in 2016
The first version of this article ran in August 2016, and one sentence in it has aged badly enough to be worth quoting:
“Once you’ve accepted for example the MIT license (currently the most popular open source license) you’re ready for all projects that use open source components with that license.”
Clear the license type and you’re done. I wrote that without hesitating, because in 2016 it was true and because everybody said it. What it assumed is that the license is a stable property of the component, and for most of open source history it effectively was.
A few smaller ones while I’m at it. I described the GPL as including “an express grant of patent rights from the contributors,” in a paragraph that also noted it comes in many versions. GPLv3 does. GPLv2 doesn’t, and if patents matter to your business then that distinction is the whole ballgame. I left the AGPL out of the license list entirely, which was defensible in 2016 and would be negligent now. And I titled that same section “Patentability,” which is a real word that means something else: whether a thing can be patented in the first place. The section was never about that. It’s about what patent rights a license hands you and what suing costs you. Nobody called me on it for ten years, which tells you something about how closely any of us read our own headings.
But the first one is the one that matters. The most expensive open source licensing events of the last eight years didn’t happen to teams that chose badly. They happened to teams that chose correctly and then stopped looking.
Summary
Vibrant, actively maintained open source projects with licenses that are compatible with your business are still a great asset, and that part I’d write again word for word.
What’s changed is that compatibility isn’t something you establish once. So check the license before you adopt, and then keep checking, because the company that wrote it is still out there making decisions about its business, and you’re downstream of every one of them.
Check your licenses. Then check them again.