Understand licensing before you commit: The models behind PIM, e-commerce & headless CMS

Licensing affects more than just the purchase price. It impacts the technical architecture and your ability to scale and evolve over time.

Solutions that appear comparable from a business perspective can operate under very different licensing structures.

One model enables access to source code and independent development, transferring maintenance accountability to the client. Another prioritizes operational simplicity and rapid deployment, while imposing predefined limits, usage metrics, and technical boundaries.

That’s why licensing decisions should not be treated as a formality.

Here we explain what a software license is, what you pay for beyond the system, and the key licensing models used in PIM, B2B/B2C e-commerce, and headless CMS.

What is a software license?

A software license is a legal agreement between the software publisher and your company. It establishes the conditions for compliant and legal use.

It’s not limited to permission to install or launch the application.

It defines accountability for infrastructure hosting, updates, support, and security. It also governs source code access and the scope of custom development.

Equally important, a license shapes the total cost of ownership over time: influenced by users, environments, integrations, API usage, language versions, traffic levels, and occasionally commercial scale.

For any organization, one thing is clear: you’re not just buying software. You’re adopting a specific way of operating it.

Why does licensing matter for your business?

The licensing model determines whether a system supports your business reality. Even strong technology cannot compensate for structural licensing limits. If the model is not aligned with your organization, you may face:

• user access limitations,
• inability to operate across multiple entities or markets,
• unexpected expansion costs,
• complications with integrations, migrations, or vendor changes.

Choosing the correct license is critical for cost control and compliance. Violations can expose the company to financial penalties. Beyond that, organizations may face project slowdowns, unplanned implementation changes, and the risk that the system cannot grow according to the original roadmap.

How to read and compare licenses in PIM, headless CMS, and eCommerce platforms?

1. PIM software approach: Akeneo, Pimcore, Ergonode

Akeneo makes this division straightforward, distinguishing between self-managed and service-based models. The Community Edition is a free, open-source PIM that can be deployed on your own infrastructure and extended internally.

In comparison, Akeneo Product Cloud (Growth, Advanced, Premium) is a vendor-managed SaaS solution that includes automatic updates, infrastructure maintenance, and SLA-guaranteed support.

The simplest way to put it: Community Edition delivers autonomy, development control, and greater freedom to create own extensions. In exchange, the responsibility for infrastructure, updates, compliance, and system maintenance lies primarily with the license holder. This approach fits organizations with established technical teams that wish to minimize upfront licensing costs. Some advanced requirements will need to be supported through custom-built features and dedicated integrations. Product Cloud is a commercially delivered service that combines convenience with clearly defined operating conditions. It is particularly effective when rapid deployment, structured governance, producer-level support, and advanced feature sets are key factors.

The Growth, Advanced, and Premium tiers differ not only in support scope but also in platform functionality, governance standards, workflow capabilities, extensions, and additional services. The choice ultimately depends on how advanced and structured you want your product data management to be.

Companies evaluating Pimcore should reassess its licensing structure. In the past, the platform was widely associated with GPL and a classic open-source framework. Since the release of version 2025.1, the vendor has shifted its model. The Community Edition is now positioned as open-core and governed by the POCL license. With the revised terms, the free Community Edition is restricted to educational and non-profit use cases, and businesses below the EUR/USD 5 million annual revenue threshold. Broader commercial production use beyond this scope requires upgrading to a higher plan.

This distinction is strategically important for clients. Although the Community Edition remains open in terms of source code access and customization, its legal and commercial framework is more defined than in the past, when it was commonly described simply as “open source.”

As a result, decision-makers must evaluate both system functionality and licensing fit. A project may qualify under Community Edition – or it may need to be structured from the beginning as a Professional, Enterprise, or PaaS implementation.

*GPL – a copyleft license requiring that derivative works be distributed under the same license.

Ergonode occupies a middle ground between open source and SaaS, with a structure that still aligns more closely with classic open-source principles.

The core repositories are released under the OSL 3.0 license. However, the vendor promotes the product as open-SaaS and builds clear commercial tiers: Free, Essential, Advance, Scale, and Enterprise.

Each plan includes the App Framework, giving businesses the ability to build custom integrations and automation tools. This helps companies stay flexible and avoid being limited by a closed system.

2. Headless CMS approach: Storyblok, Strapi, Contentful

Storyblok represents a standard SaaS delivery model. In its contractual terms, the service is described as a “subscription-based, software-as-a-service (SaaS) headless content management system (CMS) and digital experience platform (DXP).”

The solution is not sold as deployable software. No source code or installation rights are transferred. Instead, customers receive time-limited access to the hosted platform under a subscription agreement.

The platform provider takes care of product development, updates, and service reliability. Users, in turn, agree to operate within clearly defined plan limits. These limits cover practical metrics such as spaces, seats, traffic, API calls, locales, SLA, or support. For illustration, one of the plans includes 1 space, 5 user seats, 400 GB of monthly traffic, 1 million API requests, and 2 locales.

Storyblok’s pricing scales with your organization – both in terms of team size and operational scale, including publishing volume and traffic. If you expect to expand into new markets and manage multiple brands and integrations, it is wise to consider the long-term cost structure.

This approach to pricing is not a drawback. In fact, many businesses benefit from it, as it ensures predictable billing, provider responsibility, continuous updates, professional support, and fast escalation in case of incidents.

Strapi is a more complex system. At its foundation is an open-source core licensed under MIT, a permissive license that allows companies to use and adapt the software freely, even in commercial projects. Alongside this core, the vendor develops paid layers: the Growth plan as a commercial CMS offering, the Enterprise Edition for organizations that need advanced self-hosted capabilities, and Strapi Cloud as a separate platform-as-a-service hosting solution.

To properly assess Strapi, clients should consider three separate layers of decision-making. First, whether the Community edition (the open-source core) meets your needs and can be maintained in-house. Second, whether your project requires additional commercial features beyond the free core. Third, whether you prefer full control through self-hosting, or the convenience of Strapi Cloud, where the vendor provides and manages the hosting environment.

Another headless CMS, Contentful, operates under a service-based model. According to its terms and conditions, the vendor does not provide a system for installation. Instead, the customer receives a non-exclusive right to access and use the Subscription Services while the contract remains in force.

You do not own the CMS. Instead, you subscribe to the platform. Licensing discussions revolve around selecting the appropriate plan (Free, Lite, Premium) and understanding the technical and organizational limits. These limits relate to spaces, environments, content types, records, user roles, system users, or optional add-ons.

Do you plan to operate more than one website or brand? If so, this is a key consideration for your content and e-commerce teams. Within Contentful, both overall cost and long-term scalability are driven not only by editor volume but by the complexity of environments, spaces, and role structures required.

3. E-commerce platform approach: Magento, Shopware, BigCommerce

„Magento” is frequently mentioned as if it were one unified product. In practice, it now covers several deployment models. Magento Open Source continues as a free, adaptable open-source platform. Adobe also develops Adobe Commerce in two main variants: Adobe Commerce on Cloud (PaaS on dedicated infrastructure) and Adobe Commerce as a Cloud Service (SaaS with automatic functional and security updates).

Magento Open Source offers flexibility and reduces the risk of vendor lock-in. It provides a free core system that can be deeply customized and aligned with your internal processes. At the same time, you are responsible for the technical side: infrastructure, updates, security, speed, and system stability. It’s a good fit for companies that want flexibility and have the resources or the implementation partner to manage the technical workload.

Adobe Commerce on Cloud and Adobe Commerce as a Cloud Service change the approach from running your own system to using a ready commercial platform.

PaaS still allows broad customization and development, while Adobe manages the underlying environment. SaaS simplifies it further by delivering a standardized, multi-tenant service. This typically improves operational predictability and reduces technical maintenance, although it limits flexibility compared to a self-hosted model.

Additionally, the licensing model for commercial variants is linked to metrics such as GMV/AOV, order caps, store views, and environment count. This makes sales scale and platform configuration important factors in determining total costs.

Shopware supports companies at different stages of growth. Its free Community Edition forms the foundation, while paid plans extend functionality, provide official support, and introduce deployment options such as self-hosted, SaaS, and PaaS. The company points out that self-hosted is a good fit for organizations with strong development resources that value full infrastructure ownership, flexible customization, and local data control.

Organizations may begin with the Community Edition, building their eCommerce operations independently before transitioning to paid plans that offer expanded capabilities and professional support. A service-oriented model can also be implemented. As a result, Shopware is often chosen by companies that want technological openness today while keeping the door open for a more organized commercial model in the future.

If we’re talking about Shopware, there is one important detail to keep in mind, as it directly affects how you evaluate the licensing model. Starting in 2025, Shopware implements a Fair Usage Policy for organizations using the Community Edition together with the Shopware Account and Shopware Store.

Businesses generating more than €1 million in annual GMV must migrate to one of the paid plans (Rise, Evolve, or Beyond) to retain full access to the ecosystem. Although the Community Edition core remains open source and available for continued development, organizations may lose access to selected services and operational conveniences, including support, account management, and extension updates.

You can find additional details here.

BigCommerce stands out as the simplest e-commerce model to understand in this comparison. It has always operated as a SaaS platform and, in the enterprise space, is referred to as Open SaaS. It does not provide software for independent hosting. Businesses leverage the platform as a managed service within their selected plan.

With BigCommerce, businesses are not locked into a rigid system. The Open SaaS model ensures that while the provider manages the platform’s core, companies retain the freedom to integrate external tools, custom front-end experiences, and their preferred tech stack. This creates room for tailored solutions without the complexity of managing everything independently. It offers a practical compromise: reduced operational risk compared to open source, combined with stronger integration flexibility than standard SaaS platforms. Pricing plans include Standard, Plus, Pro, and a custom Enterprise option.

What should you check before entering a licensing agreement?

When reviewing licensing and service terms, identify the billing unit. Different platforms apply different metrics: users, seats, content spaces, locales, API usage, traffic volume, or system environments. In e-commerce, pricing may also scale with revenue. For example, Storyblok and Contentful emphasize consumption-driven pricing while Shopware integrates plan structure with sales performance. In contrast, self-hosted solutions typically reduce recurring license fees but increase costs related to implementation, infrastructure, and continuous development.

The second question is about environments and scaling. You should check whether development, test, stage, preview, or extra spaces are included in the plan or charged separately. In many systems, this affects how the whole project is built.

The third area involves support, security fixes, and updates. SaaS models and many commercial offerings typically include these services as part of the package. In open-source or community models, the responsibility often shifts to the client and their implementation partner. This is not a drawback, but it needs to be a conscious choice.

The topic of customization and integration should always be addressed early. In practice, companies frequently recognize the real constraints of “flexibility” only after the project is already in motion. Self-hosting often allows deeper technical customization, yet it requires greater accountability and internal resources. SaaS platforms may introduce boundaries through subscription plans, feature caps, or extension policies.

The fifth area to review is the exit process. For SaaS services, verify how data can be exported, how content can be migrated, whether you keep access to assets and APIs, and what the subscription termination rules look like. The more service-focused the model, the more important portability becomes, beyond simply starting the project.

That’s why it’s more valuable to ask, “What activates this cost?” rather than simply, “What is the license fee?”

Frequently raised questions

Does SaaS qualify as a “license”?

Yes, although it is more accurately described as a subscription-based service. Instead of purchasing software for internal infrastructure, companies obtain usage rights to an application delivered over the Internet, typically under a recurring subscription plan.

Is support available without an active subscription?

Usually not. When a subscription or maintenance contract expires, access to technical support and software updates usually ends as well. This includes important security patches. Even if the software continues running, the organization may be left without vendor assistance or access to new releases.

Does open source eliminate costs?

No. As defined by the Open Source Initiative, open-source licenses provide freedom to use, modify, and share software. However, businesses still face costs related to implementation, customization, integrations, infrastructure, and support. While the license may be free, building and sustaining a reliable solution requires investment.

Enterprise license or AI-driven open source – Which delivers better value?

Enterprise systems are typically chosen for their immediate access to mature, business-ready functionality. Open-source solutions traditionally demanded additional development to fill functional gaps, increasing implementation effort and cost. Today, AI significantly reduces that effort. It accelerates integrations, data transformation, development cycles, and process automation – areas that once represented major time investments. This shift positions “open source + AI” as a potentially more economical, yet operationally demanding, alternative.

To succeed, you need a strong technology partner and a shared commitment to long-term growth.

How to classify software licenses in IT projects

To understand software licenses, it helps to look at three separate but related aspects:

1) Who owns the code and how it can be used or shared:

• Proprietary (closed-source) license: this approach ensures that the software vendor retains complete control over the source code, product evolution, distribution strategy, and usage rights. The extent of access is defined by the licensing agreement and can include limitations on users, operational environments, geographic scope, affiliated entities, and integration capabilities.
• Open-source licence: it allows users to use the software, see how it works by accessing the source code, change it, and share it under certain license rules.
• Hybrid licensing models: organizations may adopt intermediate structures. In the source-available model, transparency is provided through code access, yet usage and redistribution rights are more limited. The open core model offers an open foundation while reserving advanced functionality for commercial licensing.

2) How access to the software is provided:

• Subscription: in this model, you can use the software as long as your subscription is active. It usually covers updates, security patches, user support, and sometimes the required infrastructure.
• Perpetual license: the business secures lifetime rights to operate a defined version of the software. It is important to note that continued access to updates, new releases, and technical support is usually not part of the base license and may involve additional costs.
• OEM license (Original Equipment Manufacturer): it means the software comes pre-installed or included with hardware sold by the device maker or an authorized distributor. It is generally locked to the original machine and cannot be transferred to another system.
• SaaS (Software as a Service): in a SaaS environment, users do not deploy or manage software on their own systems. Instead, they subscribe to a provider-managed solution delivered online. The model emphasizes defined service terms, high system availability, strong data security, and clearly structured SLA obligations.
• Free-to-use licenses: represent software models that permit usage without fees, but within defined boundaries. These licenses are often seen during product trials, solution comparisons, or when working with basic software tools. In complex data-driven and integrated sales environments, they rarely serve as a sustainable long-term solution. Importantly, “free to use” is not the same as “open source.” Even if no payment is required, the software may prohibit modification and redistribution.

3) How usage limits are defined and measured:

• Per user / named user: one license equals one person. You are charged for each individual user, even if they switch between devices.
• Concurrent user / floating: licensing is based on the maximum number of simultaneous active users within the system.
• Per device: the license is assigned to a designated hardware device, independent of user count.
• Per core / processor: the licensing structure is based on processor cores or the computational capacity of the server infrastructure.
• Per install / instance: each standalone installation, virtual instance, or operational environment may require an individual license.

Thanks to this breakdown, it’s clear that the same software can be proprietary, offered under a subscription model, and charged based on named users.

How can a client make a well-grounded decision?

Licensing is not just a legal checkbox. It directly affects cost structure, flexibility, and scalability over time. Without careful evaluation, a system that works perfectly at launch may later become expensive or difficult to scale. That’s why licensing must be considered together with architecture, integrations, and your business roadmap in any PIM, CMS, or e-commerce project.

The biggest error is labeling vendors simply as “PIM,” “eCommerce,” or “headless CMS.” While they often cover similar functional areas, their licensing structures and contract provisions vary significantly. Declaring a headless architecture does not automatically explain how the solution is licensed or who manages its operation.

Tandemite helps manufacturers and distributors move through change with control and clarity. We streamline data and processes, then align your licensing model with your commercial reality. By analyzing your situation, we help you understand the long-term financial impact of subscription versus ownership and development. We also determine whether your organization benefits more from technical autonomy or from the simplicity of a turnkey solution.