For most engineering teams, shipping software feels like crossing the finish line. CI/CD pipelines green, tests passing, code deployed to production, job done. Until an email arrives in the inbox of your CEO or General Counsel.
The subject line is formal, referencing dynamic linking, terms of use, and copyright compliance. Someone discovered that your proprietary, revenue-generating software contains an open-source component with unresolved license obligations, and you distributed or hosted it without complying with the terms.
Accidental license breaches happen all the time. A developer under deadline pressure drops in a handy library, unaware that it carries the GNU General Public License (GPL) or Affero GPL (AGPL). But once you ship or deploy that code, the clock starts ticking.
What actually happens when an open-source license breach is discovered? Who catches you, how are you notified, what are your legal obligations, and, most importantly, can you fix it?
Let's break down six real-world compliance scenarios across different license types and delivery models.
Not legal advice. We are not lawyers. This article describes patterns we have seen and what license texts say on their face; it is not a substitute for qualified counsel. Copyleft obligations, cure periods, and damages exposure all depend on the specific licenses involved, how your product is distributed, your contracts, and your jurisdiction. If you have received a compliance notice, talk to a lawyer before you respond to it.
Quick reference: license categories & compliance obligations
Before looking at specific scenarios, it helps to understand where different open-source licenses sit on the spectrum of compliance risk:
| License category | Common examples | Source disclosure required? | Primary obligation |
|---|---|---|---|
| Strong copyleft | GPLv2, GPLv3, AGPL | Yes, for the work based on the program | Open-source the corresponding source of integrated modules if distributed or hosted |
| Weak copyleft | MPL 2.0, LGPL, EPL | Partial, only for modified library files | Keep proprietary app code private, publish edits made to library files or provide a source offer |
| Permissive | MIT, Apache 2.0, BSD | No | Retain original copyright headers, attribution notices, and NOTICE files |
Who typically contacts you?
Compliance notices do not all look the same. The tone, leverage, and objectives depend heavily on who identifies the issue:
- Commercial dual-license vendors: companies that offer the same software under both a copyleft license and a paid commercial one, a model used by projects such as iText, Neo4j, and Qt. Enforcement is structural here rather than incidental: the copyleft license is what makes the commercial one worth buying, so unlicensed commercial use tends to be identified and pursued. Notices in this category typically arrive from a legal team and may seek licensing fees covering the period of unlicensed use.
- Rights organizations (the Software Freedom Conservancy, the Free Software Foundation): driven by open-source advocacy. They prioritize compliance over financial settlements, usually starting with informal outreach before issuing formal requests.
- Individual maintainers: driven by recognition or project integrity. Outreach ranges from friendly GitHub issues to legal demand letters if ignored.
- Enterprise customers: driven by corporate risk management. Issues surface during procurement scans or Software Composition Analysis (SCA) audits of vendor installers.
- Automated compliance firms: specialized agencies hired by copyright holders to scan public repositories, client-side assets, and app stores for unauthorized usage.
The SaaS platform & AGPL
For years, SaaS companies felt immune to traditional copyleft licenses like the GPL. Because web applications run on cloud servers and are never “distributed” to the user's hard drive, the GPL's source-code disclosure trigger was never pulled.
Enter the AGPL (Affero General Public License), specifically designed to close that gap. Under AGPL, simply letting users interact with the software over a network counts as a trigger.
The example: iText / iTextSharp. A classic trap involves PDF generation. iTextSharp moved from a weak-copyleft dual license, the Mozilla Public License paired with the GNU Lesser General Public License (LGPL), to the strong-copyleft AGPL at version 5. A SaaS team integrates iText to generate invoices, reports, or contracts, completely unaware of the license shift.
Who notifies you & how? With dual-licensed libraries like iText, compliance enforcement is part of the vendor's core business model. You will receive a formal cease-and-desist letter or audit inquiry from the vendor's legal team. They track usage via client-side PDF metadata, which often embeds the engine name, along with public repositories and automated web scrapers.
Real-world precedents. In Neo4j, Inc. v. PureThink, LLC, Neo4j enforced its AGPLv3-plus-Commons-Clause terms in federal court; the Ninth Circuit affirmed that downstream parties could not strip the added commercial restriction and continue redistributing. Separately, companies like Elastic relicensed to the Server Side Public License (SSPL), an AGPL-derived license, in response to cloud providers offering their software as a managed service. In many real-world cases, vendors treat AGPL non-compliance as a copyright issue once rights terminate under the license.
What do you have to do? The AGPL asks you to provide the Corresponding Source of the “work based on the Program” to all network users. Depending on integration details, that can reach beyond the library itself: where the AGPL component is tightly coupled to your application logic, the scope may extend to tightly integrated backend modules.
Can you fix it? You generally have three options:
Pay for a commercial license. The copyright holder offers to sell you one. But because you were previously in breach, they hold the negotiating leverage and may demand retroactive fees or damages.
Open-source the integrated backend. Comply with the AGPL by publishing the corresponding backend source under AGPL. For commercial startups, this is rarely viable.
Refactor and isolate immediately. Strip out the AGPL component and replace it with a permissively licensed alternative, or isolate it behind an out-of-process API microservice boundary.
Weak copyleft & modified code (MPL)
Not all copyleft licenses reach your entire codebase. Weak or file-level copyleft licenses, such as the Mozilla Public License (MPL 2.0) or Eclipse Public License (EPL), create a middle ground. You can link an MPL library to your proprietary app without open-sourcing your app.
The trap occurs when developers modify the internal source files of the MPL library itself.
The example. Your team pulls in an MPL-licensed networking or rendering library. A developer finds a bug or adds a custom performance tweak directly inside the library's source files, commits the changes to your internal repo, and ships the compiled binary.
Who notifies you & how? MPL violations are usually caught during corporate M&A due diligence, external code audits, or when an engineer unintentionally submits a pull request upstream that reveals customized internal files.
What do you have to do? Unlike the GPL, the MPL does not force you to open-source your entire application. Under Section 3 of the MPL, you must make the source of the modified MPL files available, or provide a valid written offer to supply it, to anyone to whom you distribute the executable.
Can you fix it? Yes, MPL violations are relatively clean to resolve:
- Option A: publish your specific file modifications to a public repository, such as a public GitHub fork, and include the required MPL notices.
- Option B: revert your custom file edits and move your logic outside the library, extending it via public interfaces or wrappers in your own proprietary files.
The mobile app & GPL
Mobile applications are binaries compiled and distributed directly to millions of end-user devices. Because binaries are physically distributed, standard GPLv2 and GPLv3 rules apply in full force whenever GPL code is statically or dynamically linked into the application bundle.
The example. A mobile team adds video chat, VoIP, or audio filtering using a GPL-licensed library compiled into the app. Disputes of exactly this shape, where GPL-licensed code from a well-known open-source project turns up inside a closed-source mobile app, have played out publicly more than once. They are frequently settled through public pressure and a quick remediation rather than through litigation, but the reputational cost lands either way.
Note. Calling a completely separate GPL utility as a distinct, independent subprocess is generally understood not to trigger copyleft obligations on the caller, but static or dynamic compilation into the mobile app binary does. The boundary here is contested and fact-specific, so treat it as a question for counsel rather than a settled rule.
Who notifies you & how? Two sources dominate in the mobile space. First, rights organizations like the Software Freedom Conservancy, or independent maintainers. Second, app store takedowns: maintainers can file a Digital Millennium Copyright Act (DMCA) takedown notice directly with Apple or Google, forcing them to pull your app from the store until the issue is resolved.
What do you have to do? Under the GPL, distributing compiled binaries can require providing the Complete Corresponding Source to anyone who receives the binary, where the GPL component is part of a work based on the Program.
Can you fix it? This is a point to involve counsel before acting, because the right first move depends on facts specific to your situation, and some of the obvious-looking moves carry consequences of their own. Broadly, teams in this position tend to weigh some combination of three things:
- Halting further distribution by pulling the affected release from the stores. This stops new non-compliant copies going out, but it is a business and contractual decision as much as a compliance one, and counsel may have views on timing.
- Removing the component and rewriting the module against a permissive or weak-copyleft alternative.
- Fulfilling the disclosure obligation for the versions already in users' hands, which does not go away just because later releases are clean.
Which of these applies, in what order, and on what timeline is a legal question at least as much as an engineering one. Work it out with your lawyers rather than from a blog post.
Scenario 4The missing notice (permissive non-compliance)
A common misconception is that permissive licenses like MIT, BSD, and Apache 2.0 carry zero risk. While they allow you to keep your source code completely private, they are not public domain. They are conditional licenses, and the primary condition is attribution and notice propagation.
The example. Your team builds a web application or SDK using dozens of npm or Cargo packages licensed under MIT and Apache 2.0. To optimize bundle size, your build script strips out all comments, headers, LICENSE files, and Apache NOTICE files, serving a single minified JavaScript bundle to millions of users.
Who notifies you & how? Maintainers or security researchers notice their copyright headers missing from your distributed assets or client-side bundles. You receive a formal inquiry requesting immediate restoration of attribution.
What do you have to do? Because you stripped the copyright notices and mandatory Apache NOTICE contents, you are distributing the software without meeting the license's conditions, which is what creates a copyright problem once notice is served.
Can you fix it? Permissive violations are the easiest to fix, but they require swift action:
Add an open-source notices file. Create an “About / Third-Party Software Notices” screen in your app, or an accessible NOTICES.txt in your distribution package.
Configure your build pipeline. Update Webpack, Vite, or your compiler to automatically extract and aggregate package LICENSE and NOTICE files into a final notice bundle during production builds, rather than stripping them.
On-premise enterprise software & GPL
On-premise applications are installed directly inside a client's data center or private cloud. Because corporate clients often mandate lengthy QA cycles, security reviews, and scheduled maintenance windows, deploying updates in on-prem environments takes time.
The example. An enterprise vendor bundles a GPL command-line utility, such as BusyBox or a specialized GPL data-processing tool, inside an installer package or a virtual appliance, typically shipped as an Open Virtual Appliance (OVA), the single-file virtual machine image customers import into their own infrastructure.
Who notifies you & how? Enterprise buyers frequently perform their own SCA scans on third-party installers during vendor risk assessments. A customer's legal team, or an open-source rights enforcer, flags the violation.
On-prem is a toothpaste-back-in-the-tube problem.
This is what separates on-prem from every other scenario here. With SaaS you control the deployment, so a fix you ship on Tuesday is live on Tuesday. With on-prem you control the release and nothing else. Your customers decide when, or whether, to take it. A 6-to-18-month approval cycle is ordinary. Never is entirely possible, if the version they are running still works and nothing is forcing them to move.
So you can cut a clean version 2.0 the same week you find the problem, and the affected code still sits in the field for as long as your customers leave it there, and a vendor typically has limited control over customer upgrade timelines.
Can you fix it? Two things run in parallel. You cut a patched release and push it through account managers with whatever urgency your customer agreements allow. Meanwhile you work out, with counsel, where you stand with the customers already running the affected version.
That second part is usually less dramatic than it sounds, because it depends entirely on who your customers are. Most on-prem customers have no interest in copyleft whatsoever. They bought a product to solve a problem, and a notice about license obligations in a component they have never heard of is not something they are going to act on. A minority will care, and they tend to be the ones with a real legal or compliance function, or an open-source policy they are held to. Those customers may ask for source access to the components in question, which is what the license entitles them to. So the useful question is not what your entire install base might demand, but how many of them sit in that second group. Usually it is a short list, and you can generally work out who is on it before anyone asks.
Scenario 6Code contamination and the SBOM blindspot
Not all license breaches enter through formal package managers. One of the most subtle ways copyleft risk enters a codebase is through code snippet contamination: a developer manually copy-pastes a non-trivial algorithm from an AGPL project, or a generative AI coding assistant echoes a memorized, copyleft-derived snippet directly into a proprietary file.
Why SBOM-based scanners miss it. Software Composition Analysis (SCA) and Software Bill of Materials (SBOM) tools operate at the package manifest and dependency tree level. They inspect files like package.json, go.mod, or lockfiles to detect declared dependencies and their licenses. Because copy-pasted or AI-generated snippets carry zero manifest footprint, a manifest-level scanner cannot discover this contamination. To that whole class of tool, a contaminated file looks like pure, original proprietary code.
What catches it instead. Finding this requires a different kind of scanner: a specialized pattern-matching engine that compares your source at the token and syntax level, matching structural fingerprints against large databases of public open-source repositories to flag overlaps. That is a fundamentally heavier operation than reading a manifest, and it is priced accordingly. These engagements are expensive enough that few teams run them as routine hygiene.
So when does anyone actually run one? Almost always during technical due diligence for a major business event, and in practice that usually means M&A. When a company is being acquired or taking private equity investment, the buyer commissions a deep pattern-matching scan as part of diligence. That timing is what makes contamination awkward: it tends to surface at the exact moment you have the least room to negotiate and the least appetite for a delay.
It is worth keeping the risk in proportion, though. Direct snippet contamination is fairly rare, and it is almost never caught in the wild by maintainers, because the snippet sits buried inside a compiled binary or a closed-source backend where nobody outside your company can see it.
Can you fix it? If a pattern-matching scan flags a copyleft snippet, you have two primary options. Either commission a clean-room rewrite, where an engineer who has not viewed the copyleft source rewrites the function from scratch against a functional spec, or refactor using standard libraries, since idiomatic language utilities and simpler patterns typically break the token signature and eliminate the derivation risk.
What happens inside your company after notice?
When a formal compliance letter hits executive inboxes, companies follow a predictable internal workflow:
Legal triage. Legal assesses the validity of the notice, identifies the specific license version, and evaluates whether distribution or network access occurred.
Engineering audit. Engineers locate the exact dependency, determine how it is linked or called, and check build outputs and server deployments.
Architecture review. The team decides whether the component can be swapped, refactored out-of-process, or whether a commercial license must be negotiated.
Remediation strategy. Engineering and legal align on a timeline, draft a response to the copyright holder, and assign refactoring tickets.
Resolution & release. The patch is deployed, notice files are updated, or commercial terms are executed, followed by written confirmation to the copyright holder.
Timelines: how long do you have?
GPLv3 and AGPLv3 include a 30-day cure period. Section 8 of the v3 licenses provides that if you cure a violation within 30 days of receiving notice from the copyright holder, and you have not previously received notice from that holder, your rights are reinstated. This is a term written into the license itself, not a protection granted by statute, and the reinstatement mechanics are more detailed than a single deadline suggests.
GPLv2 and permissive licenses have no cure clause. Under GPLv2, rights terminate on breach with no written path back, though in practice cease-and-desist letters almost always grant a working remedy window of roughly 14 to 30 days before formal filings. MPL 2.0 is the exception among the older licenses: Section 5 does provide a cure mechanism, so do not lump it in with GPLv2 when you assess your exposure.
In practice, cure or remediation windows tend to be measured in weeks rather than months: a fixed 30 days under the v3 licenses, and a comparable practical grace under the rest. The catch is that the clock is set by the license, not by how long your fix takes. Pulling a component and re-releasing might be a week's work, or, for on-prem software deployed across enterprise customers, considerably longer than any cure window, which is why the moment to start is when the notice arrives rather than when the plan is finished.
Can you just ignore the notice?
No. Under copyleft licenses, rights terminate upon breach, and continuing to distribute or host after termination can constitute infringement. Ignoring a notice compounds the problem in three ways:
- Platform takedowns. Copyright holders can issue DMCA takedown notices to cloud providers and to the Apple and Google app stores. App store removal is the common, well-documented outcome; getting an entire cloud-hosted service pulled is rarer and slower, but the pressure is real.
- Willful infringement damages. Ignoring written notice is the classic route to a willfulness finding, which in the US raises the statutory damages ceiling.
- M&A and fundraising freeze. An unresolved compliance dispute will stall venture funding or an acquisition during investor legal due diligence, and this is the consequence companies actually feel most often.
Summary matrix
| Scenario | License type | Primary trigger | Options typically weighed |
|---|---|---|---|
| SaaS platform | AGPLv3 | Network interaction by end users | Refactor out-of-process, buy a commercial license, or publish the backend within the cure window |
| Modified internal files | MPL 2.0 | Distributing binaries with edited library source files | Publish modified library files or move changes to external wrapper code |
| Mobile app | GPLv2 / GPLv3 | App store binary distribution of linked code | Remove GPL code, release an app update, or fulfill source disclosure |
| Stripped attribution | MIT / Apache 2.0 | Shipping binaries or JS bundles without copyright and NOTICE files | Aggregate third-party licenses into an About / Notices file or build asset |
| On-premise software | GPLv2 / GPLv3 | Delivering installers or OVAs to client data centers | Patch and release, then settle obligations on already-deployed versions with counsel |
| Snippet contamination | Any copyleft | Copy-paste or AI-suggested code with no manifest entry | Clean-room rewrite or refactor to idiomatic standard-library patterns |
An accidental open-source breach requires a calm, coordinated effort between engineering and legal. Knowing how your delivery architecture interacts with open-source licenses is what lets you resolve these questions long before you ever face a public compliance retrospective.
← Back to the OSSScan Blog