Toolkit · Technology

Software and Open Source Licensing: An IP-to-Compliance Toolkit

Type
Toolkit
Jurisdiction
National
Date
2026-04-03
Topic
Technology

A single program is protected at once by copyright, sometimes by patent, sometimes by trade secret, and is almost always assembled from third-party components carrying licenses that range from a two-line MIT permission to the source-disclosure demands of the AGPL. This toolkit maps that stack end to end: the four legal layers that protect software, the mechanics of proprietary licensing and the covenant-versus-condition fault line that decides whether a breach is contract or copyright, the open source license spectrum from permissive to network copyleft, and the enforcement case law that makes those terms bite. It then turns operational, walking through a working compliance program built on inventory and the software bill of materials, the diligence that decides deal price, the SaaS and cloud problems the AGPL created, and the unsettled questions AI code assistants now raise. Worked hypotheticals illustrate each doctrine, and the analysis links every UpLaw resource and authority you need to go deeper. The through-line: open source terms are enforceable copyright conditions, not a free-for-all, so compliance belongs in the build pipeline as engineering hygiene, not in a binder legal keeps for show.

Software and Open Source Licensing: An IP-to-Compliance Toolkit

Technology > Open Source | Published 3 April 2026 - Updated 6 June 2026 | UpLaw - uplaw.us

A field guide to the whole software licensing stack, from the four legal layers that protect code to the compliance program, diligence, and enforcement doctrine that keep an open source portfolio out of trouble.

Keywords: open source software, software licensing, copyleft, GPL, AGPL, Apache License 2.0, MIT license, permissive license, OSS compliance, software bill of materials, SBOM, M&A diligence, SaaS licensing, AI-generated code, Jacobsen v. Katzer, SPDX, derivative works, source code escrow

How to use this toolkit

Software is a strange kind of property. The same program is, at the same instant, an original work of authorship the law protects by copyright, a possible embodiment of patentable methods, a repository of trade secrets that lives or dies by how carefully it is kept, and a bundle of contract rights that stitches those regimes together and hands calibrated slices of them to customers. Ship a product and you are managing all of those layers at once: what you own outright, what you have licensed in from third parties, and what you have licensed out to users. Miss one and the others can unravel.

Open source complicates the picture because almost no modern application is written from a blank file. A typical codebase is nine parts borrowed to one part original, assembled from public repositories under licenses that vary from a two-sentence permission slip to a contract that can, if you are careless, force you to publish the source code of your crown-jewel product. Those licenses are not decoration. They are enforceable copyright conditions, and courts have said so.

This toolkit is written for three audiences. The first is the software company and the engineering and legal leaders who ship its products and must decide, early and often, which components are safe to use and on what terms to release their own. The second is the investor or acquirer sizing up a software target, for whom a sloppy open source posture is a price adjustment waiting to happen. The third is transactional counsel drafting and reviewing the license, SaaS, and diligence paper where all of this becomes concrete. Each part hands you to the deeper UpLaw article or operational checklist that treats the subject at length, so the toolkit works as a map rather than a substitute for the territory.

One idea runs through every part: compliance is engineering hygiene that legal supervises, not paperwork legal produces alone. The obligations attach to code, they are discharged in the build pipeline, and they are best satisfied by tooling and process rather than by a memo nobody reads. Treat the license text as a spec, and most of the drama disappears.

The map: eight questions this toolkit answers

  1. What actually protects software? The four legal layers, and why the distribution model usually decides which one matters.
  2. How do proprietary licenses allocate risk? The grant, the restrictions, and the covenant-versus-condition line that decides whether a breach is a contract claim or copyright infringement.
  3. What do the open source families demand? Permissive, weak copyleft, strong copyleft, and network copyleft, and the derivative-work question that drives all of them.
  4. Why is compliance not optional? The enforcement case law, from Jacobsen forward, that turns a license condition into a lawsuit.
  5. How do you build a compliance program? Policy, inventory, the software bill of materials, notices, remediation, and outbound contributions.
  6. How does licensing move a deal? Open source and license diligence in M&A and financings.
  7. What changes in the cloud? Distribution versus network use, the AGPL trap, and the relicensing wave reshaping commercial open source.
  8. What does AI-generated code break? Authorship, provenance, and the new contamination risk.

Part 1 — The four legal layers that protect software

Before you license anything in or out, you have to know what protects the software in the first place, because the protection determines both what you are allowed to license and what you are obliged to guard. Four regimes do the work, and they are complementary rather than competing.

Copyright: the default layer

Copyright is the layer that attaches automatically and covers the most ground. Original expression in both source and object code is protected on fixation, without any filing, as a literary work under 17 U.S.C. § 102(a). That is the good news. The limit is built into the same section: copyright protects expression, not the "idea, procedure, process, system, method of operation, concept, principle, or discovery" the expression describes. 17 U.S.C. § 102(b). The algorithm, the functional method, the thing the code does — none of that is copyright's business. This is the idea/expression dichotomy, and in software it does a great deal of work, because two programs can accomplish the identical function with entirely different code and neither infringes the other.

The Supreme Court's most consequential recent word on software copyright, Google LLC v. Oracle America, Inc., 141 S. Ct. 1183 (2021), lives in this territory. The Court held that Google's reuse of roughly 11,500 lines of the Java SE API declaring code was fair use, and pointedly declined to decide whether the declarations were copyrightable at all, treating them as functional interface material at the outer edge of what copyright reaches. The practical lesson for licensing is that interface and interoperability code is "thin" — protected weakly if at all — while the creative implementation beneath it enjoys ordinary protection. When a license or a diligence question turns on whether copying an interface infringed, Google v. Oracle is the starting point. The interoperability angle is developed further in POSIX standards and the law, which works through API copyright after the decision.

Two operational points matter for anyone relying on copyright. First, registration is not required for the copyright to exist, but it is a precondition to filing an infringement suit and to recovering statutory damages and attorney's fees for pre-registration infringement. 17 U.S.C. §§ 411, 412; Fourth Estate Public Benefit Corp. v. Wall-Street.com, LLC, 139 S. Ct. 881 (2019) (a copyright claimant may sue only after the Register acts on the application). Software raises a wrinkle here, because deposit of source code exposes it — so the Copyright Office allows redaction of trade-secret portions under the "rule of doubt." The mechanics are covered in registering copyright in software and source code and, operationally, in the software copyright registration checklist. Second, § 117 gives the lawful owner of a copy a narrow statutory right to make copies as an essential step in running the program and to make archival copies — a right most commercial licenses expressly negate by licensing rather than selling the copy, a point Part 2 returns to.

Patents: the functional layer

Where copyright refuses to protect the method, a patent can. A utility patent covers the functional process a program implements — the way it does what it does — for a term of twenty years from filing, in exchange for public disclosure. The catch, and it is a large one for software, is subject-matter eligibility under 35 U.S.C. § 101. Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), set the two-step test that has since invalidated a great many software patents: a claim directed to an abstract idea is ineligible unless it adds an "inventive concept" beyond generic computer implementation. Drafting around Alice is a discipline of its own, treated in depth in protecting software and business-method inventions after Alice and reduced to a working sequence in the Section 101 eligibility checklist. For licensing purposes, the point is narrower: a patent is the only regime that can stop a competitor who independently writes different code to reach the same result, and that reach is exactly why open source licenses increasingly carry their own patent terms, discussed in Part 3.

Trade secret: the hidden layer

The third layer protects what you never publish. Trade secret law — federally under the Defend Trade Secrets Act, 18 U.S.C. §§ 1836–1839, and in nearly every state under a version of the Uniform Trade Secrets Act — protects information that derives value from not being generally known, so long as the owner takes "reasonable measures" to keep it secret. Unpublished source code, build tooling, model weights, and internal know-how are classic trade secrets. Protection is potentially perpetual, but fragile: it evaporates the moment the secret is disclosed, and it does nothing against a competitor who reaches the same result by independent development or lawful reverse engineering. The reasonable-measures requirement is the whole ballgame, and it is the subject of the trade secret protection toolkit and the more foundational trade secret law overview; the program-building steps are in the trade secret program checklist.

Patent and trade secret sit in genuine tension, because they are mutually exclusive for the same information. A patent requires you to disclose the invention to the public; disclosure destroys secrecy. So for each valuable method a company must choose: patent it and publish, or keep it secret and hope no one independently invents it. The distribution model usually settles the question. Code that ships to customers is hard to keep secret and a poor trade-secret candidate; code that never leaves your servers is a natural secret because no one outside can see it. The full four-way comparison — subject matter, term, and remedies across copyright, patent, trade secret, and trademark — is laid out in copyright, trademark, patent, and trade secret compared.

Contract: the connective tissue

The fourth layer is not a form of intellectual property at all; it is the contract law that binds the other three together and moves rights from owner to user. Licenses, assignments, NDAs, and employee invention-assignment agreements are the plumbing. A recurring foundational choice — one that shapes the entire distribution regime — is whether software is sold or licensed. Vendors overwhelmingly license, because a sale would trigger the first-sale doctrine and let the buyer resell the copy freely, while a license keeps the vendor in control of downstream use. The Ninth Circuit's three-factor test in Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010), governs whether a transaction is a license or a sale, and ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), remains the touchstone for enforcing shrinkwrap and clickwrap terms against consumers who click "I agree." Getting invention assignments right so that the company actually owns what its engineers write — before a financing or acquisition tests the chain of title — is its own discipline, treated in employee invention assignment agreements. For the conceptual overview of why software is licensed at all, see how software licensing works; the four regimes as applied to code specifically are synthesized in how the law protects software.

Worked example — one product, four layers. Cardinal Analytics (hypothetical) ships a fraud-detection platform. Its scoring engine runs only on Cardinal's servers and is never distributed, so Cardinal keeps it as a trade secret behind access controls and NDAs rather than patenting it, since a patent would publish the algorithm to competitors while a server-side secret stays hidden. Cardinal does patent a genuinely novel data-partitioning method, because a patent is the only way to stop a rival who writes different code to the same end. The client-side SDK Cardinal hands to customers is a poor trade-secret candidate — customers can inspect it — so Cardinal relies on copyright plus a license that forbids reverse engineering and redistribution. The SDK also embeds three open source libraries, which drags in Part 3's obligations. Same company, same product, four different tools, each chosen by asking one question: does this code leave the building?

Go deeper: How the law protects software · The IP clearance toolkit · Protectable assets in a mobile app Primary authority: 17 U.S.C. §§ 101–106, 117, 411–412; 35 U.S.C. § 101; 18 U.S.C. §§ 1836–1839; Google LLC v. Oracle Am., Inc., 141 S. Ct. 1183 (2021); Alice Corp. v. CLS Bank Int'l, 573 U.S. 208 (2014); Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010).

Part 2 — Proprietary licensing: allocating risk in the paper

A proprietary software license is the contract by which an owner hands a customer limited rights while keeping ownership. Whether the deal is on-premise, SaaS, or a hybrid, the negotiation turns on a familiar set of levers, and the money clauses reward the most attention.

The grant and its limits

Everything starts with the grant: the scope of what the customer may do (use, copy, modify, sublicense), the territory, the term, and whether the rights are exclusive. Around the grant sits a fence of restrictions — no reverse engineering, no transfer, seat and instance caps, field-of-use limits. Then come the commercial terms: delivery and acceptance, fees and audit rights, ownership of the base software and of any customizations, warranties and disclaimers, indemnification, and the limitation of liability. The full anatomy, clause by clause, is set out in the anatomy of a software license agreement and, from the negotiation seat, in software license agreements: key terms and how to negotiate them. Two review checklists — a fast order-of-attack checklist and a complete vendor-and-customer toolkit — turn the doctrine into a repeatable review. Open source obligations bleed into this stage, too: a vendor must be sure its own inbound open source use has not contaminated the very rights it is purporting to grant.

The covenant-versus-condition fault line

Here is the most important doctrinal idea in software licensing, and the one that quietly connects proprietary and open source enforcement: not every promise in a license is created equal. A license restriction can be drafted as a condition on the copyright grant or as an independent covenant. The distinction decides the remedy. Breach a covenant and the licensor has a contract claim, with contract damages and the ordinary duty to prove loss. Exceed a condition and the licensee has acted outside the scope of the license entirely, which means the use was unlicensed, which means copyright infringement — with the far heavier artillery of statutory damages, injunctions, and, for registered works, attorney's fees.

The Ninth Circuit drew the line cleanly in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010): a licensee's violation is copyright infringement only where the term breached is a condition on the license grant and the breach implicates one of the copyright owner's exclusive rights; otherwise it sounds in contract. The court traced the principle back to Sun Microsystems, Inc. v. Microsoft Corp., 188 F.3d 1115 (9th Cir. 1999), where Microsoft's Java implementation, if it exceeded the license's compatibility conditions, was infringement rather than mere breach. Careful drafters therefore use conditional language ("provided that," "on the condition that," "only if") for the restrictions they most want to protect, because the remedy is dramatically stronger. This is not academic: it is precisely the mechanism that makes open source licenses enforceable as copyright, as Part 4 explains.

Warranties, indemnities, and the liability cap

The perennial friction points are the IP infringement indemnity and the limitation of liability, and they interact in ways that trap the unwary. Customers want a broad indemnity against third-party IP claims arising from the software; vendors want it capped, conditioned on prompt notice and control of the defense, and shot through with exclusions for customer modifications and combinations. The trap is that a vendor who grants a generous-sounding indemnity but subjects it to a general liability cap has often granted an illusion. If the indemnity is capped at twelve months' fees and a patent suit seeks ten times that, the "protection" is worth the cap and no more. That is exactly why sophisticated licensees fight to carve IP indemnity out of the general cap, and why the interaction of the two clauses matters more than either clause read alone.

From the licensee's chair, the single most valuable diligence question about a vendor is whether the vendor's own house is in order — which loops directly to the vendor's open source posture in Part 5. A vendor that cannot enumerate its open source components is a vendor whose indemnity has never been stress-tested and may not survive contact with a real claim.

Source-code escrow

For business-critical on-premise software, the licensee's nightmare is the vendor going dark — bankruptcy, acquisition, or simple abandonment — leaving the customer with a binary it cannot maintain. Source-code escrow answers that fear: the vendor deposits current source with a neutral agent, and the agent releases it to the licensee on defined trigger events (bankruptcy, cessation of support, failure to meet maintenance obligations). A workable escrow agreement grants the agent enough possessory and IP rights to perform, disclaims any duty to verify the deposit's completeness, and specifies release conditions and fees with precision. Escrow is a poor substitute for the source itself and only as good as the deposit's currency, but it is a standard risk-allocation tool for mission-critical deployments, and it appears again in Part 6 as a diligence artifact.

Worked example — the indemnity that wasn't. Meridian Health Systems (hypothetical) licenses an analytics platform from a vendor whose contract features a proud "full IP indemnity." A non-practicing entity later sues Meridian over a feature of the platform and demands damages many multiples of Meridian's annual fees. Meridian tenders the claim; the vendor accepts — and then points to the general liability cap of twelve months' fees, which by the contract's own terms limits "all liability, including indemnification." The indemnity is real but bounded, and Meridian eats the difference. The fix was one sentence Meridian's counsel should have insisted on at signing: third-party IP indemnification sits outside the general cap. The clause-level treatment lives in software license agreements: key terms and how to negotiate them.

Go deeper: The landscape of software transactions · Reviewing a software license agreement · Contracting for agile software development Primary authority: MDY Indus., LLC v. Blizzard Entm't, Inc., 629 F.3d 928 (9th Cir. 2010); Sun Microsystems, Inc. v. Microsoft Corp., 188 F.3d 1115 (9th Cir. 1999); ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996); U.C.C. Art. 2 and common-law contract principles; 17 U.S.C. § 117.

Part 3 — The open source license spectrum

"Open source" is not a synonym for "public domain" or "free of obligations." It is a licensing technique — or rather a family of them — defined by a shared floor of freedoms and separated by a single variable: how much the license makes you give back when you use, modify, or distribute the code. Understand that variable and the whole taxonomy falls into place. The comprehensive treatment is open source software licenses, compliance, and risk; this part is the map.

What "open source" actually means

Two definitions anchor the field. The Open Source Definition, maintained by the Open Source Initiative (OSI), sets the criteria a license must meet to be "open source" — free redistribution, available source code, permitted derivative works, no discrimination against persons or fields of use, and more. A license is "OSI-approved" only after the OSI vets it against that definition, and the approved list at opensource.org is the authoritative catalog. The overlapping Free Software definition of the Free Software Foundation (FSF) emphasizes the user's freedoms to run, study, modify, and share. The two communities differ in philosophy but converge on most licenses. For tracking which license governs which component, the industry standard is the SPDX identifier system (now ISO/IEC 5962:2021), a controlled vocabulary of short license tags — MIT, Apache-2.0, GPL-3.0-only, AGPL-3.0-or-later — that machines can read. Every component in your inventory should carry an SPDX tag, a point Part 5 operationalizes.

Empirically, the center of gravity has shifted toward permissive licensing over the past decade, with MIT and Apache 2.0 together dominating new projects, though the strong-copyleft GPL family still governs a substantial share of widely used software. Popularity is not permission, however: a component's obligations turn on its license text, not on how common the license is.

Permissive licenses: MIT, BSD, Apache 2.0

Permissive licenses ask for almost nothing. The MIT and BSD families require only that you preserve the copyright notice and license text; do that, and you may use, modify, sublicense, and even fold the code into a proprietary, closed-source product. Apache License 2.0 is permissive but more sophisticated in two respects that matter enormously. First, it contains an express patent grant: every contributor licenses the patents it holds that read on its contribution, to every user. Second, it contains a patent-retaliation clause: sue any user for patent infringement over the software and your patent license terminates automatically. Those two features make Apache 2.0 the preferred permissive license for patent-conscious enterprises, because the bare MIT and BSD licenses grant copyright rights but say nothing about patents, leaving a theoretical gap. For nearly all commercial purposes, permissive components are safe to combine with proprietary code — the obligations are limited to attribution and notice preservation, which a build pipeline can satisfy automatically.

Weak copyleft: LGPL, MPL 2.0, EPL

Copyleft is the mechanism that makes some open source licenses "sticky": distribute a work built on the code and you must license the result — or some defined portion of it — under the same terms, source included. Weak copyleft cabins that reciprocity to the licensed component or file rather than the whole program. The GNU Lesser General Public License (LGPL) is the archetype: you may link proprietary code to an LGPL library and keep your own code proprietary, provided you meet the linking conditions (roughly, that users can substitute a modified version of the library). The Mozilla Public License 2.0 (MPL) and Eclipse Public License (EPL) apply reciprocity at the file level — modify an MPL-covered file and that file's changes must be shared, but new files you add alongside it can stay proprietary. Weak copyleft is the pragmatic middle: reuse is broad, the give-back is contained.

Strong copyleft: GPLv2, GPLv3

Strong copyleft is where architecture decisions become legal decisions. Under GPLv2 and GPLv3, distributing a work that incorporates GPL code as part of a larger "work based on the Program" generally requires you to license the entire combined work under the GPL and to make the corresponding source available. For a company whose business depends on keeping its product proprietary, an inadvertent GPL combination is not a paperwork problem; it is a potential obligation to hand competitors the source code. GPLv3 modernized GPLv2 with an explicit patent grant, anti-tivoization provisions (you must supply the installation information needed to run modified versions on locked-down hardware), and better license-compatibility handling. The severity of the strong-copyleft consequence is the reason the derivative-work question below deserves engineering-and-legal attention before the component is committed, not after.

Network copyleft: AGPLv3

The GNU Affero General Public License (AGPLv3) exists to close what its drafters saw as a loophole. Traditional copyleft is triggered by distribution — handing someone a copy. But a SaaS company that runs modified GPL code on its own servers and exposes it only over a network never "distributes" a copy in the conventional sense, so historically its copyleft obligations never fired. Section 13 of the AGPL extends the reciprocity trigger to network interaction: if users interact with modified AGPL software remotely, they must be offered the corresponding source. For a hosted service, running AGPL code can therefore carry the same source-disclosure duty as shipping it. The AGPL is the single most common open source surprise for SaaS businesses, and Part 7 treats it in full.

The derivative-work question that drives everything

Copyleft's reach depends entirely on what counts as a single "work" or a "derivative work" that triggers reciprocity — and this is the least settled, most consequential question in the field. The technical distinctions do a lot of legal work:

  • Static linking copies the library's object code verbatim into your executable. The FSF views the result as a single combined work, so static-linking GPL code into a proprietary binary is the paradigm copyleft trigger.
  • Dynamic linking keeps the library separate and binds at runtime. The FSF still generally treats this as a combined derivative work; many practitioners disagree, and the case law does not resolve it.
  • Separate processes communicating over a defined interface (a pipe, a socket, a documented API) are, on the more permissive view, arm's-length programs rather than one work — an "aggregation" rather than a combination.
  • Mere aggregation on the same medium (two independent programs shipped on one disk or in one container image) does not trigger copyleft at all; the GPL says so expressly.

The catch is that the FSF's interpretive guidance, though influential, is not binding law, and Google v. Oracle's treatment of interface code as thin or functional cuts against an expansive reading of "derivative work" for API-level connections — without settling the linking question. Because the downside of guessing wrong is the compelled disclosure of your proprietary source, copyleft-combination questions belong to software architecture, decided with counsel early, not to a license review sprung on the team the week before ship. The enterprise-specific traps — incompatible license stacks, hidden transitive dependencies, the relicensing wave — are mapped in open source licensing traps in enterprise software.

Worked example — the week that cost a quarter. An engineer at Northwind Robotics (hypothetical) statically links a GPLv3 motion-planning library into the company's proprietary firmware to save a week of reimplementation. Two years later, during acquisition diligence, the buyer's counsel flags the static link as a potential trigger requiring Northwind to offer the entire firmware's source under the GPL. The remedy is not a memo; it is an engineering project to rip out and replace the library, re-verify safety behavior, and re-certify the product — followed by a price renegotiation while the buyer waits. Choosing a permissively licensed motion planner at the outset would have cost the same week and none of the quarter. The lesson is the toolkit's recurring one: the license is a design constraint, so make it visible at design time.

Go deeper: Open source software licenses, compliance, and risk · Open source licensing traps in enterprise software · POSIX standards and the law External: Open Source Initiative approved licenses (opensource.org/licenses); SPDX license list (spdx.org/licenses); GNU license texts (gnu.org/licenses); Apache License 2.0; MIT License.

Part 4 — Enforcement: why compliance is not optional

Skeptics used to wave off open source obligations as unenforceable idealism — a community norm dressed up as a license. That view is dead. A line of cases has established that open source terms are enforceable, that breaching them can be copyright infringement, and that the remedies are the full copyright arsenal.

The foundational decision is Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008). The dispute involved model-railroad software released under the Artistic License, whose conditions the defendant ignored. The Federal Circuit held that the license's attribution and notice requirements were conditions on the copyright grant, not mere covenants, so exceeding them was copyright infringement rather than ordinary breach. Id. at 1381–82. That holding — plugging open source licenses directly into the covenant-versus-condition machinery of Part 2 — is why the whole enforcement edifice stands. Conditions unlock statutory damages and, crucially, injunctions, because irreparable harm is easier to show for infringement than for breach, and an injunction is precisely the remedy that can force source disclosure or halt distribution.

Several later cases fill in the picture:

  • Artifex Software, Inc. v. Hancom, Inc., No. 16-cv-06982-JSC, 2017 WL 4005508 (N.D. Cal. Sept. 12, 2017), let a GPL enforcement claim proceed on a breach-of-contract theory as well as copyright, treating the dual-licensed Ghostscript license (comply with the GPL or buy a commercial license) as an enforceable contract whose terms the defendant accepted by use. The case matters because it validates the contract framing that the FSF had long resisted, giving licensors a second, complementary cause of action.
  • Software Freedom Conservancy, Inc. v. Best Buy Co. (S.D.N.Y. 2010) — one of the BusyBox cases — produced default judgments and injunctions against consumer-electronics vendors who shipped GPLv2-covered code without offering source, demonstrating that copyleft is enforced against real products, not just in theory.
  • Software Freedom Conservancy, Inc. v. Vizio, Inc. (C.D. Cal. 2022) pushed the theory further, framing GPL/LGPL compliance as an obligation enforceable by the software's users as third-party beneficiaries of the license — a contract theory that, if it holds, dramatically widens the class of potential plaintiffs beyond copyright holders. The federal court's remand to California state court kept that novel theory alive.
  • Neo4j, Inc. v. PureThink, LLC, 58 F.4th 1055 (9th Cir. 2023), came out the other way for the downstream user: a licensee could not strip the "Commons Clause" restriction that Neo4j had added to AGPLv3 and then market the result as "free and open source," because removing a further restriction the licensor had lawfully imposed was itself a breach. The case is a caution that a licensor's added terms, even ones the OSI would not bless as "open source," can bind.
  • Wallace v. International Business Machines Corp., 467 F.3d 1104 (7th Cir. 2006), disposed of the recurring argument that the GPL's zero-price term is an antitrust violation. Judge Easterbrook held the GPL does not restrain trade — "the GPL and open-source have nothing to fear from the antitrust laws" — closing off a defense infringers periodically try.

The takeaway is blunt. Violating an open source license can mean copyright infringement, statutory damages, an injunction, forced source disclosure, and — in a transaction — a repriced or dead deal. Compliance is cheaper than any of those outcomes.

Go deeper: The real cost of IP piracy · Open source software licenses, compliance, and risk Primary authority: Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008); Artifex Software, Inc. v. Hancom, Inc., 2017 WL 4005508 (N.D. Cal. 2017); Neo4j, Inc. v. PureThink, LLC, 58 F.4th 1055 (9th Cir. 2023); Wallace v. Int'l Bus. Machs. Corp., 467 F.3d 1104 (7th Cir. 2006); 17 U.S.C. § 106.

Part 5 — Build an open source compliance program

A compliance program is what turns license text into repeatable engineering practice. Done well, it is nearly invisible — checks that run in the pipeline and gates that stop problems before they reach production. Done badly, or not at all, it surfaces as the emergency remediation of Part 3's worked example. The operational detail lives in two UpLaw checklists: the single-flow open source compliance checklist and the more granular open source compliance playbook. Five components carry the load.

Policy and governance

Start with a written policy that classifies licenses into approved (permissive licenses cleared for any use), restricted (weak copyleft and anything needing architectural review before use), and prohibited (strong and network copyleft in contexts where disclosure would be unacceptable). Pair the policy with an intake process — a request-and-approval gate for adding new components — and a named owner. Larger organizations stand up an Open Source Program Office (OSPO); smaller ones designate counsel plus an engineering lead. For a recognized process baseline, OpenChain (ISO/IEC 5230:2020) specifies the key requirements of a quality open source compliance program and lets a company (or its acquirer) certify conformance — increasingly a diligence expectation rather than a nicety.

Inventory and the software bill of materials

You cannot comply with obligations you cannot see, and the average codebase's dependency tree runs hundreds of components deep, most of them pulled in transitively by other components. The answer is a software bill of materials (SBOM): a complete, machine-readable inventory of every component, version, supplier, and license, generated automatically by software-composition-analysis (SCA) tooling wired into the build. Standard formats — SPDX (ISO/IEC 5962:2021) and CycloneDX — make the SBOM portable across tools and readable by customers and acquirers.

The SBOM has moved from best practice to regulatory expectation on two tracks. In the United States, Executive Order 14028 (May 12, 2021) directed the government to require SBOMs from software suppliers, and the NTIA's Minimum Elements for a Software Bill of Materials (July 2021) defined the baseline data fields. In the European Union, the Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to produce and maintain SBOMs as part of security compliance. The catalyzing event for all of it was Log4Shell (CVE-2021-44228, December 2021), the critical vulnerability in the ubiquitous Log4j logging library: organizations discovered they had no reliable way to answer the only question that mattered — "are we running the vulnerable version, and where?" An SBOM answers that question in minutes; without one, it takes weeks of frightened grepping. Compliance and security here are the same muscle.

Obligation tracking and notices

Even permissive licenses impose duties — principally attribution and preservation of copyright and license notices — and copyleft licenses add source-availability obligations. The program must ship the required license texts and attribution notices with the product (the familiar third-party-notices file), and, where copyleft applies to distributed code, provide the corresponding source or a written offer for it. These are mechanical, high-volume tasks that tooling should handle; a human doing them by hand will miss some, and each miss is a latent Jacobsen claim.

Remediation

When a scan flags a copyleft conflict or an incompatible license pairing, the program needs a remediation path: replace the component with a permissively licensed equivalent, isolate it behind a process boundary so it does not form a combined work, negotiate a commercial license from a dual-licensing vendor, or — rarely and deliberately — accept the copyleft obligation and open-source the affected code. The decision is architectural and legal at once, which is why remediation belongs in the same review gate as intake.

Outbound contributions

Compliance is not only inbound. Code your company releases as open source, or contributes to others' projects, is a deliberate intellectual-property decision that grants the world a license to your copyright and, depending on the license, your patents. Apache 2.0's express patent grant, for instance, licenses your reading patents to every user of the project. Releasing can build community, drive adoption, and recruit talent — but it is a one-way door, and it must pass through the same governance gate as inbound use. Two hygiene tools keep outbound provenance clean: a Contributor License Agreement (CLA), by which contributors grant the project the rights it needs and warrant they have the right to contribute, and a lighter-weight Developer Certificate of Origin (DCO), a per-commit attestation. Both exist to prevent the ugliest outbound accident — an employee committing code they did not have the right to give away, or that embeds a secret the company meant to keep.

Worked example — the utility that got away. An engineer at Solstice Data (hypothetical), proud of a slick internal deduplication utility, publishes it to a public repository under the MIT license without approval. The utility embeds a proprietary matching heuristic that Solstice had guarded as a trade secret. Once the code is public and forked, the disclosure cannot be undone: the trade secret is gone, because trade secret protection evaporates on public disclosure, and the MIT grant Solstice's engineer purported to make is irrevocable as to anyone who relied on it. The failure was governance, not malice — outbound contributions were never gated the way inbound components were. The lesson: the intake gate must swing both ways. Program-building detail is in the open source compliance playbook, and the trade-secret consequences in the trade secret protection toolkit.

Go deeper: Open source software compliance checklist · The open source compliance playbook · Non-disclosure agreements for technology deals External and primary: Exec. Order No. 14028, 86 Fed. Reg. 26633 (May 17, 2021); NTIA, Minimum Elements for an SBOM (2021); Regulation (EU) 2024/2847 (Cyber Resilience Act); ISO/IEC 5230:2020 (OpenChain); ISO/IEC 5962:2021 (SPDX).

Part 6 — Transaction diligence: M&A and financings

When a software company is acquired or raises a priced round, its open source and licensing posture stops being an internal engineering concern and becomes a deal term. Acquirers and investors are buying the target's code, and they need assurance on four fronts: that the target actually owns or has properly licensed all material code; that no copyleft obligation jeopardizes the exclusivity of the flagship product; that inbound and outbound licenses survive a change of control (assignability and change-of-control clauses can silently terminate a key license at closing); and that no unresolved infringement exposure is lurking. The chain-of-title piece reaches back to Part 1's contract layer — clean invention assignments from every engineer and contractor — and is a frequent diligence failure point, treated in employee invention assignment agreements and, from the founder's side, in getting diligence-ready before you raise.

The diligence deliverable is now standardized: an SBOM-backed open source report — often the very SBOM the target's Part 5 program already generates — plus a review of all material inbound and outbound license agreements, flagged for copyleft, assignability, and exclusivity problems. Acquirers frequently run their own independent composition scan of the code base, and a mismatch between the target's representations and the scan is a credibility event that reshapes the whole negotiation.

Inadequate hygiene shows up in predictable places: price reductions sized to the remediation cost, escrow holdbacks pending cleanup, special indemnities carved out for identified open source risks, and — when the problem is severe enough, such as strong copyleft woven into the core product — a dead deal. The transaction structure and reps-and-warranties framing are covered in the landscape of software transactions and the broader IP transactions toolkit. Sellers who ran the Part 5 program present a clean SBOM, an OpenChain conformance record, and organized license agreements — and they close faster and at a better number. Diligence rewards the boring.

Worked example — diligence as discovery. Aperture Capital (hypothetical) is set to lead a Series B in a logistics-software startup at a headline valuation. Its diligence scan turns up an AGPLv3-licensed geocoding component sitting inside the startup's hosted routing service — exactly the network-copyleft trap of Part 7. Under the AGPL, the startup arguably owes source disclosure to its own customers, which would strip the moat the valuation was built on. The round does not die, but it reprices: Aperture cuts the valuation, adds a special indemnity for the AGPL exposure, and makes a portion of proceeds contingent on the startup ripping out the component within ninety days. A one-line entry in an SBOM, caught at design time, would have been a non-event. Caught at diligence, it cost the founders several points of dilution.

Go deeper: Getting diligence-ready before you raise · The IP transactions toolkit · The landscape of software transactions

Part 7 — SaaS and cloud distribution

Delivering software as a hosted service instead of a downloadable product changes the licensing analysis in ways that are easy to miss precisely because nothing is ever "delivered." Three shifts matter.

The distribution/network-use gap and the AGPL trap

Traditional copyleft — GPLv2 and GPLv3 — is triggered by distribution. A SaaS company that runs software on its own servers and exposes it to users over the network does not hand anyone a copy, so historically it could use GPL code internally without firing the copyleft obligation. This was the deliberate design of the GPL, and for years it was a genuine safe harbor for hosted businesses. The AGPLv3 was written to close it. Section 13 extends the source-availability obligation to users who interact with modified AGPL software remotely, so hosting modified AGPL code can carry the same disclosure duty as distributing it. The practical instruction is specific: inventory your AGPL exposure separately and deliberately, because it is the single most common open source surprise in a SaaS stack, and because ordinary "we don't distribute, so copyleft doesn't apply" reasoning is exactly wrong for it.

The relicensing wave

The same tension — SaaS providers using open source without giving back, cloud hyperscalers in particular monetizing others' projects as managed services — has reshaped commercial open source over the past several years. A string of companies moved flagship projects off OSI-approved licenses onto source-available licenses designed to block competitors from offering the software as a service:

  • MongoDB created the Server Side Public License (SSPL) in 2018; the OSI declined to approve it as open source, viewing its service-scope copyleft as discriminating against a field of use.
  • Elastic relicensed Elasticsearch to the SSPL and the Elastic License in 2021, prompting AWS to fork the last Apache-licensed version as OpenSearch — and, in a notable reversal, Elastic added the AGPL as an option in 2024 to reclaim the "open source" label.
  • HashiCorp adopted the Business Source License (BSL) for Terraform and other tools in 2023, triggering the community OpenTofu fork under the Linux Foundation.
  • Redis moved to a dual SSPL/source-available model in 2024, prompting the Valkey fork, also under the Linux Foundation.

The pattern is worth internalizing because it changes how you must read a dependency: a component that was permissively licensed when you adopted it may carry restrictive terms in its current release, and upgrading across a relicensing boundary can silently import obligations — or forfeit the right to use new versions in your service at all. The relicensing wave is why the SBOM must track license by version, not just by component, and it is analyzed further in open source licensing traps in enterprise software. The broader question of using intellectual property to control software after it leaves your hands connects to the right-to-repair reckoning.

Everything else in the cloud contract

Because a SaaS deal delivers a service rather than a copy, its contract lives less in the software-license clauses and more in the operational and data terms: data ownership and use rights, security and uptime commitments, sub-processor and onward-transfer terms, and audit and exit provisions. The absence of a traditional "delivery of a copy" also reshapes acceptance, warranty, and escrow analysis. For a regulated-data overlay — where the cloud vendor becomes a business associate or processor — the contracting model in HIPAA in the cloud shows how the same hosted-service structure carries additional statutory freight. And where a service ingests third-party data, the CFAA-and-contract analysis of web scraping after hiQ v. LinkedIn becomes relevant to what the service is permitted to collect.

Go deeper: The landscape of software transactions · Open source licensing traps in enterprise software · Section 230 and platform liability External and primary: GNU AGPLv3 § 13; SSPL, BSL, and Elastic License texts; 17 U.S.C. § 106 (distribution and public-performance rights); license terms as the operative authority.

Part 8 — AI-generated code: the new provenance problem

AI coding assistants have folded a new and unsettled set of questions into the licensing stack. They do not repeal any of the doctrine above; they make two familiar problems sharper and add a third.

Authorship and ownership

The first problem is who — if anyone — owns machine-written code. The U.S. Copyright Office's position, developed across its Copyright and Artificial Intelligence reports, is that purely AI-generated output without sufficient human authorship is not copyrightable; a human's creative selection, arrangement, or modification can support a claim in that human contribution, but the raw generated material is not protected. 17 U.S.C. § 102(a) (protecting works "of authorship"). The courts have backed the human-authorship requirement: Thaler v. Perlmutter, 687 F. Supp. 3d 140 (D.D.C. 2023), aff'd, 130 F.4th 1039 (D.C. Cir. 2025), upheld the Office's refusal to register a work listing an AI as author. For code, this means large blocks of substantially AI-generated source may sit in a gray zone of thin or absent copyright, which complicates both enforcement against copyists and the ownership representations a target makes in diligence. The parallel patent question — whether an AI can be an inventor — is treated in who owns AI-generated inventions.

Provenance and license contamination

The second problem is the more acute one for compliance. Models trained on public repositories can emit code that resembles their training data, and if that training data was copyleft-licensed, a generated snippet might carry — invisibly — obligations the developer never saw or accepted. A proprietary codebase could ingest GPL-flavored code without the attribution or source-availability duties that license demands, seeding a latent Jacobsen problem that no license scanner flagged because there was no dependency entry to scan. The litigation testing these theories is ongoing and inconclusive: the GitHub Copilot suit, Doe v. GitHub, Inc. (N.D. Cal.), saw most of its claims — including the DMCA § 1202 copyright-management-information theory — narrowed or dismissed, while the broader training-data copyright questions play out in the generative-AI cases surveyed in generative AI on trial. The law here is genuinely unsettled; monitor it rather than rely on any single ruling.

The tool's own terms, and practical hygiene

The third point is easy to overlook: the AI coding tool is itself licensed, and the terms vary widely. Enterprise tiers often provide IP indemnification for outputs and contractual assurances about training and telemetry; consumer tiers frequently do not, and some reserve broad rights to use submitted code. Read the assistant's agreement the way you would read any vendor's — for indemnity, IP ownership of inputs and outputs, and data use.

The hygiene that ties this together is not exotic. Route AI-generated code through the same Part 5 pipeline: run it through composition analysis and license scanning, preserve genuine human authorship and review so the output is not orphaned, and track the provenance of accepted suggestions so a later diligence question has an answer. AI does not create a separate compliance regime; it creates more code, faster, that the existing regime must catch. The wider survey of AI legal risk sits in key legal issues in artificial intelligence and the staged AI and emerging technology law toolkit.

Go deeper: Generative AI on trial · Key legal issues in artificial intelligence · The evolution of computer law External and primary: 17 U.S.C. § 102(a); U.S. Copyright Office, Copyright and Artificial Intelligence (copyright.gov/ai); Thaler v. Perlmutter, 687 F. Supp. 3d 140 (D.D.C. 2023), aff'd, 130 F.4th 1039 (D.C. Cir. 2025). AI/IP law is unsettled; verify current authority before relying on it.

The one-page compliance quick reference

A condensed checklist for the reader who has read the doctrine and wants the operational spine on a single screen. The full versions live in the open source compliance checklist and the open source compliance playbook.

Before you write code

  • [ ] Publish an approved / restricted / prohibited license policy and name an owner (OSPO or counsel-plus-engineer).
  • [ ] Gate every new component through an intake-and-approval request.
  • [ ] Decide copyleft-combination questions at architecture time, with counsel, not at ship time.

As you build

  • [ ] Generate an SBOM automatically in the pipeline; record license by version in SPDX or CycloneDX.
  • [ ] Run software-composition analysis on every build, including transitive dependencies.
  • [ ] Auto-assemble third-party attribution and notice files; fulfill source-availability duties for distributed copyleft code.

Before you ship or release

  • [ ] Clear all copyleft conflicts and incompatible pairings (replace, isolate, license, or deliberately open-source).
  • [ ] Gate outbound contributions the same way as inbound; require a CLA or DCO.
  • [ ] Confirm no proprietary secret is riding inside a component you are about to publish.

Before you transact

  • [ ] Produce a clean SBOM-backed open source report and organized license agreements.
  • [ ] Check inbound/outbound licenses for assignability and change-of-control termination.
  • [ ] Verify chain of title: invention assignments from every engineer and contractor.

Always

  • [ ] Track your AGPL exposure separately; re-check licenses across every dependency upgrade.
  • [ ] Route AI-generated code through the same scanning and provenance controls.
  • [ ] Treat the license as a spec, and compliance as engineering hygiene.

Related UpLaw Resources

Related Toolkits

Related Guides

Related Articles

Related Checklists

This toolkit is general information for legal-research purposes, not legal advice, and it does not create an attorney-client relationship. License terms control, enforcement doctrine varies by circuit, and the law governing AI-generated code and the relicensing of formerly open source projects is unsettled and moving quickly. Verify current authority before relying on any point above.