Open-Source License Compliance for Startups: The GPL, AGPL, MIT, and Apache 2.0 Audit Every Founder Must Run Before Shipping

Every startup uses open-source software. Your frontend framework, your database, your ML libraries, your build tools — all of it rests on code someone else wrote and licensed under terms that bind you whether you read them or not. Most founders never think about open-source licenses until a Series A diligence team or an acquirer sends a 200-question IP questionnaire and asks, "Do you have a complete software bill of materials, and have you reviewed every component for copyleft obligations?"

That is the worst time to discover a GPL-contaminated module buried three transitive dependencies deep in your stack. In our experience, open-source license findings — particularly GPL and AGPL — are the number one IP issue that surfaces during pre-launch legal reviews and acquisition diligence. The good news: with a structured audit, you can catch these issues early, remediate them, and walk into diligence with a clean compliance posture.

This guide walks through the four licenses you are most likely to encounter — MIT, Apache 2.0, GPL, and AGPL — clause by clause, explaining what each permits, what each requires, and where the contamination traps are. We then cover how to run a software composition analysis (SCA) and how license obligations interact with AI startups building on open-weight models like Llama.

MIT License: Permissive, But Not Permission-Free

The MIT License is the most common open-source license in the world, and it is also the simplest. It is a permissive license, meaning it allows you to use, copy, modify, merge, publish, distribute, and even sublicense the code — including in closed-source, proprietary products — with essentially one condition: you must include the original copyright notice and the license text in all copies or substantial portions of the software.

There is no copyleft obligation. You are not required to open-source your modifications. You are not required to distribute source code. You can take an MIT-licensed library, embed it in your proprietary SaaS product, and never share a single line of your own code.

The trap is simple but real: founders routinely include MIT-licensed dependencies without preserving the required copyright and license notices. If you ship a product that distributes MIT-licensed code (including in a compiled binary or a bundled JavaScript file) and you strip or fail to carry the notices, you are in technical violation. This is easy to fix retroactively — but it is even easier to get right from day one by automating notice collection in your build pipeline.

Apache License 2.0: Permissive Plus a Patent Grant

Apache 2.0 is also a permissive license — you can use it in proprietary products without copyleft consequences — but it adds two important obligations and one significant benefit that MIT does not.

The patent grant. Section 3 of the Apache 2.0 license grants you a perpetual, worldwide, royalty-free patent license from each contributor, covering any patent claims necessarily infringed by their contribution. This is a major advantage: it means that if an Apache-licensed project contributor holds a patent on a technique used in the code, they have granted you a license to use it. If you initiate patent litigation against any entity alleging that the work infringes your patents, your patent license terminates — a defensive provision known as the patent retaliation clause. The full Apache 2.0 license text spells out these terms.

Attribution and NOTICE requirements. Section 4 requires that you retain all copyright, patent, trademark, and attribution notices in any derivative works you distribute. If the original project includes a NOTICE file, you must include a readable copy of the attribution notices from that file in your derivative work. You must also cause any modified files to carry prominent notices stating that you changed the files.

The practical compliance step: maintain a NOTICE or THIRD_PARTY_LICENSES file in your repository that collects all Apache 2.0 (and other permissive) license text and attribution notices. Tools can automate this, but you need to configure them to run as part of your build, not as a one-time manual exercise.

GPL: The Copyleft Trigger That Can Force Your Code Open

The GNU General Public License (GPL), currently at version 3, is where open-source licensing stops being permissive and becomes copyleft. The GPL core principle, as stated in its official license text, is that if you distribute a modified version of GPL-licensed software, you must distribute it under the GPL — including the complete corresponding source code.

Here is what every founder needs to understand about how copyleft works in practice:

The Distribution Trigger

GPL obligations are triggered by conveying — which the license defines as any kind of propagation that enables other parties to make or receive copies. If you merely run GPL-licensed software internally (on your own servers, for your own use) and never distribute it to anyone, the copyleft obligations do not trigger. This is why some companies historically used GPL-licensed components in SaaS products without distributing the software — the so-called SaaS loophole.

But if you distribute GPL-licensed code — as a downloadable binary, a Docker image, an SDK, or even a compiled application — you must make the complete corresponding source code available under the GPL, including any modifications you made.

The Derivative Works Problem

The real trap is not distributing GPL code itself. It is what happens when GPL code becomes part of a derivative work. Under Section 0 of the GPL, a covered work includes a work based on the Program — meaning any work that is derived from or based on GPL-licensed code in a way that requires copyright permission. If your proprietary code is so tightly integrated with GPL-licensed code that it constitutes a single derivative work, then distributing that combined work triggers the obligation to distribute your source code under the GPL as well.

Whether linking, static or dynamic, creates a derivative work under the GPL is one of the most contested questions in open-source law. The FSF GPL FAQ takes the position that dynamic linking of a GPL-licensed library into your application creates a derivative work. Not everyone agrees, but the FSF interpretation matters because they are the license steward, and many courts would look to their guidance.

The practical takeaway: if your product contains GPL-licensed code that is linked into your application, you should assume that distributing the application triggers a copyleft obligation over your entire combined work. The safe path is either (a) avoid GPL-licensed dependencies in anything you distribute, (b) isolate GPL components behind a process boundary (e.g., running as a separate command-line tool invoked via subprocess, not linked into your binary), or (c) accept the copyleft obligation and plan to distribute your source code accordingly.

AGPL: The Most Dangerous License for SaaS Startups

The GNU Affero General Public License (AGPLv3) is GPL v3 with one additional clause — Section 13 — that closes the SaaS loophole. As explained by Red Hat open source legal counsel, Section 13 states that if you modify the AGPL-licensed program, your modified version must prominently offer all users interacting with it remotely through a computer network the opportunity to receive the corresponding source code.

In other words: if you modify AGPL-licensed code and let users interact with it over a network — which is exactly what a SaaS product does — you must offer those users the complete source code of your modified version, including all your proprietary modifications, under the AGPL.

There is debate about whether Section 13 triggers only when you modify the AGPL code itself, or whether incorporating an unmodified AGPL library into your larger application triggers it. The conservative reading — and the one we recommend founders adopt — is that any meaningful integration of AGPL-licensed code into your SaaS product creates a source-disclosure obligation over your entire combined work. The risk of getting this wrong is catastrophic: you could be forced to open-source the proprietary core of your product.

Our guidance to SaaS founders is straightforward: do not use AGPL-licensed dependencies in your product code. Period. If a library you want is AGPL-licensed, look for a permissive alternative or negotiate a commercial license directly with the copyright holder. Many AGPL projects offer dual licensing — a free AGPL version and a paid commercial license that does not carry the copyleft obligation. The commercial license is almost always cheaper than the alternative of being forced to open-source your product.

How to Run a Software Composition Analysis

Manual review of every dependency is not feasible for any modern software project. Your application likely has hundreds of transitive dependencies, and you cannot rely on developers remembering to check every package license. You need an automated software composition analysis (SCA) tool.

SCA tools — including Black Duck SCA, Snyk, and FOSSA — scan your codebase, identify all open-source components (including transitive dependencies), and map each component to its license. They generate a software bill of materials (SBOM) that lists every open-source package, its version, its license, and any known vulnerabilities.

Here is the minimum compliance workflow we recommend:

1. Integrate SCA into CI/CD. Run a license scan on every build. Fail the build if a new dependency introduces a GPL or AGPL license without an approved exception.
2. Maintain an allowlist. Define which licenses are pre-approved (typically MIT, BSD, Apache 2.0, ISC) and which require legal review (GPL, AGPL, LGPL, and any custom or non-OSI license).
3. Generate and preserve attribution files. Use your SCA tool to produce a THIRD_PARTY_LICENSES or NOTICE file that collects all required copyright and license notices. Include this file in your distributed product.
4. Document exceptions. If you decide to use a GPL-licensed component (e.g., a command-line tool invoked via subprocess), document the architectural isolation decision and the legal rationale in your compliance records.

Run this audit before you ship your first product, before you raise your Series A, and before any acquisition diligence. The cost of running SCA tools is trivial compared to the cost of discovering a GPL contamination issue three days before a deal closes.

Open-Weight AI Models: A Different License Universe

AI startups building on open-weight models like Meta Llama face a licensing landscape that looks superficially like open source but operates under fundamentally different rules. The Llama Community License Agreement is not an OSI-approved open-source license — it is a proprietary license with a grant that resembles open source but carries restrictions that the OSI Open Source Definition prohibits.

Key differences founders must understand:

• Acceptable use policy flow-downs. Llama license requires adherence to Meta Acceptable Use Policy, which prohibits certain use cases (illegal activities, weapons development, etc.). If you build a product on Llama, your downstream users may also be bound by these restrictions. Your product terms of service need to flow these obligations through to your users.
• Commercial thresholds. Some open-weight model licenses include commercial use restrictions that trigger above a monthly active user threshold (Llama 3 license, for example, requires requesting a commercial license if you exceed 700 million monthly active users). Most startups will not hit this threshold, but the restriction itself means the license is not open source in the OSI sense.
• No redistribution rights equivalent to GPL. Unlike GPL-licensed software, open-weight model licenses often restrict how you can redistribute the model weights or derived models, and may require you to include specific attribution or accept terms flow-down to your users.

If your AI product uses open-weight models, your license audit must cover the model license separately from your traditional OSS license review. The model license may impose obligations on your product that no permissive software license would. This is also an area where AI product liability insurance and compliance frameworks intersect — your SCA scan will not catch model license terms, so you need a separate review process for any open-weight or open-source model you embed in your product.

What to Audit Before Shipping or Raising

Whether you are preparing for launch or entering a financing round, here is the compliance checklist we run with every startup client:

1. Run a full SCA scan. Generate an SBOM. Review every component for GPL, AGPL, LGPL, and any non-OSI or custom license. This is also a TRAIGA compliance best practice for AI startups documenting their technology stack.
2. Flag and remediate copyleft dependencies. For any GPL or AGPL component, either remove it, isolate it architecturally, or obtain a commercial license. Document every decision.
3. Verify attribution compliance. Confirm that all MIT, BSD, and Apache 2.0 components copyright and license notices are preserved in your distributed product.
4. Review open-weight model licenses separately. If your product uses models like Llama, Mistral, or Gemma, confirm you comply with each model specific license terms — including AUP flow-downs and commercial use thresholds.
5. Update your developer onboarding. Add a step to your engineering onboarding that requires developers to check the license of any new dependency before merging it. Configure your package manager or SCA tool to block GPL/AGPL dependencies by default.
6. Prepare your diligence response. Compile your SBOM, your license inventory, your exception documentation, and your SCA tool configuration into a single compliance package you can hand to investors or acquirers.

Actionable Next Steps

Open-source license compliance is not a one-time exercise — it is a continuous discipline that should be baked into your development process from day one. The founders who sail through diligence are the ones who set up SCA tooling early, made explicit decisions about every copyleft dependency, and maintained documentation that proves their compliance posture.

If you have not yet run a license audit on your codebase, do it now — before your next build, before your next investor meeting, and before anyone asks. If you find GPL or AGPL components in your stack and are not sure how to remediate them, we can help you evaluate your options, negotiate commercial licenses, and build a compliance framework that scales with your company. The cost of a proactive audit is a fraction of the cost of a contamination finding in the middle of a financing round or acquisition.