Broadleaf Commerce CE: a Spring monolith, not an Apache 2 open source product

The first line of the README is a licence warning

Before any description of features, the README carries an Important notice: the Community Edition is source-available under a Fair Use license, available to companies with under $5M in revenue, and it is explicitly not an Apache 2 open source product.

That single sentence changes what kind of dependency this is. You cannot treat Broadleaf Commerce CE the way you would treat Spring or Hibernate. A revenue condition is attached to the Fair Use path.

The dual licence structure is spelled out in its own section. Broadleaf Commerce core is released under a dual license format and may be used under the terms of the Fair Use License 1.0 unless the restrictions on use are violated and require payment to Broadleaf, in which case the Broadleaf End User License Agreement version 1.1 applies. A third path exists: the commercial licence can be replaced with a mutually agreed licence between you and Broadleaf Commerce.

The practical consequence is that the licence question is a gate, not a footnote. The repository even ships a `licenses/` directory, and the two texts are hosted at license.broadleafcommerce.org. Read both before anything else.

Three editions, and CE is not the one that does microservices

The README lists three editions, and the distinction between them matters more than the feature lists suggest.

Community Edition is described as open source under a dual licence format with both fair use and commercial restrictions. Enterprise Edition is source-available under a commercial licence, built on top of Broadleaf's open core platform, and adds features and support for B2C, B2B, multi-tenant and marketplace use cases. The Microservices Edition is also commercial, and provides a microservice enablement framework of headless commerce APIs.

The architecture statement in the opening paragraph is the one to hold onto. Broadleaf CE and EE are architected as a traditional unified codebase that share a core dependency across a `site` and `admin` deployment. And the README closes that thought by redirecting anyone looking for a microservices based architecture to the Microservices Edition.

So the choice is not tier versus free. It is monolith versus distributed, and the distributed option is not the free one. A team that has decided it needs services will find that decision pushes it out of CE entirely.

The repository layout backs this up: `core/`, `admin/`, `common/` and `integration/` as Maven modules under a root `pom.xml`, plus `doc/` and a `Jenkinsfile`. That is one deployable shape, not a service graph.

What the Spring stack underneath actually is

CE is written entirely in Java and leverages the Spring framework, and the README lists the specific technologies rather than leaving them implied.

Spring is the base and supplies dependency injection and transaction control. Spring Security handles authentication and authorization at both the code and page level, which is what the access control in the framework is built on. JPA and Hibernate form the ORM infrastructure controlling persistence of the domain model. Solr provides domain search integration. Quartz handles task scheduling for repetitive work.

Email is supported in synchronous or asynchronous JMS modes, with presentation customization through Thymeleaf templates.

The presentational layer is not left to you entirely. The README notes Broadleaf includes pre-written Spring MVC controllers to speed development of the presentation layer of your own site, and the admin application is itself a Spring MVC application with interfaces for catalog, order and customer functions.

Two consequences follow. First, you inherit a running Solr alongside your database, and Solr indexing is a consistency problem you will own. Second, the framework's own admin is a web application with its own attack surface, so access control decisions made through Spring Security matter more here than in a thinner stack.

Modules and workflows are where the customisation lives

Broadleaf's extension story has two named mechanisms and one supporting facility.

The first is modules. Important e-commerce touchpoints are embodied in the concept of Broadleaf modules, and the README's examples are concrete: a module can provide interaction with a credit card processor, or a shipping provider. Any number of custom modules may be developed and used. This is the integration seam, and it is the reason the framework can stay out of the payment and logistics business.

The second is configurable workflows. Key areas in the e-commerce lifecycle are represented as configurable workflows, and implementors get full control over the key steps in pricing and checkout: manipulating module ordering, overriding existing module behaviour, and adding custom module execution. Composite workflows are supported for nested behaviour.

The third is configuration merging, described as a custom merge facility for Spring configuration files. The stated goal is to minimise the Broadleaf configuration semantics an implementer has to be aware of, letting the framework merge its own configuration information with the implementer's at runtime.

That last one is the design decision most teams will feel. Broadleaf describes itself as designed from the ground up with extensibility in mind, and almost every aspect can be overridden, added to or modified, including all services, data access objects and entities. That flexibility is real, and it is also why upgrades are not a file copy.

QOS monitoring is included for modules, both custom and default, with logging and email handlers out of the box and additional handlers addable through an open API.

Promotions, PCI segregation, and what the README does not say

Two feature areas carry decisions you will inherit.

Promotions are applied at several standard levels: order level, order item level and fulfillment group level. The business rules are expressed with the MVEL expression language. Worth reviewing who can edit it.

On PCI, the README describes a design rather than a certification. Measures are taken in construction and design to help achieve PCI compliance if you choose to store and use sensitive customer financial account information. Payment account information is referenced separately, allowing confidential data to be segregated onto a separate, secure database platform. API methods exist to allow inclusion of any PCI compliant encryption scheme, and verbose logging tracks payment interaction history.

Note the conditional phrasing throughout. It helps you toward compliance; it does not make your deployment compliant.

What the README does not cover is equally relevant. There is no documented upgrade or rollback procedure from a previous version in the text, no statement of which Java or Spring versions a given GA supports, and no community support channels or contributor guidance in the excerpt. `ISSUES.md` exists at the root of the repository. The Getting Started material lives off the repository, at the Broadleaf documentation site.

Default branch is `develop-7.0.x`. The newest tagged release in this repository is broadleaf-5.0.21-GA from 2021-12-17, with earlier 3.x GA tags behind it, so the branch you see is ahead of the tags.

Where Broadleaf is the wrong choice

The clearest reasons to stop are organisational rather than technical.

If your company is at or above the $5M revenue line named in the README, CE is not available to you under Fair Use and the commercial EULA applies. That is a licensing wall, not a technical preference, and no amount of customisation work changes it.

If you have decided on microservices, CE is the wrong shape by the maintainers' own statement, and the alternative is a different commercial product.

If you want a small storefront, CE is heavy. The framework gives you a rich domain model, JPA persistence, a Solr index, Quartz scheduling, JMS-capable email, a full admin application and a Spring Security layer. A single-SKU store needs almost none of that, and the extensibility model that makes the framework powerful also makes each upgrade a negotiation with your own overridden code.

The alternative worth comparing against is building on Spring yourself with a payment provider's SDK directly, plus a search product, plus an admin you write. The difference in approach is that Broadleaf hands you enterprise commerce structure on day one and charges you for it in licence terms and in upgrade effort; the build-it-yourself path leaves you with only what you needed.

The fair comparison is not feature count. It is whether the enterprise structure Broadleaf supplies is the structure you would have ended up with anyway.

Editorial conclusion

Adopt Broadleaf Commerce CE if your company is under the $5M revenue line the Fair Use licence names and you want an enterprise-shaped Java commerce core that hands you a data model, workflows and modules instead of an empty application. Do not adopt it if your revenue exceeds that threshold, if you need Apache 2 terms for redistribution, or if you want microservices: the README says plainly that CE and EE are architected as a traditional unified codebase, and points you to a commercially licensed Microservices Edition instead. Verify three things before writing any code: that your Fair Use 1.0 terms cover your actual use and that you know which side of the dual licence you are on, because the fallback is the commercial EULA version 1.1 rather than an open source grant; that your default branch, `develop-7.0.x`, is the line you intend to build on given that the newest tagged GA release in this repository is broadleaf-5.0.21-GA from 2021-12-17; and that Solr, Quartz, JMS and a JPA provider are infrastructure you are willing to operate. The last push was on 2026-10-14, so the source is being worked on even though the release tags are old. Licence files live under `licenses/` and the two texts are published at license.broadleafcommerce.org.

Frequently asked questions

Official sources

1. BroadleafCommerce/BroadleafCommerce on GitHub
2. Issues
3. Project website
4. README
5. Releases