Scenka z życia: „Przecież mamy już licencje” – pierwszy zgrzyt z chmurą
Dyrektor IT podpisuje umowę na migrację kluczowego systemu do AWS. Zespół techniczny planuje przeniesienie baz danych i serwerów aplikacyjnych, zakładając, że wystarczy „przenieść” dotychczasowe licencje. Po tygodniu spotkanie z działem prawnym: okazuje się, że producent oprogramowania nie uznaje wybranego modelu chmury jako środowiska, w którym wolno korzystać z posiadanych licencji.
Pierwsza myśl bywa bardzo ludzka: „Zapłaciliśmy za licencje, więc chyba możemy ich używać gdzie chcemy?”. Tymczasem licencja to nie rzecz, którą można dowolnie przewieźć jak serwer. To zestaw precyzyjnych warunków: gdzie, jak i w jakim modelu usług wolno korzystać z oprogramowania. W chmurze publicznej, takiej jak AWS, Azure czy GCP, te warunki potrafią wyglądać zupełnie inaczej niż w tradycyjnym data center.
Bring Your Own License (BYOL) często jawi się jako prosty sposób na oszczędności. Firmy liczą, że jeśli mają już kupione licencje on‑premises, to ich wykorzystanie w chmurze będzie niemal darmowe. Prawdziwy obraz jest bardziej złożony: BYOL to reżim prawno‑techniczny. Trzeba pogodzić model chmury (multi‑tenant, dedicated host, regiony, automatyzacja) z literą zapisów EULA, Product Terms czy Enterprise Agreement.
W praktyce BYOL w chmurze publicznej opłaca się tylko wtedy, gdy spełnione są jednocześnie trzy warunki: licencja prawnie na to pozwala, da się to sensownie ogarnąć technicznie i faktycznie wychodzi taniej niż wariant „license included”. Wszystko poza tym to proszenie się o problemy przy audycie lub przepłacanie za zbyt skomplikowany model.
Najważniejszy wniosek na start: decyzja „BYOL czy nie” nie powinna zapadać na poziomie pojedynczego projektu migracyjnego. To element szerszej strategii licencyjnej, w której IT, finanse i dział prawny grają do jednej bramki, zamiast ciągnąć w trzy różne strony.
Czym jest BYOL w chmurze – definicje bez marketingowego pudru
Co faktycznie „wnosimy” przy Bring Your Own License
W modelu BYOL nie przenosisz pudełka, klucza ani nośnika. Przenosisz prawo do używania oprogramowania w określonych warunkach. To prawo opisane jest w dokumentach licencyjnych producenta, a nie w folderze marketingowym czy prezentacji sprzedawcy.
W kontekście chmury publicznej BYOL oznacza, że:
- korzystasz z infrastruktury chmurowej (VM, storage, sieć) dostawcy typu AWS, Azure, GCP,
- instalujesz na niej własne oprogramowanie, do którego posiadasz licencje (np. Windows Server, SQL Server, Oracle DB, WebSphere, oprogramowanie zabezpieczające),
- rezygnujesz z licencji „wbudowanej” w usługę chmurową (np. RDS z licencją Microsoft/Oracle, Windows Server z licencją od AWS),
- samodzielnie odpowiadasz za zgodność licencyjną z producentem oprogramowania.
Na fakturze od chmury przy BYOL płacisz głównie za surową infrastrukturę (compute, storage, sieć), a za prawo do używania oprogramowania rozliczasz się oddzielnie, według umowy z producentem. To właśnie ten rozdział bywa źródłem problemów – kiedy vendor nie zgadza się, by dane licencje były wykorzystywane w środowisku należącym do trzeciej strony (cloud providera).
BYOL a modele license included, SPLA, SaaS
Przed rozważeniem, czy BYOL ma sens, dobrze jest odróżnić go od innych powszechnych modeli licencjonowania w chmurze:
- License included – licencja na oprogramowanie jest wliczona w cenę usługi chmurowej. Przykład: masz instancję Windows Server na EC2 w AWS, a na fakturze płacisz stawkę za „Windows + EC2”. Nie potrzebujesz własnej licencji Windows Server.
- SPLA / hosting provider license – dostawca usług (np. partner Microsoft, hostingodawca) rozlicza licencje hurtowo i wynajmuje ci je w modelu miesięcznym. W chmurze publicznej zwykle odpowiada to sytuacji, w której korzystasz z gotowych usług PaaS lub z aplikacji dostarczanych przez partnera.
- SaaS – oprogramowanie jako usługa. Licencji na poziomie infrastruktury w zasadzie nie widzisz, bo płacisz za subskrypcję aplikacji (np. Office 365, Salesforce). BYOL dotyczy głównie warstwy IaaS/PaaS, nie SaaS.
BYOL stoi w kontrze do tych modeli: własne licencje zamiast licencji narzuconej przez dostawcę chmury. Czasem daje to realne oszczędności (np. przy dużych inwestycjach w licencje wieczyste on‑premises), ale równie często oznacza dodatkowe koszty zarządzania, audytów i konfiguracji technicznych.
Typy licencji najczęściej używane w modelu BYOL
W praktyce BYOL w chmurze publicznej dotyczy kilku kluczowych grup oprogramowania:
- Systemy operacyjne serwerów – przede wszystkim Windows Server, czasem również Linux w wersjach komercyjnych (Red Hat, SUSE) lub Solaris w scenariuszach specyficznych.
- Bazy danych – Microsoft SQL Server, Oracle Database, DB2, czasem PostgreSQL/Enterprise czy inne komercyjne dystrybucje.
- Middleware i serwery aplikacji – WebLogic, WebSphere, JBoss EAP, serwery ESB, narzędzia integracyjne.
- Narzędzia bezpieczeństwa – systemy antywirusowe, EDR/XDR, WAF, narzędzia DLP w wersjach serwerowych.
Każda z tych kategorii ma swoje własne zasady licencjonowania, które wpływają na to, czy BYOL w ogóle jest dopuszczalny, a jeśli tak – w jakich konfiguracjach infrastruktury chmurowej i w jakich regionach.
Per-core, per-CPU, per-user – jak model licencji wpływa na BYOL
Większość licencji używanych w BYOL licencjonowana jest albo na zasoby sprzętowe, albo na użytkowników. Najpopularniejsze modele:
- Per-core / per-CPU / per-socket – licencja przypisana do rdzeni fizycznych lub logicznych, gniazd procesora, czasem do określonej mocy obliczeniowej (vCPU).
- Per-server / per-instance – stała licencja na instancję serwera, często z ograniczeniami co do liczby rdzeni lub użytkowników.
- Per-user / per-device – licencja przypisana do użytkownika lub urządzenia (często w systemach biurowych, terminalowych, aplikacjach biznesowych).
- Subskrypcje – prawo do używania w danym okresie czasu (miesiąc, rok), czasem powiązane z Software Assurance/maintenance.
W chmurze kluczowe jest, jak producent interpretuje mapowanie zasobów chmurowych na jednostki licencyjne. Np. dla SQL Server Microsoft definiuje, ile vCPU w Azure odpowiada licencjonowanemu core on‑premises, przy czym w licencji dopuszcza określone typy instancji i modele hostingu. Oracle z kolei często wymaga licencjonowania pełnych hostów fizycznych (np. w przypadku niektórych konfiguracji AWS), co drastycznie zmienia kalkulację opłacalności BYOL.
Ograniczenia geograficzne i środowiskowe w kontekście BYOL
W licencjach często pojawiają się pojęcia typu on‑premises, outsourcing, third‑party hosting, qualified cloud provider, a także ograniczenia geograficzne (np. terytorium kraju lub regionu). Dla BYOL szczególnie istotne są:
- Rozróżnienie własnej infrastruktury a infrastruktury podmiotu trzeciego – chmura publiczna jest z definicji infrastrukturą dostawcy zewnętrznego, chyba że mówimy o modelach typu dedicated region / on‑premises extension (Azure Stack, AWS Outposts, Google Distributed Cloud).
- Lista „kwalifikowanych dostawców chmurowych” – niektórzy vendorzy dopuszczają BYOL wyłącznie w chmurach z listy (np. Microsoft historycznie wskazywał Authorized Mobility Partners).
- Multi‑tenant vs dedicated – środowisko współdzielone przez wielu klientów (multi‑tenant) często jest traktowane inaczej niż dedykowany host fizyczny przeznaczony tylko dla jednej organizacji.
Jeżeli licencja mówi wprost, że przeniesienie do środowiska hostingowego lub chmury innej niż „kwalifikowana” powoduje utratę prawa do BYOL, to migracja na „zwykłe” VM w AWS, Azure czy GCP potrafi zabić całą koncepcję oszczędności. Wtedy jedynym legalnym rozwiązaniem może być zakup licencji w modelu chmurowym (license included, SaaS) albo użycie dedykowanych hostów, które vendor traktuje bardziej jak „przedłużenie on‑premises”.
Ramy prawne i kontraktowe – co tak naprawdę „mówi” licencja
Gdzie szukać realnych zasad BYOL – EULA, Product Terms, umowy EA
Warunki BYOL nie wynikają z tego, co powiedział handlowiec na spotkaniu, lecz z konkretnych dokumentów. Typowe źródła:
- EULA (End User License Agreement) – podstawowa umowa licencyjna, często akceptowana przy instalacji oprogramowania.
- Product Terms / Licensing Terms – dokument opisujący szczegółowe zasady licencjonowania produktów (np. dla Microsoft: Product Terms, wcześniej Product Use Rights).
- Umowy korporacyjne – Enterprise Agreement (EA), MPSA, umowy partnerskie, umowy utrzymaniowe (Software Assurance, maintenance).
- Polityki BYOL / Cloud Policy – dodatkowe publikacje producentów, gdzie wprost opisują zasady korzystania z licencji w chmurach publicznych.
Bez lektury tych dokumentów BYOL przypomina jazdę samochodem po obcym kraju bez znajomości przepisów – przez jakiś czas jakoś to idzie, aż do pierwszego poważnego kontrolera, który pokaże paragraf. Audytorzy producentów oprogramowania dokładnie znają te zapisy i będą się na nie powoływać, nawet jeśli „wszyscy w branży robią inaczej”.
Definicje licencyjne wpływające na korzystanie w chmurze
W dokumentach licencyjnych występują pojęcia, które wydają się techniczne, a w praktyce mają ogromne konsekwencje:
- „Licensed Server” / „Licensed Device” – określenie, do jakiego serwera lub urządzenia przypisana jest licencja. W chmurze, gdzie VM migrują pomiędzy hostami fizycznymi, bardzo ważne staje się to, czy vendor wymaga przypisania licencji do fizycznego hosta, czy dopuszcza powiązanie z „logiczna instancją”.
- „Outsourcing” / „third‑party hosting” – definicje używane, aby rozróżnić korzystanie z oprogramowania na własnej infrastrukturze od korzystania z infrastruktury podmiotu trzeciego. Chmura publiczna zwykle podpada pod tę drugą kategorię.
- „Qualified cloud provider” / „Authorized Mobility Partner” – specjalne statusy nadawane wybranym dostawcom chmury, które otwierają lub ograniczają możliwość korzystania z BYOL.
Na przykład w licencjach Microsoftu przez lata funkcjonowały rozróżnienia, które pozwalały na korzystanie z BYOL z Software Assurance tylko w chmurach wymienionych jako Authorized Mobility Partners (AWS, GCP), a jednocześnie ograniczały pewne scenariusze BYOL na własnej platformie Azure bez dodatkowych subskrypcji. Brak świadomości takich definicji prowadzi do projektów zaprojektowanych „na zdrowy rozsądek”, ale niezgodnych z literą licencji.
Prawo do wsparcia a prawo do mobilności licencji
Wielu klientów miesza dwa pojęcia: prawo do korzystania z oprogramowania i prawo do wsparcia/aktualizacji. Tymczasem programy typu Software Assurance (Microsoft) czy maintenance (u innych vendorów) często zawierają dodatkowy element: prawo do mobilności licencji (License Mobility).
W praktyce może to oznaczać, że:
- bez aktywnego SA/maintenance masz prawo używać oprogramowania tylko w on‑premises lub w ściśle zdefiniowanym modelu hostingu,
- z aktywnym SA możesz przenieść licencję do określonego typu chmury (np. do partnerów z listy Authorized Mobility Partners),
- ale nawet z SA nadal obowiązują ograniczenia co do typu instancji, środowiska (shared vs dedicated), czasu przypisania licencji do serwera itp.
Organizacje, które „tną koszty” przez rezygnację z odnowienia Software Assurance, często nie zdają sobie sprawy, że w tym samym momencie ograniczają sobie możliwość legalnego korzystania z BYOL w chmurze. Oszczędność na wsparciu bywa więc pozorna, bo trzeba potem kupić nowe licencje w modelu chmurowym lub przepłacać za droższe warianty usług.
Jak vendorzy formułują zakazy i ograniczenia BYOL
Zakazy wykorzystania BYOL w chmurze rzadko są opisane hasłem „nie wolno używać w chmurze publicznej”. Raczej pojawiają się w formie:
- wyłączenia z definicji uprawnień (np. „License Mobility does not apply to…”),
- zastrzeżenia, że licencje są ważne tylko w „on‑premises or private cloud under your sole control”,
- rozróżnienia pomiędzy „dedicated hardware” a „multi‑tenant environment”,
- dodatkowych warunków: konieczność zgłoszenia użycia licencji w chmurze, minimalne okresy przypisania licencji do serwera (np. 90 dni).
Kiedy licencja „on‑premises” nagle staje się licencją „tylko‑tu‑i‑teraz”
Podczas przeglądu architektury migracji architekt z IT mówi: „Te licencje baz danych mamy wykupione na całą firmę, więc przecież możemy je użyć w AWS”. Prawnik po dwóch dniach lektury umów wraca z jednym zdaniem: „Możecie – ale tylko w serwerowni, którą kontrolujecie”. Atmosfera na statusie projektu robi się wyraźnie chłodniejsza.
W wielu przypadkach licencja, która z perspektywy działu IT wygląda na „globalną”, w rzeczywistości jest związana z bardzo konkretnym modelem korzystania z infrastruktury. Producent pisze z pozoru niewinne „within your data centers under your control”, co w praktyce oznacza:
- brak prawa do używania tych licencji w klasycznym środowisku chmury publicznej,
- ograniczone pole manewru nawet w kolokacji czy hostingu, jeśli nie spełnia kryterium „under your control”,
- pełną odpowiedzialność po stronie klienta za to, jak interpretuje te zapisy przy projektowaniu BYOL.
Każdy projekt BYOL, który startuje od założenia „mamy licencje, więc możemy”, a nie od pytania „jakie konkretnie mamy prawa w tych licencjach”, jest kandydatem do bolesnej korekty podczas audytu lub renegocjacji kontraktu.
BYOL a model współdzielenia zasobów w chmurze (multi‑tenant, dedicated, on‑premises extension)
Dlaczego „gdzie” działa VM jest tak samo ważne jak „ile ma vCPU”
W jednym z projektów klient policzył, że przeniesienie licencji bazodanowych do chmury pozwoli zaoszczędzić kilkaset tysięcy złotych rocznie. W arkuszu kalkulacyjnym wszystko się zgadzało – do momentu, gdy okazało się, że vendor wymaga licencjonowania całego hosta fizycznego w środowisku współdzielonym. Nagłe przejście z licencjonowania 16 vCPU na licencjonowanie 2 fizycznych serwerów po 64 rdzenie każdy wywróciło kalkulację do góry nogami.
W chmurze kluczowe jest nie tylko „ile” zasobów zużywa aplikacja, ale też „jak” i „z kim” są współdzielone zasoby fizyczne. Z perspektywy licencji można wyróżnić trzy główne modele:
- Środowisko multi‑tenant – zasoby fizyczne (hosty) są współdzielone pomiędzy wielu klientów chmury, a izolacja odbywa się głównie na poziomie wirtualizacji i sieci.
- Środowisko dedicated / single‑tenant – cały host fizyczny (lub grupa hostów) jest logicznie przypisana do jednego klienta; inni klienci nie uruchamiają na nim swoich VM.
- On‑premises extension – rozwiązania typu AWS Outposts, Azure Stack HCI, Google Distributed Cloud, formalnie utrzymywane przez dostawcę chmury lub partnera, ale fizycznie zlokalizowane w infrastrukturze klienta i często traktowane w licencjach jak „przedłużenie” serwerowni.
To, do której z tych kategorii vendor przypisze używany model chmury, ma bezpośredni wpływ na możliwość zastosowania BYOL oraz na sposób liczenia jednostek licencyjnych.
Multi‑tenant – wygodnie technicznie, ryzykownie licencyjnie
Środowisko multi‑tenant to domyślny model infrastruktury w AWS, Azure i GCP. Z punktu widzenia IT ma mnóstwo zalet: automatyczną skalowalność, elastyczne rozmieszczanie VM, szybkie przydzielanie zasobów. Dla licencji on‑premises ten model bywa jednak trudny do pogodzenia z zapisami umów.
Typowe problemy w multi‑tenant przy BYOL:
- Wymóg licencjonowania całego hosta – niektórzy vendorzy (np. w kontekście części produktów bazodanowych) wymagają, aby licencja pokrywała wszystkie fizyczne rdzenie hosta, na którym może potencjalnie działać VM klienta. W multi‑tenant praktycznie nie da się „wydzielić” części rdzeni tylko dla jednego klienta.
- Brak statusu „qualified cloud provider” – jeśli vendor uzna, że dana platforma multi‑tenant nie spełnia warunków kwalifikowanego dostawcy, użycie licencji w tym środowisku może być wprost zabronione.
- Migracja VM pomiędzy hostami – automatyczne przenoszenie VM między fizycznymi hostami (np. celem utrzymania dostępności) może powodować, że licencja powinna być przypisana do wielu hostów jednocześnie, co generuje znaczne nadlicencjonowanie.
W scenariuszach, gdzie multi‑tenant jest jedyną dostępną opcją (np. standardowe instancje w mniejszym regionie chmurowym), BYOL często traci sens ekonomiczny lub wchodzi w obszar istotnego ryzyka zgodności.
Dedicated hosts i dedicated instances – kiedy chmura „udaje” serwerownię
Żeby pogodzić elastyczność chmury z wymaganiami licencyjnymi, dostawcy oferują modele z dedykowanym hardwarem. W praktyce oznacza to, że klient rezerwuje cały fizyczny host (lub pulę hostów) wyłącznie dla swoich VM, co przybliża ten model do klasycznej infrastruktury on‑premises.
Przykładowe konstrukcje spotykane u hyperscalerów:
- AWS Dedicated Hosts – fizyczne hosty przypisane do jednego konta, z możliwością kontrolowania umiejscowienia i liczb instancji na hoście.
- Azure Dedicated Host – logiczny „host” w ramach regionu Azure, na którym klient uruchamia własne VM i którego nie współdzieli z innymi klientami.
- Google Cloud Sole‑Tenant Nodes – fizyczne węzły zarezerwowane wyłącznie dla pojedynczego klienta.
Dedicated hosts zwykle otwierają bardziej korzystne scenariusze BYOL:
- część vendorów pozwala w takich środowiskach na licencjonowanie per‑core całego hosta, zgodnie z tabelami konwersji (np. ile vCPU = 1 core licencyjny),
- łatwiej jest udokumentować, że spełnione są warunki typu „under your control” lub „not shared with third parties”,
- można zoptymalizować rozmieszczenie VM z kosztownymi licencjami na mniejszej liczbie hostów, zamiast rozpraszania ich po wielu fizycznych maszynach.
Dedykowana infrastruktura w chmurze przestaje jednak być „z natury” tania: płaci się nie tylko za użyte vCPU i RAM, ale za cały host, niezależnie od jego wykorzystania. Dobrze zaprojektowany BYOL musi więc balansować pomiędzy oszczędnością na licencjach a wyższym kosztem infrastruktury.
On‑premises extension – gdy chmurowy hardware stoi u klienta
Rozwiązania typu AWS Outposts, Azure Stack HCI czy Google Distributed Cloud dzielą jeden wspólny element: sprzęt jest fizycznie zainstalowany u klienta lub w lokalnym data center partnerskim, ale zarządzany (w różnym stopniu) przez dostawcę chmury i zintegrowany z jego usługami.
Z licencyjnego punktu widzenia bywa to wygodne, bo część vendorów:
- traktuje takie środowiska jako on‑premises lub „private cloud under your control”,
- pozwala korzystać z tradycyjnych zasad BYOL, często takich samych jak dla klasycznej wirtualizacji (VMware, Hyper‑V),
- umożliwia prostsze liczenie rdzeni i serwerów – hosty są znane, kontrolowane i relatywnie stałe.
Jednocześnie pojawia się kilka pułapek:
- Modele subskrypcyjne hardware’u – gdy klient „wynajmuje” sprzęt od dostawcy chmury, niektórzy vendorzy mogą zakwalifikować to jako outsourcing lub hosting, z innym zestawem zasad licencjonowania.
- Mieszane środowiska – część workloadu migruje z on‑premises do publ