HashiCorp BSL License Change: Risks for Consul Users and a Nacos Migration Guide

Background: HashiCorp BSL License Change

In August, HashiCorp announced that future versions of many of its products will move from the Mozilla Public License v2.0 (MPL 2.0) to the Business Source License (BSL) v1.1. The change affects Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint and Vagrant. Existing versions released under MPL 2.0 remain usable, but they will no longer receive updates, bug fixes, or security patches after 2023‑12‑31.

Implications for Users

The BSL is a hybrid license that is not considered open source because it restricts commercial use during a “source‑available” period. After the period expires the code must be re‑licensed under a GPL‑compatible license. For HashiCorp products the BSL forbids providing the software as a hosted or embedded service that competes with HashiCorp’s paid offerings. This creates legal uncertainty for enterprises that run Consul, Terraform or other tools in production.

How Other Companies Use BSL

MariaDB – MaxScale may be used free on up to three production nodes; more requires a commercial license.

Couchbase – Commercial‑or‑profit use, including SaaS offerings, is prohibited.

Lightbend – Akka is free for development and testing; companies with revenue under $25 M can obtain a free production license.

HashiCorp – Production use is allowed only if the software is not offered to third parties as a competing hosted service.

Choosing an Alternative Registration Center

Because Consul’s BSL limits commercial deployment, the article compares four popular service‑discovery solutions: Nacos, Consul, Eureka and ZooKeeper. The comparison criteria are license restrictions, CAP properties, reliability features and ecosystem support.

Nacos scores highest on all criteria, making it a strong candidate for organizations seeking a permissively licensed, cloud‑native registry.

Nacos Overview

Nacos is a cloud‑native dynamic service‑discovery, configuration‑management and service‑management platform. It supports private, hybrid and public clouds and provides a plugin‑based architecture for extensibility.

Migration Path from Consul to Nacos

The recommended approach uses Nacos Sync , a Spring‑Boot‑based tool that synchronises service data between Consul and Nacos.

Install Nacos Sync and configure source (Consul) and destination (Nacos) clusters.

Update service‑consumer configurations to point to Nacos; roll back if issues arise.

Update service‑provider registrations to use Nacos; roll back if needed.

After verification, decommission Consul and Nacos Sync.

clusters:
  - clusterName: dst
    connectKeyList:
      - {nacos.endpoint}:8848
    clusterType: NACOS
  - clusterName: src
    connectKeyList:
      - {consul.endpoint}:8500
    clusterType: CONSUL
    namespace: ''
tasks:
  - source: src
    destination: dst

Using Alibaba Cloud MSE for a Managed Nacos Instance

MSE provides a fully managed Nacos cluster. The migration consists of two steps: evaluate the required instance specifications, then perform the cloud migration using the MSE console.

In the MSE console, select the region and navigate to “Register & Config Center → Migrate to Cloud”.

Run the “Specification Evaluation” wizard, then purchase the recommended instance.

Configure the migration parameters, deploy the migration tool (container or tar package), and let MSE Sync generate the Consul‑to‑Nacos sync configuration.

Conclusion

The shift to BSL introduces legal and operational risk for enterprises that rely on HashiCorp’s open‑source tools. Re‑evaluating the service‑discovery layer and adopting a permissively licensed alternative such as Nacos—preferably via the managed MSE offering—can mitigate those risks and ensure a smoother production environment.