A problem discovered at the worst possible time

Helios Systems is six weeks from closing. The term sheet is signed, the press release is drafted, the founders have already started looking at houses near the acquirer's campus—and then the buyer's technical due-diligence team sends over a one-paragraph email that turns the whole transaction into a question mark.

Helios is a fictional but entirely representative enterprise software company. Its flagship product is a proprietary analytics platform it has sold under closed-source commercial licenses for a decade. It has never released its source code, never intended to, and built a nine-figure valuation on the premise that the code is its own. Buried deep in the dependency tree of that platform, the buyer's auditors have found a component licensed under the GNU General Public License. Nobody at Helios chose it. It arrived years ago as a transitive dependency—a library that a library that a library depended on—pulled in by a developer who was solving an unrelated problem and never read past the function he needed. And depending on exactly how it is wired into the product, that single GPL component may obligate Helios to release the source code of its crown-jewel analytics engine to the entire world under the same GPL.

Helios's options are all bad. It can release its proprietary source under the GPL, which destroys the very asset the buyer is paying for. It can re-engineer the product to rip the component out, which is slow, expensive, and may not finish before the closing date. Or it can do nothing and accept the risk of a copyright-infringement claim that, as we will see, carries the threat of an injunction barring distribution of the product entirely. None of these is attractive six weeks before a closing, and all of them put the deal in jeopardy.

This is not an exotic scenario. It is the predictable consequence of how software is now built. Industry analyses—most famously the open source risk reports that scan well over a thousand commercial codebases a year—have found open source components in more than 96% of codebases, with open source making up roughly 60% to 70% of the typical application's lines of code. The average enterprise application now incorporates well over a hundred distinct open source libraries, most of them transitive dependencies that no human ever consciously selected. This reliance is not a problem to be solved; it is the foundation of modern development. It speeds time to market, frees expensive engineers for higher-value work, and gives small companies access to battle-tested infrastructure they could never build themselves. But beneath the bounty runs a web of legal obligations that can ensnare the unwary, and the consequences are no longer hypothetical. In February 2024 the Paris Court of Appeal ordered the telecommunications giant Orange to pay roughly €860,000 for violating the GPLv2. Competitors have begun weaponizing open source noncompliance as the basis for antitrust and unfair-competition claims. And a four-year lawsuit over a Vizio television has spent 2025 and 2026 testing whether any consumer who buys a GPL-running gadget can compel the manufacturer to hand over source code.

This article maps that landscape and the practical frameworks for managing it. It is the companion to our broader guide on the legal protection of software, which explains how copyright, patent, trade secret, and contract law combine to protect proprietary code; here we examine the mirror image—how that same body of copyright law is turned around and used to keep code open, and how an enterprise stays on the right side of it. For the operational tooling, intake forms, and audit worksheets that implement what this article describes, see our open source compliance checklists. The single most important fact Helios is about to learn the hard way is this: the time to address open source compliance is before a problem emerges, which is not the same as the moment a problem is found.

Why open source licensing has teeth

To understand why one overlooked component can threaten a deal, you have to appreciate the legal jiu-jitsu at the heart of the open source movement. A proprietary license grants you limited rights in exchange for money. An open source license does something cleverer and, to a lawyer, almost paradoxical: it uses copyright—the body of law designed to exclude people from copying a work—to guarantee that the work stays freely copyable, while attaching conditions to that freedom.

The story starts in 1985, when Richard Stallman, an MIT-trained programmer reacting against the commercialization of software he had grown up sharing, founded the Free Software Foundation (FSF) and articulated four freedoms that "free software" must guarantee: the freedom to run the program for any purpose, to study and adapt it (which requires access to source code), to redistribute copies, and to improve it and redistribute the improvements. To enforce those freedoms, the FSF authored the GNU General Public License and built into it a mechanism Stallman named, with characteristic wit, copyleft. Ordinary copyright lets an author prevent others from copying. Copyleft inverts the tool: the author grants everyone the right to copy, modify, and distribute—but conditions that grant on the recipient passing the same freedoms downstream, so the software and everything derived from it stays free forever. A separate camp, more interested in pragmatic adoption than philosophy, formed the Open Source Initiative (OSI) in 1998 and published the Open Source Definition, a ten-point checklist a license must satisfy to be "open source." The OSI has approved roughly a hundred such licenses. The two movements—"free software" and "open source"—differ in emphasis, but for legal purposes they describe the same machinery.

Here is the part that gives that machinery its bite. Violating an open source license is not merely breach of contract; it can be copyright infringement. The seminal U.S. authority is Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), where the Federal Circuit considered the Artistic License governing a piece of open source model-railroad software. The accused infringer argued that the license's attribution and notice requirements were mere contractual covenants—promises whose breach gives rise only to contract damages, which in the open source world (where no money changes hands) are often modest and hard to prove. The court disagreed. It held that those requirements were conditions on the scope of the license grant itself. Exceed a condition and you are no longer licensed at all; your use of the copyrighted work becomes infringement, full stop.

The distinction between a covenant and a condition is the hinge on which the entire field turns, so it is worth stating precisely. A covenant is a promise within a license that otherwise remains in force; breach it and the other side sues for damages. A condition is a limit on the license itself; exceed it and the license evaporates, leaving you an infringer. Jacobsen held that the open source terms there were conditions. The Federal Circuit also dispatched the intuition that open source licenses are toothless because they are free: even though no royalties flow, copyright holders "obtain[] credit, recognition, and a buildup of community" and other real economic benefits—reputation, market share, the ability to attract contributors—and the law protects those interests. The consequence is decisive. A copyright holder whose conditions have been violated need not prove contract damages. It can invoke copyright's presumption of irreparable harm, seek an injunction halting distribution, and pursue statutory damages and attorneys' fees under the Copyright Act. (This is the same covenant/condition line that governs ordinary commercial software licenses, drawn most influentially in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010); we work through it in the commercial-licensing context in drafting software license agreements.)

That is why the buyer's diligence team treated Helios's GPL component as deal-threatening rather than trivial. It is not a contract loose end to be quietly settled after closing. It is potential infringement of the component authors' copyrights, enforceable with the full arsenal of copyright remedies—including an injunction that could pull Helios's flagship product from the market. A volunteer developer or a nonprofit like the Software Freedom Conservancy holding the copyright in a popular library wields, against a billion-dollar corporation, not the threat of a manageable damages payment but the threat of a court order that stops the corporation from shipping its product. That asymmetry is the whole reason open source compliance is a board-level risk and not a footnote.

One open question lurks beneath all of this and occasionally resurfaces in litigation: is the GPL a "bare license" with copyright conditions attached, or is it a contract? The FSF's longstanding position—buttressed by Jacobsen—is that it is a bare copyright license, so that breach loses you the license and exposes you to infringement remedies. But in Artifex Software, Inc. v. Hancom, Inc., No. 16-cv-06982 (N.D. Cal. 2017), a court allowed a breach-of-contract claim premised on the AGPL to proceed, reasoning that a licensee who uses the software manifests assent to the license's terms as a matter of contract. The two characterizations are not mutually exclusive, and—as we will see—the Vizio litigation has made the contract theory unexpectedly central. For now, the practical takeaway is that an open source licensor may be able to come at you from two directions at once: copyright infringement and breach of contract.

The license taxonomy: permissive, copyleft, and the spectrum in between

Open source licenses sort into two broad families, and grasping the difference is the first thing any enterprise must do.

Permissive licenses—the MIT License, the BSD licenses, the Apache License 2.0—impose minimal restrictions. You can take the code, modify it, fold it into proprietary software, and ship the result without disclosing your source, provided you preserve the upstream copyright notices and license text. These are the licenses that let companies build closed products on open foundations, and they have been winning: the share of open source under permissive licenses overtook copyleft around 2015 and has kept climbing, with MIT and Apache 2.0 together accounting for roughly half of all open source usage today. Google's Android project says the quiet part out loud, going out of its way to license its own code under Apache 2.0 and avoiding LGPL libraries precisely because copyleft compliance is, in its words, difficult.

The Apache License 2.0 deserves a closer look because it carries strings that surprise companies who assume "permissive" means "free of obligations." First, it includes an express patent grant: every contributor licenses to recipients any patents that would be infringed by their contribution—a genuine benefit that became salient after a wave of open source patent disputes. But that grant comes paired with a patent-retaliation clause: sue an Apache-licensed project (or its users) claiming the software infringes your patent, and you forfeit your own patent license to that project. An enterprise that asserts a patent against an Apache project can thus lose its right to use that project's code—an interaction nobody anticipates from a "permissive" license. Apache 2.0 also requires you to preserve any NOTICE file and propagate its contents. And even the barest licenses—MIT, BSD, ISC—impose an attribution obligation: you must reproduce the copyright notice and license text in your distributed product. Those notices are routinely stripped during build and packaging, dropped from compiled binaries, or lost when code is copied-and-pasted rather than properly imported, and the resulting failure to attribute is a real violation, even if a less catastrophic one than a copyleft breach. A compliance program that waves through permissive licenses on the theory that "only copyleft matters" will quietly accumulate a backlog of attribution failures that, individually minor, collectively tell a diligence team that the company does not manage open source carefully—itself a red flag in any transaction.

Copyleft licenses—the GPL being canonical—impose the heavier obligation: distribute software that incorporates copyleft code, and you must make the corresponding source available, under the same license, to whoever receives the binary. The GPL's mechanism is elegant. Section 0 of GPLv2 makes clear that "the act of running the Program is not restricted"; internal use, however extensive, triggers nothing. It is distribution that flips the switch. Distribute a "work based on the Program," and Section 2(b) requires you to license the whole thing, "at no charge to all third parties," under the GPL. This reciprocity—"share-alike"—is what keeps improvements flowing back into the commons instead of disappearing into proprietary products.

Which raises the question on which Helios's fate rests, and which decades of debate have never fully resolved: what counts as a "work based on the Program"? The GPL defines it expansively—any work "that in whole or in part contains or is derived from the Program or any part thereof." Whether combining GPL code with proprietary code creates such a work, and thereby drags the proprietary code into the GPL's disclosure obligation, turns on technical details of how the two are bound together. We work through that analysis in its own section below, because it is where abstract doctrine meets concrete engineering and where the difference between a manageable problem and an existential one is decided.

Copyleft itself runs along a spectrum from strong to weak to network:

  • Strong copyleft (GPLv2, GPLv3) reaches the entire combined work. Ship software that incorporates GPL code, and the whole thing must generally go out under the GPL, with source. Critics call this "viral"; the FSF prefers "hereditary" or "protective." Both metaphors describe the same propagation.
  • Weak copyleft (the GNU Lesser General Public License, or LGPL) was engineered to be narrower. The LGPL lets proprietary software link against an LGPL library without copylefting the proprietary code: you must make available the source to the library itself and any modifications you make to it, but your own code stays yours. The LGPL is famously prescriptive about exactly how the linking may occur to preserve that boundary—which is part of why Google found it easier to avoid LGPL libraries than to comply with them.
  • Network copyleft (the GNU Affero General Public License, or AGPL) closes a loophole the ordinary GPL leaves open. Under the GPL, distribution triggers the source obligation—but software that merely runs on a provider's servers and is reached over a network is never "distributed" in the traditional sense. The AGPL adds a trigger for exactly that case: if users interact with AGPL software over a network, they must be offered the corresponding source.

The AGPL trap deserves to be dwelt on, because it ambushes companies that believe they have outrun copyleft entirely. Imagine a company that runs GPL-licensed code purely on its own servers, offering a web service rather than a downloadable product. It reasons that it never "distributes" the code, never ships a binary to anyone, and therefore never triggers the GPL's source obligation. Under the ordinary GPL, that reasoning is largely correct—the SaaS model has been a standard, lawful way to use GPL code without disclosing modifications, sometimes called the "ASP loophole." The AGPL exists to slam it shut. If the component is AGPL rather than GPL, the act of letting users interact with it over a network is itself the trigger, and the provider must offer those users its corresponding source. For an enterprise like Helios contemplating a hosted, cloud-delivered version of its analytics product, this is critical: a strategy of moving to SaaS to dodge copyleft works against GPL components and fails completely against AGPL ones. A single AGPL component in a hosted service can oblige disclosure of vastly more than anyone bargained for. The practical lesson is unambiguous—an enterprise license policy must treat AGPL as a distinct, elevated risk category, flagged for legal review before any use, because the network-interaction trigger defeats the very deployment strategy companies most often reach for to manage copyleft exposure. (As we will see, the AGPL also sits at the center of the relicensing wars now reshaping the industry.)

The linking question, worked through

Because the entire weight of Helios's problem rests on whether its product and the GPL component form a single "work based on the Program," it is worth walking through the analysis Helios's counsel will actually perform. This is the contested middle of open source law, and it is contested precisely because it lives at the seam between copyright doctrine and computer science.

Start with the technical vocabulary, because the legal conclusions track it closely. Software is written as human-readable source code, then compiled into machine-readable object code. Programs are combined in several ways, and the way matters:

  • Static linking. At compile time, the compiler copies the library's object code verbatim into the resulting executable, producing one self-contained program. The GPL code is now physically inside your binary.
  • Dynamic linking. The library stays a separate file; the executable holds only references to it and pulls it in at runtime. The binaries remain distinct on disk, but they run as one process and share memory and data structures intimately.
  • Plug-ins and loadable modules. A separate component the host program loads when needed—a printer driver, a kernel module—and unloads when done.
  • System calls and arm's-length communication. One program asks another to perform a service through a defined interface (a system call, an API, a pipe, a network socket), exchanging data but not code.

Now overlay the legal gradations, which the FSF and most practitioners line up against that spectrum:

At one end sits mere aggregation. Ship the GPL component alongside your proprietary product on the same disk or in the same installer, as two separate programs that merely coexist, and you have not created a derivative work. GPLv2's own language confirms this: "mere aggregation of another work … on a volume of a storage or distribution medium does not bring the other work under the scope of this License." Your proprietary code stays proprietary; you satisfy the GPL by providing source for the GPL component alone.

At the other end sits static linking. When the GPL library is compiled directly into your executable so the two become one program, there is a strong argument—indeed the consensus view—that the result "contains or is derived from" the GPL work and is therefore a single combined work the GPL reaches. For Helios, this is the nightmare scenario: it would oblige Helios to release its own source or rip the component out.

In between sits dynamic linking, the genuinely contested ground. The FSF takes the firm position that dynamically linking against a GPL library still creates a derivative work, because the two halves combine into a single running program sharing data structures and address space. Many practitioners think the question is far less settled, pointing out that no U.S. court has squarely held that dynamic linking alone creates a derivative work, and that copyright's derivative-work doctrine asks whether protectable expression was copied, not merely whether two programs interoperate. The honest answer is that the law is unresolved, which is itself a risk: an enterprise relying on dynamic linking to avoid copyleft is relying on a proposition the FSF actively disputes and no court has blessed.

The finer facts compound the analysis. Does the proprietary code call functions in the GPL component, or does the component call into the proprietary code? Was the component modified? Do the two communicate through an arm's-length interface—separate processes talking over a socket—or are they interwoven at the code level? Each of these bears on whether a single derivative work exists. As a rule of thumb the FSF itself offers, two modules that communicate "at arms length"—as separate processes exchanging data through pipes or sockets, the way unrelated programs do—are generally not a single combined work, whereas modules linked into one executable and sharing internal data structures generally are.

For Helios, the remediation path depends entirely on where its integration falls on this spectrum, which is why the first move is a precise technical-and-legal analysis rather than a panicked assumption of the worst case. If the GPL component is merely aggregated, or communicates only at arm's length through a separate process, Helios may discharge the GPL by releasing the component's source and documenting the separation. If it is statically linked into the proprietary executable, Helios faces the hard binary: release its own source, or re-engineer the product to excise the component. The facts of integration determine the obligation, and the obligation determines the cost. Counsel's job is to establish the facts before the company commits to a remedy—and, ideally, to do it long before a buyer's auditors do it first.

The anatomy of license incompatibility

One of the most treacherous features of open source law is that two perfectly valid, widely respected licenses can be legally incompatible—meaning you cannot lawfully combine code under each into a single work. The problem is not that one license is "bad"; it is that their conditions contradict each other.

The textbook example pairs GPLv2 with Apache 2.0. Both are mainstream, but Apache 2.0's patent-license and patent-retaliation provisions count, in the FSF's reading, as "additional restrictions" that GPLv2 Section 6 forbids a downstream licensor from imposing. The upshot: Apache 2.0 code and GPLv2 code cannot be combined in one work—an awkward result given how ubiquitous both licenses are. GPLv3 was deliberately drafted to fix this and is generally considered Apache-2.0-compatible. But GPLv2 and GPLv3 are themselves incompatible in certain configurations, and many flagship projects—the Linux kernel above all—have deliberately stayed on GPLv2-only, which means GPLv2-only code and GPLv3 code may not be combinable either. The result is a fractured landscape in which "it's all open source, so it must mix" is simply false.

What makes incompatibility especially dangerous is the depth of modern dependency trees. A developer consciously selects a permissively licensed library, unaware that it depends on another library, which depends on a copyleft component buried four levels down. These transitive dependencies carry their license obligations up the chain whether anyone notices or not—which is precisely how a GPL component arrived in Helios's product with no human ever having chosen it. Manual tracking of such trees stopped being feasible years ago, which is why automated tooling that walks the entire dependency graph, not just the direct dependencies, has become essential rather than optional.

When an incompatibility surfaces, the remediation menu is short and every item carries a cost:

  • Substitution. Replace the problematic component with a functionally equivalent one under a compatible license. Easy for commodity utilities with several interchangeable implementations; hard or impossible for specialized components with no ready alternative.
  • Commercial licensing. Many copyleft projects are offered under a dual-licensing model: the copyright holder will sell a commercial license that lifts the copyleft obligation for a fee. This is the business model behind MySQL, Qt, and many others, and it converts a compliance problem into a procurement decision—provided the holder is willing to deal and the price is bearable.
  • Architectural isolation. Restructure the software so the incompatible components communicate only at arm's length—separate processes, well-defined interfaces—so they are aggregated rather than combined into a single work. This is the most technically demanding option and requires careful legal analysis to confirm the isolation genuinely avoids a derivative work rather than merely appearing to.

Each option costs time, money, or engineering, and each is dramatically cheaper when the incompatibility is caught early—during component selection, when substitution is trivial—than late, under the pressure of a transaction, when the architecture is frozen and the only options are expensive re-engineering or an awkward commercial negotiation conducted from weakness. That asymmetry between the cost of early detection and the cost of late discovery is the central economic argument for continuous compliance tooling: the tooling is cheap, and the problems it surfaces are cheap to fix when surfaced early and ruinous to fix when surfaced late.

Open source in mergers and acquisitions

Few contexts expose open source risk as starkly as M&A, which is why Helios's problem surfaced in diligence rather than in ordinary operations. When an acquirer buys a software company—or its assets—it inherits the target's liabilities, including any copyright-infringement exposure from open source noncompliance. Sophisticated acquirers now treat open source audits as a standard part of technical due diligence, and they have good reason to: if a target has folded GPL code into a proprietary product without complying, the acquirer faces the same unpalatable menu Helios faces, and any of those outcomes can slash the target's value or kill the deal.

The mechanics have standardized. Diligence teams catalog the open source components, analyze how each is integrated, determine what obligations each triggers, and assess compliance—often surfacing security vulnerabilities along the way, a related risk that grew urgent after incidents like the Log4Shell vulnerability in the ubiquitous Log4j logging library, which sat undetected in countless enterprise applications as a transitive dependency. Deal documents now routinely carry representations and warranties about open source: that the target has complied with all material open source obligations; that no open source has been incorporated in a way that requires disclosure, licensing, or attribution of proprietary code; and that the target maintains accurate records of its open source usage. These reps shift risk to the seller and give the buyer indemnification claims if problems emerge post-closing. Source-code escrow, automated scanning, and manual review before closing have all become routine.

For Helios, the path forward is the remediation analysis under deadline pressure: pin down exactly how the GPL component is integrated, assess whether the integration truly creates a combined work, and—if it does—substitute the component, re-architect around it, or negotiate a price adjustment and a tailored indemnity with the buyer. Deals like Helios's usually do close, after remediation and renegotiation. But they close at a cost, in purchase price and in scramble, that a modest, proactive compliance program would have avoided entirely.

Protecting proprietary code during diligence

There is a second, subtler risk that Helios faces because of the audit, and it deserves its own attention. Submitting to a buyer's open source diligence means exposing Helios's complete source code to the acquirer's technical and legal teams—and that exposure is itself a moment of acute trade-secret vulnerability. A company's source code is among its most valuable trade secrets, and the M&A audit (escrow, automated scanning, manual review by outside auditors) necessarily puts that code in front of parties outside the company. If the deal closes, the exposure is absorbed into the transaction. If it collapses, Helios has shown its crown jewels to what may be its most dangerous competitor.

Managing this requires the same discipline we describe in our work on trade secrets in the age of remote work and cloud computing and in building a trade secret protection program from scratch: tightly drafted confidentiality and non-use provisions governing the diligence; controlled, logged, time-limited access to the code; staged disclosure that reveals the most sensitive material only late, once the deal looks likely; and the use of neutral third-party escrow agents and scanning services rather than direct competitor review wherever possible. The open source audit and the trade-secret imperative run together: Helios must let the buyer scrutinize its code closely enough to assess open source exposure, while structuring that scrutiny so its proprietary advantage is not forfeited if the deal dies. Getting both right is a large part of why pre-transaction open source hygiene pays for itself—a company that has already audited and cleaned its own codebase can present a documented, defensible compliance record rather than handing a competitor open-ended access to hunt for problems.

Software composition analysis and the SBOM

Given the scale of modern codebases, software composition analysis (SCA) has become the technical foundation of compliance, automating the discovery of open source components, their licenses, and their known vulnerabilities. SCA tools scan using several complementary techniques, and the difference between them matters:

  • Package-manager scanning reads the manifest files that declare dependencies (package.json, pom.xml, requirements.txt, go.mod) and resolves the full dependency tree. Fast and accurate for declared dependencies—but blind to anything not declared there.
  • Binary scanning examines compiled artifacts to identify components even when no source or manifest is present, which catches components baked into firmware or third-party binaries.
  • Snippet scanning fingerprints code fragments to detect open source that was copied-and-pasted rather than properly imported—the failure mode that package scanning misses entirely and that snippet scanning exists to catch.

The output is typically a Software Bill of Materials (SBOM): a structured inventory of every component, its version, its license, and its known vulnerabilities. SBOMs leapt from niche practice to industry expectation after the U.S. government's 2021 cybersecurity executive order (Executive Order 14028, "Improving the Nation's Cybersecurity") directed federal agencies to require SBOMs from their software vendors, which pulled the entire supply chain toward the practice even among companies not directly subject to procurement rules. The European Union's Cyber Resilience Act extends comparable expectations to products sold in the EU. Standardized SBOM formats—SPDX and CycloneDX—have emerged so that the inventories are machine-readable and portable across tools.

Choosing an SCA tool means weighing scanning comprehensiveness (does it use multiple techniques, or rely solely on manifests and thereby miss copied or modified components?), database coverage (how many projects, licenses, and vulnerabilities does its knowledge base span?), workflow integration (IDEs, build systems, CI/CD pipelines), and policy management (can it enforce organizational rules about acceptable licenses and vulnerability thresholds and fail a build when they are violated?). The market has matured into a recognizable set of commercial platforms—some prized for the breadth of their knowledge base and depth in M&A diligence, others for license-policy automation, others for developer-friendly CI/CD integration—alongside capable open source SCA tools a team can adopt without a commercial license to build the capability incrementally.

But tools alone do not produce compliance; they must be embedded in a program. The most effective programs adopt a tiered license policy and wire it into the development pipeline:

  • Green — permissive licenses like MIT, BSD, and Apache 2.0, pre-approved for general use (subject to honoring attribution and NOTICE obligations).
  • Yellow — weak-copyleft licenses like the LGPL and MPL, permitted after review to confirm the component is used consistently with the business model (e.g., dynamically linked, unmodified).
  • Red — strong and network copyleft like GPL and AGPL, plus the source-available licenses discussed below, requiring legal review before any use.

The policy is only as good as the processes around it: a component-intake and approval workflow, developer training, continuous monitoring integrated into CI/CD so that a non-compliant dependency fails the build before it ships, and an incident-response procedure for when violations surface anyway. The Linux Foundation's OpenChain project (now the international standard ISO/IEC 5230) provides a recognized specification for exactly this kind of program, useful both as a blueprint and as something a company can certify against to signal maturity to customers and acquirers. Our open source compliance checklists translate this architecture into the concrete intake forms, policy templates, and audit worksheets that operationalize it.

Had Helios run such a program, the GPL component would have been flagged "red" and reviewed years ago—when removing it was a trivial engineering task—rather than discovered in diligence, when it threatens a deal. And the deeper point about tooling bears repeating: an excellent platform that scans occasionally protects far less than a modest one that scans every build, because open source exposure accumulates continuously as dependencies are added and updated, and only continuous scanning catches it while it is still cheap to fix.

The evolving enforcement landscape

The open source enforcement environment has shifted markedly in the past several years, and the shift runs in one direction: toward real consequences, from more directions, in more jurisdictions. An enterprise that still treats noncompliance as a low-probability risk is reading from an outdated map.

The third-party-beneficiary theory: SFC v. Vizio

The most consequential development is the third-party-beneficiary theory at the heart of the long-running litigation between the Software Freedom Conservancy and Vizio. Traditionally, only copyright holders—the original developers—could enforce an open source license, because enforcement was a copyright-infringement action and you need to own the copyright to bring one. Software Freedom Conservancy, Inc. v. Vizio, Inc. tries something genuinely new. Filed in California state court in October 2021, it is not a copyright suit at all. The Conservancy bought a Vizio smart TV, observed that it runs Linux and other GPL- and LGPL-licensed software, requested the corresponding source code, and—when Vizio did not adequately provide it—sued in contract, claiming that as an end-user recipient of the GPL'd software it is a third-party beneficiary of the license and may enforce the source-code obligation directly, without holding any copyright.

The case has survived four years of procedural combat. Vizio removed it to federal court arguing it was really a disguised copyright claim (and therefore preempted); in May 2022 the federal court remanded it to state court, accepting that the GPL functions as a contract whose source-code obligation creates rights distinct from copyright—an important ruling in its own right. Back in state court, Vizio's summary-judgment attempt to dispose of the third-party-beneficiary theory failed in early 2024; the court let the theory proceed to trial. Through 2025 the parties traded summary-adjudication motions and gathered evidence. In December 2025 the court issued a tentative ruling partly in the Conservancy's favor, holding that a direct contract had formed when the Conservancy's administrator requested the source code, and that this contract obligated Vizio to provide the complete and corresponding source code for the TV. At the same time, the court narrowed the obligation's contours—holding that GPLv2 and LGPLv2.1 require a manufacturer to provide source code that users can obtain and revise for use elsewhere, but do not require the manufacturer to make modified code reinstallable on the original device (rejecting, on these facts, the broader "installation information" reading)—and it tentatively declined to resolve the pure third-party-beneficiary question on the papers. In February 2026 the court sent the case to trial, finding genuine factual disputes for a jury.

The stakes are enormous and still live. If the broad theory ultimately prevails, the universe of potential GPL enforcers expands from a small number of motivated, copyright-holding developers to potentially any customer who buys a device running GPL'd code—every smart TV, router, car infotainment system, and IoT gadget. That would convert GPL enforcement from an occasional activity into a standing risk from one's own customer base. Manufacturers shipping copyleft code in consumer products are watching closely; some observers expect an eventual Conservancy victory to push manufacturers toward stricter proactive compliance, and others to push them away from copyleft entirely toward permissive licenses. The case is an unresolved, developing matter rather than a settled rule—but its very existence, and the December 2025 ruling that a source-code request can ripen into an enforceable contract, should inform how any product company assesses its copyleft exposure today.

Adding restrictions and the limits of "open source": Neo4j v. PureThink

A second line of cases addresses the mirror-image problem: not failing to comply with copyleft, but trying to add proprietary restrictions to it. In Neo4j, Inc. v. PureThink, LLC (and the related appeal involving John Mark Suhy), the graph-database company Neo4j took the AGPLv3 and bolted on a "Commons Clause"—a rider forbidding commercial resale of the software. A downstream user, relying on AGPLv3 Section 7's provision that a licensee "may remove" certain "further restrictions" added by an upstream party, stripped the Commons Clause back off and redistributed the result as "free and open source." Neo4j sued.

The Ninth Circuit, in a 2021 decision, sided with Neo4j on the narrow point, reading Section 7 to permit removal only of further restrictions the original licensor itself had not imposed—so the user could not strip a restriction Neo4j had placed on its own code—and it upheld an injunction barring the user from calling the de-restricted version "free and open source," on the theory that the label was literally false because the code carried the Commons Clause restriction. The Free Software Foundation and the Software Freedom Conservancy filed briefs arguing the court misread Section 7 in a way that could weaken copyleft's anti-restriction protections. For the enterprise, Neo4j carries two practical lessons. First, the boundaries of "open source" are contested at the edges, and a license that looks open (AGPL) can be encumbered by a non-open rider (the Commons Clause) that defeats the freedoms a developer assumes—so the name of a license is not a substitute for reading it. Second, calling encumbered software "open source" can itself generate liability, here under a false-advertising theory adjacent to the issues we examine in false advertising and Lanham Act Section 43(a).

European enforcement and individual standing

European courts have shown a striking willingness to award substantial damages. In Entr'ouvert v. Orange S.A., the Paris Court of Appeal in February 2024 held the telecom giant Orange liable for contrefaçon—the French equivalent of copyright infringement—for incorporating Entr'ouvert's GPLv2-licensed Lasso library into a government identity-management platform without honoring the GPL's notice and source-code obligations, and without preserving the author's moral rights. The court awarded roughly €860,000 in total: compensatory damages for the economic harm, additional sums for moral prejudice and for Orange's profits, and costs. Two features make the case a wake-up call. First, the court treated the GPL violation as an intellectual-property tort, not a mere contract breach, mirroring the U.S. condition-based theory. Second, the record reflected that Orange had inquired about a commercial license before proceeding with the GPL code—evidence that it understood compliance might be problematic, which undercut any innocence defense. The decision caps more than a decade of litigation and stands as one of the most significant monetary awards for a copyleft violation anywhere.

Enforcement is not the exclusive province of well-funded nonprofits, either. A series of German decisions—most associated with kernel contributor Harald Welte and the gpl-violations.org project, and later cases brought by individual developers against router and device manufacturers—established that even a single individual copyright-holding contributor has standing to compel GPL compliance and obtain injunctive relief, typically awarding modest damages but confirming the principle that any contributor of copyrighted code can enforce. In the United States, Software Freedom Conservancy, Inc. v. Best Buy Co., 2010 WL 4860780 (S.D.N.Y. 2010), produced a default judgment and forfeiture order against a manufacturer (Westinghouse) that had shipped HDTVs running GPLv2 firmware without offering source—an early demonstration that distributing copyleft code in consumer electronics without compliance has teeth. And earlier foundational cases drew the boundaries of the field in ways that still matter: Planetary Motion, Inc. v. Techsplosion, Inc., 261 F.3d 1188 (11th Cir. 2001), held that distributing software under the GPL is "use in commerce" sufficient to support trademark rights (so giving code away does not forfeit the brand), and Wallace v. International Business Machines Corp., 467 F.3d 1104 (7th Cir. 2006), rejected the argument that the GPL's free-forever model is an antitrust violation, with Judge Easterbrook observing that cooperative agreements yielding new works that would not otherwise exist are pro-competitive, not predatory.

Commercial weaponization

Finally, competitors have begun weaponizing noncompliance. In the dispute between CoKinetic Systems and Panasonic Avionics, a GPL violation became the predicate for antitrust and unfair-competition claims: CoKinetic alleged that Panasonic's refusal to release the source code for its Linux-based in-flight entertainment system, in violation of the GPL, was itself an act of monopolization that locked competitors out of the market. Whatever the merits, the theory illustrates a strategic shift—an open source violation reframed not as a copyright problem to be settled quietly but as a competition wrong to be litigated publicly, by a rival with every incentive to press it. Taken together, these developments mean enforcement now comes from copyright holders, individual developers, nonprofits, commercial competitors, courts on two continents, and—if the Vizio theory ultimately prevails—potentially ordinary consumers. The low-probability era is over.

The relicensing wave: source-available licenses and the cloud wars

A different kind of landmine has emerged from a different direction: not from companies that use open source carelessly, but from companies that publish it and then change their minds. Over the past several years, a series of high-profile projects have abandoned their open source licenses in favor of "source-available" terms designed to stop cloud hyperscalers from monetizing the software as a managed service without contributing back. The pattern matters to every enterprise, because a dependency you adopted under a permissive or copyleft license can, on the vendor's next release, become something you are no longer free to use the way you did.

The two dominant source-available instruments are the Server Side Public License (SSPL) and the Business Source License (BSL). The SSPL, authored by MongoDB, is built on the AGPL but pushes the copyleft trigger dramatically further: anyone offering the software as a service must release not just the software's source but the source of essentially the entire surrounding service stack—management, orchestration, monitoring, and more. The condition is so sweeping that the OSI declined to recognize the SSPL as open source at all, and the Linux distributions that prize OSI conformance dropped MongoDB from their repositories. The BSL, popularized by MariaDB and adopted by HashiCorp, takes a time-delay approach: the code is source-available and usable for most purposes immediately, but a specified "additional use grant" forbids competitive/production use that competes with the licensor, with the whole thing converting to a genuine open source license (often Apache 2.0 or MPL 2.0) after a set period, typically four years.

The defining episodes are instructive. Elastic relicensed Elasticsearch and Kibana in 2021 from the permissive Apache 2.0 to a dual SSPL/Elastic License arrangement, explicitly to stop Amazon from offering a competing managed Elasticsearch service; Amazon responded by forking the last Apache-2.0 version into OpenSearch, which now lives on under permissive terms. (Elastic later, in 2024, added the OSI-approved AGPLv3 as an option, partially reversing course.) HashiCorp relicensed Terraform and its other core products in August 2023 from the Mozilla Public License 2.0 to the BSL; within weeks, a coalition of users and vendors forked the last MPL-licensed version into OpenTofu, which the Linux Foundation adopted, and which shipped a production 1.0 in January 2024 and has since grown into a CNCF project with millions of downloads. Redis made a comparable move in 2024, prompting the Valkey fork under the Linux Foundation.

Three practical lessons fall out of this for an enterprise. First, a license is not a permanent attribute of a dependency—the copyright holder of a single-vendor project can relicense future versions, so the terms you adopted today may not govern the version you upgrade to next year, and your SCA tooling must flag license changes, not just license types. Second, source-available is not open source, however similar it looks: code under the SSPL or BSL may forbid exactly the use your business depends on (offering it as a service, redistributing it competitively), which is why a mature license policy puts these in the "red" tier alongside AGPL and requires legal review before adoption. Third, forks create real optionality: when a relicensing threatens your use, the community fork (OpenSearch, OpenTofu, Valkey) under the prior open terms is often the safe harbor—but migrating to it is itself a project that must be planned, not assumed. An enterprise that tracks the upstream licensing health of its critical dependencies will see these storms coming; one that does not will discover, on an otherwise routine upgrade, that its foundation has quietly shifted underfoot.

Common failure modes—and the AI provenance problem

Most compliance failures fall into recognizable categories, and naming them helps an enterprise both avoid and remediate them.

The most fundamental is failure to provide source code—distributing GPL software without making corresponding source available, usually because nobody knew the GPL code was there (exactly Helios's situation). Remediation requires identifying all copyleft components, assembling the complete and corresponding source (a phrase Vizio has now put under a litigation microscope), and standing up a durable mechanism to deliver it, whether by download or by the written-offer route the GPL permits. Missing or incorrect notices—copyright lines and license texts stripped during build—violate both copyleft and permissive licenses and are fixed by ensuring notices survive into the distributed artifact (and into the "About" screen, the NOTICE file, or the printed documentation, as appropriate). License incompatibility calls for substitution, a commercial license where dual-licensing is available, or architectural isolation, each as discussed above. Insufficient documentation is the quiet root cause of most of the others: when developers do not track what they use, compliance is impossible, which is why SCA tooling and a current SBOM are foundational rather than nice-to-have. And contribution without authority—employees pushing code upstream that embeds company trade secrets, or contributing in ways that complicate later patent enforcement or muddy ownership—calls for a clear outbound-contribution policy, a discipline connected to the broader project of capturing and protecting employee innovation that we examine in employee invention assignment agreements and drafting enforceable non-disclosure agreements for technology transactions.

The newest frontier—and a genuinely unsettled one—is AI coding assistants and the provenance problem they create. When a code-completion tool trained partly on public open source repositories suggests a block of code, and that suggestion substantially reproduces GPL-licensed code, and a developer pastes it into proprietary software, has a GPL violation occurred? The honest answer is that nobody yet knows. The question splits into two. First, does training an AI model on copyrighted code infringe? That is the central issue in a wave of pending litigation against AI developers—suits we discuss in copyright infringement claims against generative AI—and it remains undecided, turning largely on fair use. Second, and distinct: even if training is lawful, does output that substantially copies a protected open source expression carry that expression's license obligations into the proprietary codebase that absorbs it? An AI assistant strips away exactly the metadata—the license header, the copyright notice, the provenance—that compliance depends on, so a developer may incorporate copyleft expression with no signal that anything is owed. The doctrinal questions overlap with the data-provenance and scraping issues we cover in data scraping after hiQ v. LinkedIn, and with the ownership puzzles in AI-generated inventions.

Pending real answers, prudent enterprises treat AI-generated code with the same scrutiny as any other third-party code rather than assuming it is clean because a machine produced it: run it through the same SCA scanning (snippet detection is the relevant technique here), prefer AI tools that surface license attribution or filter suggestions matching public code, and train developers to recognize that an unusually long, sophisticated, or oddly specific suggestion may reflect substantial copying of a real project rather than original generation. The compliance program that already inventories and scans every build is well-positioned for the AI era; the one that relies on developers to remember where their code came from is not.

A practical audit framework

Whether preparing for a transaction, responding to a compliance inquiry, or simply taking stock, an enterprise needs a structured audit. The work proceeds in phases, and the sequence matters because each phase narrows the problem for the next:

  1. Scoping and preparation. Define which products, repositories, and branches are in scope; gather existing documentation (prior SBOMs, license inventories, contribution records); and configure the tooling. Do not forget build tooling, test infrastructure, container base images, and deployment scripts, which carry their own dependencies and are routinely overlooked.
  2. Automated discovery. Run SCA across all in-scope code using multiple detection methods—manifest, binary, and snippet—so that copied or modified components are caught, not just declared ones.
  3. Manual review. Examine what tools handle poorly: code copied without attribution, modified open source components, unusual or custom licenses, and dependencies that resolve differently across environments.
  4. Legal analysis. For each component, assess the obligations its license imposes, its compatibility with the other licenses in the work and with the company's distribution model, and its current compliance status—paying special attention to copyleft components in distributed products and to AGPL and source-available components in hosted ones.
  5. Remediation planning. Prioritize by risk. A strong-copyleft violation in a distributed product is an emergency; a missing attribution notice for a permissive component is a chore. Triage accordingly.
  6. Implementation and verification. Execute the plan—substitute, isolate, license, or add notices—and re-scan to confirm the fixes landed and introduced no new problems.
  7. Process improvement. Use the findings to repair the systemic gaps—tooling, training, intake and approval workflows—that let the problems arise in the first place, so the next audit is shorter than this one.

Had Helios run this audit a year before its sale rather than meeting it for the first time in the buyer's diligence, the GPL component would have been a routine engineering ticket instead of a threat to a nine-figure transaction. That is the entire argument in miniature: the audit is cheap, repeatable, and boring when you run it on your own schedule, and expensive, adversarial, and frightening when someone else runs it on theirs.

Frequently asked questions

Does using open source software automatically make my proprietary code open source? No. Mere use of open source—even running GPL code internally—triggers nothing; GPLv2 expressly says the act of running the program is not restricted. The risk arises when you distribute (or, for AGPL, expose over a network) software that combines your proprietary code with copyleft code in a way that creates a single "work based on the Program." Permissive licenses (MIT, BSD, Apache) never require you to open your own code; they require only attribution and, for Apache, a NOTICE file and respect for the patent terms. The danger is specific to copyleft, and even then it turns on how the code is combined.

Is violating an open source license just a breach of contract, or is it infringement? Potentially both, and that is the point. Under Jacobsen v. Katzer, open source terms can be conditions on the license grant, so exceeding them means you are no longer licensed and your use becomes copyright infringement—carrying the threat of an injunction, statutory damages, and attorneys' fees. Separately, as Artifex v. Hancom and the Vizio litigation illustrate, the license may also be enforceable as a contract. An open source licensor may pursue either or both theories.

We only offer our product as a cloud service and never ship a binary. Are we safe from copyleft? For ordinary GPL components, largely yes—you are not "distributing," so the source obligation is not triggered. For AGPL components, no: the AGPL's network-interaction clause was written precisely to defeat that strategy, and letting users interact with AGPL code over a network obligates you to offer them source. And source-available licenses like the SSPL go further still, potentially reaching your entire service stack. SaaS is not a universal copyleft shield; it depends entirely on the specific license.

What is the difference between "open source" and "source-available" (BSL, SSPL)? "Open source," in the OSI's sense, means the license satisfies the Open Source Definition—including no discrimination against fields of endeavor and no restriction on who may use or commercialize the code. Source-available licenses like the BSL and SSPL let you see and often modify the source but restrict commercial or competitive use (the BSL for a period of years; the SSPL by demanding you open your whole service stack). The OSI does not recognize them as open source. Treat them as a distinct, elevated risk tier and review them before adoption, because they may forbid exactly the use your business depends on.

A library we depend on just changed its license. What do we do? First, confirm which versions are affected—relicensing usually applies only going forward, so the version you already use may still carry the old terms. Then decide: stay on the last permissively licensed version (and accept that you lose future updates), migrate to a community fork under the prior license (OpenTofu, OpenSearch, Valkey), or comply with or license the new terms. The strategic lesson is to have your SCA tooling flag license changes on upgrade, not just license types, so you make this decision deliberately rather than discovering it after the fact.

Can a customer who buys our device sue us over GPL compliance, even though they don't own the copyright? That is the open question in SFC v. Vizio. Traditionally only copyright holders could enforce the GPL. Vizio advances the theory that an end-user recipient is a third-party beneficiary of the license and can enforce the source-code obligation in contract without holding any copyright; a December 2025 tentative ruling found that a customer's source-code request can ripen into an enforceable contract, and the case proceeded to trial in 2026. If the broad theory prevails, your exposure expands from a handful of motivated developers to potentially any customer—reason enough to comply proactively now.

Conclusion and next steps

Open source licensing compliance has graduated from a niche legal curiosity into a business-critical capability. The downside of getting it wrong—substantial damages, injunctions against distribution, forced disclosure of proprietary source, and dead transactions—is concrete and growing, and the cast of potential enforcers now spans copyright holders, individual developers, nonprofits, commercial competitors, courts on two continents, and possibly, if the Vizio theory holds, ordinary consumers. The relicensing wave adds a second axis of risk, where the terms governing a dependency can change beneath you on an ordinary upgrade. And the arrival of AI coding assistants has introduced a provenance problem the law has not yet answered.

The good news is that the discipline is achievable and the playbook is known. Modern SCA tools can inventory components at scale; established frameworks like OpenChain (ISO/IEC 5230) provide a blueprint for building a program; and the legal precedents, while genuinely unsettled at the edges (dynamic linking, third-party beneficiaries, AI output), provide predictable rules across the great bulk of ordinary practice. The work is unglamorous but learnable: run a baseline audit to understand your current exposure; adopt SCA tooling and wire it into the build so non-compliant dependencies fail before they ship; write and communicate a tiered license policy; train developers in not just the mechanics but the why; and track the licensing health of your critical dependencies so the next relicensing storm does not catch you flat-footed.

Helios will probably survive its discovery—deals like its usually close, after remediation and renegotiation—but at a cost, in price and in scramble and in showing its source code to a competitor, that a modest proactive program would have avoided entirely. That is the whole lesson, and it is the same lesson whether the landmine is a buried GPL dependency, an AGPL component in a hosted service, a license that changes on upgrade, or an AI-suggested snippet of unknown origin: the cheapest moment to defuse an open source landmine is before anyone steps on it.

For guidance on building an open source compliance program, conducting a license audit, or navigating an open source issue surfaced in diligence, contact our intellectual property and technology practice.

Related articles

Selected authorities

Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008) (open source license terms enforceable as copyright conditions). MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010) (covenant-versus-condition framework). Artifex Software, Inc. v. Hancom, Inc., No. 16-cv-06982 (N.D. Cal. 2017) (AGPL enforceable as contract). Software Freedom Conservancy, Inc. v. Vizio, Inc., No. 30-2021-01226723 (Cal. Super. Ct., Orange Cnty.) (third-party-beneficiary theory; tentative ruling Dec. 2025; to trial Feb. 2026). Neo4j, Inc. v. PureThink, LLC / Neo4j, Inc. v. Suhy (9th Cir. 2021) (removal of "further restrictions" under AGPLv3 Section 7; false-advertising injunction). Software Freedom Conservancy, Inc. v. Best Buy Co., 2010 WL 4860780 (S.D.N.Y. 2010). Planetary Motion, Inc. v. Techsplosion, Inc., 261 F.3d 1188 (11th Cir. 2001). Wallace v. International Business Machines Corp., 467 F.3d 1104 (7th Cir. 2006). Entr'ouvert v. Orange S.A., Paris Court of Appeal (Feb. 14, 2024) (GPLv2 violation as contrefaçon; ~€860,000). GNU General Public License v2 and v3; GNU Lesser GPL; GNU Affero GPL. Business Source License; Server Side Public License. Executive Order 14028, "Improving the Nation's Cybersecurity" (May 12, 2021); EU Cyber Resilience Act. Linux Foundation OpenChain Project (ISO/IEC 5230); Open Source Initiative & the Open Source Definition; SPDX and CycloneDX SBOM standards.

This article is for general informational purposes only and does not constitute legal advice, nor does it create an attorney-client relationship. Open source licensing law continues to evolve, and several of the matters described—including the SFC v. Vizio litigation, the Neo4j line of cases, and the AI-and-open-source questions—remain unresolved. Consult qualified intellectual-property counsel about your specific circumstances.