I once almost tanked a multi-million dollar acquisition over a single line of code.
It was in the final days of due diligence for MovieLaLa, my second company. The acquirer’s lawyers were crawling through our codebase, and they found something I didn’t even know was there: a tiny, seemingly insignificant open-source library with a GPL license. A "General Public License." Sounds harmless, right? Wrong. It meant that our entire proprietary codebase, the very asset they were buying, was potentially "infected" and had to be open-sourced.
Panic. That ’s the polite word for it. We spent a frantic 72 hours with our own lawyers to rip that library out and prove our code was clean. We saved the deal, but it cost us a small fortune in legal fees and a few years off my life.
Most founders are completely in the dark about open source licenses. We see "free" and "open" and think it’s a buffet. It’s not. It’s a minefield. And if you don’t know the rules, you’re going to step on a mine. This is the no-BS guide I wish I had when I started out.
The License Buffet: Not All You Can Eat
Think of open-source licenses as different flavors of “free.” Some are truly free, with almost no strings attached. Others come with a very high price. You need to know the difference.
The “Do Whatever You Want” Licenses (Permissive)
These are the good guys. Licenses like MIT, Apache 2.0, and BSD are your best friends. They basically say, “Take our code, do whatever you want with it, just don’t sue us if it breaks.” You can use them in your proprietary, closed-source projects without any fear. You don’t have to release your own code. This is the kind of open source you want to see.
At RemoteTeam, we built our entire stack on permissive licenses. It was a conscious decision from day one. We knew we wanted to be acquired, and we knew that meant a clean codebase. We had a strict policy: if it’s not MIT or Apache, it doesn’t come in the door.
The “Share and Share Alike” Licenses (Copyleft)
Here’s where the trouble starts. Copyleft licenses, like the infamous GPL (General Public License), are viral. They’re designed to spread. If you use a GPL-licensed component in your software, your entire software project must also be licensed under the GPL. That means you have to make your source code publicly available. For free.
Let that sink in. You spend millions on R&D, build a revolutionary product, and because one of your engineers used a single GPL library for a tiny feature, you now have to give away your secret sauce to the world. It’s a death sentence for most startups.
There are two main flavors of GPL:
- GPL: The most restrictive. Use it, and your whole project is GPL.
- LGPL (Lesser General Public License): A slightly less aggressive version. You can use an LGPL library in your project without open-sourcing your entire codebase, but only if you dynamically link to it. If you statically link or modify the library, the viral infection kicks in. It’s a subtle distinction, but a critical one. Frankly, I tell founders to avoid LGPL too. It’s just not worth the headache.
The Real-World Risks Nobody Talks About
It’s not just about the licenses. The way you use open source can also get you into hot water.
“I just copied a snippet from Stack Overflow…”
We’ve all done it. You’re stuck on a problem, you find a solution on Stack Overflow, you copy-paste, and you move on. What you probably don’t know is that all content on Stack Overflow is licensed under Creative Commons (CC-BY-SA). That “SA” stands for “ShareAlike.” Yes, it’s a copyleft license. Technically, that little snippet you copied could infect your entire codebase.
Am I saying you should never use Stack Overflow? Of course not. But you need to be smart about it. Understand the code, don’t just copy it. And if you do use it, make sure you attribute it properly. Better yet, have a policy against copying any code from Stack Overflow or any other forum.
The “Dependency Hell” Problem
Modern software is built like a Jenga tower of dependencies. Your project uses a library, which uses another library, which uses another ten. You might have hundreds of indirect dependencies you don’t even know about. Any one of them could have a restrictive license.
This is what almost killed my MovieLaLa deal. The problematic library wasn’t something we added directly. It was a dependency of a dependency of a dependency. We had no idea it was there until it was almost too late.
My Playbook for Staying Clean
So how do you avoid my near-disaster? It’s not about avoiding open source. It’s about managing it.
- Have a Policy: From day one, create a clear, written policy about what open-source licenses are acceptable. My rule is simple: MIT and Apache 2.0 only. Everything else requires explicit, written approval from me and our lawyers. No exceptions.
- Scan Everything: Don’t trust, verify. Use automated tools to scan your codebase and all its dependencies for license compliance. Tools like FOSSA, Snyk, and Black Duck are worth their weight in gold. They’ll flag any problematic licenses before they become a problem. We used FOSSA at RemoteTeam, and it was a lifesaver.
- Educate Your Team: Your engineers need to understand the “why” behind the policy. It’s not about bureaucracy. It’s about protecting the company’s most valuable asset. I’ve given this speech to every new engineer I’ve ever hired. I tell them my MovieLaLa horror story. They get it.
- Due Diligence on Steroids: If you’re acquiring a company, your legal team needs to be all over this. Don’t just ask for a list of open-source software. Demand a full scan from a tool like FOSSA. And don’t just look at the direct dependencies. Go deep. The devil is in the details.
It’s Your Company. Protect It.
Open source is a powerful tool. It’s accelerated the pace of innovation in a way that’s hard to comprehend. But it’s not a free lunch. It comes with rules, and if you don’t follow them, you can lose everything.
Don’t be the founder who gets a call from their lawyer in the middle of an acquisition with bad news. Don’t be the one who has to open-source their entire codebase because of a single line of code. Be the founder who is smart, who is prepared, and who protects their company. It’s not glamorous, but it’s one of the most important things you’ll ever do.
Frequently Asked Questions
How often is this guide updated?
I revisit and update my guides regularly as I learn new things and as the market evolves. The core principles tend to stay stable, but specific tactics and tools get refreshed based on what's working right now.
What if I disagree with some of the advice?
Good. That means you're thinking critically, which is exactly what a good founder should do. Take what resonates, test it, and discard what doesn't work for your specific situation. No advice is universal.
How should I work through this guide?
Don't try to absorb everything in one sitting. Read through once to get the big picture, then go back and work through each section as it becomes relevant to your current challenges. Bookmark it and return to it regularly.
Is this guide based on real experience?
Every recommendation in this guide comes from direct experience, either from building and selling my own companies, or from patterns I've observed across 200+ angel investments. I don't write about things I haven't personally tested.