Dual Licensing Vocabulary

Dual licensing offers the same codebase under two licenses simultaneously — the user chooses based on their needs and obligations.

How dual licensing works:
• The copyright holder owns 100% of the code (or has collected CLAs from all contributors)
• They publish under AGPL: open source users can use it for free, but must comply with AGPL's copyleft
• They also offer a commercial license: proprietary users pay a fee to use the software without the AGPL copyleft obligation

Why it's economically viable:
• AGPL copyleft is a "forcing function" — companies that can't release source code must pay
• Open source users get the software free, building community and adoption
• Commercial users fund the development

Famous examples:
• MySQL (Oracle): GPL + MySQL Commercial License
• Qt (The Qt Company): LGPL + Commercial License
• MongoDB (historically AGPL before switching to SSPL)
• GitLab EE: MIT (CE) + proprietary (EE features)

Key vocabulary:
• Dual licensing — distributing software under two different licenses simultaneously
• Commercial license — a paid license that typically removes copyleft obligations
• Copyright holder — the entity with authority to offer alternative licenses for the same code
• Copyleft as a forcing function — using copyleft requirements to drive commercial license revenue

Dual licensing and open core are two distinct business models, though both monetize open source.

Dual licensing model:
• One codebase, two licenses (e.g., GPL + commercial)
• Copyleft forces commercial users to pay
• Open source users get the complete product under copyleft
• Revenue from commercial license fees

Open core model:
• Community Edition (CE): permissively licensed or AGPL, freely available, complete for most uses
• Enterprise Edition (EE): adds proprietary features (SAML SSO, advanced reporting, audit logs, etc.)
• Revenue from EE subscriptions/licenses
• The "core" is open; the premium features are proprietary

Examples:
• Dual: MySQL, Qt
• Open core: GitLab (CE + EE), HashiCorp (open source + enterprise), Elastic (open source + paid features)

Hybrid approaches:
• Some companies combine both — e.g., AGPL core + proprietary extensions (open core) + commercial license option (dual licensing)

Key vocabulary:
• Community Edition (CE) — the free, open source version of a product
• Enterprise Edition (EE) — the paid version with additional features for enterprise customers
• Open core — a business model where the core product is open source and premium features are proprietary
• Proprietary add-ons — features available only in the paid edition, not in the open source version

BUSL is "source-available" — the code is visible and readable, but production use is restricted, which disqualifies it from OSI's open source definition.

How BUSL works:
• Source code is published and readable by anyone
• Non-production use (testing, evaluation, local development) is permitted free
• Production use for commercial purposes is restricted for a specified period (typically 4 years)
• After the "Change Date", the license converts to a specified open source license (e.g., Apache 2.0)
• The "Additional Use Grant" can explicitly permit certain non-competing production uses

Why companies use BUSL:
• Protects against cloud providers (AWS, GCP, Azure) offering the software as a managed service without contributing back
• HashiCorp switched Terraform to BUSL in 2023 (triggering the OpenTofu fork)
• MariaDB used BUSL for MaxScale
• Sentry uses BUSL

The OSI open source definition requires:
• Free redistribution
• No restriction of use by field of endeavour (BUSL's commercial production restriction violates this)

Key vocabulary:
• Business Source License (BUSL) — a source-available license with time-limited production use restrictions
• Source-available — source code is publicly accessible but with usage restrictions
• Change Date — the date after which BUSL converts to a standard open source license
• Additional Use Grant — BUSL provision allowing the licensor to permit specific production uses

A commercial license exception is essentially "permission to ignore the copyleft" — the customer pays for the right to keep their application source proprietary.

What a commercial exception typically includes:
• Waiver of copyleft: you can ship proprietary products using the GPL code without releasing your source
• Defined scope: may limit the number of seats, deployments, or specific products
• Support obligations: often includes SLAs, bug fixes, security patches
• Attribution still required: copyright notices must be retained

What it does NOT include (unless explicitly stated):
• Right to sublicense (grant the same rights to your customers)
• Right to modify and redistribute the code independently
• Right to use competitor products made from the same code

Reading a commercial license agreement:
When evaluating a commercial exception offer, check for:
• "Permitted Uses" — exactly what product categories or industries you may use it in
• "License Term" — perpetual vs. annual subscription
• "Distribution rights" — can you ship the library inside your product to your customers?
• "Audit rights" — can the vendor audit your compliance?

Key vocabulary:
• Commercial license exception — a paid license that waives copyleft obligations for a specific customer
• Copyleft waiver — permission to distribute GPL-using software without triggering source disclosure
• License term — the duration and conditions of a paid license agreement
• Sublicensing — the right to grant the same license rights to third parties

Non-compete clauses in licenses violate the OSI Open Source Definition and make software non-open-source regardless of other terms.

OSI Open Source Definition §6:
• "The license must not restrict anyone from making use of the program in a specific field of endeavour."
• Examples of prohibited restrictions: "may not be used in business", "may not be used for genetic research", "may not compete with the licensor"

Why this matters for developers:
• Many vendors market their software as "open source with a commercial exception" when it's actually a source-available commercial license
• The non-compete clause is the giveaway — it's not OSI-compliant
• Tools that claim OSS compatibility may flag this as a violation

How to identify non-open-source "open source":
• Look for: "except for competing products", "except in the same market as licensor", "except for SaaS providers"
• These phrases indicate field-of-endeavour restrictions
• Check the SPDX license list — OSI-approved licenses all appear there
• The Commons Clause and Server Side Public License (SSPL) are examples of frequently criticized non-OSI-compliant licenses

Key vocabulary:
• OSD §6 — the Open Source Definition clause prohibiting field-of-endeavour restrictions
• Non-compete clause — a license restriction prohibiting use in products that compete with the licensor
• Commons Clause — an addendum that adds a "no selling the software" restriction, making licenses non-OSI-compliant
• SSPL (Server Side Public License) — MongoDB's license requiring that SaaS providers using the software also release all service infrastructure code