I've seen more startups die from self-inflicted wounds than from competition. And one of the sharpest, most avoidable knives is messing up open source software licensing. It sounds boring, I know. But getting this wrong can kill your company. I'm not being dramatic.
I remember the exact moment this became real for me. We were at RemoteTeam, my first company, and we were on the verge of closing our Series A. We were a small, scrappy team, moving at a thousand miles an hour. We used open source for everything. It was great. Until the investor's lawyers sent over their due diligence checklist. Suddenly, we were in a conference room for a week, digging through our entire codebase, trying to justify every single library we’d used. We hadn't paid any attention to the licenses. It was a nightmare that almost cost us the round. That was a painful lesson, and one I want to help you avoid.
The Open Source Illusion: It's Not a Free Buffet
Most founders hear “open source” and think “free.” It's not. It's free as in “free puppy,” not as in “free beer.” It comes with responsibilities. Every open source library has a license, and that license is a binding legal agreement. Some are easygoing. Others will eat your company's IP for lunch.
Think of it this way: you wouldn't build your house on a piece of land without checking the deed, right? Using open source without understanding the license is exactly that. You're building your company's most valuable asset—your code—on a foundation you don't own or understand. It's a recipe for disaster.
The License Jungle: A Founder's Field Guide
There are a ton of licenses out there, but they really boil down to two types: permissive and copyleft.
Permissive Licenses (The Good Stuff):
These are your friends. They let you do pretty much whatever you want with the code. The big three are:
- MIT License: The best of the best. It’s short, sweet, and to the point. Use it, change it, sell it—just keep the original copyright notice. We used it for our own open source projects at RemoteTeam.
- Apache License 2.0: Another solid choice. It’s a bit more lawyerly than MIT, but it does the same job and even gives you some patent protection.
- BSD License: Very similar to MIT. No complaints here.
Copyleft Licenses (The Dangerous Stuff):
This is where things get ugly. Copyleft licenses are designed to keep software free, which is a great idea in theory. In practice, for a startup, they can be a death sentence. They have a “viral” effect: if you use a piece of copyleft code, your own code becomes “infected” and you have to release it under the same license.
Here are the ones to watch out for:
- GNU General Public License (GPL): The original sin. If you use a GPL library in your app, you have to open source your entire app. Game over. You just gave away your secret sauce.
- GNU Lesser General Public License (LGPL): It's supposed to be a compromise, but it’s still a pain. It lets you use the library without open-sourcing your whole app, but you have to allow users to swap out the library, which is a technical headache you don't need.
- GNU Affero General Public License (AGPL): The scariest of them all. If you use an AGPL library in a web app, anyone who uses the app gets the right to your entire source code. For a SaaS company, that’s game over.
My Brush with GPL: A Cautionary Tale
At MovieLaLa, my second startup, we almost learned this the hard way. One of our engineers, trying to move fast, pulled in a GPL-licensed library for a minor feature. It was a tiny part of the app, but it put our entire codebase at risk. We caught it in a code audit, but it was a fire drill. We had to rip out the library and rebuild the feature from scratch. It cost us a week of engineering time. A week we didn't have. It was a stupid, avoidable mistake.
A Founder's Action Plan for Open Source Compliance
So, how do you stay out of trouble? It’s not that hard. Here’s the playbook I give to all the founders I invest in:
- Have a Policy: Write down what licenses are okay and which are not. Make it simple. Approved (MIT, Apache, BSD). Banned (GPL, AGPL). Needs Approval (LGPL). Done. A one-pager is all you need.
- Train Your Team: Your engineers aren't lawyers, but they need to know the basics. Do a lunch-and-learn. Explain the difference between permissive and copyleft. Tell them the MovieLaLa story. Scare them a little. It works.
- Use a Scanner: Don't do this by hand. Use a tool like FOSSA, Snyk, or WhiteSource. It will scan your code and flag any problematic licenses. We used FOSSA at RemoteTeam. It was a lifesaver and worth every penny.
- Audit Before You Ship: Before any major release, and especially before you go out to raise money or sell the company, do an audit. You don't want any surprises when you're in the middle of a deal.
The Bottom Line
Look, open source is a gift. It lets you build faster and better than ever before. But it's not a free lunch. As a founder, it's your job to understand the rules of the road. Don't let a dumb licensing mistake be the thing that kills your dream. It’s not the sexiest part of being a founder, but it’s one of the most important. Get this right, and your future investors—and your future self—will thank you.
Frequently Asked Questions
What's the most common pushback you get on this?
People often push back by citing exceptions or edge cases. And they're usually right that exceptions exist. But building a strategy around exceptions rather than patterns is a losing game for most founders.
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.
Do all experts agree with this view?
No, and that's fine. The best ideas in business are often contrarian. I share my perspective based on my experience and data, but I encourage you to seek out opposing viewpoints and form your own conclusions.