What this toolkit is for, and who should use it

Software is unusual among assets: a single program is simultaneously protected by copyright (the code as expression), potentially by patents (the underlying methods), and by trade secret (unpublished source and know-how), and it is almost always assembled from third-party components governed by licenses ranging from permissive to aggressively copyleft. Getting software licensing right means managing all of these layers at once—what you own, what you license in, and what you license out.

This toolkit maps that landscape. It is written for software companies and their engineering and legal leaders who ship products; investors and acquirers evaluating a software target; and transactional counsel drafting and reviewing license and SaaS agreements. It is a navigation guide—each stage hands you to the deep-dive article or operational checklist you need.

The central practical truth: open-source licenses are enforceable contracts and copyright conditions, not free-for-alls. Violating their terms can mean copyright infringement (see Jacobsen v. Katzer), loss of license, forced source disclosure, and—in a transaction—a killed or repriced deal. Compliance is engineering hygiene that legal supervises, not paperwork legal does alone.

Roadmap at a glance

  1. Map the IP layers — how copyright, patent, and trade secret protect software.
  2. Proprietary licensing — grant scope, restrictions, warranties, and risk allocation.
  3. Open source license families — permissive vs. copyleft and their obligations.
  4. Build a compliance program — inventory, SBOM, policy, and remediation.
  5. Transaction diligence — OSS and licensing risk in M&A and financings.
  6. SaaS and cloud — distribution, the AGPL, and the network-use question.
  7. AI-generated code — authorship, license provenance, and new risk.

Stage 1 — Map the IP layers in software

Before licensing anything, understand what protects the software in the first place, because the protection determines what you can license and what you must guard.

  • Copyright protects the original expression in source and object code automatically on fixation (17 U.S.C. § 102); it does not protect the underlying ideas, algorithms, or functionality (the idea/expression dichotomy). Registration unlocks statutory damages and the ability to sue.
  • Patents can protect the functional methods a program implements—subject to the subject-matter-eligibility limits of 35 U.S.C. § 101 after Alice Corp. v. CLS Bank.
  • Trade secret protects unpublished source code and know-how so long as reasonable secrecy measures are maintained—often the most practical protection for back-end code that is never distributed.

These layers are complementary: a company typically copyrights and trade-secrets its code, may patent key methods, and uses contracts (licenses, NDAs, assignment agreements) to tie it all together.

There is a structural tension worth naming. Patent and trade secret are mutually exclusive for the same information: a patent requires public disclosure of the invention, which destroys secrecy. A company must therefore choose, method by method, between patenting (a 20-year exclusive in exchange for disclosure) and keeping it secret (potentially perpetual, but vulnerable to independent invention and reverse engineering). Distributed source code that ships to customers is hard to keep secret; server-side code that never leaves your data center is a natural trade secret. The distribution model often dictates the protection strategy.

Illustration. A SaaS company's recommendation engine runs only on its own servers and is never distributed. Keeping it as a trade secret—protected by access controls and NDAs—may beat patenting it, because patenting would publish the algorithm to competitors while a server-side secret stays hidden. The same company's client-side SDK, which it ships to customers, is a poor trade-secret candidate and a better fit for copyright plus contractual restrictions.

Resources

Stage 2 — Proprietary licensing

A proprietary software license is the contract by which the owner grants a customer limited rights to use the software while retaining ownership. The negotiation turns on a familiar set of levers: the grant (scope—use, copy, modify, sublicense; territory; term; exclusivity); restrictions (no reverse engineering, no transfer, user/seat caps); delivery and acceptance; fees and audit rights; IP ownership of the software and of customizations; warranties and disclaimers; indemnification (especially IP infringement indemnity); and limitation of liability. Open-source obligations bleed into this stage too: a vendor must ensure its own OSS use does not contaminate the proprietary grant it is selling.

The perennial friction points in negotiation are the IP infringement indemnity and the limitation of liability. Customers want broad indemnity against third-party IP claims arising from the software; vendors want it capped and conditioned (prompt notice, control of defense, exclusions for customer modifications and combinations). The two clauses interact: a vendor that uncaps indemnity but caps overall liability may have created an illusory protection. From the licensee's side, the most valuable due-diligence question is whether the vendor's own house is in order—which loops directly to the vendor's open-source compliance posture (Stage 4). A vendor that cannot account for its OSS components is a vendor whose indemnity may be tested.

Illustration. An enterprise licenses a vendor's analytics platform with a robust IP indemnity but a liability cap equal to twelve months' fees. A patent troll then sues the enterprise over a feature, seeking damages far exceeding the cap. The "robust" indemnity is worth, at most, the capped amount—exactly why licensees negotiate to carve IP indemnity out of the general liability cap.

Resources

Stage 3 — Open source license families and their obligations

Open-source licenses fall on a spectrum defined by how much they require you to give back when you use, modify, or distribute the code.

  • Permissive (MIT, BSD, Apache 2.0): minimal conditions—principally attribution and preservation of notices. Apache 2.0 adds an express patent grant and a patent-retaliation clause. Permissive licenses are generally safe to combine with proprietary code.
  • Weak copyleft (LGPL, MPL 2.0, EPL): reciprocity is limited—typically to the licensed component or file. You can link proprietary code to an LGPL library and keep your code proprietary if you meet the linking conditions.
  • Strong copyleft (GPLv2, GPLv3): distributing a work that incorporates GPL code generally requires you to license the entire combined work under the GPL and provide corresponding source. For a proprietary product, an inadvertent GPL combination can be catastrophic.
  • Network copyleft (AGPLv3): extends copyleft obligations to network use—even running modified AGPL code as a hosted service (without "distributing" it in the traditional sense) can trigger the source-disclosure duty. This is the trap that catches SaaS companies (see Stage 6).

Track every component's license with standardized identifiers (SPDX) and consult the Open Source Initiative's approved-license list. Enforcement is real: Jacobsen v. Katzer established that breaching open-source license conditions can be copyright infringement, exposing the violator to the full copyright remedy set.

The decisive—and frequently mishandled—question for copyleft is what counts as a single "work" or "derivative work" that triggers reciprocity. Static linking, dynamic linking, separate processes communicating over a defined interface, and mere aggregation on the same media are treated differently, and the analysis is fact-specific and not fully settled in case law. The Free Software Foundation's interpretive guidance is influential but not binding. Because the consequence of getting it wrong (mandatory source disclosure of your proprietary product) is severe, treat copyleft-combination questions as engineering-architecture decisions made with counsel, early, rather than license trivia resolved at ship time.

Illustration. A team statically links a GPLv3 library into its proprietary binary to save a week of work. At an acquisition two years later, the acquirer's diligence flags the link as a potential trigger requiring the entire product's source to be offered under the GPL. The week saved becomes a remediation project and a price renegotiation. Choosing a permissively licensed equivalent at the outset would have avoided the entire issue.

Resources

Stage 4 — Build an open source compliance program

A compliance program turns license obligations into repeatable engineering practice. The core elements:

  • Policy and governance: an approved/restricted/prohibited license list, an intake/approval process for new components, and an owner (often an Open Source Program Office or a designated counsel).
  • Inventory and the SBOM: maintain a software bill of materials enumerating every component, version, and license, generated automatically via software-composition-analysis tooling in the build pipeline.
  • Obligation tracking and notices: satisfy attribution, notice-file, and source-availability duties; ship the required license texts and notices with the product.
  • Remediation: flag copyleft conflicts and license incompatibilities, and replace or isolate problematic components before release.
  • Audit and training: periodic scans and developer education so compliance is built in, not bolted on.

The program also governs the outbound direction—code your company contributes to or releases as open source. Releasing under an open license is a deliberate IP decision: it can build community, drive adoption, and recruit talent, but it also 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 relevant patents to all users, and many corporate open-source policies require a contributor license agreement (CLA) or developer certificate of origin to keep the provenance of contributions clean. Decide the outbound license to match your strategy, and ensure contributors actually have the right to contribute what they submit.

Illustration. An engineer, eager to share, publishes an internal utility on a public repository under the MIT license without approval. The utility embeds a proprietary algorithm the company intended to keep secret. The public release, once made, is difficult to claw back—illustrating why outbound contributions belong inside the same governance gate as inbound components.

Resources

Stage 5 — Transaction diligence: M&A and financings

When a software company is acquired or raises capital, its open-source and licensing posture is a core diligence item—often a deal-mover. Acquirers and investors want assurance that: the target actually owns or has properly licensed all material code; no copyleft obligation jeopardizes the proprietary product's exclusivity; inbound and outbound licenses are assignable (change-of-control clauses matter); and there are no unresolved infringement exposures. The diligence deliverable is usually an SBOM-backed open-source report plus a review of all material license agreements. Inadequate hygiene shows up as price reductions, escrow holdbacks, special indemnities, or, occasionally, a dead deal. Sellers who maintained the Stage 4 program present clean and close faster.

Resources

Stage 6 — SaaS and cloud distribution

Delivering software as a hosted service rather than as a downloaded product reshapes the licensing analysis. Traditional copyleft (GPLv2/v3) is triggered by distribution; merely operating software on your own servers and exposing it over a network historically did not count as distribution, which is why many SaaS companies could use GPL code internally. The AGPLv3 closed that gap: it extends source-disclosure obligations to users who interact with the software over a network, so hosting modified AGPL code can trigger the same duties as distributing it. Cloud and SaaS agreements also require attention to data rights, security and uptime commitments, sub-processor terms, and the absence of any traditional "delivery" of a copy. Inventory your AGPL exposure specifically; it is the single most common SaaS open-source surprise.

Resources

Stage 7 — AI-generated code

AI coding assistants introduce novel licensing and IP questions. Two stand out. First, authorship and ownership: the U.S. Copyright Office maintains that purely AI-generated output without sufficient human authorship is not copyrightable, which complicates ownership claims over machine-written code. Second, provenance and license contamination: models trained on open-source corpora may emit code resembling licensed training data, raising the risk that copyleft-licensed snippets enter a proprietary codebase without the accompanying obligations. Litigation over AI training and output is ongoing and the law is unsettled. Practical hygiene: route AI-generated code through the same Stage 4 compliance pipeline (composition analysis, license scanning), preserve human authorship and review, and track the provenance of accepted suggestions. Review the terms of the AI coding tool itself, too—vendor agreements vary in what indemnities, IP ownership terms, and usage telemetry they impose, and some enterprise offerings provide IP indemnification for outputs while consumer tiers do not.

Resources

Master resource index

Articles

Checklists

Related toolkits

External & primary sources

This toolkit is general information, not legal advice. License terms control; AI/IP law is unsettled—verify current authority before relying on it.