| title | The Open Source Guide: What the README Won't Tell You |
|---|
They say it's open source. They say it's free. They're not lying—but they're not telling you the whole truth either.
I spent years believing that "open source" meant anyone could take the code, use it however they wanted, and build a business on it. I was wrong. And if you're a developer, solopreneur, or first-time founder, you're probably wrong too.
This guide will unravel everything.
- The Question That Started Everything
- The License Spectrum (What Nobody Explains)
- Case Studies: The License Wars
- The Fork Phenomenon
- Clean Room Development: What You CAN Legally Do
- True Open Source Success: Red Hat's $34 Billion Exit
- What Actually Protects These Businesses
- The Solopreneur's Decision Framework
- Final Thoughts
Here's what confused me: If the code is free and open, how are these companies making hundreds of millions of dollars? And more importantly—what's stopping me from copying their code, calling it something else, and competing with them?
The answer is more nuanced than anyone wants to admit.
Actual footage of me reading my first AGPL license
"Open source" isn't one thing. It's a spectrum, and companies deliberately blur the lines. As a solopreneur, understanding this spectrum is critical before you build on, contribute to, or compete with any project.
This is what most people imagine when they hear "open source."
What it means:
- Use it however you want
- Modify it freely
- Sell it, redistribute it, build commercial products
- Almost zero restrictions
- No requirement to share your modifications
Examples: React, Vue.js, Node.js, Python, TensorFlow, Kubernetes
Can you copy it and compete? Yes. Completely. That's the point.
For solopreneurs: These are safe to build on. No strings attached.
Here's where it gets interesting.
GPL (General Public License):
- You can use and modify the code
- If you distribute software containing GPL code, you must open-source your entire codebase under GPL
- Your code becomes "infected" with the same license
AGPL (Affero GPL) - The Network Clause:
- Everything GPL does, PLUS
- If you modify AGPL software and run it as a web service, you must make the modified source code available to network users. The scope of what counts as 'your code' vs 'their code' is legally murky—which is why most companies avoid AGPL entirely.
Me realizing AGPL means network users can demand my source code
Why companies use AGPL: It's a poison pill. Big corporations won't touch AGPL code because they don't want to open-source their proprietary systems. This forces them to either pay for a commercial license or build their own solution from scratch.
⚠️ CRITICAL WARNING FOR SOLOPRENEURS: If you use AGPL code in your SaaS, the scope of what you must open-source is legally murky and potentially broad. Most startups avoid AGPL entirely to eliminate this risk.
This is the sleight of hand.
What it means:
- You can SEE all the code
- You can RUN it yourself
- You can even MODIFY it
- You CANNOT use it commercially without paying (or competing with the company)
The marketing trick: Companies call this "open source" because the source is... open. You can read it. But that's not what open source historically meant.
Business Source License (BSL):
- Non-production use is free
- Commercial use that competes with the company requires a license
- After 4 years (the "Change Date"), the code converts to a true open source license
Server Side Public License (SSPL):
- If you offer the software as a service, you must open-source your ENTIRE infrastructure stack
- Not just the application—everything: monitoring tools, deployment scripts, all of it
- No cloud provider will accept these terms
Functional Source License (FSL):
- Similar to BSL but converts to open source after only 2 years
- Created by Sentry as a "fairer" alternative
For solopreneurs: Read these licenses CAREFULLY before building anything commercial.
The most common model for VC-backed "open source" companies.
How it works:
- Core product: Actually open source (often AGPL to prevent cloud providers from monetizing)
- Premium features: Proprietary, locked in a separate folder (often
/eeor/enterprise) - Self-hosting: Free for personal use
- Commercial use: Pay us
The folder trick: Look at any popular "open source" company's GitHub. You'll often find an /ee (Enterprise Edition) folder. That code is visible—you can read every line—but it's commercially restricted. You can look, but you can't use it in production without paying.
For solopreneurs: The free tier might not include what you actually need.
These aren't hypotheticals. These are real companies, real decisions, and real consequences.
The Setup: HashiCorp created Terraform, one of the most important infrastructure-as-code tools in the world. It was open source under the Mozilla Public License (MPL 2.0) since 2014. Developers loved it. Companies built their entire infrastructure on it.
The Problem: Other companies were building commercial products on top of Terraform without contributing back. HashiCorp's stock dropped 67% from its 2021 IPO, and revenue growth was declining.
The Switch: On August 10, 2023, HashiCorp switched Terraform to the Business Source License (BSL). The new rule: you cannot use Terraform as part of a commercial service that competes with HashiCorp.
The Fallout:
- The community exploded with anger
- Within weeks, the OpenTofu fork was announced
- The Linux Foundation took OpenTofu under its wing
- Companies like Spacelift, Env0, and Scalr began contributing to the fork
💬 "We're not the first and we're not the last. There's a fundamental problem at the heart of open source—a tragedy of the commons." — Armon Dadgar, HashiCorp Co-founder
⚡ The Lesson: If a project is governed by a single company (not a foundation), the license can change at any time. Your dependency on that project is a business risk.
The Setup: Redis, the insanely popular in-memory database, was open source under BSD-3 for over a decade. Massive adoption. AWS, Google, and others offered Redis-as-a-service.
The Problem: Redis (the company) had raised over $300 million and was preparing for an IPO. But cloud providers were making money on Redis while the company struggled to capture value.
The Switch: In March 2024, Redis switched to dual licensing: SSPL (Server Side Public License) and their own RSAv2 (Redis Source Available License v2). Both prevent cloud providers from offering Redis as a service without paying.
The Immediate Response: Within days of the announcement, Redis contributors banded together and created Valkey under the Linux Foundation. Major backers included AWS, Google Cloud, Oracle, Ericsson, and Snap Inc.
The open source community when you pull a license rug pull
The Data: Before the relicense, Redis had nearly twice as many external contributors as internal employees. After the relicense, external contributors dropped to ZERO. Every single one moved to Valkey.
⚡ The Lesson: When you have a diverse contributor base, a "rug pull" on licensing creates an instant, well-resourced competitor.
The Setup: MongoDB was the poster child of the NoSQL movement. Open source under AGPL. Massive developer adoption.
The Threat: MongoDB saw cloud providers coming. As their database gained popularity, they realized AWS, Google, and others could offer MongoDB-as-a-service, undercutting the company that built it.
The Preemptive Strike: In October 2018, MongoDB created the SSPL (Server Side Public License), requiring anyone offering MongoDB as a service to open-source their entire stack. This was before major cloud competition emerged.
The Validation: Three months later (January 2019), Amazon launched DocumentDB—a MongoDB-compatible database service. MongoDB's preemptive move meant AWS had to build a compatible implementation from scratch rather than simply wrapping MongoDB itself.
The Controversy: The Open Source Initiative (OSI) refused to recognize SSPL as a valid open source license. MongoDB effectively became "source available." But the company went public and became extremely successful commercially.
⚡ The Lesson: MongoDB didn't wait to be attacked—they saw the threat and moved first. Sometimes strategic paranoia saves your business.
The Setup: Elasticsearch was truly open source under Apache 2.0—one of the most permissive licenses. Elastic built a massive business around it.
The Problem: Amazon created Amazon Elasticsearch Service, directly competing with Elastic's cloud offering.
The Switch: Elastic changed to SSPL and their Elastic License, both restricting commercial SaaS use.
The Community Response: AWS forked Elasticsearch and created OpenSearch, placing it under the Linux Foundation. The community split.
⚡ The Lesson: License changes have lasting consequences. Once you lose community trust, getting it back is extremely difficult—if not impossible.
Sentry, the error tracking platform, has changed licenses multiple times:
- 2009: BSD-3 (true open source)
- Later: BSL (Business Source License)
- 2023: Created the Functional Source License (FSL)
Why FSL? Sentry felt BSL had too many variables and a 4-year conversion period that was "almost might as well be 100 years." FSL converts to Apache 2.0 or MIT after just 2 years.
⚡ The Lesson: Even companies that care about open source are still experimenting with the right balance between openness and commercial viability.
When companies change licenses, the community often responds by forking—creating an independent copy that maintains the original open source license.
Research from the CHAOSS project analyzed what happens to relicensed projects and their forks:
Terraform → OpenTofu:
- OpenTofu was forked on August 25, 2023
- No previous Terraform contributors joined initially (they were all HashiCorp employees)
- But new contributors from 11 organizations quickly joined
- Spacelift employees made over half of all contributions in the first year
- Now under the Linux Foundation, actively developed
Redis → Valkey:
- Forked in early 2024—within days of the license change
- Unlike Terraform, Redis had many external contributors before the change
- ALL external contributors from Amazon, Alibaba, Tencent, Huawei, and Ericsson stopped contributing to Redis
- ALL of them moved to Valkey
- Valkey quickly released new versions with major performance improvements
Elasticsearch → OpenSearch:
- Created by AWS after Elastic's license change
- Now under the Linux Foundation's OpenSearch Software Foundation
- Active development continues independently
The ability to fork is a check on corporate power. When evaluating a dependency:
- Check the governance: Is it a single company or a foundation?
- Check the contributor diversity: How many organizations contribute?
- Check the license history: Has it changed before?
If a project is foundation-governed with diverse contributors, you have protection. If it's a single-vendor project, you're at their mercy.
Here's the part that surprised me most: You can legally build a competing product by reading someone else's code—if you do it right.
This is the case that enabled the entire PC clone industry and made personal computing affordable.
The Problem: IBM created the PC in 1981. They used commodity hardware anyone could buy. But one component was proprietary: the BIOS (Basic Input/Output System). Without a compatible BIOS, you couldn't run PC software.
Some companies like Eagle Computer simply copied IBM's BIOS. IBM sued them successfully.
Phoenix Technologies' Solution: Phoenix used "clean room" reverse engineering:
-
The "Dirty" Room: One team of engineers read IBM's BIOS source code (published in IBM's Technical Reference Manual). They wrote detailed specifications describing what each function did—without including any actual code.
-
The "Clean" Room: A completely separate team of programmers who had NEVER seen IBM's code received only the specifications. They wrote new code that did the same things.
-
The Chinese Wall: The two teams were completely isolated. Their interactions were documented as an audit trail.
The Result: Phoenix's BIOS was functionally identical to IBM's—but legally distinct. Because the programmers who wrote the code had never read IBM's code, nothing they wrote could have been "copied," even if sections happened to be similar.
The sheer genius of the clean room technique
The Business Impact:
- Phoenix licensed its BIOS to major manufacturers for significant fees
- They took out a substantial insurance policy against copyright lawsuits (never needed)
- HP, Tandy, AT&T, and others licensed Phoenix BIOS
- The entire PC clone industry exploded
- IBM lost control of the PC market
- Computing became affordable for everyone
This 10-year legal battle answered a critical question: Can you reimplement an API?
The Situation: Google created Android. To make it easy for Java developers to write Android apps, Google copied 11,500 lines of Java API "declaring code"—the names and structures of functions, not the actual implementations.
Oracle (who acquired Java) sued for $9 billion.
The Supreme Court's Decision (6-2): Google's use was fair use. Key reasoning:
- APIs are "inherently bound together with uncopyrightable ideas"
- Google's purpose was "transformative"—creating a new platform for a new market (smartphones)
- Google copied only what was needed to allow programmers to use their existing skills
- The copied portion (0.4% of the total Java codebase) was "tethered to a valid, transformative purpose"
The Impact:
- Software developers can reimplement APIs
- Interoperability is protected
- You can build compatible products without licensing every interface
You cannot copyright:
- Ideas
- Features
- Functionality
- Business logic
- API structures (after Google v. Oracle)
- "A document sharing platform with analytics"
You CAN only copyright:
- The specific code (the exact lines)
- Specific creative expressions
So if you:
- Read a competitor's code
- Understand conceptually how it works
- Close the browser
- Write your own implementation from scratch
That's 100% legal. That's called learning.
Before you conclude that open source can't be a real business, consider Red Hat.
- Acquired by IBM in 2019 for $34 billion—the largest open source acquisition in history
- $3.4 billion annual revenue at acquisition
- 15% year-over-year growth
- First open source company to reach $1 billion in revenue (2012)
- Reached $2 billion by 2015
Red Hat's core product, Red Hat Enterprise Linux (RHEL), is based on Linux—completely free and open source software. Anyone can download Fedora (the community version) for free.
How did they build a $34 billion business on free software?
-
Enterprise Support: Companies pay for guaranteed support, SLAs, and someone to call at 2 AM when production goes down.
-
Certification: Red Hat certifies hardware and software compatibility. Enterprise customers want assurance that things will work.
-
Training and Consulting: Teaching organizations how to use open source effectively.
-
Stability and Testing: RHEL is extensively tested and stabilized. Enterprises can't afford surprises.
-
Compliance and Security: Red Hat handles security patches, compliance certifications, and audits.
💡 THE KEY INSIGHT: "Open source is a development model, not a business model." — Jim Whitehurst, Red Hat CEO
The code is free. The expertise, reliability, and support are not.
Even Red Hat isn't immune to controversy. In 2023, Red Hat changed how it makes RHEL source code available, limiting access to paying customers. This sparked outrage and accusations of "open washing."
Oracle and SUSE announced they would fork RHEL. Rocky Linux and AlmaLinux scrambled to maintain compatibility.
The lesson: Even the most successful open source company faces pressure to capture more value.
If I can read all the code—even the premium features in the /ee folder—what stops me from copying everything?
Yes, violating a software license is illegal. But enforcement is expensive.
Reality check:
- Lawsuits cost $50,000-$500,000+
- Most startups won't sue small competitors
- International enforcement is nearly impossible
- License violations happen constantly and go unpunished
When legal matters:
- Enterprise customers do due diligence
- Acquisitions require clean IP
- IPOs require legal clarity
GitLab IS GitLab. Terraform IS Terraform (until they changed the license, anyway).
If you fork a project and call it something else, you start with:
- Zero credibility
- Zero trust
- Zero enterprise relationships
- Zero track record
Enterprise customers—the ones paying real money—won't buy mission-critical software from unknown entities.
This is the real moat:
- 7,000 GitHub stars
- 60+ active contributors
- Years of bug fixes
- Security audit history
- Integration partnerships
- Documentation ecosystem
- Stack Overflow answers
- Tutorial videos
- Conference presence
You can copy the code. You cannot copy years of accumulated community knowledge and trust.
Established projects ship continuously. A fork is always behind. By the time you catch up, they've moved forward.
This only works if the original project maintains momentum. When HashiCorp slowed down and angered the community, OpenTofu quickly caught up and even began adding features Terraform didn't have.
Whether you're building ON open source, building IN open source, or competing WITH open source, here's how to think about it.
Before adding any dependency, check:
| License | Can I use commercially? | Do I owe anything? | Risk Level |
|---|---|---|---|
| MIT | Yes | Nothing | Low |
| Apache 2.0 | Yes | Nothing | Low |
| BSD | Yes | Nothing | Low |
| LGPL | Yes | Link dynamically | Medium |
| GPL | Yes | Must open-source your code | High |
| AGPL | Yes | Must share modified code with network users | Very High |
| BSL | Maybe | Check additional use grant | High |
| SSPL | Only if not SaaS | Must open-source entire stack | Very High |
| Custom/Proprietary | Read carefully | Varies | Check |
Quick Decision Tree:
- Is it MIT/Apache/BSD? → Safe, use it
- Is it GPL? → Only if you're okay open-sourcing your work
- Is it AGPL? → Probably avoid for commercial SaaS
- Is it BSL/SSPL/Custom? → Read the full license text. Then read it again.
Choose your license strategically:
| Your Goal | Recommended License | Why |
|---|---|---|
| Maximum adoption | MIT or Apache 2.0 | No friction for users |
| Prevent proprietary forks | GPL | Forces others to stay open |
| Prevent cloud providers | AGPL or SSPL | Network use triggers copyleft |
| Build a business | Open Core (AGPL + proprietary) | Free core, paid premium |
| "Source available" with flexibility | BSL | Control commercial use temporarily |
Warning: If you start with a permissive license and change later, you cannot revoke the old license. Anyone can fork your last permissive version. This is exactly what happened to Terraform, Redis, and Elasticsearch.
Can you legally build "Competitor Park" after reading their code?
Yes, if you:
- Never copy code directly
- Write your own implementation
- Use clean-room principles for anything sensitive
- Don't violate trademarks (the name, logo, etc.)
Should you?
Probably not, unless:
- The incumbent is poorly maintained
- You have a significantly different vision
- The market is large enough for multiple players
- You can build sustainable differentiation
Building a clone is legal but usually unwise. The clone starts at zero while the original has years of momentum.
After all this, here's what I've learned:
For many companies, "open source" means:
- Free distribution (developers try it, companies pay)
- Trust signaling ("we have nothing to hide")
- Community-driven R&D (free contributions)
- Recruiting advantage (developers want open source on their resume)
This isn't inherently bad. But it's not the idealistic "information wants to be free" movement of the 1990s.
Don't ask "Is this open source?" Ask:
- What license is it actually under?
- Who controls the project?
- Has the license changed before?
- What happens if I use this commercially?
⚠️ DEPENDENCY RISK ALERT: If one company controls a project you depend on, you're at their mercy. They can:
- Change the license overnight (like HashiCorp did)
- Abandon the project entirely
- Get acquired and shut down
Your production system could be at risk.
Safer options:
- ✅ Foundation-governed projects (Linux Foundation, Apache Foundation, CNCF)
- ✅ Projects with diverse corporate contributors
- ✅ Projects with clear governance documents
The ability to fork is what keeps open source honest. When companies abuse their position, the community can—and does—walk away.
But forking is expensive. It only happens for important, widely-used projects. Niche tools may not get rescued.
Open source creates immense value. But someone always pays:
- Contributors donate their time
- Companies pay for support, hosting, or premium features
- Users pay with data, attention, or lock-in
- Society pays when critical infrastructure is underfunded
The question isn't whether to participate in open source. It's how to do so with clear eyes.
- ✅ MIT License
- ✅ Apache 2.0
- ✅ BSD (2-clause, 3-clause)
- ✅ ISC License
- ✅ Unlicense
⚠️ LGPL (okay if linking dynamically)⚠️ MPL 2.0 (file-level copyleft)⚠️ GPL (if you're okay with copyleft)
- 🚫 AGPL (network copyleft)
- 🚫 BSL (time-limited restrictions)
- 🚫 SSPL (extreme copyleft)
- 🚫 Any "Source Available" license
- 🚫 Any custom license
- What's the exact license? (Check the LICENSE file, not the README)
- Is there dual licensing?
- Are there enterprise/proprietary components?
- Who governs the project?
- What's the license history?
License Comparison Tools:
- choosealicense.com - GitHub's license picker
- tldrlegal.com - Plain-English license summaries
- opensource.org/licenses - OSI-approved licenses
Foundation-Governed Projects:
- Linux Foundation (OpenTofu, Valkey, Kubernetes)
- Apache Foundation (Kafka, Spark, Airflow)
- Cloud Native Computing Foundation (Prometheus, Envoy)
Further Reading:
- "The Business Source License" - MariaDB's original BSL documentation
- "Working in Public" by Nadia Eghbal - Economics of open source
- OSI's Open Source Definition - The official standard
Here's the thing nobody talks about after all the legal analysis and license breakdowns.
Yes, you can legally copy almost anything. You can read their code. You can understand their architecture. You can build your own "Paper Park" or "Copper Mark" or whatever clever name you come up with. The Phoenix BIOS team proved it. Google proved it in the Supreme Court. The law is on your side.
But here's what keeps me up at night:
Even if you copy the commercial parts, even if you make it better, even if you out-execute the original—you're still playing their game. You're building in their shadow. Every feature you add, every decision you make, is defined by what they did first.
The existential moment every founder faces: choosing your strategy
🤔 THE REAL QUESTION: The question isn't "Can I copy this legally?"
The question is: "Is this who I want to be?"
📋 Path 1: The Clone
You read the code. You understand the patterns. You build a faster, cheaper, better version. You compete on price. You compete on features. You spend your days watching what they do so you can do it too.
This is a valid path. Companies have made billions this way. AWS built DocumentDB by studying MongoDB. Phoenix Technologies enabled an entire industry by cloning IBM's BIOS. The PC revolution happened because people copied.
If this is your path, own it. Don't apologize for it. Learn everything you can from their code, their mistakes, their successes. Then execute better than they ever could.
✨ Path 2: The Creator
You look at the same market and ask a different question: "What haven't they built? What can't they see? What would I build if they didn't exist?"
Maybe you find that document sharing isn't actually about analytics—it's about trust. Maybe you discover that the real problem isn't tracking who viewed your PDF—it's that PDFs shouldn't exist in the first place. Maybe you see an angle that everyone else missed because they were too busy copying each other.
This path is harder. There's no blueprint. No code to read. No architecture to borrow. You're building from first principles.
But when you succeed, you're not "the alternative to X." You're the original. The one others will try to copy.
I'm not here to tell you which path to choose. Some of the most successful companies in history were "fast followers" who took someone else's idea and executed better. Some of the biggest failures were "visionaries" who were too early or too different.
What matters is that you choose consciously.
Don't stumble into copying because it's easier. Don't avoid copying because you think it's beneath you. Make the choice with clear eyes.
If you decide that copying—legally, ethically, through clean-room development—is your path, here's my advice:
-
Don't just copy the product. Copy the lessons. Read their blog posts. Watch their founder interviews. Understand why they made the decisions they made, not just what those decisions were.
-
Find the gap they left behind. Every product has users they don't serve well. Every pricing model has customers who feel ignored. That's your wedge.
-
Move faster. The only advantage a clone has is speed and focus. You don't have legacy code. You don't have enterprise customers demanding backward compatibility. Use that.
-
Build community from day one. The original has years of Stack Overflow answers, tutorial videos, and conference talks. You need to start building that moat immediately.
-
Be honest about what you are. Don't pretend to be something you're not. "We're a simpler, faster alternative to X" is a legitimate positioning. Own it.
If you decide to build something genuinely new, here's what I've learned:
-
Ignore the competition longer than feels comfortable. The temptation to peek at what others are doing is overwhelming. Resist it. Your unique perspective is your greatest asset.
-
Talk to users, not competitors. The insights that lead to breakthrough products come from understanding problems deeply, not from feature comparisons.
-
Be patient with confusion. When you're building something new, people won't immediately understand it. That's okay. That's actually a sign you're onto something.
-
Expect to be copied. If you succeed, you'll become the one being cloned. Plan for it. Build moats that can't be copied: community, brand, network effects, data.
Here's the secret that applies to both paths:
🔥 THE ULTIMATE TRUTH: Code is never the moat.
Whether you copy code or write it from scratch, the code itself is the least defensible part of any business.
The real moat is:
- The community that forms around your product
- The trust you build with users over years
- The brand that means something to people
- The relationships with customers who root for your success
- The institutional knowledge your team accumulates
- The speed at which you ship and iterate
These cannot be forked. These cannot be cloned. These cannot be reverse-engineered in a clean room.
Phoenix could copy IBM's BIOS, but they couldn't copy IBM's enterprise relationships. Google could reimplement Java's APIs, but they built their own developer ecosystem around Android. Valkey can fork Redis's code, but they're building their own community from scratch.
The code is just the beginning. Everything that matters comes after.
If you've read this far, you're not just someone looking for a quick hack. You're thinking seriously about building something.
Whatever you build—whether it's a clone or a creation, whether it's open source or proprietary, whether it's your first project or your tenth—build it with intention.
The world doesn't need another thoughtless copy. But it also doesn't need another "visionary" who's too proud to learn from what came before.
The best founders I know are students first. They read code. They study competitors. They understand the landscape deeply. And then they make a conscious choice about where they want to stand in it.
You now have the legal knowledge. You understand the licenses. You know what's possible.
The only question left is: What will you build?
Now you know what they don't tell you in the launch tweets.
Go build something that matters.
This guide is for educational purposes only and does not constitute legal advice.
The information here is based on publicly available documentation and case studies. Software licensing is complex and varies by jurisdiction. Before making any business or legal decisions:
- Consult with a qualified attorney who specializes in software licensing
- Have your lawyer review any licenses you plan to use or comply with
- Get professional advice for your specific situation
This guide is a starting point for understanding the landscape—not legal advice, not a substitute for a lawyer, and not an endorsement of any particular strategy.
When in doubt, talk to a lawyer. The cost of getting it wrong is far higher than the cost of proper legal counsel.
Seriously though. Get a lawyer. I just read a lot.