Part of Red River WestPart of Red River WestLearn more →

Open Source Software Licenses: How to choose the right one for your business?

Abel Samot — March 26, 2025

The Basics of Software Licenses

Open Source licenses fall into two main categories: permissive licenses and copyleft licenses. This article also addresses fair code licenses, which aren't truly Open Source but offer comparable advantages.

Permissive Licenses: These allow software to be used, modified, and distributed with minimal restrictions. Examples include MIT License, Apache License 2.0, and BSD License.

Copyleft Licenses: These impose restrictions ensuring derivative works are distributed under the same license. If you build software derivative of a copyleft-licensed project, it must be Open Source. The GNU General Public License (GPL) is the best-known copyleft license.

Fair Code Licenses: Fair code licenses aren't Open Source because they impose usage restrictions, typically prohibiting commercial use without permission. Companies choose fair-code licenses to ensure software remains freely available for non-commercial use while requiring commercial users to pay, and to prevent cloud providers from repackaging and redistributing their products for financial benefit.

If you choose a fair-code license, remember you won't be an Open Source company, so don't communicate as one. Avoid changing existing projects to fair code, as you risk losing community members and breaking user trust.

MIT and Apache 2.0 are the most popular licenses, both permissive. Among Commercial Open Source companies, over 70% use permissive licenses and less than 5% use fair-code licenses. However, among the top 10 biggest Open Source companies by valuation, only 3 have permissive licenses, while 4 have copyleft licenses and 3 have fair-code licenses. Some have recently switched to less permissive licenses, creating community tension.

Why You Should Choose Wisely: A Few Examples

Open Source licensing decisions have significantly impacted several companies over the years.

Docker represents an iconic Open Source success story regarding adoption but also a famous case of monetization struggles. Using Apache 2.0 for its core container runtime allowed cloud providers like AWS, Google Cloud, and Azure to integrate Docker into their managed services without compensating the company. While Docker became synonymous with containers, the company faced severe financial difficulties, eventually restructuring and selling its enterprise business to Mirantis in 2019.

Several major Open Source businesses attempted to avoid similar issues by switching from Open Source to fair code licenses, but alienated their communities in the process.

HashiCorp: In 2023, HashiCorp switched Terraform from Mozilla Public License (MPL) to Business Source License (BSL), restricting commercial use. This sparked significant community backlash over the sudden licensing shift.

Elasticsearch: Elasticsearch switched from Apache 2.0 to SSPL in 2021 to prevent cloud providers from offering its services without contributing back. This led to a fork into OpenSearch. Due to community backlash, Elastic eventually dual-licensed under both Elastic License 2.0 and SSPL. OpenSearch continues thriving as a fully Open Source alternative maintained by AWS and the community, and Elastic lost significant community trust.

Confluent and MongoDB made similar changes, always resulting in strong community backlash. Notably, none of these companies experienced notable revenue growth rate changes after switching licenses. Some, like HashiCorp and Confluent, actually saw negative valuation impacts from licensing changes.

Choosing the Right License for Your Open Source Business

Your license choice should align with your business model and strategic objectives. Here are the primary license categories with their characteristics:

Permissive Licenses

Who Should Use Them:

  • Companies seeking broad adoption: Permissive licenses maximize distribution and use, encouraging adoption in proprietary projects. This builds user bases and ecosystems quickly.
  • Companies with clear monetization strategies: If you don't primarily rely on hosting/SaaS and have established monetization methods that won't be significantly undermined by others forking or reselling your project, permissive licenses boost adoption.

Viable Business Models with Permissive Licenses:

Open-Core: Open Source your product's core using a permissive license and sell paid features for enterprises.

Open Peripheral: When your main product is closed-source but you distribute some tools as Open Source to build community engagement.

Consulting/Services: When monetizing through support for Open Source projects, permissive licenses help build large potential customer bases.

When to Avoid Permissive Licenses:

  • If you want modifications and improvements shared back with the community, permissive licenses may not suit your goals.
  • If you lack significant competitive advantages from community, closed-source features, or team expertise, competitors could easily create competing versions.

Choosing the Right Permissive License:

MIT License: Best for simplicity and broad compatibility. Most permissive, requiring only original license and copyright notice inclusion.

Apache License 2.0: Ideal when patent protection matters. Includes patent grants protecting you and users from lawsuits.

BSD License: Similar to MIT but provides control over how your product's name and contributors' names are used for promotion.

Copyleft Licenses

Who Should Use Them:

  • Companies wanting to ensure modifications remain Open Source: Copyleft licenses enforce that all derivative works are also Open Source.
  • Companies preventing proprietary forking: Licenses like GPL prevent companies from taking Open Source code, modifying it, and releasing proprietary versions.

When Should You Avoid It?

  • If you want your software used in proprietary environments. Google avoids copyleft code because it requires modified or derivative work to be Open Sourced.
  • If your business model involves dual licensing, you might prefer permissive licenses to avoid managing complex copyleft obligations.
  • If you want to avoid legal complexity.
  • If significant revenue depends on hosting/SaaS, particularly AGPL, which could force Open Sourcing components you prefer keeping proprietary.

Choosing the Right Copyleft License:

GNU GPL: For strong copyleft enforcement, ensuring all derivative works remain Open Source under the same license.

GNU AGPL: For networked environment software, requiring source code availability to users interacting with the software over networks.

LGPL: For libraries that might link with proprietary software without requiring proprietary code to be Open Source.

MPL or EPL: For file-level or weaker copyleft requirements. Best for infrastructure/developer tools targeting B2B with broad adoption goals.

Fair-Code Licenses

Who Should Use Them:

  • Companies deriving majority revenue from hosted product versions: SSPL effectively protects against cloud provider exploitation.
  • Companies with uncertain monetization strategies: If you want Open Source benefits without needing extensive contributors. Starting with fair-code and moving to permissive is better than reversing.
  • Companies wanting time-limited commercial protection: Business Source License (BSL) protects initial development while automatically transitioning to more permissive licenses.

When Should You Avoid It?

  • If widespread adoption is your priority.
  • If you aim to form partnerships or integrate with commercial platforms.
  • If you need substantial community contributions, as many Open Source contributors avoid fair-code projects.
  • If you want to call your product Open Source. Fair-code isn't Open Source.

Choosing the Right Fair-Code License:

SSPL: When preventing cloud providers from offering hosted versions without contribution is your primary concern.

SUL or RSAL: When you want to restrict commercial use and require businesses to pay while allowing free non-commercial use.

BSL: When you need commercial protection periods before fully open-sourcing.

Dual Licensing

If you want the best of both worlds, release part of your software under Open Source licenses and part under commercial licenses. This is particularly useful for open-core businesses. If possible, use permissive rather than copyleft licenses for the "Open Source" part.

Who Should Use Them:

  • Projects requiring both Open Source engagement and commercial flexibility: Dual licensing is particularly useful when you want to build a strong Open Source community while monetizing from closed-source features or products.
  • Projects wanting to ensure enterprise companies using their code contribute financially while maintaining a genuine Open Source version.

Drawbacks of Dual Licensing:

  • Increased complexity managing different licensing agreements. When Semgrep removed critical engine features behind commercial licenses, a consortium built a competitor based on their Open Source version: Opengrep.
  • Potential company avoidance due to legal and compliance concerns.
  • It may be perceived as restrictive, deterring some developers.

License Enforcement and Differences Across International Borders

When selecting a license, consider that copyright laws and enforcement mechanisms vary internationally. What works in one jurisdiction may have different implications in another.

In the United States, Open Source licenses have strong legal backing through copyright law. Courts have generally upheld these licenses as valid legal agreements.

The European Union provides similar protections, though with regional variations. Germany stands out as particularly favorable for license enforcement, with several successful GPL compliance cases. France created the CeCILL license (by CEA, CNRS, and INRIA) as an adaptation of international Open Source licenses to comply with French law.

The situation becomes more challenging in parts of Asia, Eastern Europe, and South America. In China, copyright enforcement for software generally remains inconsistent. Russia similarly presents limited legal recourse for foreign copyright holders.

Most successful enforcement doesn't involve courtrooms. Organizations like the Software Freedom Conservancy typically start with educational outreach and compliance assistance.

When planning your licensing strategy, consider not just theoretical protections a license offers, but how practically enforceable it will be in your target markets.

Conclusion

Selecting the right Open Source license is a critical decision influencing any Open Source business's trajectory. There is no one-size-fits-all answer; choose based on your business model, needs, and threats. Making the right choice from the start and communicating about it is very important. If you're considering building an Open Source business, think about it thoroughly.

Originally published on Substack