Licencje bez tajemnic: Jakie modele spotkasz w projektach PIM, e-commerce i headless CMS?

Wybierając system PIM, headless CMS czy platformę e-commerce, łatwo skupić się na tym, co widać od razu: funkcjach i budżecie wdrożenia. Równie ważny jest model licencyjny.

Licencja jest jednym z tych elementów, które wpływają nie tylko na koszt zakupu oprogramowania, ale też na architekturę rozwiązania i elastyczność rozwoju.

To istotny detal, ponieważ podobne z perspektywy biznesowej narzędzia mogą działać na zupełnie innych zasadach.

Jeden system daje dostęp do kodu i pozwala rozwijać rozwiązanie po swojemu, ale przenosi więcej odpowiedzialności za utrzymanie na klienta. Inny gwarantuje firmie wygodę, szybszy start i mniej obowiązków operacyjnych, ale jednocześnie wiąże się z określonymi limitami, metrykami rozliczeń i mniejszą elastycznością po stronie technicznej.

Dlatego licencji nie warto sprowadzać do formalności.

W dalszej części wyjaśniamy, czym jest licencja oprogramowania, co naprawdę kupujesz poza samym systemem oraz jakie są najważniejsze modele w świecie PIM, e-commerce B2B/B2C i headless CMS.

Czym jest licencja oprogramowania?

Licencja oprogramowania to formalna umowa pomiędzy wydawcą systemu a użytkownikiem, czyli Twoją firmą, która definiuje warunki legalnego użycia programu.

I nie chodzi tylko o prawo do instalacji czy uruchomienia.

Licencja jasno ustala, kto hostuje infrastrukturę, kto dostarcza aktualizacje, zapewnia wsparcie oraz dba o bezpieczeństwo. Reguluje też dostęp do kodu i zakres możliwych modyfikacji (custom development). 

I wreszcie: wskazuje, co wpływa na koszty w czasie – liczba użytkowników, środowiska (np. testowe i produkcyjne), integracje, zapytania API, wersje językowe, ruch, a niekiedy nawet skala sprzedaży.

Dla organizacji oznacza to jedną ważną rzecz: nie kupujesz wyłącznie „systemu”. Kupujesz także określony model korzystania z tego systemu.

Dlaczego temat licencji jest ważny biznesowo?

Licencja decyduje o tym, czy rozwiązanie będzie działało w realiach Twojej organizacji. Możesz mieć świetny system, ale źle dobrany model licencyjny szybko tworzy realne bariery – i zaczynają się problemy:

• zbyt mała liczba użytkowników,
• brak prawa do użycia w wielu spółkach lub krajach,
• nieprzewidziane koszty przy rozwoju projektu,
• trudności przy integracji z innymi rozwiązaniami, migracji lub zmianie dostawcy.

Wybór odpowiedniej licencji wpływa bezpośrednio na budżet przedsiębiorstwa oraz bezpieczeństwo, ponieważ naruszenie warunków może prowadzić do kar finansowych. Dochodzą do tego jeszcze opóźnienia projektowe, konieczność nagłej zmiany zakresu wdrożenia i ryzyko, że system nie będzie mógł zostać rozszerzony zgodnie z planem.

Jak czytać licencje z grupy oprogramowania PIM, eCommerce i headless CMS?

1. Podejście do korzystania z PIM: Akeneo, Pimcore, Ergonode

Akeneo pokazuje ten podział bardzo jasno. Z jednej strony mamy Community Edition, czyli darmową, open-source’ową wersję PIM-a. Można ją pobrać, hostować samodzielnie i rozwijać we własnym zakresie.

Druga opcją jest model usługowy Akeneo Product Cloud (pakiety Growth, Advanced, Premium), w którym platforma jest utrzymywana przez producenta, z automatycznymi aktualizacjami oraz wsparciem gwarantowanym umową SLA.

Najprościej ująć to tak: Community Edition oznacza większą niezależność, kontrolę nad rozwojem rozwiązania i łatwiejsze tworzenie własnych rozszerzeń. Jednocześnie trzeba pamiętać, że odpowiedzialność za hosting, aktualizacje, zgodność i utrzymanie w większym stopniu spoczywa na użytkowniku licencji. Pasuje do firm z własnym zapleczem technicznym, które chcą zacząć bez opłat licencyjnych. Pewne potrzeby trzeba będzie pokryć custom developmentem i dodatkowymi integracjami. Natomiast Product Cloud to gotowa usługa w modelu komercyjnym, która daje wygodę i przewidywalne warunki. Sprawdza się tam, gdzie kluczowe są szybkie uruchomienie, pomoc producenta, uporządkowane środowisko i zaawansowane funkcje dostępne w płatnych pakietach.

Growth, Advanced i Premium różnią się nie tylko poziomem wsparcia, ale też funkcjami, governance, workflow, dodatkami i usługami platformowymi. Czyli finalnie decydujemy, jak szeroki model pracy z danymi produktowymi ma iść w parze z PIM-em.

W przypadku wdrożenia Pimcore klient musi dziś zachować większą czujność niż jeszcze kilkanaście miesięcy temu. Wiele osób nadal pamięta ten system jako rozwiązanie kojarzone z GPL* i klasycznym open source. Tymczasem od wersji 2025.1 producent zmienił model i komunikuje Community Edition jako rozwiązanie open-core licencjonowane w modelu POCL. Zgodnie z nowymi warunkami darmowa Community Edition jest przeznaczona m.in dla zastosowań edukacyjnych i non-profit oraz dla firm poniżej progu 5 mln EUR/USD rocznego przychodu. Przy szerszym komercyjnym użyciu produkcyjnym trzeba przejść na wyższy plan.

Dla klienta to bardzo ważne rozróżnienie. Community Edition nadal oferuje otwarty dostęp do kodu i możliwość modyfikacji. Mimo to w ujęciu prawnym i komercyjnym nie jest to już tak oczywiste jak dawniej, gdy mówiło się: „Pimcore jest open source”.

Trzeba zatem patrzeć nie tylko na to, co system potrafi, ale także na to, czy planowane wdrożenie mieści się jeszcze w zakresie Community Edition, czy od razu powinno być projektowane jako wdrożenie Professional, Enterprise albo PaaS.

*GPL – licencja typu copyleft; przy dystrybucji utworów pochodnych wymaga zachowania tej samej licencji.

Ergonode stoi trochę pomiędzy tymi światami, ale pozostaje bliżej klasycznego modelu open source.

Z jednej strony oficjalne repozytoria produktu są publikowane jako open source na licencji OSL 3.0. Z drugiej strony, sam producent na stronie opisuje Ergonode jako open-SaaS software i rozwija wyraźnie komercyjne plany: Free, Essential, Advance, Scale i Enterprise.

W każdym planie dostępny jest App Framework, co daje możliwość tworzenia własnych aplikacji do integracji i automatyzacji. To dobra wiadomość dla biznesów, które chcą zachować elastyczność integracyjną i nie zamykać się w sztywnym pudełku.

2. Podejście do korzystania z headless CMS: Storyblok, Strapi, Contentful

Storyblok to czysty model SaaS. W swoich warunkach dostawca wprost opisuje usługę jako “subscription-based, software-as-a-service (SaaS) headless content management system (CMS) and a digital experience platform (DXP)”.

Storyblok działa trochę jak „wynajmowany, stale utrzymywany system”. Klient nie kupuje tutaj kodu do instalacji na własnym serwerze. Kupuje prawo do korzystania z gotowej usługi w czasie trwania subskrypcji.

Producent odpowiada za rozwój platformy, aktualizacje i działanie usługi. W zamian trzeba zaakceptować to, że sposób użytkowania programu jest opisany przez plan i limity. A te parametry są bardzo konkretne: spaces, user seats, traffic, API requests, locales, SLA czy support. Dla przykładu, w jednym z planów uwzględnione są: 1 space, 5 user seats, 400 GB traffic/month, 1M API requests, 2 locales.

Przy Storyblok koszt rośnie nie tylko wraz z zespołem, ale też wraz ze skalą publikacji i ruchem. Jeśli dziś projekt jest mały, a za rok ma obsługiwać kilka marek, wiele krajów i dużą liczbę integracji, to warto patrzeć nie tylko na cenę wejścia, ale też na to, co będzie naliczane po wzroście.

Taki model nie jest niczym złym. W wielu firmach często działa na plus, ponieważ zapewnia przewidywalność, odpowiedzialność dostawcy, support, aktualizacje oraz szybki kontakt, gdy pojawia się awaria lub pilny temat.

Strapi jest bardziej złożonym systemem. Rdzeń Strapi jest komunikowany jako open source na licencji MIT, a więc bardzo elastycznej licencji, która pozwala na szerokie wykorzystanie, także komercyjne. Obok tego producent rozwija wokół tego rdzenia kilka płatnych warstw: Growth jako komercyjny plan CMS, Enterprise Edition jako wyższy, self-hosted wariant dla bardziej wymagających organizacji oraz Strapi Cloud jako osobną usługę hostingową/PaaS.

Dla klienta najlepiej rozumieć Strapi jako system wymagający trzech osobnych decyzji. Pierwsza brzmi: czy wystarczy nam Community, czyli otwarty rdzeń, który wdrażamy i utrzymujemy sami. Druga: czy potrzebujemy dodatkowych funkcji, które nie są częścią darmowego core’a i są objęte osobną komercyjną warstwą. Trzecia: czy chcemy hostować Strapi samodzielnie, czy wolimy skorzystać z Strapi Cloud, gdzie producent zapewnia środowisko do uruchomienia projektu.

Contentful działa jeszcze inaczej. Tutaj model jest od początku bardzo wyraźnie usługowy. W warunkach korzystania producent nie mówi o przekazaniu klientowi systemu do instalacji, tylko o tym, że przyznaje klientowi niewyłączne prawo dostępu i używania Subscription Services w czasie obowiązywania umowy.

Nie kupujesz CMS-a „na własność”, lecz korzystasz z platformy w modelu subskrypcyjnym, a rozmowa o licencji jest w praktyce rozmową o planie (dostawca opiera swoją ofertę na planach Free, Lite i Premium) oraz limitach organizacyjno-technicznych (dostawca operuje pojęciami takimi jak spaces, environments, content types, records, roles, users czy add-ons). 

Czy Twoja organizacja planuje kilka serwisów lub kilka marek? To istotne dla zespołów contentowych i e-commerce, ponieważ przy Contentful koszty i skalowalność projektu zależą nie tylko od liczby redaktorów, ale też od tego, ile środowisk, przestrzeni i ról realnie potrzebujesz.

3. Podejście do korzystania z platform sprzedażowych: Magento, Shopware, BigCommerce

W rozmowach bardzo często mówi się po prostu „Magento”, jakby chodziło o jedno rozwiązanie. Tymczasem dziś pod tym szyldem klient może spotkać co najmniej kilka różnych modeli. Magento Open Source pozostaje darmową, elastyczną platformą open source. Obok niej Adobe rozwija płatne Adobe Commerce w dwóch głównych wariantach: Adobe Commerce on Cloud jako rozwiązanie PaaS na dedykowanej infrastrukturze oraz Adobe Commerce as a Cloud Service jako SaaS z automatycznymi aktualizacjami funkcji i bezpieczeństwa.

Magento Open Source oznacza przede wszystkim kontrolę i mniejsze ryzyko pełnego uzależnienia od jednego producenta. Dostajesz darmowy silnik, który możesz rozwijać po swojemu i mocno dostosowywać do własnych procesów. Ale razem z tą swobodą bierzesz też na siebie sporą część odpowiedzialności: za infrastrukturę, aktualizacje, bezpieczeństwo, wydajność i stabilność sklepu. To często dobry model dla firm, które chcą mieć duży wpływ na rozwiązanie i mają kompetencje lub partnera, który tę odpowiedzialność uniesie.

Z kolei Adobe Commerce on Cloud i Adobe Commerce as a Cloud Service przesuwają środek ciężkości z „posiadania i utrzymywania silnika” na „korzystanie z komercyjnej platformy”.

W modelu PaaS klient nadal ma duże możliwości rozwoju i personalizacji, jednak działa już na dedykowanej infrastrukturze Adobe. W modelu SaaS idzie się jeszcze dalej: producent dostarcza gotową, wielodzierżawną usługę. Dla biznesu oznacza to zwykle większą przewidywalność operacyjną i mniej pracy po stronie zespołu technicznego, ale też mniejszą swobodę niż w klasycznym self-hostingu.

Dodatkowo, licencjonowanie komercyjnych wariantów jest związane z takimi parametrami jak GMV/AOV, order limit, liczba store views czy liczba środowisk, zatem znaczenie ma też skala sprzedaży i to, jak platforma jest uruchomiona.

Shopware daje kilka ścieżek. Łączy darmowy, open-source’owy Community Edition z płatnymi planami rozwijającymi ten rdzeń oraz z oficjalnym supportem i różnymi modelami wdrożenia: self-hosted, SaaS i PaaS. Sam producent podkreśla też, że self-hosted jest dobrym wyborem dla organizacji, które mają mocny zespół deweloperski i potrzebują pełnej kontroli nad własną infrastrukturą, szerokich możliwości customizacji i lokalnego przechowywania danych.

Można zacząć od Community Edition i budować sklep samodzielnie, a później wejść w płatne plany z dodatkowymi funkcjami i wsparciem. Można też oprzeć się bardziej na modelu usługowym. Dzięki temu Shopware bywa atrakcyjny dla firm, które chcą mieć otwarty fundament technologiczny, ale nie wykluczają, że z czasem będą potrzebować bardziej uporządkowanego, komercyjnego modelu współpracy.

A jeśli mówimy już o Shopware, to jest jeden ważny niuans, o którym warto wiedzieć, ponieważ ma wpływ na ocenę modelu licencyjnego. Od 2025 roku Shopware stosuje Fair Usage Policy dla firm używających Community Edition wraz z Shopware Account i Shopware Store.

Organizacje z wskaźnikiem GMV powyżej 1 mln euro rocznie muszą przejść na płatny plan (Rise, Evolve, Beyond), jeśli chcą nadal korzystać z konta i sklepu Shopware. Bez tego rdzeń Community Edition pozostaje do użytku i rozwoju, ale organizacja może utracić dostęp do usług oraz części wygód operacyjnych (np. support, obsługa konta, aktualizacje rozszerzeń).

Więcej na ten temat przeczytasz tutaj.

BigCommerce jest najłatwiejszym systemem do zrozumienia spośród tej trójki, ponieważ od początku działa jako platforma SaaS, a w segmencie enterprise producent określa ją także jako Open SaaS. W praktyce oznacza to, że klient nie dostaje silnika do dowolnego hostowania na własnych serwerach, lecz korzysta z usługi w ramach wybranego planu.

BigCommerce nie jest „sztywnym pudełkiem”. Właśnie określenie Open SaaS precyzuje, że choć rdzeń usługi jest utrzymywany przez dostawcę, klient nadal może integrować platformę z własnym stackiem, frontem, narzędziami zewnętrznymi. Taki model ma dawać swobodę doboru wyspecjalizowanych rozwiązań bez zamykania się w jednym, całkowicie zamkniętym ekosystemie. Dla wielu firm to atrakcyjny kompromis: mniej odpowiedzialności operacyjnej niż w open source, ale więcej elastyczności integracyjnej niż w klasycznych platformach SaaS. Producent oferuje plany Standard, Plus, Pro i Enterprise, przy czym Enterprise jest wyceniany indywidualnie.

O co warto zapytać przed podpisaniem umowy licencyjnej?

W praktyce w warunkach licencyjno-usługowych warto sprawdzić przede wszystkim, co jest jednostką rozliczenia. W jednych systemach będą to użytkownicy lub seats, w innych spaces, locales, API requests, ruch, środowiska, a w e-commerce nawet wartość sprzedaży. Storyblok i Contentful mocno pokazują logikę consumption-based, Shopware łączy plan z poziomem sprzedaży, a w rozwiązaniach self-hosted ciężar kosztu częściej przesuwa się z licencji na wdrożenie, utrzymanie i rozwój.

Drugie pytanie dotyczy środowisk i skalowania. Trzeba ustalić, czy development, test, stage, preview albo dodatkowe spaces są częścią planu, czy osobnym kosztem. W wielu systemach to element wpływający na architekturę całego projektu.

Trzecia rzecz to support, security fixes i aktualizacje. W modelach SaaS i w części ofert komercyjnych są one zwykle integralną częścią usługi. W modelach open source albo community odpowiedzialność częściej przechodzi na klienta i partnera wdrożeniowego. Nie jest to wada, ale musi być świadomą decyzją.

Pytanie o możliwość modyfikacji i integracji powinno paść zawsze, gdyż wiele firm zdaje sobie sprawę z realnych granic „elastyczności” dopiero wtedy, gdy projekt jest już rozpędzony. Przy self-hostingu zwykle masz większą swobodę techniczną, ale jednocześnie bierzesz na siebie większą odpowiedzialność. W SaaS część ograniczeń może pojawić się w samym modelu planu, limitach lub dostępnych rozszerzeniach.

Piąta sprawa to wyjście z systemu. Szczególnie w usługach SaaS warto sprawdzić, jak wygląda eksport danych, migracja treści, dostęp do assetów, API i logika zakończenia subskrypcji. Im bardziej usługowy model, tym ważniejsze jest pytanie o portability, a nie tylko o start projektu.

Dlatego dużo ważniejsze od pytania „Ile kosztuje licencja?” jest pytanie: „Co dokładnie uruchamia ten koszt?”.

Często wątpliwości

Czy model SaaS też jest „licencją”?

Tak, choć częściej mówi się o nim jako o subskrypcji usługi niż o klasycznej licencji instalowanej lokalnie. W modelu SaaS firma nie kupuje programu do własnej infrastruktury, tylko uzyskuje prawo do korzystania z aplikacji przez Internet, zwykle w ramach miesięcznej lub rocznej subskrypcji.

Czy brak aktywnej subskrypcji oznacza brak wsparcia?

Bardzo często tak. Po wygaśnięciu aktywnej subskrypcji lub maintenance użytkownik traci dostęp do wsparcia i aktualizacji oprogramowania, w tym poprawek bezpieczeństwa. Nawet jeśli część systemu nadal działa, organizacja może zostać bez pomocy producenta, bez nowych wersji i bez istotnych security fixów.

Czy open source oznacza brak kosztów?

Nie. Open Source Initiative wskazuje, że licencje open source pozwalają używać, zmieniać i udostępniać oprogramowanie, ale to nie oznacza, że wdrożenie, integracje, hosting czy wsparcie są darmowe. Chociaż firma może nie płacić za samą licencję, nadal ponosi koszty związane z uruchomieniem i utrzymaniem całego rozwiązania.

Enterprise czy rozwiązanie open source wsparte AI – co dziś bardziej się opłaca?

Firmy z reguły decydują się na licencję enterprise, ponieważ większość przydatnych biznesowo funkcji jest dostępna od ręki. W przypadku open source historycznie oznaczało to konieczność budowy brakujących elementów – a więc większy nakład czasu, pracy i kosztów. Dziś ta granica się zaciera. Narzędzia AI realnie przyspieszają prace w obszarach takich jak integracje, transformacja danych, development czy automatyzacja procesów, które wcześniej były najbardziej czasochłonne. W efekcie połączenie “open source + AI”może stać się tańszą, ale nieco trudniejszą alternatywą.

Warunek: dobry partner technologiczny i gotowość do współodpowiedzialności za rozwój.

Jakie są rodzaje licencji oprogramowania w projektach IT?

Naszym zdaniem najwygodniej jest opisywać licencjonowanie oprogramowania nie jako jeden prosty podział, lecz jako trzy uzupełniające się obszary:

1) Ze względu na prawa do kodu i jego wykorzystania (redystrybucji):

• Licencja własnościowa (proprietary, closed-source): to model, w którym twórca oprogramowania zachowuje pełną kontrolę nad kodem źródłowym, rozwojem, sposobem dystrybucji oraz zakresem używania systemu. Zakres uprawnień zależy od konkretnej umowy licencyjnej i może obejmować na przykład limit użytkowników, środowisk, lokalizacji, spółek w grupie czy dostępnych integracji.
• Licencja open source (otwarte oprogramowanie): to model, w którym użytkownik może korzystać z programu, analizować jego kod źródłowy, modyfikować go i (na warunkach danej licencji) dalej udostępniać.
• Modele pośrednie: wyróżnia się model source-available (kod źródłowy jest dostępny do wglądu, ale zasady jego używania, modyfikowania i dalszego udostępniania są bardziej ograniczone niż w klasycznym open source) i open core (podstawowa wersja produktu jest dostępna na zasadach otwartych lub częściowo otwartych, a funkcje rozszerzone pozostają komercyjne).

2) Ze względu na sposób udzielenia licencji lub dostępu do oprogramowania:

• Subskrypcja: w modelu subskrypcyjnym prawo do korzystania z oprogramowania jest powiązane z aktywną opłatą abonamentową. W ramach subskrypcji użytkownik zwykle otrzymuje dostęp do aktualizacji, poprawek bezpieczeństwa, wsparcia i niekiedy także infrastruktury.
• Licencja wieczysta (perpetual): firma kupuje prawo do korzystania z danej wersji oprogramowania bez ograniczenia czasowego. Nie oznacza to jednak automatycznie prawa do wszystkich przyszłych aktualizacji, nowych wersji czy stałego wsparcia – te elementy często są rozliczane osobno.
• Licencja OEM (Original Equipment Manufacturer): to model, w którym oprogramowanie jest dostarczane razem ze sprzętem przez producenta urządzenia albo autoryzowanego partnera. Najczęściej nie może być swobodnie przenoszona na inny sprzęt.
• SaaS: użytkownik nie tyle instaluje oprogramowanie i zarządza nim samodzielnie, ile korzysta z niego jako z usługi. W praktyce płaci za dostęp do rozwiązania utrzymywanego przez dostawcę. Znaczenie mają też warunki świadczenia usługi, dostępność systemu, bezpieczeństwo danych i SLA.
• Licencje bezpłatne do użycia: to grupa modeli, w których oprogramowanie można używać bez opłaty, ale w określonych granicach. Podany typ licencji najczęściej spotyka się na etapie testowania narzędzi, porównywania rozwiązań bądź przy prostszych programach użytkowych. Rzadko wystarczają jako docelowa forma pracy w bardziej złożonym ekosystemie danych, sprzedaży i integracji. „Darmowe do użycia” nie jest równoznaczne z terminem „open source”. Taki program może być bezpłatny, ale nadal nie wolno go modyfikować ani rozpowszechniać.

3) Ze względu na sposób liczenia zakresu uprawnień:

• Per user / named user: licencja jest przypisana do indywidualnego użytkownika; dostęp jest rozliczany „na osobę”, nawet jeśli używa go na kilku urządzeniach.
• Concurrent user / floating: opłata zależy od maksymalnej liczby użytkowników korzystających z systemu jednocześnie.
• Per device: licencja jest przypisana do konkretnego urządzenia (niezależnie od liczby osób korzystających z danego sprzętu).
• Per core / processor: licencjonowanie według liczby rdzeni procesora lub mocy obliczeniowej serwera.
• Per install / instance: każda osobna instalacja, instancja lub środowisko może wymagać osobnej licencji.

Dzięki temu łatwiej zrozumieć, że np. to samo oprogramowanie może być równocześnie własnościowe, sprzedawane w subskrypcji i rozliczane według liczby named users.

Jak wyrobić sobie opinię jako klient?

Dobrze dobrana licencja nie tylko zabezpiecza zgodność prawną. Przede wszystkim pozwala uniknąć sytuacji, w której system działa dobrze w dniu uruchomienia, ale po roku staje się zbyt drogi, zbyt zamknięty albo zbyt trudny do skalowania. Właśnie dlatego w projektach PIM, CMS i e-commerce warto analizować licencję równolegle z architekturą, integracjami i roadmapą biznesu.

Największy błąd to wrzucanie dostawców do jednej kategorii: „PIM”, „eCommerce” albo „headless CMS”. Technicznie rozwiązują podobne potrzeby, ale różnią się zasadami licencji i zapisami w kontrakcie. Sama decyzja „przechodzimy na headless” nie określa jeszcze, jak kupujesz rozwiązanie i kto odpowiada za jego działanie.

W Tandemite pomagamy producentom i dystrybutorom przejść przez zmiany bez stresu: od uporządkowania danych i procesów, po dopasowanie modelu licencyjnego do realiów sprzedaży. Analizujemy Waszą sytuację, byście wiedzieli, co będzie bardziej kosztowne w przyszłości: subskrypcja czy utrzymanie i rozwój. Wskazujemy też, czy w Waszym modelu biznesowym lepsza będzie swoboda techniczna zespołu, czy wygoda gotowego rozwiązania.