I once saw a nine-figure acquisition deal almost completely implode. It wasn't over revenue, or team, or tech. It was over a single, tiny open source library the engineers had used without thinking. A library with a "viral" license that put the buyer's entire intellectual property portfolio at risk. The deal eventually closed, but not before the lawyers racked up an extra million in fees and the founders gave up a painful chunk of their exit.
This isn't some rare, black swan event. It happens all the time. As an investor in over 200 companies, including giants like Anthropic and OpenAI, and having gone through two exits myself with RemoteTeam and MovieLaLa, I can tell you this: most founders are flying blind when it comes to open source. They see "free" and think it means no strings attached. That's a dangerous, and potentially company-killing, mistake.
This is the guide I wish I had when I was starting out. No dense legal jargon, just a founder-to-founder roadmap for using open source software without accidentally giving away the keys to your kingdom.
What "Open Source" Actually Means
Let's clear this up first. Open source doesn't mean "free to use however you want." It simply means you can see the source code. That's it. The real rules are in the license that comes with the software.
Think of it like this: a city might have a beautiful public park (the open source code). But there are rules for using it. Some parks let you have a picnic anywhere (a permissive license). Others have strict "keep off the grass" signs and require you to book a specific picnic table (a restrictive license). Ignoring the license is like ignoring the park rules—you might get away with it for a while, but eventually, the park ranger (or a lawyer) is going to show up.
The License Jungle: A Founder's Field Guide
There are hundreds of open source licenses, but for a startup founder, you only need to understand two main categories: Permissive and Copyleft.
1. Permissive Licenses (The Good Stuff)
These are the ones you want to see. Think of MIT, Apache 2.0, and BSD licenses. They basically let you do whatever you want with the code—use it in your commercial, closed-source product, modify it, and not share your changes. The only thing they usually ask for is that you keep the original copyright notice somewhere in your product. It's a small price to pay.
When we were building RemoteTeam, we standardized on using libraries with permissive licenses wherever possible. It made our lives infinitely easier and was a huge green checkmark for Gusto's lawyers during the acquisition diligence.
2. Copyleft Licenses (Handle With Extreme Care)
This is where the danger lies. The most famous of these is the GPL (GNU General Public License) and its even more restrictive cousin, the AGPL.
Copyleft licenses have a "viral" effect. If you use a piece of GPL-licensed code in your proprietary software, your entire software product may now be legally required to be open-sourced under the same GPL license. It "infects" your codebase. The AGPL is even stricter, triggering this requirement if you just run the software on a server that users interact with over a network—they don't even have to download it.
I've seen this happen. A founder I know had a team that used a cool charting library they found on GitHub. It was licensed under the GPL. When they went to raise their Series A, the investor's due diligence team flagged it. They had to spend six months and over $200,000 in engineering and legal fees to rip it out and replace it. It almost killed their momentum.
My 3-Step Compliance Framework for Startups
You don't need a full-time legal team to handle this. You just need a simple, repeatable process.
Step 1: Inventory Everything. Now.
You can't manage what you don't measure. Your first step is to get a complete list of every open source component and dependency in your codebase. In the early days of MovieLaLa, we did this with spreadsheets. It was pure pain. Don't do that. Use automated tools like Snyk, FOSSA, or Dependabot (built into GitHub). They scan your repository and spit out a full report of every library and its license. Set this up from day one.
Step 2: Create a Simple Policy.
This doesn't need to be a 50-page legal document. It can be a one-page doc in Notion that your engineers can actually read. It should have three sections:
- Pre-Approved: A list of permissive licenses (MIT, Apache 2.0, etc.) that engineers can use without asking.
- Requires Review: Licenses that need a second look (e.g., LGPL, which is less restrictive than GPL but still tricky).
- Banned: A hard "no" list. For most startups, this should include all GPL and AGPL licenses.
Step 3: Due Diligence is Your Superpower.
Every time you look at an acquisition, or an investor like me looks at your company, we run an open source scan. A clean report signals that you are a professional, disciplined founder. A messy one is a giant red flag. It tells me you're sloppy, and if you're sloppy here, where else are you cutting corners?
When Gusto was acquiring RemoteTeam, our clean bill of health on the open source front made the technical diligence process smooth and fast. It built trust. I have personally passed on investing in companies purely because their open source hygiene was a disaster. It's a proxy for quality.
The Hidden Traps Beyond the License
It's not just about the license text. There are two other things to watch out for.
First, security vulnerabilities. Open source is not inherently secure. When a vulnerability like Log4j is discovered, you need to know immediately if you're affected. The inventory you built in Step 1 is your first line of defense. Tools like Snyk will actively alert you when a library you use has a known vulnerability.
Second, attribution. Even the most permissive MIT license requires you to include the original copyright notice. The easiest way to handle this is to have an "Open Source Licenses" or "Acknowledgements" screen in your app's settings menu or a page on your website that lists all the libraries you use and their license text. Most of the automated tools can generate this for you.
Don't Be Scared, Be Smart
Open source is one of the greatest tools we have as builders. It lets us stand on the shoulders of giants and build faster than ever before. This isn't about avoiding it. It's about using it with your eyes open.
Getting your open source strategy right isn't just about avoiding legal trouble. It's a signal to investors, acquirers, and future hires that you are building a professional, high-quality organization. It's the difference between building a solid brick house and a house of cards. Build it right from the start.
Frequently Asked Questions
How can I apply this thinking to my own situation?
Start by identifying the core principle behind the opinion, not the specific example. Then ask yourself: does this principle apply to my context? If yes, test it in a small, low-risk way before going all in.
What experience informs this perspective?
This perspective comes from over a decade of building companies in Silicon Valley, two successful exits (RemoteTeam to Gusto, MovieLaLa to Gfycat), and investing in 200+ startups including Anthropic, OpenAI, and Scale AI. I write about what I've lived.
How has this view evolved over time?
My thinking on most topics has changed significantly over the years. Early in my career, I held many conventional views that experience proved wrong. I try to update my beliefs when the evidence changes.