There is GPL code in our product: what open source licenses actually require of you

Using an open source library costs nothing, but it is not unconditional. Every license is a grant of permission: you may use, modify and redistribute the code as long as you meet the conditions, and the moment you stop meeting them the permission lapses and what remains is an ordinary copyright infringement. In practice you deal with three families. Permissive licenses (MIT, BSD, ISC, Apache 2.0) ask for little beyond attribution. Copyleft licenses (GPL, LGPL, MPL, AGPL) ask you to release the source of what you derive under the same terms. A third group, source-available licenses such as SSPL and BUSL, lets you read the code but forbids certain uses outright. The distinction that matters most: copyleft obligations are triggered when you hand the software to someone else, not when you run it internally. AGPL is the exception to that rule, and it is the one license a SaaS company should keep an eye on.

The scale of this is larger than most teams assume. Black Duck's 2026 OSSRA report, which audited 947 commercial codebases across 17 industries, found open source in 98% of them and at least one license conflict in 68%. The year before, that figure was 56%. The report calls it the largest single-year jump it has recorded, and one codebase in the sample carried 2,675 distinct conflicts. These numbers come from codebases that were audited, meaning someone was buying, investing or doing due diligence. Most companies learn what is in their own product when the other side of the table looks.

What the word "distribution" opens and closes

In the GPL family, the obligation arises when the software leaves your company. Running it internally is not distribution. You can take a GPL-licensed library, modify it, run it inside your own systems for years and publish nothing. Teams that do not know this panic for no reason.

The cases that do count as distribution are clear enough: an app you upload to a store, an installer you send a customer, firmware you burn onto a device, a version you deploy on the customer's own server. All of these trigger the full obligation, which includes the complete corresponding source plus the scripts used to build it.

Classic GPL does not treat SaaS as distribution. Your product runs in a browser, no code reaches anyone's machine, no source offer is owed. AGPL was written to close exactly that gap. Its section 13 requires you to offer the source to anyone who interacts with the software over a network. An AGPL component that ends up in your SaaS build raises a question about the whole product, so if you see AGPL in your dependency list, do not leave that line to chance.

Three families, three different bills

Permissive licenses. MIT and BSD ask for one thing in practice: carry the copyright notice and the license text in every copy you distribute. Apache 2.0 is a little more detailed. It asks you to include the license, to state which files you changed, and to carry the contents of any NOTICE file into your own product. In return it gives you an explicit patent grant, which terminates if you sue over that patent.

Strong copyleft. GPLv2, GPLv3 and AGPL require the entire derivative work to be distributed under the same license. Where a derivative work begins is one of the most contested questions in the field, but a practical rule holds up: linking a library into your own process is high risk, while calling it as a separate process across a defined interface leaves you on more defensible ground. GPLv3 additionally requires installation information for consumer devices, so a user can install their own build.

File-level copyleft. MPL 2.0 and EPL 2.0 sit here and are far easier to live with. The obligation covers only the files you modified; your own code stays closed. LGPL belongs in the same range: link dynamically and let users swap in their own build of the library, and you do not have to open your product.

License compatibility is its own topic. The best-known case is that Apache 2.0 and GPLv2 are incompatible. You can run a build that contains both for years without noticing, and that is precisely the kind of conflict audits surface.

The most common violation is a small one

What usually catches companies out is not GPL code smuggled in by a developer. It is failing to meet MIT's single condition, which means shipping hundreds of permissively licensed libraries without their copyright notices and license texts in the package.

On mobile and desktop products the standard answer is an open source licenses screen inside the app. On the web a text file or a page does the job. Do not maintain it by hand; generate it at build time from your package manager's license output, or it will fall out of date with the first dependency bump and nobody will notice.

What enforcement looks like: the Vizio case

For anyone who thinks copyleft exists only on paper, the most interesting case of the last five years is Software Freedom Conservancy's suit against Vizio. Filed in October 2021, it takes an unusual route: SFC sues not as a copyright holder but as someone who bought a television containing GPL software, claiming source code as a third-party beneficiary of the license. Vizio's motion for summary judgment was denied on December 29, 2023, and the case moved forward on the merits. Trial is scheduled for late 2026 and no final judgment has been issued. Whatever the outcome, the shift is already visible: the party that buys a product may be able to demand compliance.

The direct consequence of a violation is written into the license itself. Under GPLv2 the license terminates automatically the moment you breach it, and getting it back means asking the copyright holder. GPLv3 softened this with a 30-day window to cure after notice. In 2017 and 2018, Linux kernel developers along with Red Hat, IBM, Google and Facebook committed to extending that same cure period to their own GPLv2 code. It is a commitment rather than a guarantee, and it only binds the rights holders who signed it.

The license you see today may not be the license tomorrow

The most expensive surprises of the last three years came from license changes, not vulnerabilities.

On August 10, 2023, HashiCorp moved Terraform and the rest of its products from MPL to BUSL 1.1. The community forked the last open version, and OpenTofu was accepted by the Linux Foundation on September 20, 2023, continuing under MPL 2.0. Redis switched from BSD to a pair of RSALv2 and SSPLv1 with version 7.4 in March 2024; the Valkey fork appeared under the Linux Foundation within days, and Redis added AGPLv3 back as an option with Redis 8 on May 1, 2025. Elastic had moved to SSPL and Elastic License 2.0 in 2021, then added AGPLv3 on August 29, 2024 and returned to the open source side.

The operating rule that follows is simple: choosing a dependency is not a one-time decision. Check the license line when you upgrade, because relicensing arrives with a new version while the old version keeps its old terms. That is the second reason, independent of security, to pin versions and know exactly what sits in your build. The inventory habit described in software supply chain security does the same job here.

"Source-available" is not "open source"

What SSPL and BUSL have in common is that the Open Source Initiative has not approved either. MongoDB withdrew its SSPL application. These licenses let you read the source and, in most cases, use it, but they do not meet the open source definition.

With BUSL the boundary is drawn by the company granting the license. The standard text blocks production use, and companies loosen it with an additional use grant. HashiCorp's grant permits production use while excluding hosted services that compete with its own products. BUSL also requires a change date no more than four years out for each release, at which point the code converts to a GPL-compatible license. For Terraform, that change license is MPL 2.0.

The practical upshot: for most companies these licenses cause no trouble day to day. They cause trouble in contracts. If your tender response or customer agreement states that only open source components were used, an SSPL or BUSL component does not satisfy that commitment.

What license does AI-generated code carry?

The term OSSRA uses to explain the jump in license conflicts is "license laundering": AI assistants produce snippets derived from copyleft sources without carrying the original license information along. In the same report's survey, 76% of organizations check AI-generated code for security risk, only 54% check it for intellectual property and licensing risk, and just 24% check all four categories. Adding a license item to your review checklist closes a measurable gap. We covered the wider question in reviewing AI-generated code.

The same rule applies to code copied by humans. Snippets taken from question and answer sites usually sit under a Creative Commons license that requires attribution. Code pulled from a repository with no license at all is not free to use; the default is all rights reserved.

No inventory means no compliance

License compliance looks like legal work and is actually inventory work. The starting point is a software bill of materials generated automatically from your production build. Two formats dominate: SPDX, which grew out of license tracking (version 2.2.1 was standardized as ISO/IEC 5962:2021), and OWASP's CycloneDX, which leans toward security use cases (ECMA-424). Which one you pick matters far less than not keeping the list in a spreadsheet.

Generate it in the build, because a hand-maintained list stops reflecting reality within a week. Then attach it to a gate: when a new dependency arrives with a license your policy does not allow, the pull request goes red. GitHub opened this check in preview on June 30, 2026 for Enterprise Cloud customers with Advanced Security Code Security, and independent tools have done it for years. If you already run a CI/CD pipeline, this is one more step in it.

The policy fits on one page

Three buckets beat a long legal memo.

• Allowed: MIT, BSD, ISC, Apache 2.0, Unlicense. The only condition is carrying notices into the package.
• Needs review: LGPL, MPL 2.0, EPL 2.0. Usually fine if dynamic linking and the file boundary are respected.
• No by default: GPL, AGPL, SSPL, BUSL and anything with no stated license. Not in a distributed product without written approval.

Read the buckets together with context. GPL in a tool that never leaves your network is a non-issue. The same component in a product you install at a customer site is a real decision. AGPL in your SaaS concerns the entire product.

If you outsource development, put it in the acceptance criteria

Most companies that take delivery of custom software never ask how much of the delivered code belongs to somebody else. Three clauses close that gap: a component list with license information delivered alongside the code, copyleft components only with written approval, and the required notice files present in whatever you ship. These follow naturally from the contract work described in source code ownership and escrow, and the easiest place to verify them is acceptance testing.

When you hit a genuinely contested question, such as where the derivative work boundary falls for your particular architecture, do not settle it in a team meeting. An hour with an IP lawyer is cheaper than rewriting a product later.

Four things you can do this week

1. Produce the list. Export components and licenses from your production build. Most package managers do this in one command; if yours does not, an SBOM tool takes half an hour to set up.
2. Look for four things. Components under GPL, AGPL, SSPL or BUSL, plus any package with no license at all. This is usually the shortest section of the list and it contains every decision you need to make.
3. Check the notice file. Does the package you ship to customers include the license texts? If not, that is the fastest gap you will ever close.
4. Write the three buckets and wire them to a gate. One page of policy today, an automatic check on pull requests this week.

Most teams that run step one find something they did not expect. That is not carelessness; it is the dependency of a dependency of a dependency. Once the list exists, the job shrinks to a few minutes a month.