Dual Licensing Explained: How to Balance Open Source Principles with Commercial Profit

It's a common conundrum in the open source world: How can a business use open source software and still make money? Fortunately, the idea that companies committed to open source principles can't be profitable is a misconception

This article explains what open source software is, whether open source principles are at odds with making money, and how to balance open source values with commercial interests.

What Is Open Source Software?

Open source software is software with source code that anyone can access, use, modify, or share. Open source software can be used for both commercial and noncommercial purposes.

Open source principles include transparency, collaboration, freedom to modify and distribute code, and decentralization. Open source software development is public, meaning the community can access, view, and contribute to open source projects. This means that there is no individual or business who owns open source code, making it a community-driven, decentralized form of software development

To be considered truly open source, the software and license must meet the following criteria:

• Allows for free redistribution
• Includes or provides access to the source code
• Allows derived works and allows them to be distributed under the original software's license terms
• The license can restrict the source code from being distributed in modified form, as long as the license allows program modification patch files to be distributed with the source code, and explicitly allows distribution of software built from modified source code
• Doesn't discriminate against individuals, groups, or specific fields of endeavor 
• The program's rights transfer to all recipients without requiring an additional license
• The program's rights can't be specific to a product
• The software license can't place restrictions on any other software that is distributed along with the licensed software
• The license must not depend on or favor any specific technology or interface

The Open Source Initiative (OSI) defines open source software as that which allows for free redistribution and includes the source code, among other criteria

Many developers store open source code in a public repository (repo) that anyone can access, contribute modified versions of the code to, and–as long as permissions allow–share. The rules for what people can and can't do with the open source code depend on the specific license.

Permissive open source licenses like MIT and Apache have minimal restrictions and typically allow people to use and distribute the code as they see fit, while copyleft licenses, such as the GNU General Public Licenses (GPL), often have stricter conditions, such as requiring derived works to be released under the same license as the original software.

For example, the MIT license is short and sweet, giving users permission to use the licensed software without restriction, as long as the copyright notice and permission notice are included in all copies of the software

What Are the Benefits of Using Open Source Software?

With open source software, you can rely on a community of developers and users who are continuously working to update and improve the software. More eyes on the software means bugs get found and fixed faster. Since anyone can contribute to the software, it promotes innovation

Another benefit of using open source software is that it's often available without licensing fees, which can reduce upfront and ongoing costs compared to commercial software.

Are Open Source Principles at Odds With Commercial Profit?

The open source principles of transparency, collaboration, and the freedom to access, modify, and distribute source code are not necessarily at odds with commercial interests

There is nothing inherently against making a profit within open source principles. Successful businesses need to focus on providing value to customers, building revenue, and protecting their intellectual property. You can use open source software to grow your company while staying true to open source principles as long as you abide by open source licensing terms and ensure your business goals align with open source values

The misconception that companies can't use open source software to make money may come from confusion between the definitions of open source software and free software.

The Free Software Foundation (FSF) explains that the word "free" in free software doesn't refer to price, but to users' freedom to run, study, modify, and share the software.

Most open source software is also free software. For example, the FSF publishes the GNU GPL with the purpose of promoting software freedom, but it is also considered an open source license

Both free and open source licenses allow for software to be distributed for any purpose, including commercial purposes. However, depending on the license, there may be certain restrictions concerning how the software can be distributed.

The GPLv3 explains that it grants users the freedom to modify and distribute software as they wish–including for commercial purposes–as long as they provide recipients with access to the source code and a copy of the license terms

Now, let's take a look at how businesses can balance open source principles with turning a profit.

How to Balance Open Source Principles with Commercial Profit

The only thing you're not allowed to do to make money off open source software is charge royalties or licensing fees to access or use open source code. Open source profit strategies can include selling services, warranties, customization, or maintenance work, or licensing the trademark

Balancing open source principles with business objectives can involve selecting the right license, using a dual licensing or open core model, or offering a combination of free and paid services

1. Choose the Right License

Copyleft licenses, such as the GPL or the Affero General Public License (AGPL), have more conditions than permissive licenses like the MIT or Apache licenses. While all open source software can be used for commercial purposes, many copyleft open source licenses require businesses to distribute software under the same license.

When choosing an open source license, there are a few important considerations to keep in mind:

• If your primary goal is making money off your software, you might consider a permissive open source license over a copyleft license, since permissive licenses come with minimal conditions.
• Open source licenses can't include restrictions that require users to register or purchase additional licenses to remove conditions
• If your project involves multiple open source licenses, you'll need to ensure that the licenses are compatible.

Mozilla's Source Code License Policy lists the types of licenses and waivers that are compatible with its Mozilla Public License (MPL), including the MIT, New BSD, and other similar permissive licenses, as well as licenses that are incompatible with the MPL, including the CC-BY, CC-BY-, and the GPL

You might also consider source-available licenses, such as a Server Side Public License (SSPL) or Business Source License (BSL). These types of licenses are based on open source principles but are not considered open source by the OSI as they are too restrictive to meet its requirements.

As with open source licenses, the BSL allows anyone to access, use, modify, or copy the source code, but the BSL doesn't allow the licensed code to be used in production without permission from the licensor. The BSL eventually converts to a GPL-compatible open source license after either four years or an earlier time set by the licensor

HashiCorp's BSL includes an Additional Use Grant that explains that licensees can use the software for production purposes as long as they aren't competitive with HashiCorp's products

MongoDB introduced the SSPL to protect open source projects from poaching by large cloud vendors by requiring anyone using its software as a service to release enhancements to the community

The SSPL is based on the open source GPLv3 and provides users the freedom to use, review, modify, and redistribute source code, but has additional terms for offering publicly available software as a service

Section 13 of the SSPL states that anyone who offers the original software or a modified version to third parties as a service must make the service source code available for free under the terms of the license

MongoDB's software is available for free under the SSPL license, or users have the option of purchasing a commercial license with MongoDB Enterprise Advanced

While these "source-available" licenses share some surface similarities with open source, they are not OSI-approved. The Open Source Initiative is explicit: "The SSPL is not an Open Source License." In practice, this means that software under these licenses may be excluded from major Linux distributions and open source repositories, as happened when Debian and Fedora removed SSPL-licensed MongoDB from their package lists.

Debian's legal review concluded that SSPL violates the Debian Free Software Guidelines, which led to its removal from official Debian repositories, a decision later mirrored by Fedora and RedHat.

A further risk, as OSI and other experts point out, is that dependencies with source-available licenses "may appear to be under open source licenses but come with usage and business model restrictions." This can create unexpected compliance hurdles for downstream users, especially in SaaS and cloud deployment contexts.

Keep in mind that if you restrict access to the source code or prevent users from modifying or redistributing the source code, the software may not be considered open source and may be in violation of open source licensing terms.

2. Use a Dual Licensing Model

Dual licensing is when you offer software under two different licenses, such as an open source license and a commercial license.

Dual licensing works well when you want to give customers who don't want to comply with open source licensing conditions the option to purchase a commercial license

With dual licensing, businesses might offer free use of their software to individual users or small businesses under an open source license, while charging enterprises to use a more business-friendly version of their software under a commercial license

Businesses that use a dual licensing approach often choose copyleft licenses such as AGPL or GPL as their open source license, as they come with more conditions. If users want more freedoms than these licenses allow, they can pay to use a version of the software licensed under a commercial license.

One example of a company successfully using a dual license model for its software is Oracle. Oracle offers its MySQL database server and Client Libraries under the GPL for open source projects. Organizations that want to use MySQL to create and distribute proprietary works without sharing the source code can enter into a commercial licensing agreement with Oracle

As licensing expert Heather Meeker explains, "Dual licensing often refers to the scenario where a developer makes software available under a choice between two licenses… [Alternatively] multiple licenses apply simultaneously… users must comply with the terms of multiple licenses."

This distinction matters because most commercial strategies use the choice-of-license model, while multi-licensing can impose a heavier compliance burden on the user and should be approached with caution.

It's also worth noting that, in community-driven projects, dual licensing can create contributor friction. As one long-time open source participant put it, "Dual licensing feels weird as a contributor… now the 'owner' can use it under a second license, but you… cannot. You feel second class."

If your goal is to maintain active outside contributions, be prepared to address this perception through transparent governance and clear contributor license agreements (CLAs). CLAs allow the copyright owner to relicense code, which is why they're almost always required for dual licensing strategies.

Businesses that want to use MySQL without complying with the GPL terms can purchase a commercial license from Oracle.

If a business offered its dual license product under a permissive license, users wouldn't be motivated to pay for the commercially licensed alternative, as permissive open source licenses already allow users to do pretty much whatever they want with the software

A permissive open source license, such as Apache 2.0, allows users to modify and redistribute software as long as they meet licensing requirements, including providing a copy of the license and a modification notification to recipients

To help visualize the legal distinctions, business benefits, and potential risks, here's a side-by-side comparison of common monetization-related licensing models:

For example, the Mozilla Public License and GNU GPL have been used together in certain projects, requiring simultaneous compliance. While it can ensure broad compatibility, it can also create unexpected legal complexity for downstream users.

Another example of a company that uses dual licensing is Qt. Qt provides an open source version of its software under the GNU Lesser General Public License Version 3 (LGPL) as well as a commercially licensed option

Qt's Obligations of the GPL and LGPL page explains that it uses LGPL as its primary open source license because it provides users with the freedom to run, study, redistribute, and improve its software

Businesses can also purchase a commercial license to use Qt's software, including its development, quality assurance, and design tools.

3. Use an Open Core Model

Using an open core model means offering the "core" version of your software as open source, while proprietary features are available under a commercial license

An open core model can work well when you want to protect proprietary features by requiring paid upgrades to access premium features

For example, GitLab offers two software distributions: the open source Community Edition (CE) and the open core Enterprise Edition (EE). Users who upgrade to its paid plans can access features such as AI code suggestions, release controls, priority support, and unlimited users

GitLab's pricing page lists the features available with its free, premium, and ultimate plans

The open core model has been praised for encouraging adoption and monetizing premium features, but it has also faced criticism within the open source community. Some view it as "open source in name, proprietary in practice," especially if the commercial features are core to product functionality. This is less of a legal risk and more of a brand and trust concern—one that can impact long-term community support.

4. Offer a Combination of Free Software and Paid Services

With this model, you offer your open source software for free but charge for services such as technical support or hosting services

Offering a combination of free software and paid services can be beneficial when you don't want to deal with the complexity of dual licensing or open core models, or if customers are more likely to pay for services such as extra support or consulting than for proprietary software features

As the largest open source company in the world, RedHat serves as a good example of how offering a combination of free software and paid services under an open source license can be successfully implemented. RedHat distributes free open source Linux software, but charges for support services, consulting, training, and certification programs.

RedHat offers free subscriptions to its Enterprise Linux for developers.

Customers can get additional support by purchasing a subscription to RedHat's Enterprise Linux Server.

Summary

Whether you choose to use a dual license model or an open core approach, or offer a combination of free and paid services, there are a few important things to keep in mind when balancing open source principles with commercial profit.

Choosing the right open source license for your software, ensuring your license terms are clear and accessible, and aligning your business goals with open source values can help protect your business, avoid license violations, and attract customers and open source contributors

Open source software is software with source code that anyone can access, use, modify, or share

The benefits of using open source software can include lower costs, more freedom, and stronger community support compared to commercial software

Open source principles include transparency, collaboration, and the freedom to access, modify, and distribute source code.

While open source principles and commercial objectives may seem to be at odds, there's no problem with using open source software to make money as long as you comply with open source licensing conditions and honor open source values

Balancing open source software with commercial profit can involve choosing the right license, employing a dual license model, using an open core model, or offering a combination of paid and free services

Whether you choose to generate revenue through a dual licensing or open core model or offer free and paid services, you'll want to make sure you choose the right open source license for your software, clearly communicate licensing terms, and create a business plan that aligns with open source principles.

The licensing choice you make is not purely a legal instrument, it's also a signal to the community you hope to engage. Expert guidance from practitioners like Heather Meeker, as well as awareness of OSI's formal positions, can help ensure that your business model aligns with both your commercial objectives and your credibility in the open source ecosystem.