Can You Build a Company on Open Source?

Open source has quietly eaten the software world: Linux runs the internet, and nearly every startup ships a codebase built on free, openly licensed components. But “anyone can use this for free” and “we run a profitable company” seem to be in direct tension. This guide explains how founders resolve that tension — the business models that work, the license traps that don’t, and where your actual competitive moat lives.

Can you make money if anyone can copy your code?

This is the paradox at the heart of every open-source business. Under any true open-source license, a user — including a competitor — can download your code, run it, modify it, and even sell it. So the money almost never comes from selling the software itself. It comes from selling what’s hard to copy:

• Convenience and operations — running the software so customers don’t have to.
• Proprietary add-ons — features you never open-sourced.
• Trust and support — a paid relationship, SLAs, and someone to call at 2 a.m.
• The brand — the name and reputation customers already recognize.

Think of the open-source project as the top of the funnel: it drives adoption, distribution, and developer goodwill at near-zero marketing cost. The business is monetizing a slice of that adoption. Get this mental model right and the specific models below make sense. For the foundational IP concepts behind all of this, start with the pillar guide, open source and software IP.

What are the main open-source business models?

Four models dominate, and most successful companies blend two or three.

• Hosted / managed service (SaaS). You run the open-source software as a cloud product and charge for uptime, scaling, security, and convenience. This is the biggest revenue category in open source — and, as we’ll see, the one that provoked the license wars.
• Open core. The core project is open source; a commercial edition layers on proprietary features (SSO, advanced security, compliance, admin tooling) that larger customers pay for. GitLab and many database companies run this way. The art is deciding what goes in the open core versus the paid tier.
• Support, services, and training. The classic Red Hat model: give away the software, sell subscriptions, certification, and enterprise support. It scales more slowly than SaaS but builds durable enterprise relationships.
• Dual licensing. You offer the same code under a copyleft open-source license and a paid commercial license. Companies that want to embed your code in a proprietary product buy the commercial license to escape the copyleft obligations. MySQL built a business this way.

None of these are mutually exclusive. A modern open-source company might run an open-core project, sell a hosted version of it, and offer enterprise support on top.

Which open-source license should you choose?

Your license choice is a business decision disguised as a legal one, because it dictates what others can take from you. Licenses fall into three broad camps.

Permissive licenses — MIT, Apache 2.0, BSD — let anyone use, modify, and redistribute your code, even inside closed-source commercial products, with almost no strings beyond attribution. They maximize adoption but give competitors the most freedom to build on your work without giving anything back. Apache 2.0 also includes an express patent grant, which MIT lacks — a meaningful difference for enterprise adopters.

Copyleft licenses — the GPL family — require that anyone who distributes modified versions release their changes under the same license. The GNU Affero General Public License (AGPLv3) closes the “SaaS loophole”: it extends the copyleft obligation to software offered over a network, meaning a company that modifies your AGPL code and runs it as a hosted service must publish those modifications. That makes AGPL a favorite defensive choice for companies worried about cloud providers freeloading.

Source-available licenses are not open source at all. More on those below.

Picking a license without understanding how it interacts with the other code in your stack is a classic mistake. Our guide on open-source license compatibility covers which licenses can and can’t be combined.

What is the source-available trend, and why are companies relicensing?

The defining IP story in open source over the last several years is companies leaving open source for source-available licenses. These publish the code but add restrictions that violate the Open Source Initiative’s definition — usually a clause barring you from offering the software as a competing commercial service.

The two most prominent examples:

• Server Side Public License (SSPL). Created by MongoDB, which adopted it in 2018. The SSPL says that if you offer the software as a service, you must open-source your entire service stack — a requirement so broad that no major cloud provider will comply, which is exactly the point.
• Business Source License (BSL / BUSL). A “delayed open source” license: the code is source-available with a usage restriction (typically no competing production use), and each release automatically converts to a truly open license (often Apache 2.0) after a set “change date,” commonly four years.

Why the exodus? Because the hosted-service model worked too well for someone else. Large cloud providers took popular open-source projects, ran them as lucrative managed services, and returned little to the companies doing the core development. Relicensing is these companies’ attempt to reclaim the hosting revenue their own code generated.

The pattern is remarkably consistent:

• MongoDB moved from AGPL to the SSPL in 2018.
• Elastic relicensed Elasticsearch and Kibana from Apache 2.0 to a dual SSPL/Elastic License in 2021 — then, in 2024, added AGPLv3 back as an option, after its litigation and trademark dispute with the cloud provider that had forked it (into OpenSearch) had settled.
• HashiCorp switched Terraform and its other tools from the Mozilla Public License to the BSL in 2023, prompting the community to fork Terraform into OpenTofu under a foundation; HashiCorp was later acquired by IBM.
• Redis left its BSD license for a dual source-available model in 2024, triggering the Valkey fork backed by the Linux Foundation — and then added AGPLv3 back as an option in 2025.

The lesson for founders: every relicensing move buys revenue protection but risks a community fork, because a permissively licensed project can be forked and continued by anyone. You cannot un-ring the open-source bell for code you already released.

How do you keep copyleft from “contaminating” your proprietary code?

If you sell any proprietary component, the biggest legal risk is copyleft contamination — accidentally combining GPL or AGPL code into your closed-source product in a way that triggers the obligation to release your source code. This is a real, recurring compliance failure, not a theoretical one.

Practical guardrails:

• Maintain a license inventory. Know exactly what license every dependency carries. Use automated software-composition-analysis (SCA) tooling in your CI pipeline.
• Segregate strong copyleft. Keep GPL/AGPL components at arm’s length — separate processes, network boundaries, or clean APIs — rather than statically linking them into proprietary code. (Linking analysis is fact-specific; get counsel.)
• Watch the AGPL specifically if you run a SaaS product, since its network-use clause reaches hosted software that GPL doesn’t.
• Prefer permissive dependencies (MIT, Apache 2.0) for anything that will touch your proprietary code.
• Honor attribution and notice requirements, even for permissive licenses — the most common violations are the boring ones.

Copyright in code is automatic the moment it’s written, and a license is simply permission to use someone else’s copyrighted work on stated conditions. Violate the conditions and you’re infringing. To see how courts treat software copyright and licensing disputes, browse our copyright case archive.

Who owns the contributions — and why do CLAs matter?

Here’s a trap that only bites later: when outside developers contribute to your open-source project, they own the copyright in what they wrote unless they’ve agreed otherwise. If you ever want to dual-license, relicense, or sell the project, you need the legal right to all of the code — and you can’t get it retroactively without tracking down every contributor.

Two mechanisms solve this:

• Contributor License Agreement (CLA). Each contributor grants your company a broad license (or assigns copyright) in their contributions. A CLA is what let MongoDB, Elastic, and others relicense their own projects — they had gathered the rights in advance. If you have any commercial ambition, a CLA is close to mandatory.
• Developer Certificate of Origin (DCO). A lighter-weight sign-off (used by the Linux kernel) where contributors attest they have the right to submit the code, but don’t grant you extra relicensing rights. It’s community-friendly but won’t support a future relicensing.

The choice is strategic: a CLA preserves your freedom to change the business model, but adds friction that can deter contributors. A DCO lowers friction but locks in your license. We cover the tradeoffs and sample language in contributor license agreements. This is also part of the broader question every startup faces about who owns the startup’s IP, especially when employees and contractors touch the codebase.

Where is your real moat if the code is free?

If a competitor can legally copy your code, what actually protects the business? For most open-source companies, the durable moat is not the source code at all. It’s a stack of things that can’t be forked:

• Your trademark. This is the single most underrated asset in open source. Anyone can fork your code, but they cannot use your project’s name or logo — those are protected by trademark law, which is entirely separate from copyright and the software license. When Terraform forked to OpenTofu and Redis forked to Valkey, the forks had to rename precisely because the original names were trademarked. The name customers search for and trust stays yours. (Register it deliberately — see the trademark side of the copyright vs. trademark vs. patent distinction.)
• Operational scale. Running a reliable, secure hosted service at scale is genuinely hard, and it’s the value cloud customers actually pay for.
• The community and mindshare. The maintainers, the roadmap control, the ecosystem of plugins, and the developer trust are extraordinarily hard for a fork to replicate.
• Speed and roadmap. You’re usually months ahead of any fork, and you control where the project goes next.

Register your trademark early, keep control of the project’s official name and domains, and treat the brand as the crown jewel. If you also have patentable inventions in your stack, weigh whether to patent or keep them as trade secrets — see patent vs. trade secret — but recognize that publishing code as open source can act as prior art against your own later patents.

The bottom line

You can absolutely build a company on open source — plenty of billion-dollar businesses have — but only if you separate two decisions that founders tend to blur. First, the business model: decide up front whether you’ll monetize through hosting, open core, support, or dual licensing, because that determines which components you keep proprietary. Second, the IP architecture: choose a license that matches your strategy (permissive for adoption, copyleft/AGPL for defense, source-available if you must protect hosting revenue), gather contributor rights through a CLA if you might ever relicense, keep copyleft away from your proprietary code, and treat your trademark as the moat it actually is. The code can be free. The company doesn’t have to be.

This guide is general education, not legal advice, and does not create an attorney-client relationship. Open-source license obligations and relicensing rights turn on your specific code, contributors, and dependencies — consult an attorney licensed in your jurisdiction before choosing a license or changing one.