I still remember the early days of RemoteTeam. We were a small, scrappy team, building our product with a mix of passion, caffeine, and a whole lot of open-source code. It was exhilarating. We were moving fast, shipping features, and felt like we were on top of the world. Then, we got a letter from a lawyer.
It turned out that a library we were using had a particularly restrictive license. We had to rip it out and replace it, which cost us weeks of development time and a lot of sleepless nights. That was my first real lesson in the legal side of open source. It’s a lesson I’ve never forgotten.
As a founder, you’re always looking for an edge. Open-source software seems like a gift from the heavens. It’s free, it’s powerful, and it can save you thousands of hours of development time. But here’s the thing: “free” doesn’t mean “no strings attached.” In fact, some of those strings can tie your business up in knots if you’re not careful.
This is the guide I wish I had when I was starting out. I’m going to break down the complex legal jargon into actionable steps for early-stage founders. No fluff, no BS, just the stuff you need to know to protect your company.
The Open Source License Minefield
Think of an open-source license as a contract between you and the creator of the software. It sets the rules for how you can use, modify, and distribute their work. There are a ton of different licenses out there, but they generally fall into two categories: permissive and copyleft.
Permissive licenses are the most common and the easiest to work with. They’re like a friendly handshake. They let you do pretty much whatever you want with the code, as long as you give credit to the original author. The most popular permissive licenses are:
- MIT License: This is my go-to license. It’s short, simple, and lets you do almost anything with the code. You can use it in your own proprietary software without having to release your source code.
- Apache 2.0 License: This is another great permissive license. It’s a bit longer than the MIT license, but it also includes a patent grant, which can be a big deal for some companies.
- BSD License: This is another simple and permissive license that’s similar to the MIT license.
Copyleft licenses are a bit more…viral. They’re designed to keep open-source software open. If you use a copyleft-licensed component in your software, you have to release your entire application’s source code. This can be a huge problem if you’re trying to build a proprietary product. The most common copyleft licenses are:
- GPL (General Public License): This is the most well-known copyleft license. It’s a powerful tool for keeping software free and open, but it can be a nightmare for businesses.
- AGPL (Affero General Public License): This is an even more restrictive version of the GPL. It’s designed for web applications and requires you to release your source code even if you’re just running the software on your own servers.
How to Navigate the Minefield
So, how do you avoid stepping on a legal landmine? Here are a few simple rules to follow:
- Know what you’re using. The first step is to create an inventory of all the open-source components you’re using in your product. There are a number of tools that can help you with this, like FOSSA and Snyk.
- Read the licenses. I know, I know, reading legal documents is about as much fun as a root canal. But you have to do it. You need to understand the terms of each license before you use the software.
- Have a policy. Create a clear policy for your team on how to use open-source software. This should include a list of approved licenses and a process for getting new components approved.
- When in doubt, ask a lawyer. I’m not a lawyer, and this isn’t legal advice. If you have any questions about a particular license, you should talk to a lawyer who specializes in intellectual property.
My Personal Philosophy on Open Source
I’m a huge believer in open source. I’ve built my career on it. I’ve also been burned by it. Here’s my personal philosophy on how to use open source without getting screwed:
- Permissive by default. I always try to use permissive-licensed components whenever possible. It just makes life easier.
- Isolate the copyleft. If I have to use a copyleft-licensed component, I try to isolate it in a separate service or library. That way, I don’t have to release the source code for my entire application.
- Give back. I’m a big believer in giving back to the open-source community. I’ve contributed to a number of open-source projects, and I’ve even open-sourced some of my own code. It’s a great way to build your reputation and connect with other developers.
The Bottom Line
Open-source software is a powerful tool, but it’s not a free lunch. You need to understand the legal implications before you use it. By following a few simple rules, you can avoid the legal landmines and build a successful business on the back of open source.
I’ve seen too many founders get into trouble because they didn’t take the legal side of open source seriously. Don’t be one of them. Take the time to understand the licenses, create a policy, and when in doubt, ask a lawyer. It’s a small price to pay to protect your company.
Frequently Asked Questions
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.
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 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'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.