Open Source License Compliance for Startups: What GPL, AGPL, and MIT Actually Require

Nearly every startup in Texas — and everywhere else — builds on open-source software. Your frontend runs on React. Your backend uses Node.js or Python. Your database is PostgreSQL. Your CI pipeline runs on Jenkins or GitHub Actions. The vast majority of your codebase's dependencies are open-source, and that is a good thing: open-source software dramatically reduces development cost, accelerates time-to-market, and connects you to communities of maintainers who fix bugs and patch vulnerabilities faster than any single company could.

But open source does not mean "no rules." Every open-source dependency carries a license, and that license imposes obligations — attribution requirements, copyleft triggers, patent restrictions, and compatibility constraints that can determine whether you can keep your code proprietary, whether you must publish your source, and whether an investor's automated scan will flag your codebase as a deal risk before your Series A closes.

We have helped Texas founders navigate the intersection of software licensing, IP ownership, and investor diligence across a range of issues — from TRAIGA compliance for AI startups to AI product liability and insurance gaps. Open-source license compliance is the layer underneath all of it: if you do not understand the licenses in your dependency tree, your IP foundation is built on someone else's terms — and you may not know what those terms are until an investor's scanner tells you.

This guide covers what every founder needs to understand: the copyleft vs. permissive distinction, why AGPL is the "toxic" license for SaaS, license compatibility problems, attribution and notice file requirements, and the SBOM and open-source audit that investors now expect during due diligence.

Copyleft vs. Permissive: The Core Distinction

Open-source licenses fall into two broad categories, and understanding the difference is the single most important thing a founder can do to manage open-source license compliance.

Permissive licenses — MIT, Apache 2.0, BSD (2-clause and 3-clause), and ISC — let you use, modify, and distribute the software with minimal restrictions. You can include MIT-licensed code in a proprietary, closed-source product. You generally need to provide attribution (keep the copyright notice and license text), but you are not required to open-source your own code. The Open Source Initiative's license list categorizes these as "Popular / Strong Community" licenses, and they are the most widely used licenses in commercial software development.

Copyleft licenses — the GNU General Public License (GPL v2 and v3), the GNU Affero General Public License (AGPL v3), and the GNU Lesser General Public License (LGPL) — carry a reciprocal obligation. If you distribute software that incorporates GPL-licensed code, you must distribute your own source code under the same GPL terms. The copyleft is "viral" in the sense that it propagates: the GPL's terms extend to derivative works, which means your proprietary code can become subject to GPL disclosure obligations if you are not careful about how you integrate GPL-licensed components.

GitHub's Choose a License tool distills this distinction simply: MIT "lets people do almost anything they want with your project, including making and distributing closed source versions," while GPLv3 "also lets people do almost anything they want with your project, except distributing closed source versions." That one sentence captures the entire economic stakes of the copyleft vs. permissive decision.

Permissive Licenses: MIT, Apache 2.0, and BSD

MIT is the most permissive widely used license. It requires you to include the copyright notice and license text in any copy or substantial portion of the software. That is essentially the entire obligation. There is no patent provision, no copyleft, no requirement to share modifications. MIT-licensed dependencies are safe to use in proprietary software without triggering disclosure obligations.

Apache 2.0 adds one important feature that MIT lacks: an explicit patent grant. The Apache license grants users a license to any patents held by the contributor that are necessary to use the software. It also includes a defensive patent termination clause — if a licensee initiates patent litigation against a contributor, the patent license terminates. For startups, this means Apache 2.0-licensed dependencies are generally safe to use in proprietary software, and the patent grant provides additional protection against patent trolls who might claim that the open-source software infringes their patents.

BSD (both 2-clause and 3-clause) is functionally similar to MIT. The 3-clause BSD adds a prohibition against using the contributor's name for endorsement without permission. None of these licenses impose copyleft obligations.

Copyleft Licenses: GPL, LGPL, and AGPL

The GPL comes in two current versions: GPLv2 and GPLv3. Both require that if you distribute software that incorporates GPL-licensed code, you must make your source code available under the same GPL license. The key word is "distribute" — and this is where the analysis gets nuanced for SaaS startups.

Under GPL v2, "distribution" means conveying the software to a third party. If you run GPL-licensed software on your servers and users interact with it over a network (SaaS), you are generally not "distributing" the software to them — and the GPL's copyleft does not trigger. This is known as the "application service provider loophole," and it was the reason the Free Software Foundation created the AGPL.

LGPL is a weaker copyleft designed for libraries. It allows you to link to LGPL-licensed libraries from proprietary software without triggering the full GPL copyleft, as long as you allow users to replace the LGPL-licensed library with a modified version. LGPL is less dangerous than GPL for SaaS startups, but it still imposes notice requirements and some source-disclosure obligations for modifications to the library itself.

Why AGPL Is the "Toxic" License for SaaS Startups

The AGPL closes the SaaS loophole. Under AGPL v3, if you modify the software and make it available for use over a network — even without distributing binary copies — you must offer the source code of your modified version to every user who interacts with it over the network. For a SaaS startup, this means that incorporating AGPL-licensed code into your product can force you to open-source your proprietary modifications — the very code that constitutes your competitive advantage.

This is why AGPL is widely described as "toxic" in the venture capital and startup ecosystem. Many VC firms and acquirers treat AGPL-licensed dependencies as deal-killers. The risk is not theoretical: if your SaaS product incorporates an AGPL-licensed component and you have made modifications, the AGPL's network-use provision can require you to publish your entire modified source code — not just the component, but potentially your proprietary application code that integrates with it, depending on how the AGPL's derivative-work analysis applies to your architecture.

The practical guidance for founders is straightforward: audit your dependencies for AGPL-licensed components before they enter your codebase. If you find AGPL-licensed dependencies, evaluate whether they can be replaced with permissively licensed alternatives. If they cannot, you need to assess whether your use triggers the AGPL's network-use disclosure obligation — and that assessment requires legal counsel, not a developer's intuition.

Some major open-source projects have adopted AGPL or AGPL-equivalent licenses specifically to require SaaS companies to either open-source their modifications or purchase a commercial license. MongoDB, Elastic, and Redis have all moved to non-OSI-approved licenses (the Server Side Public License, or variants) that function similarly to AGPL for cloud and SaaS use cases. These licenses are sometimes referred to as "source-available" rather than "open source" because they do not meet the OSI's Open Source Definition — but the practical compliance risk for startups is the same: using these components in your SaaS product without a commercial license can trigger disclosure obligations that destroy your IP moat.

License Compatibility: When Mixing Licenses Breaks Things

License compatibility is the question of whether you can legally combine code under two different licenses into a single work. Not all open-source licenses are compatible with each other, and the incompatibilities are not always intuitive.

The most important compatibility rule: GPL and proprietary licenses are compatible only if the GPL's copyleft terms are satisfied. You cannot incorporate GPL-licensed code into a proprietary application and keep the application proprietary. The GPL's terms override. Similarly, you cannot combine GPLv2-licensed code with GPLv3-licensed code in a single work, because GPLv2 (in its plain version, without the "or later" clause) is not compatible with GPLv3.

Permissive licenses are generally compatible with everything. You can incorporate MIT-licensed code into a GPL-licensed project, an Apache-licensed project, or a proprietary project. The MIT license's minimal requirements (attribution) are satisfied by any downstream license.

Apache 2.0 and GPLv2 present a specific compatibility problem: GPLv2 does not include an explicit patent grant, and the Apache 2.0 patent termination clause was viewed by the Free Software Foundation as incompatible with GPLv2. This was resolved in GPLv3, which explicitly accepts Apache 2.0 as a compatible license. But if you are working with a GPLv2-only project, incorporating Apache 2.0 code may create a licensing conflict.

For founders, the practical implication is that your dependency tree's license mix matters. If your application uses a GPLv3-licensed library that transitively depends on a GPLv2-only library, you may have an incompatibility that prevents you from distributing the combined work at all. Automated license scanning tools (which we discuss below) can identify these transitive conflicts before they become legal problems.

Attribution and Notice File Requirements

Even permissive licenses carry obligations, and the most commonly overlooked one is attribution. MIT, BSD, and Apache 2.0 all require you to retain and reproduce copyright notices and license text when you distribute software that includes their licensed components. For a startup distributing a web application, this is generally satisfied by including a NOTICE file or an "Open Source Licenses" page in your application that lists every open-source dependency and its license.

The requirement is not cosmetic. Failing to provide attribution is a license violation, and some open-source copyright holders have pursued enforcement actions — including litigation — against companies that failed to comply with attribution requirements. The risk is low for early-stage startups, but it escalates as you grow, ship more products, and attract more scrutiny.

For Apache 2.0 specifically, the NOTICE file requirement goes beyond the standard copyright notice. Section 4(d) of the Apache 2.0 license requires that you include a readable copy of the NOTICE file (if the original work has one) in your distribution, and that any modifications to the NOTICE file are clearly marked. Many Apache-licensed projects include a NOTICE file with additional attribution text that must be carried forward.

The practical checklist for attribution compliance:

• Maintain a dependency inventory. List every open-source dependency in your project, including transitive dependencies. For each, record the license type, copyright holder, and any specific attribution requirements.
• Generate a NOTICE file or open-source attribution page. Include copyright notices, license text, and any additional required attributions (such as Apache NOTICE file contents).
• Update the attribution file when you add dependencies. Make it part of your CI/CD pipeline to flag new dependencies and verify that their licenses have been added to the attribution file.
• Include the attribution file in your distributed software. For web applications, this can be an "About" or "Open Source Licenses" page accessible from the application. For downloadable software, include the file in the distribution package.

Preparing for Investor OSS Due Diligence

Investor due diligence has evolved. Five years ago, open-source compliance was rarely part of the diligence process. Today, it is standard — and increasingly automated. Venture capital firms and acquirers use software composition analysis (SCA) tools like FOSSA and Black Duck to scan codebases for open-source dependencies, identify their licenses, and flag compliance risks before the deal closes.

These tools do not just look at your direct dependencies. They recursively scan your entire dependency tree — including the dependencies of your dependencies — and report every license they find. If a transitive dependency is AGPL-licensed, the scanner will flag it. If two dependencies have incompatible licenses, the scanner will flag that too. If you are missing attribution for a permissive-licensed component, the scanner will note it.

The reason investors run these scans is that open-source license violations can create IP contamination that affects the entire company's value. If your proprietary code incorporates GPL-licensed components and you have been distributing the software without complying with the GPL's source-disclosure requirements, you may have already forfeited your ability to keep that code proprietary — and the investor's acquisition of your company may be acquiring a legal liability, not an asset.

Here is what to prepare before an investor's scanner runs against your codebase:

1. Run Your Own Scan Before the Investor Does

Use an SCA tool — FOSSA, Black Duck, Snyk, or even a free tool like ScanCode — to scan your codebase and generate a full open-source dependency report. The report should list every dependency, its license, and any compliance flags. This is your opportunity to find and fix problems before they appear in an investor's diligence report.

2. Build a Software Bill of Materials (SBOM)

A Software Bill of Materials is a formal, machine-readable inventory of every component in your software — including open-source dependencies, their versions, their licenses, and their transitive relationships. CISA, the federal agency responsible for cybersecurity and infrastructure security, published its 2025 Minimum Elements for an SBOM in August 2025, building on the 2021 NTIA minimum elements and reflecting the growing adoption of SBOMs across both public and private sectors.

For startups, an SBOM serves two purposes. First, it is a compliance artifact: you can hand it to investors during diligence and demonstrate that you have already inventoried your open-source dependencies and assessed their license compliance. Second, it is a security artifact: the SBOM allows you to quickly identify whether any of your dependencies have known vulnerabilities (CVEs), which is increasingly part of investor diligence as well.

3. Remediate Flagged Issues

If your scan flags AGPL-licensed dependencies, evaluate whether they can be replaced with permissively licensed alternatives. If your scan flags GPL-licensed dependencies that are incorporated into your proprietary application in a way that triggers copyleft, assess whether you can restructure the integration (for example, by running the GPL-licensed component as a separate process rather than linking it into your proprietary code). If your scan flags missing attribution, fix it.

4. Document Your Open-Source Policy

Investors want to see not just that your current codebase is compliant, but that you have a process for keeping it compliant as you grow. A written open-source policy should define: which licenses are approved for use in your codebase, which require legal review before adoption, which are prohibited (typically AGPL and non-OSI source-available licenses), who is responsible for reviewing new dependencies, and how the policy is enforced (for example, through pre-commit hooks or CI/CD checks that block unapproved licenses).

This is analogous to the compliance documentation we recommend for other regulatory frameworks. Just as our guide to Texas startup legal fundamentals emphasizes building compliance infrastructure early, open-source compliance should be built into your engineering workflow before an investor asks for it — not after.

Actionable Next Steps

1. Audit your dependency tree today. Run an SCA tool against your codebase and generate a complete list of every open-source dependency — direct and transitive — along with its license. If you do not know what licenses are in your codebase, you cannot assess your compliance risk. This is the foundational step for everything else.
2. Flag every copyleft and AGPL dependency. For each GPL or AGPL-licensed dependency, evaluate whether your use triggers copyleft obligations (for GPL) or network-use disclosure obligations (for AGPL). If AGPL-licensed components are present, prioritize replacing them with permissively licensed alternatives or obtaining commercial licenses.
3. Generate or update your NOTICE file. Ensure every open-source dependency's copyright notice and license text is included in your attribution file. For Apache 2.0 dependencies, include the contents of any NOTICE files. Make this a maintained document, not a one-time export.
4. Build an SBOM. Use your SCA tool to generate a machine-readable SBOM (SPDX or CycloneDX format are the standards). Store it in your repository and update it as part of your CI/CD pipeline. This artifact doubles as a compliance document for investors and a security tool for vulnerability tracking.
5. Adopt a written open-source license policy. Define which licenses are approved, which require legal review, and which are prohibited. Assign ownership for reviewing new dependencies. Enforce the policy through CI/CD checks that block unapproved licenses from entering the codebase.
6. Check license compatibility in your dependency tree. If your application mixes GPL and proprietary code, or GPLv2-only and Apache 2.0 code, you may have incompatibilities that prevent distribution. Your SCA tool should flag these; if it does not, have counsel review the license mix.
7. Prepare a diligence-ready open-source compliance package. Before an investor's scanner runs against your codebase, have your SBOM, license inventory, NOTICE file, open-source policy, and remediation log ready to share. Being able to hand over a complete compliance package signals operational maturity — and prevents the investor's scanner from being the first time you learn about a license problem.
8. Get legal review of flagged issues before they become deal-blockers. If your scan flags AGPL contamination, GPL copyleft triggers, or license incompatibilities, engage counsel before the investor does. The cost of pre-diligence remediation is a fraction of the cost of a deal that stalls or collapses because of open-source license risk — and a fraction of the cost of retroactively unwinding a license violation that has already contaminated your proprietary code.

Open-source software is the foundation of nearly every startup's technology stack. Using it wisely means understanding the licenses that govern it — not just the permissive ones that let you build freely, but the copyleft and network-use licenses that can constrain your ability to keep your code proprietary. The founders who audit their dependency trees, build SBOMs, remediate license risks, and document their compliance posture before an investor asks will close their rounds faster, on better terms, and without the surprise of a scanner flag that turns a funding milestone into a legal fire drill.