License change done on a minor release,

[RonaldPhilipsen]

As per the EMQX Licensing FAQ the licence of emqx has changed from Apache to BSL starting with release 5.9.0.

Given your versioning scheme matches SemVer I expected this to be a major release.

[zmstone]

Thank you for your interest in EMQX.

Before finalizing the version number for this release, the EMQX team had extensive internal discussions and ultimately decided to keep it as 5.9 rather than moving to 6.0. Let me briefly explain the reasoning.

While the license change might seem significant, there are no breaking changes in the areas that Semantic Versioning primarily concerns:

• For clients: The supported protocols remain MQTT v3.1.1 and MQTT v5.0, with no changes in behavior or compatibility.
• For administrators:
  • There are no breaking changes to management APIs.
  • There are no breaking changes to configuration files.

For Enterprise Edition users, the license has already been BSL prior to 5.9, so nothing changes for them.
For Open Source Edition users, as mentioned in the Licensing FAQ, there is a seamless upgrade path to the Enterprise Edition without any compatibility issues.

We hope this clarifies the decision.

[RonaldPhilipsen]

Hi @zmstone,

Thank you for your thoughtful response. I recognize that changing a project’s license is never a simple decision, and I appreciate the ongoing work that goes into maintaining EMQX.

As someone who runs a homelab, I rely on open source software to experiment and evaluate solutions before recommending them in any professional context. My workflow involves using tools like Renovate to automatically merge updates that aren’t flagged as breaking changes, with the understanding that I can roll back if needed.

However, with the recent license change to BSL, this approach can unintentionally put users in violation of the new EULA—especially since features like clustering may silently stop working, even though the update appears backwards compatible. This creates a tricky situation for homelab users who want to stay compliant while continuing to test and learn from your project.

[jacaudi]

@zmstone, I would argue that by reducing a feature-set, i.e. removing the ability to run HA multi-server deployments without a license agreement, is a breaking change. You are changing the expected behavior as a result. Just my two cents. Thanks!

[remi-gelinas]

@zmstone, the blog post explaining the license change decision explicitly called out that an agreement would only be needed for "production clustered deployments". Where do homelab users running clustered deployments for evaluation purposes fit into the new scheme?

Although this wasn't meant to be a breaking change, this does remove clustering ability for arguably "non-production" deployments. Was that intentional?

[onedr0p]

For Open Source Edition users, as mentioned in the Licensing FAQ, there is a seamless upgrade path to the Enterprise Edition without any compatibility issues.

@zmstone

This is not true because you revoked the ability to run a cluster of EMQX nodes for "non-production" deployments. I was using EMQX in my homelab with Home Assistant, zigbee2mqtt and other IoT projects. The main reason I choose to use EMQX is because I could scale the broker. Are there any plans to allow this functionality post 5.9.0 for people using it in a non-enterprise/non-production setting or should I explore other solutions?

Instead of completely blocking the feature of clustering for "non-production" maybe allow up to 3 nodes in a cluster for free, without a license? 3 nodes in an EMQX cluster would cover my use case at home and also give others the ability to test or explore using it at work.

[rouke-broersma]

@onedr0p 3 nodes would not allow for upgrades (at least with the default emqx kubernetes operator setup) because it creates 3 new nodes before scaling down the old 3 nodes, so for a HA kubernetes setup you realistically want at least 6 nodes in the free license I think.

@zmstone

For Enterprise Edition users, the license has already been BSL prior to 5.9, so nothing changes for them.
For Open Source Edition users, as mentioned in the Licensing FAQ, there is a seamless upgrade path to the Enterprise Edition without any compatibility issues.

We gain features that are nice-to-have but in the day-to-day not required like SSO on the dashboard, and we lose features that are necessary to keep my partner happy (clustering). This is not a seamless transition and there are compatibility issues.

[notjulian]

I noticed a parallel situation with the recent license change.

Version 5.9.0 changes the license from Apache License 2.0 to BSL, which affects clustering functionality for non-production deployments like homelabs.

For those seeking alternatives that maintain the Apache License 2.0 model, VerneMQ is worth consideration: https://github.com/vernemq/vernemq

P.S.: How long will 5.8.x be supported for security fixes? This information would be helpful for planning purposes. Thanks.

[onedr0p]

@onedr0p 3 nodes would not allow for upgrades (at least with the default emqx kubernetes operator setup) because it creates 3 new nodes before scaling down the old 3 nodes, so for a HA kubernetes setup you realistically want at least 6 nodes in the free license I think.

I was able to run 3 nodes and have HA, it's true that 3 new pods would get created before the old 3 were terminated though.

---

@zmstone The change to BSL already prevents production use of EMQX, so help me understand why go further and limit functionality of the app? I've yet to come across any project that's license under BSL that does that (I'm sure some exist though, it feels rare).

[psych0d0g]

for me it was a breaking change, as my cluster became unavailable after fluxcd updated one of the 3 pods to the new version and it never came up due to license change, leaving my cluster in a semi-broken state and my tasmota home automation devices non functioning aswell.
Even better, i wasted time debugging my nspanel update that i happened to make at the same time the emqx cluster broke, before even suspecting the mqtt service being the culprit...
this was not only a breaking change, but even worse, it was a "makes the wife unhappy" change

[tifawychoi]

The free license prevents me from upgrading to 5.9, the new pod can't start since the old one is still running, and emqx complains there are more than one instance running in the cluster.
But then, it is just a loop:

1. the old one won't terminate until the new one is up and running (1 old + 1 new = 2 instances)
2. the new one can't start because of the single node license limitation
3. the upgrade process can't be completed since the new one is blocked
4. it is even worse if you manually terminate the old pod, the cluster config just breaks

[rouke-broersma]

@tifawychoi you will have to change your configuration to in-place upgrade instead of rolling update before you can update to 5.9 since rolling update effectively creates a cluster which is no longer allowed.

[x3pp]

I found this: https://docs.emqx.com/en/emqx/latest/changes/eol-ee.html, and it shows that the EOL date for version 5.8.x is February 27, 2026.Hope can provide long-term support, including security patches and security bug fixes, for version 5.8.x.
I believe always using the latest version is not necessarily a good idea, especially when 5.8.x already meets most of our needs.
As long as there are no serious security issues, we can continue using v5.8.x. This version has no licensing restrictions, making it ideal for use in a homelab environment.
Version 5.9.0 just does not allow cluster. So is nothing wrong with individual developers, use single node in a homelab environment.

[onedr0p]

and it shows that the EOL date for version 5.8.x is February 27, 2026.Hope can provide long-term support, including security patches and security bug fixes, for version 5.8.x.

Looking at the tag history of this repo, it does not appear like they back-port any changes to previous minor versions or release updates to previous minor versions after a new minor is released. All I am saying don't hold your breath that they suddenly will.

[x3pp]

Looking at the tag history of this repo, it does not appear like they backport any changes to previous versions or release updates to previous major or minor versions.

Yeah, that seems to be the case — but 5.8.6 works just fine for what I need right now.

[Benniu]

Hi everyone,

Thank you all for the thoughtful feedback. We hear you - losing clustering stings, especially when it shows up in a minor release.

License changes are not easy and can stir up a lot of questions and feelings in the community. As the PM of EMQX, I want to be completely open and honest with you about my thoughts and our team's journey on this.

Why we decided to change the license

To be completely honest, we need a sustainable way to keep the project thriving. EMQX has been around for 12 years now, and it's become one of the most popular MQTT brokers out there. We're incredibly grateful for all the community contributions – your ideas, suggestions, bug reports, all of it. That's truly a vital part of our journey.

As you know, EMQX is built with Erlang. It's a fantastic language for a message broker, giving us some serious advantages. But, let's be real, the talent pool is small, and the core work still largely lands on our team's shoulders. New features, bug fixes, striving for 24/7 support – the costs keep climbing. To keep investing and improving, we need a way to generate reasonable revenue. That's the honest truth.

The balancing act and our thinking behind the license change

Was this decision easy? Not even close. We've been wrestling with this for months. We've been trying really hard to balance everyone's interests – community users, commercial customers, and our company's needs. And honestly, even internally, we've had countless discussions between our open-source advocates, developers, and sales team trying to find the right path forward.

The current decision is imperfect, but it’s the best compromise we could see.

For our community users:

• Clusters (≥2 nodes) now need a license key. That hurts, we know.
• On the flip side, everything the Enterprise version had is now yours: 50+ built-in data integrations, the visual flow designer, Cluster Linking, Schema Validation, etc.
• Plus, cool new stuff we're working on, like LLM integration and better data storage, will land in this one unified version for everyone.
• Our feeling is that for many community users, having the full feature set and access to the latest innovations might be more valuable in the long run than free clustering for all use cases.
• To soften the blow for folks using the open-source version for smaller commercial projects or personal businesses, our 'Additional Use Grant' lets you run a single node instance in production for free.
• We also saw some confusion around what 'a single node instance' means. We've updated our FAQ to make it crystal clear: you can run as many single EMQX instances as you like, as long as they aren't clustered together.

For EMQ and the EMQX project:

• This lets us pour all our energy into developing one rock-solid version of the EMQX platform.
• And frankly, we hope that businesses needing clustering features will see the value and choose to support us by purchasing a commercial license.

We know this has an impact, and we want to help

We know this change will affect some of you, and for that, we're truly sorry. We've tried to come up with a few ways to help:

• If you need a free, stable development environment without worrying about infrastructure: You might want to check out our fully managed service, EMQX Cloud. The Serverless Plan offers 1 million free session minutes per month, which is enough for about 23 devices connected 24/7. It's a great way to develop and test without any upfront costs.
• If you're an individual user or hobbyist focusing on self-hosted setups: We really encourage you to upgrade to 5.9.0 and beyond. You'll get a ton of new features. A single node should be plenty for most personal projects and learning.
• If you're running a homelab or in the early stages of developing a solution:
  -- For self-hosting, go ahead and use a single node of EMQX 5.9.0 for your development and prototyping. When you're ready to show it off to potential clients or partners and need to prove scalability or HA with clustering, just contact us to get a free evaluation license for your self-hosted setup.
  -- Alternatively, you could also explore our EMQX Cloud Dedicated Plan, which offers a 14-day free trial. This gives you a fully managed environment for your development and prototyping with clustering and other advanced capabilities.
  -- If things go well with either approach, we'd love for it to turn into a commercial success story together!
• If you're an educational institution or an NGO working on a non-profit project and genuinely need clustering for high availability, please reach out to us. We'll work with you to get a free license.

Our Commitment to Older Versions

And just to be clear: we're committed to maintaining the last major open-source version (EMQX 5.8) with security patches and critical bug fixes.

Finally...

A massive thank you to all of you in the community for sticking with us and supporting EMQX. You've helped us get this far. We really hope you can understand our reasons and continue to help EMQX grow. We also believe that by having a commercially stronger EMQ, we can bring even more value to everyone in the long run.

Please keep the dialogue open. We're listening.

All the best,

Ben, PM of EMQX

[onedr0p]

@Benniu I can't speak for everyone but I could accept using your product under the BSL licence because I'm using it only at home. However I don't see any value in using it at home or test driving it at work when there's a bunch of other FOSS MQTT projects out there (rabbitmq, nats, hivemind, vernemq, mosquitto, etc...) that can be deployed for free with or without clustering.

Given how we've recently seen Redis and Elasticsearch retract their decisions on using a stricter license I hope you all made the right decision here. Good luck, I'm out.

[Benniu]

Hi @onedr0p ,

Thank you so much for taking the time to share your thoughts. I completely understand your disappointment. It’s never easy to see a valued community member decide to step away, and while I'm sorry to hear you're moving on, I absolutely respect your choice.

You're spot on, there are many excellent open-source MQTT brokers out there. But the blunt truth is that EMQ faces the same sustainability squeeze that’s hitting a lot of 'infra projects'. That's why NATS is talking about pulling the project back from CNCF and relicensing, and Mosquitto maintains its open-source single-node version while its Pro version with HA is, if I recall correctly, a commercial offering by Cedalo. And I have a lot of respect for companies like HiveMQ and VerneMQ too, and while I don't have direct insight into their day-to-day, I imagine they are also navigating these commercial realities.

I want to be clear: I'm not dunking on any of them. Far from it. As someone who's been in the open-source commercialization world, I think there's a shared understanding of the tough choices involved when trying to sustain a project long-term. Projects like RabbitMQ, backed by a tech giant, are a different story.

And you've hit on a really important question: with so many FOSS options, what's the unique value EMQX brings? And would just keeping clustering free have been enough to make EMQX stand out? I actually don't think so.

My firm belief, and the core of our strategy, is that what truly differentiates EMQX and will continue to do so is our relentless focus on innovation that goes beyond just being an MQTT broker. It's about pushing the boundaries, integrating with new technologies, and solving broader IoT data challenges. Clustering is an important feature, absolutely, but it's not the only pillar of our value. To pursue that kind of deep innovation, we need to focus our very limited resources effectively and achieve a level of commercial success that allows us to reinvest heavily into developing these groundbreaking features for EMQX.

Thank you again for all your past support and for being part of the EMQX journey. Even if you're switching for now, I truly hope you'll keep an eye on what we're doing. Maybe one day, a new version or a new feature will give you a compelling reason to come back.

P.S. On a related note, if you are looking for an open-source MQTT broker, our NanoMQ project is donated to the LF Edge Foundation and uses the MIT License. It might be worth a look for some of your use cases!

All the best,
Ben

[onedr0p]

@Benniu

Not sure if your info is up-to-date but NATS and the CNCF has come to an arrangement, which is a major win for the open source community.

https://www.cncf.io/announcements/2025/05/01/cncf-and-synadia-align-on-securing-the-future-of-the-nats-io-project/

[Benniu]

@Benniu

Not sure if your info is up-to-date but NATS and the CNCF has come to an arrangement, which is a major win for the open source community.

https://www.cncf.io/announcements/2025/05/01/cncf-and-synadia-align-on-securing-the-future-of-the-nats-io-project/

Thank you for the update. Glad to see they reached an agreement. The IP of projects donated to a foundation should be respected. As always, we will continue our investment in the two open-source projects to which we have contributed: NanoMQ and eKuiper.

[rouke-broersma]

@Benniu

My firm belief, and the core of our strategy, is that what truly differentiates EMQX and will continue to do so is our relentless focus on innovation that goes beyond just being an MQTT broker. It's about pushing the boundaries, integrating with new technologies, and solving broader IoT data challenges. Clustering is an important feature, absolutely, but it's not the only pillar of our value.

Yet it is the only feature that I personally need, and it is the only feature you restricted in the new licensing scheme. I appreciate that you need revenue to continue to exist and I fully support that. I just don't understand why you place the biggest restriction on users that would have never moved to Enterprise in the first place.

In think you're misunderstanding homelab users here. We are talking about users using EMQX with their smart home solution, these users will never move to a paid license and bar clustering support and a nice dashboard EMQX offers nothing extra of value to these users under the new license. All these users need - including myself - is super duper simple MQTT to turn lights on and off. Using clustering so that I can do rolling updates. I don't even really need clustering, I just need the ability to update without my home going offline. Now I'm not going to pretend that these users are a big customer funnel where because they use it at home they are now going to recommend using it at work, that's not realistic. It's not realistic to see this as a potential revenue stream at all. Which is also why it doesn't make any sense to restrict features they use behind a license for public pricing isn't even available. It also doesn't make sense to recommend that homelab users request a trial for 15 days. A homelab is not a potential production environment, it is not a testing bed for potentially commercial products. It's something you setup in your home. Maybe I'm missing something, but I just don't see the value of restricting non-commercial use of clustering. It'll never lead to increased sales, nor really decreased sales either.

[mikeyyuen]

Personally, I would be happy to pay a reasonable one time fee for a home lab license covering 5.x and 6.x versions. Home labs are never going to be a high earner for EMQX as it’s a personal “lab”, no one is really making money from their home lab, if I were i’d be more than happy to pay a commercial license.

Is that something EMQX might consider?

[zmstone]

but I just don't see the value of restricting non-commercial use of clustering. It'll never lead to increased sales, nor really decreased sales either.

Thank you for sharing your thoughts.
I just want to quickly add that, it was never the agenda/intention to convert homelab (or any single-node users) into paying customer.
For single node users, you are welcome, enjoy more features for free.
For us, we no longer need to maintain two flavors of releases (configuration, tests, build scripts, release pipeline, artifacts, etc. etc.)

[jingshui127]

看来对于个人用户来说。还是直接焊死在5.8版本得了。

[psych0d0g]

i think the reason why emqx was becoming so popular was partly the ability to setup a cluster that keeps mqtt running on updates etc, loosing that feature, at least for me, deems open-source products as more suited for my homelab, since all the other features you guys promote would just add unnecessary bloat anyways.
so personally i will potentially switch back to mosquitto where i came from in the first place, since its kiss and one-tool for the job, without licence related tradeoff's that i would have happily made if the one core feature that made me switch to emqx (clustering) would be included :)

this is my final thoughts on this matter, wish you all the best for the future

[mooooooonkey]

Let me translate the BSD open source agreement: "You are forbidden from even thinking about using my software to make money." This is basically the most restrictive agreement, allowing only internal single-node use, which is meaningless. Why not just close the source?

[takarabt]

Hi @zmstone
Could you please confirme the EOL date for 5.8.x LTS ?

• Aug 27, 2027 https://docs.emqx.com/en/emqx/latest/changes/eol-ee.html
• February 2026 https://www.emqx.com/en/news/a-notice-on-the-emqx-5-8-open-source-version

Regards.

[zmstone]

Hi @takarabt

To clarify, the dates differ because they define the lifecycle of the official binary releases and support:

• February 2026: End of Life for official Open Source package downloads.
• August 27, 2027: End of Life for Enterprise edition support and packages.

How this works in the repository: Since we have moved the Enterprise code (BSL license) into this public repo, the release-58 branch is shared.

We will continue to push both v (Open Source) and e (Enterprise) tags to release-58 until 2027.

However, after Feb 2026: We will stop building and publishing official downloadable packages for the v tags.

The source code remains fully available. You can can continue to use the Open Source edition by checking out a v tag and building the package yourself using the emqx-builder images.

emqx-builder images are maintained here: https://github.com/emqx/emqx-builder
You can inspect the latest image tags by cloning the repo and run ./show-latest-images.sh

5.8 is on Erlang/OTP 28, so you should pull a 26 image such as ghcr.io/emqx/emqx-builder/6.0-4:1.15.7-26.2.5.14-1-ubuntu24.04, and:

• run make emqx-tgz, then you'll find the .tar.gz package in _packages/emqx/
• run make emqx-pkg, then you'll find the .deb or .rpm package in _packages/emqx/
• run make emqx-docker to build dockage image

[matthijsvdr]

Kinda late to the party, but only recently learned about the change. For me personally I use my homelab to learn and try things. Spending a lot of time making everything Highly Available and as robust as possible. Do i need all of that? No, do i want to learn? Yes.

If there is no way to do this with EMQX ill probably move away to another solution. Now EMQX might not care about this use case because it will never make them any (or very little) money.

But .....

I think you (EMQX) are missing a vital part. I work in IT / develop software / manage infra structure as my job (as i expect many here). When time comes to pick a MQTT solution at work the top contenders will always be the solution people have experience with. If i have experience with EMXQ (configuration and management) at home in a cluster setup then EMQX is a top contender. However if I go with another MQTT solution at home then its very likely that we will go with another solution at work and EMQX will miss out. Right at the moment where money could have been made.

Anyway I hope the EMQX team reads this and thinks about offering something for those in a Homlab.