Strategic Licensing for Your Open Source Startup
Your OSS license is your contract with the market. Pick it wisely.
Your license is your contract with the market. It is your business model enforcement mechanism. Define it early. Be transparent about your boundaries. And remember: You can always make a restrictive license more permissive later, but making a permissive license more restrictive is a painful, trust-burning one-way door. Measure twice, cut once.
Your license choice is one of the most important decisions you’ll make in the life of your company. If you get it wrong in one direction, you undermine your community by being overly restrictive, strangling the top-of-funnel adoption that makes the COSS model so powerful. If you get it wrong in the other direction, you hand your revenue directly to hyperscale cloud providers by being too permissive. Let’s strip away the legal hedging and philosophical debates. We are going to look directly at what these licenses actually do in the market, how they shape competitive dynamics, and how you must use them to defend your enterprise.
The permissive trap
When a founder writes their first line of code, their primary objective is adoption. They want developers to use their tool, love their tool, and share their tool. Consequently, developers instinctively reach for permissive licenses. Recent data from the Open Source Initiative (OSI) confirms this enduring psychological default: in 2025, the MIT license remained the most-viewed license in the world with over 1.5 million pageviews, followed distantly by Apache 2.0 with 344,000.
The gap between this permissive instinct and commercial reality is the central crisis of the modern COSS ecosystem. Starting with an MIT or Apache 2.0 license maximizes initial adoption and friction-free distribution because it provides absolute freedom. These licenses allow anyone to embed your code into any commercial product without restriction. However, they provide precisely zero legal protection against commoditization.
As of Q4 2025, AWS, Azure, and Google Cloud together held sixty-three percent of the global cloud market and generate $119 billion in quarterly cloud infrastructure revenue. These are the apex predators of the internet. If your permissively licensed infrastructure tool achieves widespread popularity, it will inevitably attract their attention. The pattern is painfully consistent: you spend years building a massive open-source ecosystem; a hyperscaler launches a managed service wrapping your exact code without contributing a single commit back to the core project; your enterprise buyers default to the hyperscaler because the spend is already committed in their multi-year enterprise discount programs; and finally, you are starved of the very managed-service revenue you created. You must plan your defense before they arrive, not after they have integrated your life’s work into their cloud console.
From copyleft to network defense
To defend your business, you must understand the mechanics of the traditional open-source spectrum beyond permissive licenses. Moving up the ladder of protection, we encounter weak copyleft licenses like MPL 2.0 and LGPL. The key characteristic of these licenses is that any modifications made specifically to the licensed files must be shared back with the community. However, the enforcement mechanism is limited strictly to the file level, meaning a hyperscaler can easily build a proprietary control plane around your unmodified open-source core without triggering any obligation to share their lucrative management software.
Strong copyleft, GPL 2.0 and 3.0, escalate the defense. Any software that incorporates GPL code must itself be GPL, and the trigger is distribution: ship the software, share the source. But the modern cloud broke that lever. Hyperscalers don’t distribute software. They host it, and hosting isn’t distribution. This massive loophole gave rise to network copyleft licenses, specifically the AGPL v3.
AGPL v3 is the strongest fully OSI-approved license available. It extends GPL to network use, so a company that modifies an AGPL application and offers it as a service is legally compelled to share its modifications. In theory that puts enormous pressure on cloud providers and forces their proprietary wrappers into the open. In practice the corporate reaction was swift and brutal. Because AGPL is viral, it’s banned across much of the enterprise. Many Fortune 500 companies maintain blanket policies forbidding any AGPL dependency, on the reasoning that one bad import could infect their proprietary code. So AGPL protects you against cloud providers and, in the same stroke, throttles the enterprise adoption you were counting on. Strong defense, narrow doorway.
Source-available and fair source
Because traditional OSI-approved licenses either failed to protect revenue (Apache/MIT) or triggered enterprise procurement bans (AGPL), a new category of “source-available” licenses emerged to thread the needle. These are not technically “open source” by OSI definitions, but they provide the community with source code access while erecting commercial firewalls.
MongoDB invented the first of these, the Server Side Public License, later adopted by Redis. The SSPL is a poison pill aimed squarely at hyperscalers. It adds one devastating clause beyond AGPL: any company offering the software as a managed service must open source its entire infrastructure stack, not just its modifications. Because no hyperscaler will ever open source their proprietary operational backend, it practically outlaws third-party managed services without a commercial agreement. It is incredibly powerful, but major Linux distributions immediately removed MongoDB packages upon its adoption, and the ecosystem backlash was severe.
More recently, the Business Source License (BSL 1.1) became the most widely adopted source-available license, largely popularized by MariaDB, CockroachDB, and heavily utilized by HashiCorp. BSL is generally considered more “enterprise friendly” because it allows free use for almost all internal commercial purposes. Its enforcement mechanism specifically restricts production use only if it is part of a competing managed service. Crucially, BSL requires that the code revert to a fully OSI-approved license, typically after four years. It does not force anyone to open-source anything; it simply buys the creator a temporary monopoly on cloud commercialization.
Elastic took its own route with Elastic License v2 (ELv2). This license cleanly bars SaaS use without the vendor’s permission and bars circumventing built-in license keys or usage limits. It avoids the viral “entire stack” complexities of the SSPL, making it an elegant, targeted weapon against cloud commoditization, though it is best suited for younger products where the risk of a massive community fork is lower.
The newest arrival is the Fair Source family, led by the Functional Source License (FSL) that Sentry adopted recently. FSL is built for SaaS companies that care about developer sustainability. It keeps the source available and protected from commercial competitors for two years, then converts automatically to permissive Apache 2.0 or MIT. Because it carries none of AGPL’s viral obligations, it sails through enterprise legal review.If you are building a SaaS application rather than an on-premise infrastructure tool, FSL is a masterclass in balancing commercial defense with long-term open-source contribution.
Working the decision in order
Choosing a license is a sequence of business questions, and the order matters.
First, coldly evaluate your commoditization risk. If you’re building core database infrastructure, an observability platform, or an event-streaming pipeline, AWS is coming for you, and you need protection. If you’re building a niche developer workflow tool with no heavy compute appetite, your risk is genuinely lower and you can lean toward permissive adoption.
Then look at how much your roadmap depends on outside contributions. If community pull requests are a real engine of your velocity, a heavily restrictive license like BSL or SSPL will scare off the enterprise contributors who write most of them.
Then look at how you ship. A pure SaaS company gets time-limited protection and enterprise friendliness from FSL. An on-premise infrastructure company has to weigh the OSI-approved purity of AGPL against the broader, more contested commercial protection of BSL.
The last question is the one founders skip and later regret: who owns the intellectual property? The choice is between a Contributor License Agreement (CLA) and a Developer Certificate of Origin (DCO). A DCO is light. It’s a one-line sign-off in a Git commit, developers like it, and it adds almost no friction. It also gives you no future flexibility, because you never consolidate the rights and so can never unilaterally relicense the project. A CLA is the opposite trade. It adds friction, and many corporate developers are forbidden from signing one, but it grants the commercial entity full IP rights over the aggregated codebase.
The answer here isn’t balanced, and it shouldn’t be. If there’s any chance you’ll need to change your license later, to fend off a hyperscaler, to clean up before an IPO, or to position for an acquisition, you must institute a CLA on day one. HashiCorp’s pivot to BSL, community fallout and all, was only legally possible because someone had the foresight to require a CLA.
The full spectrum
A reference map of the field, from maximum freedom to maximum defense.
OSI-approved licenses
License Type Key characteristic What enforces it MIT / Apache 2.0 / BSD Permissive Maximum freedom; embeddable in any commercial product Nothing; anyone can do anything MPL 2.0 / LGPL Weak copyleft Changes to licensed files must be shared back File-level copyleft only GPL 2.0 / 3.0 Strong copyleft Any software incorporating GPL code must be GPL Distribution triggers sharing AGPL v3 Network copyleft Extends GPL to network use; SaaS apps must share source Network use triggers sharing
Source-available and fair source
License Type Key characteristic What enforces it SSPL Source-available Offering it as a service requires sharing the entire stack Prohibits managed-service competitors in practice BSL 1.1 Source-available Restricts competing managed services; reverts to OSS after a set period Production use as a managed service is restricted Elastic License v2 Source-available Prohibits SaaS use and circumventing license restrictions Custom vendor license FSL Fair source Source-available for two years, then converts to Apache 2.0 Time-limited commercial protection
OSI license pageview data for 2025 shows MIT is still the most-viewed license (1.53M pageviews), with Apache 2.0 second (344K). Developers still start with permissive licenses. The gap between that instinct and commercial reality is the central problem this chapter addresses.
The source-available options, up close
Business Source License (BSL 1.1)
BSL is the most widely adopted source-available license since 2022. It allows free use for almost everything, including internal commercial use, and restricts only production use as part of a competing managed service. After a defined window, typically four years, it reverts to an OSI-approved license such as AGPL or MPL. And it imposes no copyleft obligation — nothing downstream has to be open-sourced.
Who runs it: HashiCorp moved Terraform, Vault, Consul, and Nomad to it in August 2023, alongside MariaDB and CockroachDB.
The verdict: BSL is the most enterprise-friendly of the source-available options because it permits most commercial use. Its weak spot, which HashiCorp found the hard way, is that it triggers forks on contact. OpenTofu launched within thirty days of the announcement. If your project is dominant enough that a foundation will back the fork (and the Linux Foundation backed OpenTofu), BSL buys time without permanently protecting your position.
SSPL (Server Side Public License)
SSPL was MongoDB’s invention and was later used by Redis before the Valkey fork. The SSPL adds one clause beyond AGPL: any company offering the software as a service must open-source its entire infrastructure stack, not just its modifications. That effectively bars cloud providers from offering a managed service without a commercial agreement because no hyperscaler will open-source its whole operations stack.
The verdict: powerful on paper, but not OSI-approved and widely treated as a non-open-source license. Major Linux distributions removed MongoDB packages after the change. The Redis switch triggered the Valkey fork, backed by AWS, Google, Snap, and others, which picked up adoption fast. SSPL works only if you can stomach the community and ecosystem cost.
Elastic License v2 (ELv2)
Elastic’s custom license (ELv2) is the most vendor-friendly of the bunch. It prohibits two things: SaaS use without the vendor’s permission, and circumventing built-in license or usage restrictions.
The verdict: ELv2 is cleaner and simpler than SSPL, with narrower restrictions, and no entire-stack open sourcing requirement. But Elastic’s own history shows the catch. Switching from Apache 2.0 to ELv2 prompted AWS to fork Elasticsearch into OpenSearch (Apache 2.0) and split the community for good. ELv2 fits products that are newer or less dominant, where fork risk is lower.
FSL (Functional Source License)
FSL is the newest major license in the category, adopted by Sentry in 2024 and others. It converts to Apache 2.0 or MIT after two years. Per FSL’s own site, it’s designed for SaaS companies that value both user freedom and developer sustainability.
The verdict: the most developer-friendly of the source-available options, thanks to that two-year sunset into fully open source. It carries no AGPL-style obligations, so it passes muster in enterprises where AGPL is banned. If you’re a SaaS company rather than an on-premise infrastructure product, FSL deserves a serious look.
AGPL v3, the strongest OSI-approved option
AGPL v3 is the strongest fully open-source license. Its key extension over GPL: any software that communicates over a network must share its source. In theory that pressures cloud providers running AGPL software to share their modifications.
The reality bites the other way. AGPL is widely banned in the enterprise because it’s viral, and many large companies forbid AGPL dependencies outright. So it protects you against cloud providers while capping your enterprise adoption. Elastic’s 2024 move, adding AGPL v3 as a third option alongside SSPL and ELv2, was a goodwill gesture to OSI-aligned developers, not a commercial pivot. The commercial default stayed ELv2.
Case studies, and what they cost
HashiCorp to BSL, August 2023
The change: Terraform, Vault, Consul, and Nomad all moved from MPL 2.0 to BSL 1.1.
The trigger: stopping competing managed-service providers, Gruntwork, Env0, and Spacelift, from using the code commercially.
The outcome: OpenTofu launched within thirty days, backed by the Linux Foundation. Gartner put the industry re-tooling cost above $600M. IBM later acquired HashiCorp for $6.4B, a 54% discount to its $14B IPO valuation. The prevailing read is that the BSL change was meant in part to clean up the cap table before an exit. It worked in that narrow sense while dissolving the community moat that made HashiCorp worth the premium in the first place.
The lesson: a license change that fragments the community right before an exit destroys the trust-based moat that justified the price.
Elastic to SSPL/ELv2, January 2021, then AGPL, September 2024
The change: Apache 2.0 to dual SSPL/Elastic License in January 2021, then back to AGPL v3 in September 2024 alongside SSPL and ELv2.
The trigger: AWS launched Amazon Elasticsearch Service in 2015 and contributed little. By 2021, Elastic was bleeding cloud revenue to AWS.
The outcome: AWS immediately forked OpenSearch (Apache 2.0) and split the community for good. In August 2024, Elastic’s stock dropped 27% on weak cloud guidance, with OpenSearch pressure cited. The 2024 return to AGPL was a sound strategy since AGPL blocks managed-service extraction better than SSPL because it’s OSI-approved. It was also a public admission that the 2021 change had damaged community trust.
The lesson: never say you’ll never change your license, which is precisely what Elastic had said in public. And build your cloud offering before the cloud providers build theirs. Elastic Cloud launched in 2019. Four years after AWS Elasticsearch.
Redis to SSPL/RSALv2, March 2024
The change: BSD to dual SSPL/Redis Source Available License.
The trigger: AWS ElastiCache was capturing managed Redis revenue without contributing back. Underneath sat Redis’s 1% conversion problem: only 1% of Redis users ever became paying Redis Enterprise customers, while AWS earned ElastiCache revenue from the other 99%.
The outcome: the Valkey fork launched within weeks, backed by AWS, Google, Snap, Ericsson, and others, and again by the Linux Foundation. Enterprise migration was fast, and Redis’s community position weakened sharply.
The lesson: BSD-licensed infrastructure that becomes a cloud staple gets commoditized eventually. The relicense bought time at the cost of the community.
MongoDB to SSPL, October 2018
The change: AGPL to SSPL.
The trigger: AWS DocumentDB, MongoDB-compatible but not MongoDB, launched in 2018 and captured enterprise AWS customers who wanted compatibility without paying MongoDB.
The outcome: commercial success. Atlas grew from $100M annualized in 2019 to 75% of MongoDB’s $2.4B ARR in 2025. The trade, community damage for commercial protection, paid off because Atlas, not community-driven adoption, had already become the primary growth engine.
The lesson: if your business has already pivoted to managed cloud as its main growth engine, the SSPL’s community costs may be a price worth paying. MongoDB made that trade with open eyes, and it worked.
Ring-fencing the value into three layers
Trust requires clarity, and clarity means saying out loud which parts of your software live under which rules. This is a communication strategy as much as a legal one. It tells every user exactly where they stand. Three layers do the work.
Layer one: the commons
This is the engine of the flywheel, and it has to stay friction-free.
License: permissive, Apache 2.0 or MIT.
The promise: this code will always be free. Run it, inspect it, modify it, build on it. It includes the core runtime, the standard APIs, and single-node functionality.
The strategy: this layer optimizes for ubiquity. It drops the barrier to entry to zero and lets developers quietly bring your product into the enterprise without procurement approval. Choke this layer and you kill your own top-of-funnel.
Layer two: the enterprise product
This is where you capture value, and it aims at the organization, not the individual developer.
License: proprietary or source-available, such as Polyform, ELv2, or a commercial EULA.
The promise: these features are for companies operating at scale. They solve organizational, compliance, security, and governance problems. They are paid.
The strategy: this layer monetizes complexity and risk. Single Sign-On, audit logs, role-based access control, and multi-region replication all belong here. The individual developer does not care about SSO. The Chief Information Security Officer does, and the CISO is who you’re selling to.
Layer three: the cloud shield
This is the defense against a hyperscaler taking your code, selling it as a service, and contributing nothing.
License: copyleft (AGPL v3) or Business Source License.
The promise: you cannot wrap our code in a cloud service and resell it against us without contributing back or paying a license fee.
The strategy: this is what stops the Amazon problem. If a cloud provider wants to monetize your R&D, it has to either open-source its entire stack, which it won’t, or come negotiate a commercial partnership.
The rug pull and how not to do one
The most damaging move in the COSS world is the rug pull: build a large community on a permissive license like Apache, then flip overnight to something restrictive like BSL to force monetization. It reads as betrayal, and it taxes exactly the hobbyists and early adopters who built your success.
Sometimes you genuinely have to change licenses to survive, say moving from Apache to BSL to stop a cloud competitor. When you do, integrity is the difference between a hard pivot and a rug pull. Four rules hold the line.
Exempt the little guy. Make the new license permissive for non-commercial use, development, and companies under a revenue threshold. You’re targeting the whales, not the minnows.
Honor the legacy. Never retroactively relicense old versions. Code that was free stays free. The new terms apply only to future versions.
Give notice, in plain words. Explain the economics, not the legalese: we need to protect our ability to invest in R&D against cloud providers who strip-mine our work, and this change is how we keep building the best product for you.
Never bait and switch. Don’t move features from the free tier to the paid tier. That’s the cardinal sin. The only direction you may move a feature is from paid to free.
CLA versus DCO, in practice
The choice between a Contributor License Agreement (CLA) and a Developer Certificate of Origin (DCO) is a strategic one, not a paperwork detail to delegate to outside counsel. Both govern how IP from outside contributors flows into your project. They determine what rights your company holds over code other people commit and what every contributor has to agree to before their code lands. It decides whether you can adapt your business model five years from now or sit paralyzed by fragmented IP. You can’t maximize commercial optionality and community velocity at once. You have to choose.
A CLA is a formal contract a developer signs before any code merges. Signing it grants your company broad rights over the contributed code, often including the right to relicense it, dual-license it, or use it in proprietary products. The IP consolidates under your roof, and that buys you commercial agility. Because you control the aggregated rights to the whole codebase, you can change the open-source license later on your own authority. When a hyperscaler starts strip-mining the project, or when an IPO requires ring-fencing the commercial offering, the CLA is what lets you pivot. HashiCorp’s move to BSL was possible only because it had one. The cost is friction. CLAs are heavy, many enterprise developers are barred by their legal departments from signing them, and requiring one lowers your raw contribution volume.
A DCO is the lightweight alternative the Linux kernel popularized. There’s no document to sign. A developer adds a Signed-off-by line to the commit message, asserting only that they wrote the code or have the right to contribute it under the project’s existing license. Developers love it, it rarely trips corporate legal alarms, and if your goal is to grow the ecosystem and aggregate contributions fast, the DCO is the gold standard. The cost is total. A DCO transfers no broad rights, so the IP stays fragmented across every contributor, and you can’t relicense later without tracking down each one. Launch on Apache 2.0 under a DCO, and when AWS commoditizes you three years on, switching to a protective license means getting explicit permission from everyone who ever committed. That isn’t a hard task. It’s an impossible one.
For a venture-backed COSS company the recommendation is clear: a CLA is usually necessary to preserve the option for dual-licensing or defensive relicensing.
How to actually execute
Don’t let lawyers pick your license. Your business model picks it. An open-core model needs a permissive core and a proprietary wrapper. A dual-licensing model, selling exceptions to GPL, needs a copyleft base. Lawyers optimize for risk. You have to optimize for leverage.
Gate features by buyer versus user. When you decide which features go in the free core and which go in the paid tier, ask who the feature serves. Does it help an individual developer build an app, the CLI, local testing, and raw speed? Make it free. Does it solve a problem for a manager, an auditor, or a VP, compliance, reporting, or team management? Make it paid. The developer is the user. The manager is the buyer, and the buyer is who pays.
Manage copyright deliberately. A CLA hands you the rights to relicense later, at the cost of contribution friction. A DCO keeps contribution easy at the cost of relicensing freedom. For a venture-backed company that may one day need to launch an enterprise edition or defend against a hyperscaler, the CLA is usually the right call.
Let the business model dictate the legal strategy, never the reverse. Default to AGPL v3 when you need the strongest OSI-approved protection against hyperscalers and can absorb the enterprise procurement friction that comes with it. Default to MIT or Apache 2.0 only when ubiquity is the whole game and cloud extraction risk is genuinely low. Look hard at FSL if you’re a modern SaaS company looking for a principled path to commercial sustainability. The license is the one decision you make under no pressure and live under for years. And the asymmetry never moves: loosening is free, and tightening is the door that swings one way.