Back to blog

// OSSeva Blog

Compliance

RabbitMQ Licence: MPL 2.0, Tanzu RabbitMQ and What You Can Run for Free

Randall McClure8 min read

The short answer

The RabbitMQ server and its tier 1 (core) plugins are licensed under the Mozilla Public License 2.0, according to the LICENSE file in the rabbitmq-server repository. You can download it, run it in production on as many nodes as you like and use it for commercial work without paying anyone. Two things are not free. The first is Tanzu RabbitMQ, Broadcom's commercial edition, which adds features the open source build does not have. The second is the patch releases for any series that has left community support: under RabbitMQ's community support policy, those are not made available to non-paying users, except possibly for very high severity CVEs.

So the licence is not what limits you; the patch policy is. You may legally run RabbitMQ 3.13 or 4.0 for free forever, but once a series is out of community support, the fixes for it go only to commercial customers.

Which licence covers which part

ComponentLicenceSource
RabbitMQ server and tier 1 pluginsMPL 2.0rabbitmq-server LICENSE
Some RabbitMQ server OCF filesApache License 2.0rabbitmq-server LICENSE
Java client libraryYour choice of MPL 2.0, GPL 2 or Apache 2.0rabbitmq-java-client LICENSE
.NET client libraryApache 2.0 and MPL 2.0 (dual-licensed)rabbitmq-dotnet-client LICENSE
Erlang/OTP, the runtime RabbitMQ needsApache License 2.0erlang/otp LICENSE.txt
Community (tier 2) pluginsSet by each plugin's authorEach plugin's repository

RabbitMQ moved to MPL 2.0 with release 3.8.6, published in August 2020. The release notes say the core server and all tier 1 plugins were relicensed from MPL 1.1 and that the permissiveness of the two is "largely the same". Releases up to 3.8.5 still carry MPL 1.1 in their LICENSE file, which matters only if your legal team tracks the exact licence text per version.

Tier 1 plugins ship with the server and only need enabling. Community plugins are separate downloads contributed by other authors, so check the licence in each one's repository before you add it to a build you distribute.

What MPL 2.0 allows and what it requires

MPL 2.0 is a file-level copyleft licence. The obligations attach to the RabbitMQ files themselves, not to the applications around them. In practice:

  • Running it internally: no obligations triggered. Using RabbitMQ as the broker for your own systems, on your own servers or in your cloud account, does not require you to publish anything.
  • Your applications: code that connects to RabbitMQ over AMQP, MQTT or STOMP is not part of the covered software, so it can stay proprietary. For the Java client you choose among MPL 2.0, GPL 2 and Apache 2.0.
  • Distributing RabbitMQ: if you ship RabbitMQ in executable form, for example inside an appliance, an installer or a container image you hand to customers, section 3.2 requires that the source code of the covered files, including any changes you made to them, is available to recipients, with instructions on how to get it.
  • Modifying RabbitMQ files: changes to MPL-covered files stay under MPL 2.0 when you distribute them (section 3.1). New files you write and combine with RabbitMQ can carry any licence you like, because section 3.3 lets you distribute the combined "Larger Work" under your own terms.
  • Hosting it as a service: MPL 2.0 has no network-use clause like the AGPL's. Its source obligations follow distribution of the software, so running RabbitMQ for others over a network does not, on its own, trigger them.
  • Patents: each contributor grants a patent licence for its contributions, with the limits set out in section 2.3.
  • Trademarks: the licence grants no trademark rights. Broadcom owns the RabbitMQ marks, and its trademark guidelines say you may not form a company or name a software product with "RabbitMQ" in it.

This is a summary of the licence text, not legal advice. If you redistribute RabbitMQ inside a commercial product, have counsel read sections 3.1 to 3.4.

What is commercial-only: Tanzu RabbitMQ

Tanzu RabbitMQ is Broadcom's commercial edition. Its commercial features page on rabbitmq.com lists what it adds beyond the open source build:

  • Longer support timelines, with critical patches and CVE fixes for release series after community support ends
  • 24/7 support from the RabbitMQ core engineers
  • FIPS 140-2 compliant TLS, forward proxy support for OAuth 2.0 and continuous CVE scanning
  • Disaster recovery through continuous schema and data replication to a standby cluster, with promotion
  • Distributed shovels, hosted across all cluster nodes
  • AMQP 1.0 over WebSockets, for browser-based clients
  • Intra-cluster traffic compression
  • Audit logging on Kubernetes
  • A stream browser for inspecting stream contents by offset or timestamp

Everything else, including quorum queues, streams, the management UI, federation, the shovel plugin and the MQTT and STOMP plugins, ships in the open source server under MPL 2.0.

Community and commercial support windows by version

The release information page on rabbitmq.com publishes two end dates per series. Broadcom notes that the commercial dates are indicative and that the official lifecycle sits on the Broadcom support portal.

SeriesEnd of community supportEnd of commercial supportStatus on 4 October 2026
4.330 Nov 202630 Apr 2028Community supported
4.231 Jul 202630 Jun 2030Commercial only
4.131 Jan 202630 Apr 2027Commercial only
4.030 Apr 202530 Sep 2026Unsupported
3.1330 Sep 202431 Dec 2029Commercial only
3.1229 Feb 202430 Jun 2025Unsupported
3.1130 Jun 202330 Jun 2024Unsupported
3.1030 Sep 202231 Dec 2023Unsupported

The page adds that older releases not listed are unsupported, which covers 3.8 and 3.9. Note the 3.13 row: its community window closed in 2024, while Broadcom's commercial date runs to the end of 2029, so 3.13 users on the open source build have had no regular public patch releases for two years.

What "community support" means in practice

RabbitMQ's COMMUNITY_SUPPORT.md file, in the server repository, sets the rules. The points that matter for planning:

  • Only the latest minor series of the latest major version is eligible for community support. The file still names 4.0.x as the current example, so use the release information table above for the actual series.
  • Patch releases for older series are available only to users with a Tanzu RabbitMQ commercial licence. The team does not backport fixes to older open source series, even fixes the community contributed.
  • Being in community support is what keeps public patch releases coming. Out of it, patch releases "will not be made available to non-paying users", with a possible exception for very high severity CVEs.
  • The core team has no obligation to answer issues from open source users. Eligible users are regular contributors and users on the latest series who file detailed reports. Responsibly disclosed vulnerabilities, proven data safety risks and nodes failing to start or join a cluster are always investigated.
  • Questions about OAuth 2, TLS, network connectivity and LDAP get little or no attention from the core team unless a systemic problem is shown. The file says guidance on those topics is for commercial customers.

So what can you run for free?

  • The current series, fully patched: run the latest minor series (4.3 today) and upgrade when the next one ships. This is the only free path that keeps receiving public fixes.
  • Any older series, unpatched: MPL 2.0 lets you keep running 3.8, 3.13 or 4.0 indefinitely. You are on your own for any CVE found after the series left community support, and your scanners will keep flagging it.
  • Your own patches: the source is open, so you can backport fixes yourself and build your own packages. That is allowed, and the cost is engineering time plus the Erlang/OTP version pinned to each series.

Options when a series leaves community support

  • Upgrade to the current series. The cleanest answer when it is possible. Moving from 3.x to 4.x means replacing classic mirrored queues, which 4.0 removed, with quorum queues or streams.
  • Buy Tanzu RabbitMQ. The right choice if you need the commercial-only features or want support from the core engineers. Commercial dates run to 2029 for 3.13 and 2030 for 4.2.
  • Use third-party support for community RabbitMQ. OSSeva ships patched, signed builds of community RabbitMQ for 3.8 through 3.13 and the 4.x series, paired with patched Erlang/OTP builds, and runs clusters on your infrastructure on the Operate tier. It does not add the Tanzu-only features. See RabbitMQ support for coverage and OSSeva vs Broadcom Tanzu RabbitMQ for a side-by-side.

For the dates behind each series, see the RabbitMQ end-of-life tracker.

Common questions

Is RabbitMQ free for commercial use?

Yes. MPL 2.0 places no restriction on commercial use, the number of nodes or the size of the company. The obligations start only when you distribute RabbitMQ or modified RabbitMQ files to someone else.

Did Broadcom change the RabbitMQ licence?

Not the licence. The LICENSE file in the main branch of rabbitmq-server still says MPL 2.0, as it has since 3.8.6. What changed is access to patches: the community support policy limits public patch releases to the current series, and fixes for older series go to commercial customers.

Do I have to publish my application code because it uses RabbitMQ?

No. Applications that talk to the broker are separate works. Even if you bundle RabbitMQ with your product, MPL 2.0 lets the combined work carry your own licence, as long as the RabbitMQ files themselves stay available under MPL 2.0.

Can I call my product "RabbitMQ something"?

Not without Broadcom's permission. MPL 2.0 grants no trademark rights, and Broadcom's guidelines suggest forms such as "<product name> for RabbitMQ" instead.

Tags

RabbitMQLicensingMPL 2.0Tanzu RabbitMQEnd of Life

Ready to get your open source under control?

Talk to an OSSeva engineer about CVE coverage, compliance, and migration support for your stack.