The Hidden Battle Over Open‑Source Licenses: Why Companies Switch to Community Licenses

Recent shifts in open‑source licensing

In late 2018 several high‑profile projects altered their licensing to protect revenue from managed cloud services:

Confluent moved from Apache 2.0 to the Confluent Community License for parts of its Kafka platform.

AWS launched a managed Kafka service at the same time.

Redis Labs re‑licensed a plugin under the Commons Clause.

MongoDB replaced its AGPL license with the Server Side Public License (SSPL).

CockroachDB introduced the CockroachDB Community License.

All of these changes aim to preserve the vendors' monopoly on hosted offerings and to mitigate the competitive pressure from public‑cloud providers such as AWS, GCP, and Azure.

Key sources of community frustration

Vendors claim a product is “open‑source” while the license imposes usage restrictions.

Open‑source contributions are solicited under a permissive license, then the license is changed to a more restrictive one.

A perceived “mid‑life crisis” in open‑source where projects migrate from permissive to limited licenses.

These practices erode trust because the community sees the license change as a bait‑and‑switch that limits downstream freedom.

Copyleft versus permissive licensing

Two philosophical views are contrasted:

Copyleft ("crusader" view) : aims for universal sharing but can create evolutionary dead‑ends because every derivative must retain the same license, limiting commercial exploitation.

Permissive (MIT, Apache 2.0) : allows downstream projects to re‑license under any terms, fostering broader adoption and ecosystem growth.

From a practical standpoint, permissive licenses tend to attract larger contributor bases and more integrations, while copyleft licenses may restrict use in large enterprises that forbid AGPL/SSPL.

InfluxData case study

InfluxDB was launched under the MIT license. In early 2016 commercial pressure forced the clustering and high‑availability features into a closed commercial license. The company later experimented with AGPL for the UI component (Chronograf) but reverted to MIT to encourage community contributions.

The open‑source collector Telegraf, also MIT‑licensed, attracted hundreds of plugins from both InfluxData and competing projects. This demonstrated that a permissive core can drive ecosystem growth while the company monetises value‑added services (e.g., managed InfluxDB SaaS, enterprise clustering).

Proposed hybrid licensing model

A pragmatic approach combines:

Core codebase released under a permissive license (MIT or Apache 2.0) to maximise community contributions, plugin ecosystems, and downstream adoption.

Value‑added features (e.g., clustering, high‑availability, managed service) offered under a separate commercial license or SaaS subscription.

This model lets developers freely build on the core while giving the vendor a sustainable revenue stream through proprietary extensions or hosted services.

Implications for open‑source strategy

Adopting a hybrid model acknowledges that:

Purely permissive licensing does not preclude commercial success if the company can monetize services.

Restrictive community licenses (AGPL, SSPL, “community” licenses) often limit adoption in enterprise environments and can fragment the ecosystem.

Maintaining a clear separation between open‑source and commercial components reduces community backlash and legal uncertainty.

Overall, a balanced licensing strategy—open core plus optional closed extensions—supports both a healthy community and a viable business model.

Original source: https://dzone.com/articles/copyleft-and-community-licenses-are-not-without-me