October 13, 2026
Open source software is code anyone can use, modify and share under a public license, and almost every startup product is built on it. It is safe to use as long as you know what you are using and what each license asks of you. Permissive licenses ask for little more than attribution, while copyleft licenses can require you to publish your own source code, so the legal risk is not open source itself but not knowing which open source is in your product.
Key takeaways
Code is protected by copyright the moment it is written, so nobody can copy or change it without permission. An open source license is the author’s public grant of that permission. Anyone can view, use, modify and redistribute the code, as long as they follow the license’s conditions. If you ignore the conditions, you lose the permission, and your use becomes copyright infringement.
Licenses fall into two broad families. Permissive licenses let you do almost anything with the code, including putting it in a closed, proprietary product. Copyleft licenses let you do the same, but require that anything you distribute that is based on the code be shared under the same license, with source code available. For a longer tour of individual licenses, see What Are the Most Common Open Source Licenses for Startups?
The difference is what you owe back. With a permissive license, you owe attribution: keep the copyright notice and license text in your code and, for distributed products, in your notices file. The Apache 2.0 license also includes an express patent license from contributors and asks you to mark files you changed.
Copyleft comes in two strengths. Weak copyleft licenses, such as the LGPL and the Mozilla Public License, require you to share changes you make to the licensed component itself, but generally let you combine it with proprietary code without opening up the rest of your product. Strong copyleft licenses, such as the GPL, require that a work based on the GPL code be distributed under the GPL. How far that reaches is genuinely contested. The Free Software Foundation’s view is that linking a program to a GPL library usually creates a combined work, while many lawyers argue it depends on how tightly the code is combined. Because the answer depends on the facts, treat any GPL code that sits inside your product as something to review before you ship.
The obligations are triggered by distribution. If you ship software to customers (a mobile app, a desktop app, an on-premise install, firmware in a device), you are distributing it. If you only run the code on your own servers, the GPL generally is not triggered. The AGPL is the exception.
| License | Type | Fine in a closed SaaS product? | Main obligation |
|---|---|---|---|
| MIT, BSD, ISC | Permissive | Yes | Keep copyright and license notices |
| Apache 2.0 | Permissive | Yes | Notices, mark changed files, patent terms |
| MPL 2.0 | Weak copyleft (file level) | Usually | Share changes to MPL files if you distribute them |
| LGPL | Weak copyleft (library) | Usually, with review | Share changes to the library; allow relinking if distributed |
| GPL v2 / v3 | Strong copyleft | Usually, if never distributed | Distributed works based on it must be GPL with source |
| AGPL v3 | Network copyleft | Review first | Users over a network can get the source of your modified version |
| BSL, SSPL | Source-available, not open source | Depends on the terms | Commercial or competitive use may be restricted |
The AGPL is the license that catches SaaS companies. It closes the “we don’t distribute, we host” gap: if you modify AGPL code and users interact with it over a network, you must offer those users the source code of the modified program. If your own code is part of that program, it can be pulled in too. Many startups simply don’t use AGPL code in their product. Running an unmodified AGPL tool internally, or as a separate service your product talks to, is a different question that a short review can usually answer.
Some well-known projects have moved away from open source licenses toward “source-available” licenses. You can read the code, but use is restricted, usually to stop cloud providers from offering it as a competing service. The Business Source License (BSL) and the Server Side Public License (SSPL) are the common examples. HashiCorp moved Terraform to the BSL in 2023, which led to the OpenTofu fork. Elastic and Redis moved to source-available licenses and later added the AGPL back as an option.
Two lessons for founders. First, source-available is not open source, so read the actual terms before building on it, particularly if your product could be seen as competing with the licensor. Second, a license applies to a specific version. A dependency you rely on can change its license in its next release, so your inventory should record versions and someone should notice when a key dependency changes terms.
It can. AI coding assistants learn from public code, including GPL code, and occasionally reproduce recognizable snippets. If a copyleft snippet lands in your codebase, it carries its license with it whether or not anyone chose it. Turn on the duplicate-detection or code-referencing filters your tools offer, and run the same license scanning on AI-assisted code that you run on everything else. Ownership of AI-generated code is a separate question: it is a new area of law that is likely to shift. See Who Owns Startup IP?
Yes, with two kinds of homework. The legal homework is license compliance, covered above. The security homework is keeping dependencies patched. Open source code is public, so known vulnerabilities in old versions are easy for attackers to find, and abandoned projects stop getting fixes. Prefer well-maintained projects with an active community, use automated dependency scanning to flag known vulnerabilities, and have a plan for replacing a critical component if its maintainers walk away. For anything mission-critical, paid commercial support can be worth it.
A seed-stage policy fits on one page. It should cover four things:
Name one person who owns the policy, and add a line on contributions: employees should get approval before contributing company code to outside projects, and their CIIAA should make clear the company owns what they write.
Compliance is the policy in practice. For each component, your inventory should record the name and version, the license, where it came from, what it does in your product, how it is integrated (bundled, linked, called as a separate service), whether you modified it, and whether it ships to customers. With that record, the obligations follow: keep notices in place, publish a third-party notices file with anything you distribute, and provide source code where a copyleft license requires it. Review the inventory whenever you add a major dependency and before each financing.
At Series A and in any acquisition, expect an open source questionnaire and often a third-party code scan. They want to see your inventory or SBOM, your policy, any copyleft or AGPL code in the product and how it is used, and any open source you have released yourself. A clean answer is fast. A messy one can delay a closing while engineers rip out and replace components. See Startup Due Diligence.
It can be a good growth strategy, but choose the license on purpose. If you want maximum adoption, a permissive license (MIT or Apache 2.0) removes friction for users. If you want to stop large cloud providers from hosting your project as a competing service, founders tend to choose the AGPL, a source-available license, or an “open core” model with paid features under a commercial license. If outsiders will contribute, use a contributor license agreement so the company keeps the rights it needs to relicense or sell. Investors are comfortable with open source companies, but they will ask how you make money and whether your license choice protects that.
Most problems are fixable. Identify the component, then remove or replace it, isolate it so it runs as a separate program, or comply by releasing the required source. Most enforcement starts as a request to comply, not a lawsuit, and fixing the issue quickly usually ends it. The bigger cost is discovering the problem during diligence, when you have the least time to fix it.
For more on protecting your code, see Copyright Registration for Startups, Startup Licensing Agreement and Startup Intellectual Property. If you’d like help reviewing an open source issue or writing a policy, contact us.
