Redis, Elastic, MongoDB: pułapki licencji source available

Od „darmowego jak powietrze” do pułapek licencji source available

Source available a open source – podobne z wierzchu, kluczowa różnica w środku

Na pierwszy rzut oka Redis, Elastic i MongoDB wyglądają jak klasyczne projekty open source. Kod jest na GitHubie, dokumentacja publiczna, społeczność aktywna. Problem zaczyna się przy licencji. Open source (MIT, Apache 2.0, GPL itd.) oznacza, że kod jest nie tylko dostępny, ale też można go dość swobodnie używać, modyfikować i rozpowszechniać w projektach komercyjnych, o ile dotrzyma się jasno opisanych warunków.

Source available to zupełnie inna kategoria. Kod jest widoczny, można go czytać, często nawet modyfikować lokalnie. Jednak warunki jego użycia są istotnie ograniczone, szczególnie jeśli zarabiasz na oprogramowaniu lub świadczysz usługi w modelu SaaS / hosting. W praktyce oznacza to: widzisz kod, ale nie masz swobody klasycznego open source.

Redis, Elastic i MongoDB w części swoich dystrybucji i modułów przeszły właśnie na licencje typu source available (SSPL, Elastic License, Redis Source Available License – RSAL). To nie są „jeszcze jedne dziwne licencje”, tylko narzędzia, które wprost ograniczają możliwość budowania na ich bazie usług konkurujących z dostawcą oryginalnego produktu.

Dlaczego Redis, Elastic i MongoDB zmieniały licencje

Wspólny mianownik: walka z dużymi chmurami i chęć przejęcia większej części tortu. Główne projekty typu baza danych czy silnik wyszukiwania przez lata były rozwijane jako open source, a potem wielkie chmury (AWS, Azure, GCP) brały ten kod, tworzyły własną usługę zarządzaną (DBaaS, managed search), zarabiały na niej miliardy, oddając społeczności minimalnie.

Z perspektywy takich firm jak Elastic czy MongoDB wyglądało to tak:

• one ponoszą ogromne koszty rozwoju,
• chmura oferuje gotową usługę opartą o ich produkt,
• klienci zamiast kupować licencje / subskrypcje od producenta idą do chmury,
• producent traci potencjalny przychód i kontrolę nad ekosystemem.

Odpowiedzią stały się licencje typu SSPL (MongoDB), Elastic License oraz model open core + moduły RSAL w Redisie. Te licencje mają jedno zadanie: uniemożliwić lub drastycznie utrudnić chmurom i innym dostawcom usług zbudowanie konkurencyjnej oferty bez wykupienia oficjalnej licencji.

Przy okazji oberwały też mniejsze firmy: integratorzy, start‑upy SaaS, lokalni hostingodawcy i wszystkie zespoły, które do tej pory traktowały te projekty jak klasyczne open source.

Złudzenie „kod jest na GitHubie, więc mogę wszystko”

Scenariusz powtarza się regularnie. Zespół wybiera MongoDB, Elasticsearch lub Redis, bo:

• „wszyscy tego używają”,
• „jest darmowe do komercyjnego użytku”,
• „jest community edition, więc spoko”.

Mało kto weryfikuje, że to „darmowe” ma konkretny cennik w postaci ograniczeń licencyjnych, szczególnie przy świadczeniu usług na bazie tych technologii. Kod na GitHubie bywa tylko wygodną iluzją: daje złudne poczucie swobody, a prawdziwe reguły gry stoją w pliku LICENSE i w dodatkowych warunkach licencyjnych na stronie producenta.

Dla małych projektów bywa to bezbolesne, dopóki:

• nie dostają pierwszego większego klienta,
• nie wchodzi inwestor robiący due diligence,
• nie rośnie ruch i nie trzeba przeskoczyć na model multi‑tenant / B2B2C.

Wtedy nagle pojawia się prawnik po stronie klienta lub funduszu i zadaje banalne pytanie: „Na jakiej podstawie licencyjnej korzystacie z MongoDB / Elasticsearch / Redis w tym modelu usługi?” – i całe „darmowe jak powietrze” rozpływa się w powietrzu.

Jak zmiany licencji uderzają w różne typy firm

Efekty zmiany licencji zależą od modelu biznesowego. Kilka typowych przypadków:

• Side‑project i mały produkt B2C – jeśli MongoDB, Elasticsearch czy Redis są wykorzystywane „na własne potrzeby” aplikacji, bez oferowania ich jako osobnej usługi, zwykle da się to ułożyć w zgodzie z licencją. Problem pojawia się, gdy produkt staje się platformą dla innych.
• SaaS B2B / B2B2C – ryzyko rośnie drastycznie. Multi‑tenant, instancje per klient, funkcjonalność „projektów” klienta na twojej infrastrukturze – wszystko to zbliża cię do definicji „dostawcy usługi” z SSPL / Elastic License / RSAL.
• Integratorzy i software house’y – własne pakietowane rozwiązania: monitoring, analytics, log management czy „managed database”. Tu zderzenie z ograniczeniami licencji jest najmocniejsze, bo biznes polega właśnie na sprzedawaniu usługi na cudzej technologii.
• Lokalni hostingodawcy / MSP – oferowanie klientom kontenerów, klastrów Kubernetes, usług „database hosting” bez porządnej analizy licencji tych konkretnych technologii to prosty sposób na narażenie się na roszczenia.

Im bardziej twoja usługa przypomina ofertę producenta danego narzędzia, tym większe ryzyko, że licencja source available została napisana właśnie po to, by ci to utrudnić.

Podstawy licencji: od MIT do SSPL – co naprawdę wolno

MIT, Apache 2.0, GPL – krótka mapa swobody

Żeby zrozumieć, czym jest SSPL czy Elastic License, dobrze ustawić je na tle klasycznych licencji:

• MIT – bardzo liberalna. Możesz używać w projektach komercyjnych, zamkniętych, SaaS. Wymaga głównie zachowania informacji o autorach i wyłączenia odpowiedzialności. Produkt oparty o MIT możesz sprzedawać niemal dowolnie.
• Apache 2.0 – podobnie szeroka jak MIT, ale dokładniej opisuje kwestie patentów. Również przyjazna dla komercyjnych projektów i SaaS, przy zachowaniu wymogów licencji (notices, informacje o modyfikacjach itd.).
• GPL (oraz AGPL) – licencje copyleft. Pozwalają wykorzystywać oprogramowanie komercyjnie, ale nakładają obowiązek udostępnienia kodu twojej aplikacji (lub jej istotnych części), jeśli ją dystrybuujesz (GPL) lub udostępniasz jako usługę sieciową (AGPL). W praktyce są trudniejsze do pogodzenia z zamkniętymi produktami SaaS, bo wymagają otwarcia kodu lub stosowania bardzo ostrożnej architektury izolującej komponenty.

Wspólne dla MIT/Apache jest to, że nie blokują cię z powodu modelu biznesowego. Możesz konkurować z każdym, także z twórcą biblioteki czy bazy danych. GPL/AGPL są bardziej wymagające, ale reguły są od dekad stabilne i dobrze opisane.

Gdzie na tej osi lądują SSPL, Elastic License i RSAL

Licencje stosowane dziś przez MongoDB, Elastic i Redis sytuują się poza klasycznym światem open source:

• SSPL (Server Side Public License) – formalnie inspirowana AGPL, ale z dodanymi zapisami, które wymagają otwarcia całego stosu usługowego, jeśli oferujesz usługę opartą o MongoDB. OSI nie uznaje SSPL za open source.
• Elastic License – licencja stworzona przez Elastic, wyraźnie nie‑open‑source. Blokuje tworzenie konkurencyjnych usług (np. managed Elasticsearch) oraz ogranicza modyfikację i dystrybucję binariów w kontekście komercyjnych usług.
• RSAL (Redis Source Available License) – stosowana dla wybranych modułów Redisa. Kod widać, ale licencja ogranicza wykorzystanie w usługach konkurencyjnych wobec Redis Ltd., szczególnie w modelu „database as a service”.

Ideowo te licencje mają charakter pro‑biznesowy dla producenta: pozwalają mu publikować kod, korzystać z wkładu społeczności, ale równocześnie chronią przed sytuacją, w której inna firma (zwykle duża chmura) buduje na tym kodzie tańszą lub wygodniejszą usługę.

Dla ciebie jako użytkownika oznacza to coś bardzo prostego: nie możesz kopiować modelu biznesowego producenta, jeśli opiera się on na oferowaniu tej technologii jako usługi. Nawet gdybyś technicznie był w stanie zrobić kopię 1:1.

„Dostawca usługi”, „konkurencyjna oferta” i „oprogramowanie jako usługa” – niebezpieczne definicje

W licencjach typu SSPL, Elastic License czy RSAL kluczowe są definicje, często zamieszczone na początku dokumentu licencyjnego. Np.:

• „Service” / „Offering as a service” – zazwyczaj oznacza udostępnianie funkcjonalności oprogramowania innym podmiotom przez sieć. Nie musisz sprzedawać osobnego „MongoDB as a Service”. Wystarczy, że twoja platforma de facto pozwala klientowi działać tak, jakby miał własną zarządzaną bazę czy klaster wyszukiwania.
• „Competitive offering” – bardzo pojemne pojęcie. Chodzi nie tylko o bezpośrednią usługę DBaaS czy managed search, ale także o rozwiązania „spakowane” (appliance, platforma monitoringowa, system do logów), które z punktu widzenia klienta zastępują usługę producenta.
• „Cloud provider” / „hosting provider” – czasem licencja mówi wprost o dostawcach chmurowych, ale w praktyce wiele jej zapisów ma zastosowanie też do mniejszych firm hostingowych czy integratorów z usługami „managed”.

Interpretacja tych definicji jest kluczowa. Często zespół techniczny uznaje, że „przecież nie oferujemy MongoDB jako usługi, tylko nasz SaaS”. Prawnik producenta może mieć inne zdanie, jeśli twój model działania na rynku jest zbliżony do modelu, który licencja stara się zablokować.

Kiedy „niekomercyjne użycie” przestaje być niekomercyjne

Wiele zespołów opiera się na intuicji: dopóki nie zarabiamy bezpośrednio na technologii, wszystko jest „niekomercyjne”. W przypadku licencji source available to założenie jest zwykle błędne. „Niekomercyjny” oznacza najczęściej dosłownie: brak przychodu, brak świadczenia usługi, brak komercyjnego modelu dystrybucji.

Z chwilą, gdy:

• sprzedajesz abonament za dostęp do platformy,
• pobierasz opłatę setupową,
• oferujesz SLA, wsparcie, utrzymanie,
• na fakturze pojawia się pozycja „usługa” powiązana funkcjonalnie z danym oprogramowaniem,

twoje użycie przestaje być „niekomercyjne”. To szczególnie istotne w kontekście zapisów typu „free for non‑commercial use” czy wyjątków od ograniczeń licencyjnych: bardzo łatwo je przekroczyć znacznie wcześniej, niż projekt „zacznie zarabiać poważne pieniądze”.

Dlatego przy MongoDB, Elastic i Redis nie ma co zakładać, że „dopóki mamy małe przychody, nikt nie zwróci uwagi”. Przychody nie są wyznacznikiem legalności – są tylko jednym z czynników wpływających na to, czy spór jest ekonomicznie sensowny dla obu stron.

MongoDB i SSPL – co się zmieniło i kogo to boli

Od AGPL do SSPL – dlaczego MongoDB zerwało z klasycznym open source

MongoDB zaczynało na licencji AGPL, czyli wersji GPL rozszerzonej o usługi sieciowe. AGPL już wtedy chroniło przed typowym scenariuszem chmurowym: „bierzemy kod, oferujemy jako usługę, nie otwieramy żadnych własnych zmian”. Tyle że duże chmury nauczyły się obchodzić AGPL, korzystając z rozmaitych konstrukcji architektonicznych i prawnych.

MongoDB zdecydowało się na SSPL, aby:

• mocniej przycisnąć dostawców usług,
• wymusić otwarcie całego stosu technologicznego, jeśli ktoś chce oferować MongoDB jako usługę,
• mieć mocniejszy argument negocjacyjny w rozmowach z dużymi partnerami i chmurami.

Organizacje standaryzujące open source (jak OSI) uznały SSPL za niezgodne z definicją open source, głównie przez rozszerzający się obowiązek otwierania kodu wszystkiego, co współtworzy usługę.

Kluczowe ograniczenia SSPL: otwórz wszystko albo kup licencję

SSPL można streścić w jednym zdaniu: jeśli oferujesz MongoDB jako usługę, musisz udostępnić cały kod źródłowy infrastruktury, która tę usługę realizuje. To oznacza nie tylko samą bazę, ale także:

• systemy orkiestracji,
• panele administracyjne,
• systemy billingowe,
• automatyzację backupów, skalowania, monitoringu,
• wszelkie komponenty integrujące się i tworzące „complete offering”.

Dla typowego dostawcy chmury lub DBaaS to nieakceptowalny warunek. Biznes polega właśnie na tym, że know‑how dotyczące automatyzacji, skalowania i utrzymania pozostaje wewnątrz firmy.

W praktyce SSPL działa jak „licencja z odstraszającą opcją open source”: nikt poważny nie wybierze ścieżki otworzenia całego stosu, więc zostaje jedna droga – negocjacja komercyjnej licencji z MongoDB Inc.

Scenariusze ryzyka przy MongoDB

Typowe modele wdrożenia MongoDB a SSPL

MongoDB na SSPL jest względnie bezpieczne w kilku prostych scenariuszach. Problemy zaczynają się, gdy z „bazy w aplikacji” robisz „funkcjonalność bazy dla innych”. Dobrze jest jasno oddzielić te dwa światy:

• aplikacja biznesowa / produkt SaaS – MongoDB jest tylko wewnętrznym komponentem. Użytkownik korzysta z funkcji aplikacji (CRM, panel analityczny, sklep), ale nie ma ekspozycji typu „masz tu własny klaster MongoDB”. To jest typowe, niskoryzykowne użycie, o ile nie budujesz funkcji wprost zastępujących usługę DBaaS;
• platforma lub narzędzie dla innych zespołów – np. multi‑tenant platforma devopsowa, system do logów, który klient „konfiguruje jak własną bazę dokumentową”. Tu pojawia się pytanie, czy z perspektywy klienta nie jest to już „MongoDB as a Service” schowane w ładnym UI;
• oferta managed / hostingowa – przejmujesz utrzymanie MongoDB od klienta, wystawiasz mu endpoint, dajesz SLA, rozliczasz się za zasoby lub instancje. W tym momencie wchodzisz w strefę, którą SSPL ma zablokować.

Granica nie zawsze jest oczywista. Jeśli KPI twojego produktu to „czas uruchomienia nowej instancji bazy dla klienta” albo „ilość zarządzanych klastrów MongoDB”, to dla prawnika MongoDB jesteś raczej dostawcą usługi bazodanowej niż „zwykłym SaaS‑em z bazą pod spodem”.

Mały zespół kontra wielka licencja – kiedy naprawdę zaczyna się ryzyko

W praktyce spory o SSPL nie wybuchają przy trzech klientach i przychodzie rzędu kilku tysięcy miesięcznie. Eskalacja pojawia się, gdy spełnią się dwie przesłanki naraz:

• zaczynasz wchodzić w radar – pojawiasz się w porównaniach z Atlasem, klient pyta „czemu was, a nie oficjalną chmurę MongoDB”, ktoś z MongoDB widzi twoją ofertę na konferencji lub w artykule branżowym;
• masz powtarzalny, policzalny przychód z usługi, która z grubsza kopiuje model DBaaS (abonament za instancję, rozliczanie „per node/GB”, oferta migracji z własnego MongoDB).

Dla małego startupu, który dopiero szuka product‑market fit, bardziej racjonalne bywa:

• sięgnąć po fork na starej licencji (np. projekty oparte na kodzie sprzed zmiany licencji, jeśli takie istnieją w danej technologii),
• albo od razu zacząć z inną bazą dokumentową na licencji MIT/Apache/GPL, jeśli produkt ma potencjał „infrastrukturalny”.

Oszczędza to później kosztownych migracji „na żywym organizmie”, kiedy liczba klientów i danych jest już trudna do przeniesienia bez poważnego przestoju.

Tanie strategie ograniczania ryzyka przy MongoDB

Jeżeli z jakichś powodów MongoDB jest dla ciebie kluczowe, a równocześnie istnieje ryzyko, że w przyszłości wejdziesz w szarą strefę SSPL, da się ograniczyć szkody kilkoma prostymi podejściami:

• techniczna warstwa abstrakcji – pisać aplikację tak, by wymiana silnika bazy była możliwa w tygodnie, nie w lata (ORM, własna warstwa repozytoriów, ograniczenie użycia specyficznych funkcji);
• jasne „no‑go” w ofercie – nie komunikować nigdzie, że sprzedajesz „managed MongoDB”, nawet jeśli technicznie hostujesz ją klientowi; sprzedajesz rozwiązanie aplikacyjne, nie bazodanowe;
• alternatywa w szufladzie – znać 1–2 realne zamienniki (np. PostgreSQL z JSONB, inna baza dokumentowa z liberalną licencją) i przetestować migrację na wczesnym etapie rozwoju produktu.

Wszystkie te działania kosztują trochę więcej czasu na starcie, ale zmniejszają prawdopodobieństwo, że za kilka lat jedyną realną opcją stanie się droga licencja enterprise lub bolesny re‑write.

Elastic i Elastic License – szare strefy dla deweloperów i integratorów

Dlaczego Elastic odciął się od Apache 2.0

Elasticsearch i Kibana długo były na licencji Apache 2.0. To umożliwiało chmurom budowanie wprost konkurencyjnych usług – w stylu „Elasticsearch as a Service” – bez większych zobowiązań wobec Elastic NV. Gdy te usługi zaczęły rosnąć szybciej niż biznes samego Elastic, firma przeszła na model dualny: Elastic License + Server Side Public License dla części komponentów.

Od strony biznesowej motywacja jest podobna jak przy MongoDB:

• zatrzymać „kanibalizowanie” rynku przez wielkie chmury,
• skierować ruch na własną ofertę Elastic Cloud,
• utrudnić partnerom zbudowanie w pełni konkurencyjnego stacka „na plecach” kodu Elastica.

Dla użytkowników oznacza to, że od konkretnej wersji (w Elasticsearch od 7.11 wzwyż) wchodzą w grę dodatkowe ograniczenia, których nie było przy Apache 2.0.

Co faktycznie blokuje Elastic License

Elastic License nie zabrania zwykłego użycia Elasticsearch w aplikacji czy wewnętrznej infrastrukturze. Problem pojawia się, gdy:

• oferujesz usługę hostowaną z wyszukiwaniem/logami zbudowaną na Elasticsearch i komunikujesz ją jako alternatywę dla Elastic Cloud lub innych produktów Elastic,
• modyfikujesz kod i dystrybuujesz własne binaria Elasticsearch/Kibany w ramach komercyjnej oferty,
• tworzysz rozwiązanie, gdzie z perspektywy klienta dostaje on po prostu „zarządzanego Elastica”, choćby pod inną nazwą.

Stare wydania na Apache 2.0 wciąż są dostępne (np. 7.10), ale zatrzymanie się na nich to ryzyko techniczne: brak nowych funkcji, łatek bezpieczeństwa, zmian w protokołach i formatach indeksów. Z czasem rośnie to do poziomu długu, którego spłata będzie droższa niż zakup licencji albo migracja na inne narzędzie.

Integratorzy, firmy od logów i APM – najbardziej wrażliwa grupa

Dla zwykłego SaaS‑u wykorzystującego Elasticsearch jako wewnętrzny silnik wyszukiwania ryzyko jest ograniczone. Najbardziej narażone są firmy, które sprzedają:

• platformy logów w modelu multi‑tenant (klient „ma swój indeks”, swoje dashboardy, często z opcją eksportu danych czy własnego Query DSL);
• monitoring i APM – zwłaszcza gdy produkt jest reklamo­wany jako tańszy zamiennik Elastic Observability;
• „managed ELK stack” – oferty wprost mówiące: „my ogarniamy Elasticsearch i Kibana za ciebie, z SLA i rozliczeniem per GB / per cluster”.

Tu wchodzisz już w przestrzeń, którą Elastic License ma chronić. Bronią Elastica są nie tylko zapisy licencyjne, ale też znak towarowy („Elasticsearch”, „Kibana”), z którym wiąże się odrębny reżim prawny i brandingowy.

OpenSearch jako „tańszy” (ale nie darmowy) zamiennik

Reakcją na zmianę licencji Elasticsearch był projekt OpenSearch, rozwijany głównie przez AWS i społeczność, oparty na forku kodu z czasów Apache 2.0. Z punktu widzenia licencji to powrót do otwartości: Apache 2.0, bez ograniczeń typowych dla Elastic License.

Zyskujesz:

• swobodę budowy własnej usługi „as a Service”,
• brak ryzyka, że producent za kilka lat zmieni licencję pod ciebie,
• łatwiejszą drogę do customowych buildów, rozszerzeń, dystrybucji własnych binariów.

Ceną są inne koszty:

• rozejście się roadmapy – Elasticsearch i OpenSearch rozwijają się już w odmiennych kierunkach, więc nie wszystko da się „łatwo przenieść”,
• mniej gotowych integracji w niektórych obszarach (choć sytuacja szybko się poprawia),
• czas na migrację, testy kompatybilności, przeszkolenie zespołu.

Dla firm od logów i monitoringu OpenSearch bywa rozsądną drogą „odcięcia pępowiny” od Elastic License. Trzeba jednak policzyć koszty: migracja z produkcyjnymi indeksami, retencją i skomplikowanymi pipeline’ami ingestu to nie jest weekendowy projekt.

Praktyczne zasady używania Elasticsearch z ograniczonym budżetem ryzyka

Jeśli nie planujesz zostać następnym wielkim dostawcą logów, racjonalne podejście do Elasticsearch zwykle sprowadza się do kilku prostych zasad:

• wykorzystuj Elasticsearch jako komponent wewnętrzny, a nie „produkt, który sprzedajesz dalej”;
• korzystaj z oficjalnego Elastic Cloud, jeśli i tak nie zamierzasz budować własnej usługi – przerzucasz wtedy część ryzyka prawno‑licencyjnego na producenta, płacąc za to gotówką zamiast czasem prawników i devopsów;
• jeżeli musisz mieć własny hosting i multi‑tenant logi, policz od razu koszt przejścia na OpenSearch – może się okazać, że od pierwszego dnia taniej jest inwestować w stack, który nie ma „zaminowanej” licencji.

Odkładanie tej decyzji zwykle działa jak dorzucanie kolejnych walizek do samochodu, którym i tak trzeba będzie zawrócić. Im później, tym droższy skręt.

Redis, RSAL i model „core open source + moduły komercyjne”

Dlaczego Redis nie jest po prostu „darmową bazą w pamięci”

Sam Redis jako silnik in‑memory jest dostępny na liberalnej licencji BSD‑3‑Clause. Problem pojawia się przy modułach i rozszerzeniach, które dają mu „drugie życie”: RedisJSON, RediSearch, RedisGraph i podobne. Część z nich przeszła na Redis Source Available License (RSAL) albo inne warianty source available.

Efekt jest taki, że wiele materiałów w sieci mówi „Redis jest open source, korzystaj śmiało”, a jednocześnie nowoczesne funkcje, które czynią z Redisa konkurencję dla wyszukiwarek czy baz dokumentowych, są już objęte ograniczeniami licencyjnymi.

Na czym polega pułapka RSAL

RSAL w uproszczeniu pozwala:

• czytać kod,
• uruchamiać go lokalnie,
• wykorzystywać w wewnętrznych systemach i zwykłych aplikacjach.

Zakazuje natomiast budowania usług konkurencyjnych wobec oferty Redis Ltd., głównie w obszarze Database as a Service i szeroko rozumianych usług hostowanych. Jeśli więc:

• tworzysz platformę, gdzie klient „dostaje instancję Redisa z modułami” z rozliczeniem per GB / per request,
• oferujesz zarządzane klastry z modułami RSAL jako główny feature produktu,
• komunikujesz ofertę jako alternatywę dla Redis Enterprise Cloud,

wchodzisz w obszar, który licencja stara się zablokować. Dodatkowy problem: nie wszystkie moduły mają identyczne warunki, więc każdorazowo trzeba zajrzeć do konkretnego pliku LICENSE.

Typical stack z Redisem i gdzie w nim są miny

Z punktu widzenia większości zespołów Redis jest „cachem” albo prostą kolejką i tu ryzyka praktycznie nie ma. Kłopot zaczyna się, gdy Redis staje się „główną bazą danych plus indeksy wyszukiwania plus dokumenty JSON”. Przykładowe scenariusze:

• front do aplikacji mobilnej trzyma dane użytkownika w RedisJSON, a wyszukiwanie robi RediSearch – aplikacja jest monolitem biznesowym, więc tu RSAL raczej nie „ugryzie”, dopóki nie sprzedajesz samej usługi bazy;
• platforma SaaS udostępnia klientom „super szybkie API danych w pamięci”, a pod spodem dla każdego klienta stoi logiczna instancja Redisa z modułami – tu bardzo szybko można zostać uznanym za dostawcę DBaaS;
• mniejszy dostawca chmury oferuje „Redis z modułami jako usługę zarządzaną” – to podręcznikowy przypadek naruszenia RSAL.

Różnica między „użyciem wewnętrznym” a „oferowaniem usługi bazodanowej” jest subtelna w marketingu, ale kluczowa w licencji. Nazwa pakietu pricingowego i opis na stronie sprzedażowej bywają dla prawnika ważniejsze niż to, jak zespół techniczny rozumie swoją architekturę.

Oszczędne alternatywy dla „pełnego” Redisa

Jeżeli chcesz ograniczyć koszty ryzyka licencyjnego, a jednocześnie korzystać z ekosystemu Redisa, masz kilka ścieżek:

• zostać przy core Redisie na BSD – potraktować go wyłącznie jako cache, prostą kolejkę, ewentualnie sesje; wyszukiwanie i JSON przenieść do innych, otwartych technologii;
• sięgnąć po alternatywne moduły lub forki pod liberalnymi licencjami (tam, gdzie istnieją), zamiast kluczowych modułów RSAL;
• jeśli twoim modelem biznesowym jest DBaaS, od razu wybrać inną technologię, która nie ma klauzul blokujących konkurencyjne usługi (np. PostgreSQL, KeyDB, DragonflyDB – każdorazowo z weryfikacją konkretnej licencji).

Najczęstsze mity wokół Redis, Elastic, MongoDB w firmach

„Przecież to open source, więc mogę wszystko”

Najpopularniejsze uproszczenie brzmi: „kod jest na GitHubie, więc to open source, więc luz”. W praktyce:

• MongoDB od wersji 4.0+ na SSPL nie jest akceptowane przez OSI jako open source; to licencja source available z dodatkowymi ograniczeniami dla usług hostowanych;
• Elastic od 7.11+ (Elasticsearch, Kibana) ma dual‑licensing (Elastic License / SSPL), więc w nowych wersjach nie działasz już na Apache 2.0;
• moduły Redisa na RSAL również nie są „wolnym oprogramowaniem” w klasycznym znaczeniu – możesz je czytać i używać, ale nie budować na nich konkurencyjnego DBaaS.

Źródło nieporozumień jest proste: slajd na konferencji czy blog sprzed pięciu lat był prawdziwy w swoim czasie, ale licencje się zmieniły. Materiały marketingowe za zmianami nie nadążają.

„Ryzyko licencyjne dotyczy tylko dostawców chmur”

Drugi mit: dopóki nie masz wielkiego logo chmury na stronie, prawnicy MongoDB czy Elastica się tobą nie zainteresują. To wygodne założenie, ale niekoniecznie bezpieczne.

Na celowniku bywają firmy średniej wielkości, które:

• sprzedają managed cluster pod inną marką („my zarządzamy Mongo/Elastic/Redisem za ciebie”);
• budują gotowe appliance / VM‑ki z preinstalowanym stackiem i dokładają do tego fakturę abonamentową;
• robią white‑label SaaS, gdzie realnie oferują usługę bazodanową, choć na stronie produkt nazywa się „Customer Data Hub” czy „Log Center”.

Masz przewagę nad hiperscalerem – możesz się dogadać, zmienić ofertę, szybko zmigrować. Ale im później zorientujesz się, że jesteś „małym AWS‑em od Elastica”, tym więcej będzie kosztowało wyhamowanie.

„Jak nie sprzedaję samej bazy, to jestem bezpieczny”

SSPL, Elastic License czy RSAL nie patrzą wyłącznie na to, co masz wpisane w kolumnie „Product name” w CRM‑ie. Istotne jest, co obiektywnie robisz:

• czy twoja usługa oferuje możliwość tworzenia i zarządzania instancjami danej bazy / wyszukiwarki;
• czy billing i marketing odnoszą się do zasobów typowo bazodanowych (GB danych, IOPS, liczbę shardów, liczbę requestów do DB);
• czy klient może korzystać z API tej bazy bez pośredniego kontekstu biznesowego (czyli to jest raczej „DBaaS” niż „aplikacja biznesowa, która pod spodem używa DB”).

Jeżeli dasz klientowi panel, gdzie może „dodać instancję Mongo z 2 vCPU, 4 GB RAM i 200 GB storage”, to nawet jeśli nazwiesz to „Analytics Node”, w praktyce sprzedajesz usługę bazodanową.

„Dawne wersje na Apache / AGPL rozwiążą problem na lata”

Popularna ucieczka: „zostaniemy na wersji X, która była jeszcze na Apache 2.0 / AGPL, i po temacie”. To działa, dopóki:

• nie potrzebujesz łat bezpieczeństwa, które wychodzą tylko dla nowych wydań;
• nie pojawi się krytyczny bug w protokole lub formacie danych i integracje wymuszą update;
• klienci nie zaczną wymagać konkretnych funkcji dostępnych wyłącznie w nowszych wersjach.

Techniczny koszt „zamrożenia” wersji bywa dużo wyższy niż koszt licencji albo migracji. Szczególnie przy długim retencji danych (logi, analityka), gdzie utrzymujesz te same klastry przez lata.

„Przerzucimy ryzyko na klienta w umowie”

Czasem pojawia się pomysł, by w umowie z klientem dopisać, że „klient ponosi pełną odpowiedzialność za użycie baz XYZ”. Problem w tym, że:

• jeśli to ty uruchamiasz i zarządzasz klastrem, to ty jesteś stroną używającą oprogramowania pod daną licencją;
• nawet jeśli klient podpisał każdy możliwy disclaimer, producent licencjonowanego oprogramowania idzie do ciebie, bo to ty dystrybuujesz usługę opartą na jego kodzie;
• klient może oczekiwać odszkodowania od ciebie, gdy z powodu sporu licencyjnego musisz wyłączyć usługę lub ją nagle zmigrować.

„Przerzucanie ryzyka” na papierze bez zmiany architektury ma sens tylko do momentu, w którym faktycznie ktoś zapuka z roszczeniami. Potem liczy się to, co zrobić możesz technicznie, a nie to, co jest w paragrafach.

„Jak zmienimy nazwę, to nie będziemy konkurencją”

Kolejna iluzja: „nie piszmy, że to managed Elastic/Mongo/Redis, tylko wymyślmy swoją nazwę produktu i po kłopocie”. Zarówno SSPL, Elastic License, jak i RSAL odnoszą się do charakteru usługi, a nie do brandingu.

Jeżeli usługa:

• realnie umożliwia klientom hostowanie i używanie danej bazy w sposób podobny do ofert producenta,
• zapewnia SLA, backup, autoskalowanie tej bazy,
• pozwala programistom podłączyć się standardowym driverem Mongo/Elastica/Redisa,

to dla prawnika producenta jesteś konkurencyjną usługą – niezależnie od tego, czy nazwiesz ją „TurboCache Cloud”, „SearchHub”, czy „DataLake 2.0”.

Konsekwencje biznesowe: vendor lock‑in, pivot technologiczny i koszty odwrotu

Jak rodzi się vendor lock‑in przy licencjach source available

Techniczny lock‑in to jedno (API, format danych, DSL), ale przy licencjach source available dochodzi lock‑in prawny. Schemat jest prosty:

1. wybierasz narzędzie, bo jest „praktycznie open source” – kod jest dostępny, licencja wydaje się znośna;
2. budujesz wokół niego kluczowe usługi, które trudno będzie przepisać;
3. producent zmienia licencję, model cenowy lub egzekwowanie istniejących zapisów;
4. masz do wyboru: płacić, ryzykować spór albo finansować migrację na inne rozwiązanie.

To, co na początku było oszczędnością („weźmy to, bo darmowe / tanie”), po kilku latach bywa jednym z największych wydatków w roadmapie.

Kiedy pivot technologiczny jest tańszy niż walka z licencją

Są trzy momenty, w których realnie opłaca się usiąść i policzyć koszt zmiany technologii:

• Po zmianie licencji lub cennika – np. zmiana na SSPL, Elastic License, RSAL lub wzrost cen supportu/licencji o kilkadziesiąt procent;
• Po wejściu w nowy model biznesowy – np. startujesz jako produkt SaaS „z bazą w środku”, a po dwóch latach chcesz oferować klientom zarządzane klastry;
• Przy większym re‑archecie – i tak zmieniasz strukturę danych, pipeline’y, komponenty, więc migrację bazy da się „wpleść” w większy projekt.

Kalkulacja jest ziemska: ile kosztuje rocznie licencja / ryzyko prawne vs. ile pochłonie jednorazowa migracja (dev, QA, downtime, szkolenia). Przy dłuższym horyzoncie (3–5 lat) migracja częściej wychodzi taniej, niż się wydaje po pierwszym, pobieżnym spojrzeniu.

Warstwy abstrakcji jako „ubezpieczenie” na wypadek zmiany licencji

Jednym z prostszych, budżetowych zabezpieczeń jest architektura anty‑lock‑in. Nie musi to być od razu hyper‑skomplikowany data mesh. W praktyce pomagają rzeczy typu:

• wydzielenie warstwy dostępowej do bazy (np. moduł, serwis, biblioteka), zamiast klejenia drivera do każdego mikroserwisu;
• unikanie „wycieków” DSL‑a wyszukiwarki czy specyficznych komend DB do warstwy frontu i kontraktów z klientami;
• opisanie formatów danych i miejsc, gdzie korzystasz z vendor‑specyficznych funkcji (np. pipeline’ów agregacyjnych, skryptów w indeksie).

Dzięki temu pivot z Elasticsearch na OpenSearch, z MongoDB na Postgresa z JSONB, czy z modułów Redisa na alternatywę jest kwestią „przepisania jednego miejsca i testów”, a nie przeklejenia połowy kodu w całej organizacji.

Scenariusz migracji: ile to naprawdę kosztuje

Migracja z „zaminowanego” narzędzia to nie tylko przestawienie drivera. W typowym projekcie w koszty trzeba wrzucić:

• czas zespołu dev – adaptacja schematów, zapytań, indeksów, batchy, workerów;
• testy wydajności – nowa baza może inaczej reagować na patterny odczytu/zapisu, więc trzeba mieć budżet na tuning;
• okno migracyjne – pełny downtime, przełączenie na żywo albo dłuższe „podwójne pisanie” do dwóch systemów;
• koszt infra w okresie przejściowym – przez kilka miesięcy często utrzymujesz dwa klastry równolegle;
• szkolenie zespołu – nawet dobra baza „plug‑and‑play” wymaga poznania niuansów, żeby nie generowała niespodzianek po produkcji.

Z drugiej strony – to są koszty jednorazowe. Licencje, opłaty za komercyjne moduły czy ryzyko procesów ciągną się co rok. W pewnym momencie bilans przesuwa się na stronę „przepisać i mieć spokój”.

Taniej nie znaczy zawsze „open source za wszelką cenę”

Czasem najbardziej ekonomicznym ruchem jest świadome pójście w komercję zamiast trzymania się na siłę darmowego forka. Przykład z życia:

• mała firma integratorska ma kilka krytycznych wdrożeń na Elasticu, ale żadnych planów budowy własnego „managed ELK”;
• zespół zna bardzo dobrze oficjalne narzędzia Elastica, pipeline’y, dashboardy i nie ma zasobów na przepisywanie wszystkiego na OpenSearch;
• koszt przejścia na Elastic Cloud / komercyjną licencję jest niższy niż łączny koszt migracji, retrainingu i przezbrojenia monitoringu.

W takiej sytuacji „budżetowy pragmatyk” kupi normalną licencję i pogodzi się z vendor lock‑in, ale z pełną świadomością, że zapłacił za mniejszy ból głowy. Sztuczka polega na tym, żeby policzyć oba scenariusze, a nie automatycznie zakładać, że open source = taniej.

Strategia „plan B”: mieć przygotowaną drogę odwrotu

Niedrogi sposób na ograniczenie ryzyka to przygotowanie planów awaryjnych, nawet jeśli ich nigdy nie zrealizujesz. W praktyce to może być:

• prosty proof of concept na alternatywnej technologii (np. zestawienie OpenSearch obok Elastica i odtworzenie krytycznych dashboardów);
• spisanie listy feature’ów, z których realnie korzystasz (sharding, TTL, pipeline’y ingestu, moduły) i sprawdzenie, czy są odpowiedniki w alternatywach;
• utrzymywanie eksportu danych w ustandaryzowanej formie (np. NDJSON, Parquet), a nie wyłącznie w vendor‑specyficznych strukturach.

To nie musi być projekt na kwartał. Kilka dni pracy rozłożone w czasie potrafi w krytycznym momencie skrócić migrację z miesięcy do tygodni – a to już różnica między kontrolowanym pivotem a gaszeniem pożaru po nocach.

Bibliografia

• The Open Source Definition. Open Source Initiative – Definicja open source, kryteria licencji uznawanych przez OSI
• MIT License. Massachusetts Institute of Technology – Treść licencji MIT i zakres dozwolonego użycia komercyjnego
• Apache License, Version 2.0. Apache Software Foundation (2004) – Treść licencji Apache 2.0, w tym postanowienia patentowe
• GNU General Public License, version 3. Free Software Foundation (2007) – Treść GPLv3, zasady copyleft przy dystrybucji oprogramowania
• Server Side Public License (SSPL) FAQ. MongoDB Inc. – Wyjaśnienie SSPL, wymogi wobec dostawców usług i powody zmiany licencji
• Elastic License 2.0. Elastic NV (2021) – Treść Elastic License 2.0, ograniczenia usług konkurencyjnych i dystrybucji
• Redis Source Available License (RSAL). Redis Ltd. – Treść RSAL, ograniczenia budowy usług konkurencyjnych wobec Redis
• Open Source Licensing: Software Freedom and Intellectual Property Law. Prentice Hall (2004) – Przegląd modeli licencyjnych, w tym MIT, Apache, GPL i ich skutków prawnych