Dual Licensing vs. Open Core: Legal Distinctions Every Business Should Understand

Building a sustainable business around open source software is a balancing act. You want the massive community adoption and collaborative power that comes with an open license, but you also need a clear path to generating revenue.

Dual licensing and open core are two popular license models businesses use to square this circle. They both aim to blend openness with profit, but they do so in legally distinct ways that affect everything from contributor rights to compliance obligations.

For business owners, the core decision is whether you want to monetize by selling exceptions to a copyleft license (dual licensing) or by selling proprietary add-ons and services around an open core. This article explains how each model works in practice, the main legal risks, and how to pick a structure that matches your product, investor expectations, and compliance constraints.

What is Dual Licensing?

Dual licensing means offering the same software codebase under two different licenses simultaneously. It typically comprises a copyleft open-source license like the GNU General Public License (GPL) and a commercial license.

Here's how it works: you release one piece of software but offer two legal frameworks, allowing users to choose which one governs their use. Developers who are comfortable with the obligations of a copyleft license (i.e., releasing their modifications or derivative works under the same license) can choose the open-source version in their projects.

If, however, developers want to build proprietary products without the copyleft requirements, they'll have to pay for a commercial software license that removes those conditions. Here's how QT's licensing page describes the dual licensing model:

The dual licensing model was first implemented by MySQL, now owned by Oracle. The database is famously available under the GPLv2 for open-source projects. If you modify MySQL and distribute your changes, you must release your source code under the GPL's terms.

However, if a company, say a hardware manufacturer, wanted to embed MySQL into their device without releasing their own firmware source code, they would need to purchase a commercial license from Oracle, as shown on MySQL's commercial license page:

For this model to work legally, you must own or control 100% of the copyright to your entire codebase. You can't offer a commercial license for someone else's GPL-protected code.

This is why most projects that use dual licensing often require contributors to sign a Contributor License Agreement (CLA). These agreements grant the project owner the rights to relicense the contribution. Here's Qt's Contribution Agreement, for example:

Without consolidated copyright ownership, you can't offer a commercial alternative. You'd instead need permission from every contributor who's added code.

What is Open Core?

Open core means splitting your software into two architecturally distinct products. Instead of one codebase with two licenses, you maintain a free, fully open-source "core" product, and a separate set of proprietary features or add-ons available only through paid licenses.

The "core" product, which contains the essential software functionality, is typically shipped under a permissive, OSI-approved license like MIT or Apache 2.0 to encourage widespread adoption and community contributions. Advanced features, however, are built as separate codebases and licensed exclusively under a traditional proprietary model.

In other words, open core uses a "freemium" product strategy. Developers get value from the core software, but premium/enterprise features (such as granular access controls, proprietary integrations, security/compliance support, etc.) are locked behind a paywall.

A prime example of the open core model today is GitLab. Its Community Edition (CE) is a fully functional, MIT-licensed open-source project for the entire DevOps lifecycle. However, features like vulnerability management and AI-powered code suggestions are exclusive to its proprietary Enterprise Edition (EE).

Companies often use the open core model to build a large user base with the freemium version. They then monetize by upselling the must-have features that larger organizations need to scale and comply with internal policies.

Open core is also credited for its protection of competitive advantages. You can open-source enough to gain credibility in the development community without giving away the features that differentiate you commercially.

What Are the Legal and Contractual Differences Between Dual Licensing and Open Core?

Dual licensing and open core both mix open-source reach with commercial control. But legally, they rest on different foundations.

Dual licensing is a choice-based model (a single product under alternative rules). Open core is a boundary-based one (two separate products from the start). This distinction shapes everything from copyright ownership to compliance risk. Let's take a closer look.

Copyright Ownership

In a dual-licensed model, the publisher must own (or have rights assigned through CLAs for) every part of the codebase. Without unified copyright control, you can't legally relicense the same code under a commercial agreement.

For example, here's how Google's individual CLA sets out its contributions terms, including (notably exhaustive) rights developers confer on Google by signing the agreement:

For this reason, dual licensing often creates contributor friction. Some developers resist signing away relicensing rights, viewing it as the company profiting from community work without a reciprocal benefit.

Open core is less demanding here. You only need copyright control over proprietary components. Community contributions to the open source core don't necessarily require CLAs because those contributions don't get relicensed commercially; they remain under the original open source license (typically a permissive one like Apache).

Still, open core raises other concerns for contributors. Companies that use the open core model tend to prioritize their proprietary version at the expense of improving the core codebase. As one licensing expert puts it:

"…there is a deep motivational problem for open source projects that operate in the shadow of a proprietarily relicensed version: the sense that most of the salaried development attention is going to the proprietary version anyway…it also becomes a self-fulfilling prophecy: as more outside developers stay away, the company sees less reason to invest in the open source codebase, because they're not getting a community multiplier effect anyway…"

License Application: Choice vs. Separation

Dual licensing offers users a legal choice: comply with copyleft requirements (typically GPL) or pay for a commercial license to bypass those obligations. Users are paying for a different set of rights to the same asset.

The legal risk here is misunderstanding or breaching those license terms. Violating copyleft requirements can easily trigger a full-fledged intellectual property infringement case. The Entr'Ouvert v. Orange S.A. ruling is a popular case study that illustrates this risk clearly.

Entr'Ouvert offered its LASSO software under a dual licensing model (GPLv2 or a commercial license). Orange then used a modified version of LASSO in a public portal, but never bought the commercial license and failed to comply with the GPLv2's source code requirements.

The Paris Court of Appeal ultimately found Orange liable for copyright infringement and GPLv2 license violations and ordered Orange to pay a total of €800,000 in damages and related amounts, including compensatory damages, disgorgement of unjust enrichment, and moral prejudice.

For businesses, this decision confirms that non‑compliance with copyleft terms in a dual-licensing context is enforced as a serious IP breach, not a mere contractual oversight, and can lead to high six‑figure liability plus reputational damage.

Open core, on the other hand, operates under simultaneous but separate licenses. The boundary here is architectural. Because of this, the separation of both codebases must be technically and legally airtight in an open core model.

Blending proprietary code into the open-source layer risks "license contamination," meaning the copyleft obligations attached to the open-source core may legally extend to parts of your proprietary code if the components are too tightly combined.

Jurisdictional notes: While Entr'Ouvert v. Orange is a French appellate decision, courts in other jurisdictions have also treated open-source license obligations as enforceable legal commitments, whether as copyright conditions, contractual terms, or both. For cross‑border deployments, in‑house counsel should assume that failure to comply with copyleft terms (e.g., GPL or AGPL) can trigger infringement claims, injunction requests, and significant damages exposure in multiple forums, even when the software is offered only as a cloud service.

Modification and Derivative Work Rights

Under dual licensing, the commercial license's value is removing copyleft's "viral" effect. GPL requires that modifications and derivative works also be released under GPL if distributed.

The Affero GPL (AGPL) extends this effect to certain "network use": if you modify AGPL‑licensed code and let users interact with it over a network (for example, as a SaaS product), you can be required to make your modified source code available to those users.

By contrast, an open core model splits modification rights by component. Changes to the open source core follow its license terms (typically permissive like MIT or Apache). But proprietary add-ons remain contractually restricted. Users can't modify them without explicit authorization.

Warranty, Indemnification, and Compliance

Open source licenses typically disclaim all warranties. GPLv3 Section 15 explicitly states the software is provided "AS IS" with no warranty of merchantability or fitness for a particular purpose. If the open source program breaks, there's no legal recourse against the licensor.

Dual licensing allows companies to monetize this gap. The commercial licenses in a dual licensing model are negotiated contracts that almost always include additions, such as:

• Explicit Warranties: Assurances about the software's functionality and lack of defects, usually within a specified timeframe.
• Indemnification: A legal promise to defend the end user and provide financial coverage against third-party lawsuits (e.g., patent or copyright claims) stemming from use of the software.
• Support and SLAs: Service Level Agreements that guarantee quick response times and availability.

For example, here's how Veeam's End User License Agreement (EULA) provides a 90-day warranty for its perpetual/subscription license, which doesn't apply to the free and community edition licenses:

And here's Veema's indemnification clause for end users of its paid license, which also doesn't apply to its free/community license:

Put simply, commercial license users in a dual licensing model pay not just for freedom from copyleft obligations, but also for reductions in legal and operational risk. Qt's commercial license, for example, includes high-priority support and compliance building blocks that are absent from the community edition.

In an open core model, the division is a product tier differentiation. The open source core comes "AS IS" under its license terms. Premium tiers then include SLAs, priority support, feature upgrades, and (sometimes) limited warranties on enterprise modules or hosted services.

For customers, that means the legal protections they receive depend on whether the feature they rely on is in the paid layer or the open core. For example, GitLab's premium and ultimate pricing plans include priority support, SLA management, compliance, governance, etc.

The difference isn't about the same code under different licenses but about different products with different service levels.

Which License Model Fits Your Business?

Choosing between dual licensing and open core comes down to which legal structure aligns with your business strategy and risk tolerance. A solid approach is to start with the risks you want to prevent rather than the features you want to sell.

Let's break it down:

Choose dual licensing when you need strong control.

Dual licensing works best for developer-first products (databases, SDKs, infrastructure tools) where competitors can monetize your work by hosting it as a service.

Many companies adopt the AGPL specifically for this reason. Pairing AGPL, which triggers copyleft obligations even for network use, with a commercial license forces competitors to either release their modifications or pay you.

MySQL's success with this model shows its viability. Companies that build proprietary applications pay Oracle rather than expose their source code under the GPL terms. Today, Qt, MongoDB, Elastic, and Neo4j all use some form of the dual licensing structure to stop AWS-style monetization without compensation.

That said, dual licensing requires consolidated copyright ownership through CLAs, which often creates contributor friction. Experts believe dual licensing works best when the copyright holder can maintain development momentum without relying heavily on outside contributions.

Choose open core when broad adoption is your growth engine.

Use an open core model when broad adoption and a clear upgrade path to paid features matter more than strict control over every use of your core code.

Open core also creates a natural upsell path. Users start with the free core, discover limitations, then upgrade for SLAs, proprietary features, priority support, and enterprise controls.

The legal maintenance burden is usually lighter than dual licensing because you're not enforcing copyright boundaries for every commercial exception; you're simply licensing add-ons.

The legal trade-off is maintaining strict architectural boundaries that separate your proprietary features from the core. You also risk bigger players and competitors forking your open source core and building competing products around it.

Redis Labs faced this problem when cloud providers offered managed Redis services using their open core without contributing revenue back, which ultimately pushed the company to relicense under a source-available model.

Your choice ultimately hinges on your competitive moat. If your differentiation comes from the core technology itself, dual licensing protects it. If your moat is execution, integration, or services around the core, open core lets you maximize adoption while monetizing operational value.

Summary

Choosing between dual licensing and open core is a legal decision that shapes your copyright obligations and your relationship with contributors. To recap:

• Dual licensing = one codebase, two licenses. You publish the same software under an open license (ideally, GPL) and a commercial license.
• Open core = an open foundation with proprietary extensions. Different parts of the product sit under different licenses at the same time.
• Dual licensing requires consolidated copyright ownership (or airtight CLAs). Open core doesn't necessarily require it.
• Dual licensing sells exceptions (warranties, indemnity, commercial rights) while open core sells add-ons and service tiers.
• Dual licensing creates clear, mutually exclusive paths; open core requires strict boundary management so proprietary components remain protected.
• Choose dual licensing when you're concerned about competitive pressure or network use (AGPL). Choose open core when you need frictionless adoption, community contributions, and a straightforward premium upsell path.

Before choosing a model, in‑house teams should at minimum:

• Map which parts of the product will be open source vs. proprietary and confirm that copyright ownership and CLAs actually allow that split.
• Identify all third‑party open-source components (and their licenses) and assess whether copyleft or AGPL terms would conflict with planned commercial uses.
• Define a written enforcement and compliance strategy, including how you will respond if major customers or cloud providers violate your license terms or fork your core.