What Founders Need to Know About Open Source Software Licensing

Open source software licensing determines what obligations your startup assumes when it incorporates third-party code into its products. Permissive licenses (MIT, Apache 2.0, BSD) impose minimal restrictions and are generally safe for commercial use. Copyleft licenses (GPL, AGPL, LGPL) can require you to release your proprietary source code under the same license — a potentially catastrophic outcome for a startup whose value is built on proprietary technology.

---

The License Spectrum

Understanding open source licenses requires thinking in terms of a spectrum from fully permissive to strongly copyleft. Where a license falls on this spectrum determines what you can and cannot do with the code.

Permissive Licenses

Permissive licenses allow you to use, modify, and distribute open source code — including in proprietary, closed-source products — with minimal obligations. The primary requirements are attribution (keeping the copyright notice) and, in some cases, a patent grant or liability disclaimer.

MIT License. The most commonly used open source license. Requires only that you include the copyright notice and license text in any distribution. You can use MIT-licensed code in proprietary software, modify it without releasing changes, and sublicense it. There are essentially no "gotchas."

Apache License 2.0. Similar permissiveness to MIT but adds an explicit patent license — contributors grant users a royalty-free patent license to any patents embodied in their contributions. Apache 2.0 also includes a patent retaliation clause: if you sue someone for patent infringement related to the licensed work, your patent license terminates. This makes Apache 2.0 slightly more protective than MIT for users.

BSD Licenses (2-clause and 3-clause). Functionally similar to MIT. The 3-clause version adds a restriction against using the project's name for endorsement. BSD 2-clause is essentially identical to MIT in practice.

Bottom line: If your dependencies are MIT, Apache 2.0, or BSD licensed, you're in good shape for commercial use. These are "safe harbor" licenses.

Weak Copyleft Licenses

LGPL (Lesser General Public License). The LGPL occupies a middle ground. If you dynamically link to an LGPL library (using it as a shared library without modification), you can keep your own code proprietary. If you statically link to or modify the LGPL code itself, the copyleft provisions trigger, requiring you to release those modifications under the LGPL.

The dynamic vs. static linking distinction creates practical challenges. In compiled languages (C, C++, Rust), the distinction is relatively clear. In interpreted languages (Python, JavaScript) and modern application architectures, the boundaries are murkier, and legal opinions vary.

MPL 2.0 (Mozilla Public License). File-level copyleft. Modifications to MPL-licensed files must be released under the MPL, but you can combine MPL files with proprietary files in the same project without the copyleft extending to your proprietary code. This is the most startup-friendly of the copyleft licenses.

Strong Copyleft Licenses

GPL v2 and v3 (General Public License). The GPL requires that any "derivative work" that incorporates GPL-licensed code must itself be distributed under the GPL, with full source code available. This is the "viral" or "copyleft" effect — the license propagates to your code.

What constitutes a "derivative work" under the GPL is the central legal question and has never been definitively resolved by courts. The Free Software Foundation takes a broad view: any software that links to GPL code (dynamically or statically) is a derivative work. Others argue that mere aggregation or runtime linking doesn't create a derivative work. This legal uncertainty itself is a risk factor.

Key nuance: The GPL's copyleft only triggers on "distribution." If you use GPL code internally (on your servers, for internal tools) but never distribute the software to users, the copyleft doesn't apply. This is why many SaaS companies have historically used GPL libraries on their backend without releasing source code — they're providing a service, not distributing software.

AGPL v3 (Affero General Public License). The AGPL closes the SaaS loophole. It extends the GPL's copyleft to software accessed over a network. If your SaaS product incorporates AGPL code and users interact with it over the internet, you must make the complete source code of the application available to those users under the AGPL.

AGPL is the most dangerous license for startups. A single AGPL dependency in your SaaS backend can theoretically require you to open source your entire application. This is why AGPL triggers immediate flags in investor due diligence.

License Compliance in Due Diligence

Investors and acquirers scrutinize open source license compliance during IP due diligence. This is not a theoretical concern — it's a standard checklist item that can delay or kill deals.

What Investors Look For

1. AGPL and GPL dependencies in proprietary code. Any strong copyleft dependency is a red flag that requires detailed analysis of how the code is used, whether the copyleft is triggered, and what remediation options exist.

2. License inventory completeness. Does the company actually know what open source it's using? Many startups have no systematic tracking. Investors expect at minimum a dependency list with associated licenses.

3. IP assignment and CIIA coverage. Are all contributors (employees and contractors) bound by agreements that assign IP to the company and require compliance with the company's open source policy?

4. Outbound open source contributions. Has the company released any proprietary code under an open source license? Was this intentional and properly authorized?

5. License compatibility. Some licenses are incompatible with each other. Combining Apache 2.0 code with GPLv2 code, for example, creates a conflict because the Apache 2.0 patent retaliation clause is an "additional restriction" that GPLv2 doesn't permit.

Common Violations Found in Diligence

• AGPL database drivers or libraries embedded in the application backend (e.g., MongoDB's server-side public license before they switched to SSPL, certain graph database clients)
• GPL-licensed fonts, icons, or CSS frameworks included in the application UI
• Copy-pasted code from GPL-licensed projects (even a few lines can theoretically trigger copyleft)
• Missing attribution notices for permissive licenses (technically a license violation, though rarely enforced)
• Unlicensed code — code from repositories with no license file, which defaults to "all rights reserved" under copyright law (meaning you have no right to use it)

Software Bill of Materials (SBOM)

SBOMs are becoming a standard requirement in both regulatory and investor contexts. An SBOM is a comprehensive inventory of all software components (including open source dependencies) in a product, along with their versions, licenses, and known vulnerabilities.

Why SBOMs Matter

Regulatory pressure. Executive Order 14028 (May 2021) requires SBOM documentation for software sold to the U.S. federal government. While this doesn't directly apply to most startups, it's establishing an industry standard that cascades to enterprise customers and investors.

Supply chain security. High-profile supply chain attacks (SolarWinds, Log4j) have made SBOM generation a security best practice. Enterprise customers increasingly require SBOMs as part of vendor security assessments.

Due diligence efficiency. Companies with maintained SBOMs can respond to license compliance questions quickly during fundraising. Those without SBOMs face expensive and time-consuming audits.

Generating SBOMs

Tools for SBOM generation include:

• Package manager exports: npm list, pip freeze, go mod graph, cargo tree — these provide dependency lists but not full SBOM format
• Dedicated SBOM tools: Syft, CycloneDX, SPDX tools — these generate standardized SBOM documents
• Commercial platforms: FOSSA, Snyk, Black Duck (Synopsys), WhiteSource (Mend) — these provide continuous scanning, license identification, and vulnerability tracking

For most startups, integrating a tool like FOSSA or Snyk into the CI/CD pipeline provides automated SBOM generation and license compliance checking with minimal engineering overhead.

Dual Licensing Strategies

Some startups release their core technology as open source while maintaining a proprietary commercial offering. This "dual licensing" or "open core" model requires careful license selection:

Community License (Copyleft)

Release the open source version under AGPL or GPL. This allows community use and contribution but forces any commercial competitor who wants to embed your code to either comply with copyleft (releasing their source code) or purchase a commercial license.

Commercial License

Offer a separate proprietary license that permits commercial use without copyleft obligations. Revenue comes from companies that want to use your technology in proprietary products.

Requirements for Dual Licensing

• The company must own all copyright in the codebase. This means all contributors must sign CLAs (Contributor License Agreements) assigning or licensing their contributions to the company.
• IP assignment agreements must be airtight for all employees and contractors.
• Community contributions complicate ownership. Each external contributor must sign a CLA, and managing this at scale requires tooling (CLA Assistant, DCO bots).

Notable examples: MySQL (GPL + commercial), MongoDB (SSPL + commercial), Elasticsearch (SSPL + commercial, now AGPL), GitLab (MIT for CE, proprietary for EE).

Practical Open Source Policy for Engineering Teams

Every startup that writes software should have a written open source policy. This doesn't need to be a 50-page document — a clear one-page policy covers 90% of scenarios.

Inbound Policy (Using Open Source)

Approved licenses (no review needed):

• MIT, Apache 2.0, BSD 2-clause, BSD 3-clause, ISC, Unlicense, CC0

Requires legal/CTO review:

• LGPL, MPL 2.0, EPL (Eclipse Public License)
• Any license not on the approved or prohibited list

Prohibited (never use without explicit approval):

• GPL v2/v3 in any code that ships to customers or is linked with proprietary code
• AGPL in any context (backend, frontend, tooling that touches production code)
• SSPL (Server Side Public License)
• Creative Commons licenses with NonCommercial or ShareAlike clauses on code

Process:

1. Before adding any new dependency, check its license (it's in the package.json, LICENSE file, or repository metadata)
2. If approved, proceed
3. If requires review, create a ticket and wait for approval
4. If prohibited, find an alternative with an approved license

Outbound Policy (Contributing to or Releasing Open Source)

• All contributions to external open source projects require CTO/legal approval
• No proprietary code, trade secrets, or customer data may be included in open source contributions
• Contributions must be made under the company's name (not personal accounts) for code developed on company time
• Releasing company code as open source requires CEO approval and license selection by counsel

Remediation Strategies

When diligence reveals open source compliance issues, the path forward depends on the severity:

Replace the Dependency

The cleanest fix. Find an alternative library with a permissive license that provides equivalent functionality. This is often possible — most GPL-licensed libraries have MIT/Apache-licensed alternatives.

Timeline: Days to weeks depending on how deeply integrated the dependency is.

Isolate the Component

If replacement isn't feasible, architectural isolation may resolve the copyleft concern. Running the GPL component as a separate process that communicates with your application via API, network protocol, or inter-process communication may avoid creating a "derivative work." This approach has legal support but is not guaranteed.

Timeline: Weeks to months depending on architectural changes required.

Obtain a Commercial License

Many copyleft projects offer dual licensing. Contact the copyright holder and purchase a commercial license that permits proprietary use. This is often the fastest resolution for dependencies on commercially-maintained open source projects.

Timeline: Days to weeks, depending on negotiation.

Accept and Disclose

In rare cases — particularly for internal tools or non-core components — the company may decide to comply with the copyleft license by releasing the affected portion of code. This only works if the copyleft code is truly isolated and the released code doesn't contain trade secrets or competitive advantages.

Retroactive Compliance

For permissive license violations (missing attribution), the fix is straightforward: add the required notices. Include a NOTICES or THIRD-PARTY-LICENSES file in your distribution that lists all open source components and their license texts.

Building a Compliance Culture

The most effective open source compliance isn't a one-time audit — it's an ongoing practice integrated into the engineering workflow:

1. Automated scanning in CI/CD. Tools like FOSSA, Snyk, or even license-checker (npm) flag problematic licenses before code merges.
2. Developer education. Engineers should understand the basics: permissive = generally fine, copyleft = ask first, no license = don't use it.
3. Regular audits. Quarterly or semi-annual review of the full dependency tree, especially after major feature development that may have introduced new dependencies.
4. Documented decisions. When a review approves a borderline dependency, document why and under what conditions it's acceptable.

Investors increasingly view open source hygiene as a proxy for overall engineering and legal maturity. A startup that can produce a clean SBOM, point to a written open source policy, and demonstrate automated license scanning signals that it takes IP protection seriously — which translates directly to confidence in the company's enterprise readiness and acquisition attractiveness.