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

The question tests understanding of how a license explanation is delivered during a code review. The correct answer highlights that the reviewer is accurately communicating the dual-licensing terms – AGPL and commercial. Misconceptions here often involve thinking the reviewer should be discussing *why* the licensing exists, which is outside the immediate scope of a code review comment.

This exercise checks if the user understands that 'dual licensing' means *both* licenses are available. The key here is that Alice's question demonstrates she recognizes there are two distinct options (AGPL and commercial), even if she doesn't know what those differences entail. The incorrect answers reflect a misunderstanding of what constitutes a dual-licensing model.

This tests whether the user understands how licensing information should be communicated within a PR. The description correctly identifies the key aspects: copyleft license *and* a commercial exception. The other options highlight common misunderstandings – failing to acknowledge the dual nature or using overly technical language without explanation.

This assesses understanding of how dual-licensing is explained in a common communication setting. David's statement accurately defines the dual-licensing arrangement: AGPL for open source and commercial for proprietary use. The other options demonstrate misunderstandings about what constitutes a clear explanation of the licensing terms.

This scenario tests whether the user can interpret technical information (an API response) related to dual licensing. The API clearly states both license types and their terms, presenting an accurate summary of the dual-licensing model. The other options reflect a misunderstanding of how such data is presented and utilized in a developer context.