OSS commercial license: AGPL vs BSL vs Elastic

When you publish an open source project, you must choose how to protect yourself from those who profit from your efforts without contributing. Not all licenses are equal: AGPL, Business Source License, and Elastic License offer three different strategies for commercial copyleft. In this article we analyze the trade-off between community freedom and economic sustainability for software maintainers.

What is a commercial open source license?

A commercial open source license is an agreement that allows you to distribute software for free for non-commercial use (or with restrictions), but requires payment or special compliance when the software is used in a business context. The objective is twofold:

1. Economic sustainability: whoever maintains the project can monetize without closing the source code.
2. Community protection: modifications made remain accessible to those entitled to access.

The distinctive feature is copyleft — a legal mechanism that obligates anyone using the software to respect the same freedoms as those who inherit it. If you modify the code, you must share the modifications with the same terms.

AGPL: the most aggressive copyleft

AGPL (GNU Affero General Public License) is a variant of the GPL that closes the so-called "network loophole" — the hole through which users of GPL software via the network (like SaaS) could avoid releasing modified code.

With AGPL, if you modify the software and use it on a server reachable over a network (including SaaS), you must share the source code with all users who access it. It is the strongest copyleft:

AGPL v3 - Main obligations:
1. Provide source code to anyone who requests it
2. If you modify, you must release the modifications
3. If you use over network, you must share the code with end users
4. Maintain the same license in perpetuity
5. Explicitly declare significant modifications

Real-world case: Nextcloud uses AGPL for the core. Any fork or client-server modification remains AGPL, preventing cloud providers from creating proprietary versions without releasing the code.

Pro AGPL

• Maximum protection for developers: no proprietary derivatives in SaaS.
• Strong community: all improvements return to the project.
• Clear ethical position: freedom for all or nothing.

Con AGPL

• Legal toxicity: many companies refuse to depend on AGPL for fear of contamination.
• Reduced adoption: the ecosystem tends toward MIT/Apache 2 for legal simplicity.
• Compliance costs: code auditing can be expensive for large companies.
• No direct revenue: it is a purely open source license.

BSL: Business Source License (or SSPL)

BSL (Business Source License), often confused with SSPL (Server Side Public License), is a "source available" model that starts proprietary and becomes open source after a period.

The idea: code is public and modifiable, but with temporary commercial restrictions. After N years (typically 2-4), the license automatically converts to a permissive open source license (MIT, Apache 2, etc.).

{
  "name": "example-project",
  "license": "BUSL-1.1",
  "conversionDate": "2029-01-15",
  "restrictions": {
    "prohibited": [
      "Competing with the original project",
      "Providing as managed service without permission"
    ],
    "allowed": [
      "Internal use",
      "Modifications for personal use",
      "Contributing back to original"
    ]
  },
  "commercialLicenseAvailable": true,
  "commercialLicenseUrl": "https://example.com/commercial-license"
}

Real-world case: CockroachDB and Sentry use BSL. Code is visible, community can contribute, but operating a competing SaaS is forbidden until the conversion period.

Pro BSL

• Revenue-friendly: protects a SaaS/managed service model without proprietary forks.
• Community trust: code is visible, restrictions are temporary and explicit.
• Clear roadmap: you know it will become "pure" open source after N years.
• Growing adoption: companies like Elastic, HashiCorp have adopted it.

Con BSL

• Legal complexity: what does "competing" mean? Disputes are expensive.
• Community friction: feels limiting, especially if the period is long (4+ years).
• Not OSI-approved: it is not formally "open source" until the conversion period.
• Risk of contention: suppliers wanting to operate in "gray zone" can contest the terms.

Elastic License: Elastic's hybrid license

Elastic License (used by Elasticsearch, Kibana, Beats) is a dual license approach:

1. For non-commercial use (community): AGPL license (or SSPL in Elastic's case).
2. For commercial use: Elastic License (proprietary but reversible to AGPL).

The code is public, but "premium" features (security, monitoring, machine learning) are disabled in the AGPL version and only enabled with a commercial Elastic License.

# elasticsearch/license.yml
# Community version: AGPL, limited features
license_type: basic
features_available:
  - indexing
  - search
  - monitoring: disabled
  - machine_learning: disabled
  - security: basic
---
# Commercial version: Elastic License
license_type: platinum
features_available:
  - indexing: true
  - search: true
  - monitoring: advanced
  - machine_learning: enabled
  - security: advanced
  - compliance: soc2, pci-dss

Pro Elastic License

• Clarity: the community knows exactly what is free and what is paid.
• Predictable revenue: feature tracking and upsell are easy.
• Trust: the "engine" remains AGPL, only advanced features are proprietary.

Con Elastic License

• Fork risk: the community can fork the AGPL version and implement missing features.
• Maintenance overhead: managing two versions is expensive.
• Perceived fairness: some see it as paywalling basic features.

Comparative table

When to use AGPL

Choose AGPL if:

• Your project is infrastructure-level (database, cache, monitoring).
• You want maximum ideological protection from proprietary lock-in.
• Your business model is consulting/support, not SaaS.
• You can tolerate reduced adoption among enterprises.

Examples: Nextcloud, OSQA, Zulip (partly), Redis Streams (before switching to SSPL).

When to use BSL/SSPL

Choose BSL if:

• You want to operate a SaaS/managed service model without proprietary forks.
• You accept sharing the code, but with temporary restrictions.
• Your strategy is "source-available → pure open source" after N years.
• You want growing revenue but community involvement.

Examples: CockroachDB, Sentry, HashiCorp (Terraform), Supabase (partly).

When to use Elastic License

Choose Elastic License if:

• You have a base open source project with paid premium features.
• You want a clear separation between community and commercial tiers.
• Your revenue model is per-feature upsell or hosted SaaS.
• You can manage two versions of code in parallel.

Examples: Elasticsearch (now Elastic), Mattermost, Gitea (partly).

Hybrid pattern: Dual Licensing AGPL + Commercial

A sophisticated approach is to offer two licenses simultaneously:

Open source version:   AGPL (strong copyleft)
                       ↓
Commercial license:    Proprietary or permissive
                       (available for payment)

Example: Developer internal to your project
  → Modifies code locally
  → If using AGPL: must share modifications
  → If buying commercial license: no copyleft

This allows:
- Free community (AGPL)
- ISVs/companies who want to close the code (commercial license)

Real-world case: Qt has used this model for years. Free LGPL version, proprietary commercial version.

Legal impact: compliance and disputes

Regardless of the license, you must consider:

Enforcement

Who violates the license? How do you identify it? Many open source projects lack resources for litigation. Consider:

• Funding for legal defense (Conservancy, Software Freedom Conservancy).
• Preventive compliance: document clearly what is permitted, with examples.

Derivative works

What counts as a derivative? With AGPL, if you embed the library in your SaaS and modify even one line, your entire codebase must become AGPL. Evaluate:

• Classpath exception: allow linked code to remain proprietary.
• API separation: explicitly define which APIs are "copyleft boundary".

Internationalism

Open source licenses were drafted mostly under USA law. In the EU, GDPR and software regulations add complexity. Consult a lawyer if your audience is significantly European.

Case study: Redis and the switch to SSPL

In 2024, Redis abandoned BSD (permissive license) to switch to SSPL. The reason:

• Cloud services (AWS, Google Cloud) offered Redis as a managed service.
• Redis Maintenance Company was not getting significant revenue.
• SSPL protects the SaaS business model.

Community reaction: open fork (Valkey under ELv2), debate about freedom vs. sustainability.

Lesson: Choose the license from day 1. Changing it retrospectively (especially toward more restrictive licenses) alienates the community.

OSS Sustainability series roadmap

In the next articles we will explore:

• Dual licensing in practice: how to manage repositories with AGPL + Commercial
• Revenue models: support, training, premium hosting
• Governance: foundation (CNCF, Apache) vs. single-vendor projects
• Security auditing: when Open Source becomes a legal advantage
• Trademark & branding: protecting your project name

Frequently Asked Questions (FAQ)

Can I switch from MIT to AGPL retroactively?

Not legally. Once released under MIT, the code remains MIT forever (it is irrevocable). You can however license new code under AGPL. This creates a "mixed" codebase — complex to manage. Lesson: choose from the beginning.

If I modify an AGPL project internally, must I release the code?

It depends on deployment. If you modify locally and use only internally (not as a service), the answer is no. But if you expose it over the network (internal SaaS), AGPL obliges you to share the code. "Network" includes internal APIs, VPN, etc.

Which license is best for attracting investment?

It depends on the fund. Traditional VCs prefer BSL or Elastic License (clear revenue path). Impact/open source funds accept AGPL if the business model is sustainable. No "absolute best" exists.

Is AGPL really "toxic"?

Legally no. But historically, large companies have avoided AGPL for fear of contamination (worry that AGPL will "infect" proprietary code). This is largely a legal myth — with proper architecture (process separation, API boundaries), the risk is minimal. But the myth persists.

Can I use Ollama to generate license compliance documentation?

Yes, you can use Ollama locally (model `llama3.1:8b` or equivalent) to generate compliance checklists, term templates, and license compatibility analysis across dependencies. Don't rely on cloud AI for this: use your on-prem model to maintain privacy.

Conclusion

There is no universally "right" license for commercial open source. The choice depends on your business model, the community you want, and the ethical position you want to take. AGPL is the maximum of freedom (at the cost of reduced adoption), BSL is the practical compromise (revenue + community), Elastic License is the clear separation (free base, paid premium).

The key is to communicate your choice clearly, from day 1. An unexpectedly restrictive license, introduced years later, burns the community. Choose with conscience and maintain consistency.