Open Source Licenses for Startups: A Practical Guide

Open source code comes with a license, and the license sets the rules for using it. Permissive licenses such as MIT and Apache 2.0 mostly ask for credit. Copyleft licenses such as the GPL can require you to share your own source code when you distribute a product that includes theirs. Keep an inventory, check licenses before shipping, and ask counsel about anything borderline.

Startup lifecycle A to Z · Letter O · Stage: Build

By the Revolutionary Startups editors · Reviewed 11 November 2026 · 16 min read · 3,454 words

Why open source licenses matter to a startup

Nearly every modern software product is built on open source. A web app might pull in hundreds of libraries without anyone deciding to, because each library depends on others. That is normal and mostly fine. The catch is that each piece of code arrives with a license, and the license is a legal document that sets conditions on how you may use it.

Most of those conditions are light. Some are not. A few licenses can, in certain situations, require you to make your own source code available to the people who receive your product. For a startup whose main asset is its code, that is a problem worth understanding early, because it is far cheaper to fix while the product is small.

It also matters for money. Investors and acquirers routinely ask what open source is inside the product and under which licenses. A clean, current answer speeds up a deal. A shrug, or a surprise found late, slows it down and can change the price. The self-study IP law course is a good place to learn how licensing fits into copyright law more broadly.

This guide is general education about how open source licenses commonly work in the United States. It is not legal advice, and it does not tell you what any specific license means for your specific product. Licenses are legal texts, and the details matter.

Open source is not the same as free of rules

People often hear "open source" and assume "do whatever you like." That is not how it works. Open source code is still protected by copyright, and the license is the permission slip. If you do not follow the license, you have no permission, and using the code can be copyright infringement. Our guide on copyright for software startups covers why code is protected by default.

The opposite mistake is just as common: code with no license at all. Public code on a hosting site with no license file is generally not free to reuse. Without a license, the default is that the author keeps all rights. If you cannot find a license, treat the code as off limits until you get one or ask the author.

Permissive vs copyleft: the core difference

Open source licenses fall on a spectrum, but two broad families cover most of what you will meet.

Permissive licenses

Permissive licenses let you use, modify and include the code in your own product, including a closed-source commercial one, as long as you meet a short list of conditions. Typically the conditions are keeping the copyright notice and the license text, and sometimes noting your changes. You are not generally required to publish your own code.

The licenses people name most often in this family are MIT, BSD (in several variants) and Apache 2.0. Apache 2.0 is longer and also includes an express patent license from contributors, which some companies like because it reduces uncertainty about patent claims from the code's authors.

Copyleft licenses

Copyleft licenses add a sharing condition. In general terms, if you distribute software that includes or is derived from copyleft code, you may have to offer the corresponding source code of the combined work under the same license. The idea is that freedom to see and change the code should travel with the code.

The GNU General Public License (GPL) is the best-known strong copyleft license. The LGPL is a weaker version designed mainly for libraries, with more room to link to the library from other code. The Mozilla Public License (MPL) is often described as weak copyleft that works at the level of individual files. The AGPL goes further and adds a condition for software that people use over a network, which we cover below.

Side by side

License family	Common examples	What it generally asks of you	Usual startup concern
Permissive	MIT, BSD, Apache 2.0	Keep notices and license text. Apache 2.0 also has a patent grant and asks you to flag changes.	Low. Mainly keeping attribution tidy.
Weak copyleft	LGPL, MPL	Share changes to the licensed files or library itself. Your separate code can often stay closed, depending on how it connects.	Medium. How you link or combine matters.
Strong copyleft	GPL	If you distribute a combined work, offer its source under the same license.	High for distributed products. Needs a decision.
Network copyleft	AGPL	Like the GPL, plus obligations that can apply when users interact with the software over a network.	High for SaaS. Often avoided or handled with counsel.
No license / unclear	Code with no license file	No permission granted. All rights reserved by default.	Do not use until clarified.

Treat this table as orientation, not as a reading of any particular license version. Versions differ, and some projects add their own exceptions or use dual licensing.

MIT vs Apache vs GPL explained in plain words

MIT

MIT is one of the shortest licenses in common use. It lets you do nearly anything with the code, provided you include the original copyright notice and license text. It does not say much about patents. Because it is so short and permissive, it is a common choice for libraries that want wide adoption.

Apache 2.0

Apache 2.0 is also permissive, with more detail. Contributors grant a patent license for their contributions, and the license includes a provision that can end that patent license for someone who sues over patents in the code. It asks you to keep notices and to state significant changes. Many companies are comfortable with it for the patent clarity.

GPL

The GPL is the reason this topic makes founders nervous. It is built so that anyone who passes the software along must pass along the freedoms too. If your product incorporates GPL code and you distribute it, you may need to make the source for the whole combined work available under the GPL. That can clash with a closed-source business model. Whether a given use counts as a combined work is a legal question, not just a technical one, and it is where people disagree.

So, can I use GPL code in a commercial product?

Often yes, but the answer depends on how you use it. Selling a product is not forbidden by the GPL. The issue is what you must do in return. Using a GPL tool on your own computer to build or test your software generally does not make your software GPL. Shipping a GPL library inside the application you give customers is where the sharing obligation can arise. Running GPL software on your own servers and never distributing it is treated differently from handing it to someone else, which brings us to what actually triggers obligations.

What triggers obligations: distribution, linking and network use

Most license conditions only apply when something specific happens. If you know the triggers, you can usually tell which parts of your product to worry about. The list below is a general map, not a ruling on any license.

Distribution

For many copyleft licenses, the main trigger is distribution: giving a copy of the software to someone else. That includes shipping a downloadable app, a desktop installer, a mobile app, firmware on a device, or a container image you hand to a customer to run. If you never give anyone a copy and only run the software yourself, many copyleft obligations are not triggered, though other terms still apply.

Linking and combining

The harder question is how your code connects to the open source code. Calling a separate program from the command line is usually treated differently from compiling a library into your executable. Static linking, dynamic linking, plugins and extensions are all discussed in the open source world, and lawyers and communities do not always agree on the lines. This is exactly the kind of detail to take to counsel rather than settle by guesswork.

Network use and the AGPL

A software-as-a-service (SaaS) product is accessed over the internet. You run the code, and users never receive a copy. Under the GPL, that generally avoids the distribution trigger. The AGPL was written to close that gap: it adds a condition aimed at software people interact with over a network, which can include offering the source of your modified version to those users. That is why many SaaS companies set a rule such as "no AGPL in the core product without review."

The exact reach of that condition is a legal question and depends on the version and the facts. For a startup the practical takeaway is simple: flag any AGPL component early and get advice before building on it.

Other common conditions

Attribution. Keep copyright notices and license texts, often in a NOTICE file or an "open source licenses" screen in your app.
Notice of changes. Some licenses ask you to mark modified files.
Patent terms. Some licenses grant patent rights and may end them if you sue over patents in the code.
Trademark limits. Many licenses do not give you the right to use the project's name or logo.

A worked example

Imagine a three-person startup building a scheduling app. For example, it uses a permissive MIT-licensed date library, an Apache 2.0 web framework, and one small utility library under the GPL that a contractor added to speed up report exports.

The app is a web service. Customers use it in a browser, and the startup never gives them a copy of the server code. The MIT and Apache libraries need attribution, so the team adds them to a notices file. The GPL utility is used only on the server side, so the distribution trigger may not apply, but the team is planning a downloadable desktop companion app that would ship the same utility. That plan is the moment to stop and decide.

The options are the usual ones: replace the GPL library with a permissive alternative, rewrite the small function in-house, buy a commercial license if the author offers one, or accept the GPL terms for that component and structure the product around it. For a small utility, replacing it is often cheapest. For something central to the product, the choice is bigger and counsel should be involved. Notice that the problem was easy to fix because someone noticed before launch.

How to keep an open source inventory

An inventory is a simple list of every open source component in your product, its version, its license, and how it is used. It is the single most useful thing you can have when a diligence reviewer asks, and it is cheap to start.

What to record

Component name and version.
License name and, where it matters, version (for example GPL version 2 versus 3).
Where it came from (the project page or package registry).
How it is used: build tool only, server side, shipped to customers, or modified by you.
Whether you changed it, and where those changes live.
Who approved it and when, if you have an approval step.

How to build it

Start with your package manifests: the files that list dependencies for each language you use. Include the dependencies of those dependencies, often called transitive dependencies.
Run a dependency license scanning tool. Several free and paid tools read manifests or scan code and report license information. Pick one that supports your languages and treat its output as a starting point, since scanners can miss things or misread a license.
Look for code that did not come through a package manager: files copied from tutorials or forums, vendored folders, snippets pasted into the repository, and assets such as fonts and icons.
Flag anything with a copyleft, network copyleft, unknown or missing license for human review.
Save the inventory in your repository or a shared drive, and update it on a schedule, such as before each major release.

Do not forget that AI coding assistants and copied snippets can introduce code whose origin you cannot trace. Some teams keep a short rule about reviewing generated or pasted code of any size, and the course on generative AI and IP law explains the open questions in this area.

Policies, contributors and the rules your team follows

Tools find problems after the fact. A short written policy stops many of them from happening.

An internal open source policy

One page is enough. Common elements are a list of pre-approved licenses (often the permissive ones), a list that needs review (copyleft, network copyleft, unknown), a rule that nobody adds a new dependency with a restricted license without sign-off, and a named person who approves exceptions. Keep it short enough that engineers will actually read it.

When your own team contributes to open source

If employees contribute to other projects, decide ahead of time what is allowed. Contributions made on company time or using company know-how can raise ownership and trade secret questions. Your employee agreements should say who owns work product, and our guides on employee and contractor IP agreements and IP assignment agreements explain the basics. Many projects also ask contributors to accept a contributor license agreement or a sign-off, so check what you are agreeing to on the company's behalf.

When you release your own code as open source

Releasing your own code under an open license is a legitimate strategy, and some companies build their whole business on it. But it is close to irreversible for the version you release, and it can interact with trade secret protection, since published code is no longer secret. Decide on the license deliberately, confirm you own all the code in the release, and remove anything confidential or third-party. Some companies use dual licensing or a source-available license, which is not the same as an open source license in the technical sense, so read the terms carefully. Our licensing basics guide covers the general ideas.

Contractors and freelancers

A contractor can bring open source into your code as easily as an employee. Write into the agreement that they must disclose third-party and open source code they include, and must not add code under restricted licenses without approval.

What due diligence reviewers look for

When a company raises money or is acquired, the other side's lawyers or technical advisers review the code and the paperwork. This is part of the broader process described in protecting IP before fundraising, and it matters again when you sell, as our guide on what happens to IP in a sale or shutdown explains.

Reviewers vary, but the questions are predictable:

Do you have a list of open source components and their licenses?
Is any copyleft or network copyleft code in the product, and how is it used?
Is any code under an unknown, missing or custom license?
Did any code come from a source whose terms were not checked, such as a forum, a gist or a generated snippet?
Do you have a policy, and is there evidence the team follows it?
Have you contributed code to open source projects, or released any of your own, and under what terms?
Do the contributors who wrote your code, employees and contractors alike, have signed agreements assigning their work to the company?

Some buyers run an automated scan of the codebase and compare it to what you told them. If the two differ, trust takes a hit even when the actual risk is small. Running your own scan first, and fixing or documenting what it finds, is the best preparation. That is the idea behind a license audit before an acquisition: find the surprises yourself, on your own timeline. The startup IP audit checklist puts open source inside a wider review.

Mistakes to avoid and a quick checklist

Common mistakes

Assuming that public means free. Code with no license is not free to reuse.
Copying snippets from forums and tutorials without checking their terms.
Adding a dependency because it solves a problem today, without looking at its license.
Treating a scanner report as final. Tools make mistakes and miss non-package code.
Waiting until a financing or sale to look. Fixes are cheaper and faster early.
Reading a license once and assuming every version, or every fork, has the same terms.
Deciding alone that a borderline use is fine. Linking and network questions deserve legal input.

A one-page checklist

List every open source component, version and license.
Mark each as permissive, weak copyleft, strong copyleft, network copyleft or unknown.
For each copyleft item, note whether you distribute it and how it connects to your code.
Keep required notices and license texts with the product.
Write a one-page policy and name an approver.
Add a license check to your build or pull request process.
Update the inventory before each release and before any fundraising or sale.
Take anything borderline to a lawyer experienced in software licensing.

Counsel is worth the cost when you plan to ship copyleft code, when a core component is under an AGPL or custom license, when you are about to raise or sell, or when you intend to release your own code. See how to find an IP attorney for your startup for how to choose one.

Where this fits in the startup lifecycle

Open source is a Build stage topic. You make most of your dependency choices while writing the first version, so that is the cheapest moment to set a policy. Before it, the trade secrets and NDAs guide covers keeping unreleased code confidential, and NDAs for startups covers when to sign one. After it comes the patent process for startups, for the parts of your product that may be patentable, and later the IP audit checklist, which is where you check that all of this is in order before investors look.

The whole sequence is laid out in the startup lifecycle A to Z. If you are shipping a service to customers, the terms of service and privacy policy guide covers the customer-facing side of the same product.

Frequently asked questions

What is the difference between permissive and copyleft licenses?

Permissive licenses such as MIT and Apache 2.0 let you include the code in closed-source products, mostly asking you to keep notices. Copyleft licenses such as the GPL can require you to offer source code under the same license when you distribute a product that includes or builds on the code. The exact reach depends on the license and how you use it.

Can I use GPL code in a commercial product?

Often yes, but with conditions. The GPL does not ban selling software. It generally requires you to offer source code for the combined work if you distribute it. Using GPL tools internally is treated differently. Whether your design triggers the obligation is a legal question, so ask a software licensing lawyer before shipping.

Is the AGPL a problem for SaaS companies?

It can be. The AGPL adds conditions for software that users interact with over a network, which can reach SaaS products that the ordinary GPL would not. Many startups avoid AGPL components in their core product or review them with counsel first. The details depend on the version and the facts.

What is dependency license scanning?

It is the use of a tool that reads your dependency files or code and reports the license of each open source component. It helps you build an inventory and spot copyleft or unknown licenses. Scanners can miss pasted code or misread unusual licenses, so a person should review the flagged items.

Will investors ask about my open source use?

Commonly, yes. Reviewers often ask for a list of open source components and licenses, whether any copyleft code is included, and whether contributors signed assignment agreements. Having a current inventory and a short policy ready makes the review quicker and avoids late surprises.

Is code without a license free to use?

Generally no. Code with no license is protected by copyright and the author keeps all rights by default. Being public does not grant permission. Ask the author to add a license, find an alternative, or avoid using it in your product.

Do I need a lawyer for open source compliance?

Not for routine permissive use, where an inventory and attribution usually cover it. You should involve a lawyer for copyleft code you plan to distribute, AGPL or custom licenses in core components, releasing your own code, or an upcoming financing or sale.

Key terms on this page

Copyright for Software Startups: What It Covers IP guideCopyright for software explained for founders: what source code protection covers, when to register, work made for hire, and open source basics.
Startup IP Audit Checklist: Find Gaps in 90 Minutes GuidePractical IP audit checklist for startups: inventory names, code, inventions, data, content, agreements and open source, with scoring and a 90 minute workflow.
Employee Invention Assignment Agreements for Startups GuideEmployee invention assignment agreement basics: what employees, contractors and interns sign on day one so your startup owns the IP they create.
IP Licensing for Startups: Key Terms and Deal Checklist GuideIP licensing for startups: licensing out and in, exclusive vs non-exclusive, royalty vs flat fee, field of use, key terms and a deal checklist.
IP Due Diligence for Startups Before Fundraising IP guideIP due diligence for startups: what investors ask about IP, a practical checklist, and why founder IP assignment should come before funding.

Learn more from Wysebridge

Wysebridge owns, operates and sponsors Revolutionary Startups, so these are links to its own free resources and directories. Read the disclosure.

Wysebridge copyright law guideFree guide to what copyright protects, registration, fair use, work made for hire and the DMCA.
Wysebridge U.S. IP law courseA 20-chapter self-study course on U.S. patent, trademark, copyright and trade secret law; module 1 is free.
Wysebridge IP law in the age of AI courseHow generative AI affects copyright, patent, trademark and trade secret law, in 18 chapters.

Part of Protecting Your Startup · All guides · Glossary

Sources

General information, not legal, tax or financial advice. Reviewed 11 November 2026.