I almost lost a company over a single line of code.
It was years ago, during the early days of RemoteTeam. We were a small, scrappy team, moving fast and building things. One of our developers pulled in a slick-looking charting library to build a new dashboard feature. It worked perfectly. We shipped it. Customers loved it. Six months later, we were in the middle of our first serious acquisition talk. The buyer's tech diligence team started digging through our codebase. Then came the call that made my stomach drop.
"Sahin, we have a problem. You're using a library with a GPL license in your core product."
That one line of code, buried deep in our application, carried a "viral" license. The short version? It meant our entire proprietary codebase, the very asset the acquirer was buying, was potentially now required to be open-sourced. The deal was immediately put on ice. What followed was a frantic, three-week-long fire drill involving expensive lawyers and our best engineers ripping that library out of our product. We saved the deal, barely. But it cost us over $150,000 in legal fees and emergency engineering work, not to mention the trust we almost lost.
I see founders making this same mistake all the time. We fall in love with the idea that open-source software (OSS) is "free." But "free" as in "free speech," not as in "free beer." Using OSS without understanding the rules is like picking up a free puppy. It feels great at first, but it comes with a whole set of responsibilities you'd better be ready for. Ignore them, and that cute puppy can grow up to bite you, hard.
The Three Flavors of Open Source
Forget the hundreds of different licenses. As a founder, you only need to understand the three main categories. I think of them in terms of how much they demand in return.
1. The "Do Whatever You Want" Licenses (Permissive)
These are my favorite. Licenses like MIT, Apache 2.0, and BSD are the most common and the most business-friendly. They basically let you do anything you want with the code: use it, modify it, and sell it as part of your own proprietary software.
Your only real obligation is to keep the original copyright notice and license text somewhere in your product's documentation. That's it. It’s a simple, fair exchange. You get to use incredible software built by others, and you give them a small nod of credit. For 99% of startups building a commercial product, this is the safe zone. When my engineers ask what they can use, I tell them to stick to MIT and Apache 2.0, and they'll rarely run into trouble.
2. The "Share and Share Alike" Licenses (Copyleft)
This is where the danger lies. The most famous copyleft license is the GNU General Public License (GPL). There are a few versions, but they all operate on a principle of reciprocity. If you use a GPL-licensed component in your software, and you distribute that software, your entire application is now considered a "derivative work." That means your own proprietary code—your secret sauce—is now subject to the GPL and you must make your source code available to anyone who asks.
This is the "viral" effect I mentioned. It spreads from the open-source component to your own code. For a startup whose entire value is tied up in its intellectual property, this can be an extinction-level event. An acquirer won't touch you. A VC won't fund you. It's a poison pill.
There's also the AGPL (Affero General Public License), which is even stricter. It triggers the sharing requirement even if you just run the software on a server and let users interact with it over a network—which describes basically every SaaS company on the planet. My advice for most startups? Avoid AGPL-licensed code like the plague unless you are building an open-source company from the ground up.
3. The "Friendly Neighbor" Licenses (Lesser Copyleft)
Finally, there's a middle ground. The LGPL (Lesser General Public License) is a compromise. It allows you to use the open-source component in your proprietary product without infecting your entire codebase. You can dynamically link to an LGPL library, and your own code remains your own.
However, if you modify the LGPL-licensed library itself, you have to share those specific modifications. It's a way to encourage improvements to the open-source project without forcing your entire business to become open source. It's less risky than GPL, but it still has compliance requirements that you need to track carefully.
Real Stories from the Trenches
I've been an angel investor in over 200 companies, including some big names in the AI space like Anthropic and Scale AI. I see this issue pop up constantly during due diligence.
One of my portfolio companies, a promising AI startup, had a $50 million acquisition offer on the table. The deal was cruising along until the buyer's scan found a single, critical data processing library that was GPL-licensed. The founders had no idea. The developer who added it had left the company a year earlier. The deal didn't die, but it was delayed by two months, and the final purchase price was cut by $5 million to cover the perceived risk and the cost of remediation. The founders were lucky it wasn't worse.
Another founder I advise had to pull their app from the App Store after a competitor discovered they were using a GPL component without releasing their source code. It turned into a public relations nightmare and a legal mess that cost them their early momentum.
My Playbook for Using OSS Safely
You can't build a modern tech company without open source. It's the foundation of everything. So the goal isn't to avoid it, but to use it with your eyes open. Here is the simple playbook I give all my founders.
1. Create a Simple Policy. You don't need a 50-page legal document. Just a simple one-pager on your internal wiki that says:
- Green Light (Pre-Approved): MIT, Apache 2.0, BSD.
- Yellow Light (Review Required): LGPL, Mozilla, and other less common licenses. Engineering leads must review with the CTO.
- Red Light (Forbidden): GPL, AGPL. Do not use without explicit CEO and legal approval.
2. Train Your Engineers. Every new engineer should get a 15-minute briefing on this policy during onboarding. It's not about making them lawyers. It's about making them aware that licenses have consequences. The biggest risk comes from a well-meaning developer trying to solve a problem quickly without understanding the tools they're using.
3. Automate, Automate, Automate. Don't rely on manual checks. Humans make mistakes. Use automated tools that scan your codebase and all its dependencies. Services like Snyk, FOSSA, or Black Duck can be integrated directly into your development pipeline. They'll flag problematic licenses before the code even gets merged. We implemented FOSSA at RemoteTeam after our near-disaster, and it was a lifesaver. It's a non-negotiable part of the tech stack for any serious company.
4. Check Your Dependencies' Dependencies. The real trap is often in transitive dependencies. You might use a library with a safe MIT license, but that library might depend on another library with a GPL license. Your scanner will catch this. This is why manual checks are not enough.
5. When in Doubt, Pay a Lawyer. If you're unsure about a license, don't guess. Find a lawyer who specializes in open-source compliance. A one-hour consultation might cost you $500. That's a rounding error compared to the millions you could lose in a botched acquisition.
Open source is a gift. It has enabled a generation of founders, myself included, to build incredible things faster and cheaper than ever before. But it's a gift that comes with instructions. Read them. Follow them. Build your company on a foundation of solid rock, not on legal quicksand.
Frequently Asked Questions
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.
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.
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.