Microsoft SPLA

Niniejszy dokument ma charakter wyłącznie informacyjny i służy jako praktyczny przewodnik po postanowieniach licencyjnych Microsoft SPLA. Dokument nie zastępuje postanowień umowy SPLA ani postanowień licencyjnych SPUR. W przypadku jakichkolwiek rozbieżności rozstrzygający i nadrzędny charakter mają zawsze aktualne dokumenty licencyjne Microsoft (SPUR).

Postanowienia licencyjne

Postanowienia licencyjne SPLA mają nadrzędny charakter wobec innych warunków licencyjnych Microsoft. Wyjątkiem są wybrane korzyści Software Assurance, w szczególności License Mobility oraz Flexible Virtualization.

SPUR – Commercial Licensing Terms oraz End User Licence Terms (EULT) są dokumentami regulującymi zasady korzystania z poszczególnych Produktów Microsoft dostępnych dla użytkowników końcowych w ramach umowy SPLA.​

Glosariusz

Autoryzacja – autoryzacja do dostępu oznacza, że użytkownik jest technicznie uprawniony do uruchomienia i korzystania z oprogramowania, nawet jeśli faktycznie tego nie robi. Uprawnienie to może wynikać z przynależności do odpowiedniej grupy domenowej w Active Directory, która ma nadane prawa do korzystania z aplikacji lub logowania (np. przez RDS), albo z członkostwa w lokalnej grupie na serwerze, która daje możliwość uruchomienia danego programu.

Edycja – to wariant tej samej wersji oprogramowania, różniący się zestawem funkcji, licencją lub przeznaczeniem (np. Standard, Pro, Enterprise).

Metryka na rdzeń (per Core) – odnosi się do rdzenia procesora fizycznego dla serwerów fizycznych i liczby rdzeni wirtualnych vCPU dla maszyn wirtualnych.

Metryka User SAL – licencja dostępowa dla użytkownika rozumianego jako osoba fizyczna, do której jest przypisana.

OSE (Operating System Environment) – środowisko systemu operacyjnego, w praktyce najczęściej jedna konkretna maszyna wirtualna lub fizyczna.

Rdzeń wirtualny (vCPU) – rdzenie wirtualne przypisane do maszyny. Wyłączenie rdzeni w BIOS/UEFI nie zmniejsza wymogu licencyjnego.

Środowisko dedykowane – infrastruktura przeznaczona wyłącznie dla jednego klienta (np. indywidualny serwer fizyczny). Wówczas, wszystkie maszyny wirtualne hostowane na takim sprzęcie muszą należeć do jednego odbiorcy.

Środowisko produkcyjne – definiowane jest jako to fizyczne OSE działające z obciążeniem produkcyjnym lub uzyskujące dostęp do danych produkcyjnych, lub dowolne fizyczne OSE, które hostuje co najmniej jedno wirtualne OSE działające z obciążeniem produkcyjnym lub uzyskujące dostęp do danych produkcyjnych.

Środowisko współdzielone – infrastruktura serwerowa (np. host), na której utrzymywane są zasoby (np. maszyny wirtualne) przeznaczone dla różnych klientów.

VM – maszyna wirtualna.

Wersja – oznacza konkretne wydanie oprogramowania określone numerem (np. 2025, 11), które pokazuje etap rozwoju produktu oraz zakres zmian między kolejnymi aktualizacjami.

2.1 Prawo do obniżenia wersji oprogramowania​

Co do zasady w modelu SPLA, Klient końcowy ma prawo zainstalować Produkt w wersji niższej niż ta wynikająca z posiadanej licencji. W przypadku produktów Windows Server oraz SQL Server dopuszczalne jest również korzystanie z niższych edycji tych systemów.

2.2 Przypisanie i zmiana przypisania licencji

Licencja musi być przypisana do użytkownika lub serwera przed użyciem oprogramowania.

Zmiana przypisania w trakcie tego samego miesiąca kalendarzowego jest co do zasady niedozwolona, z wyjątkiem:

• trwałej awarii lub utraty sprzętu,
• tymczasowego przydziału SAL z powodu nieobecności użytkownika.

Po przeniesieniu licencji należy usunąć oprogramowanie lub zablokować dostęp poprzedniemu użytkownikowi albo urządzeniu.

2.3 Ograniczenia ogólne

Bez zgody Microsoft zabronione jest m.in.: dalsze udostępnianie lub podwynajmowanie oprogramowania podmiotom trzecim (np. sytuacja, w której klient dzierżawiący serwer w środowisku Atman przekazuje to urządzenie w podnajem innemu podmiotowi), obchodzenie zabezpieczeń technicznych, używanie jednej licencji w więcej niż jednym OSE, wykorzystywanie własności intelektualnej Microsoft w innych rozwiązaniach.

2.4 Multipleksowanie

Stosowanie warstw pośrednich (sprzętowych lub programowych) w celu ograniczenia lub grupowania Środowisk Systemu Operacyjnego albo użytkowników czy urządzeń uzyskujących dostęp do produktu nie zmniejsza wymogu licencyjnego. Współdzielenie kont nie eliminuje obowiązku posiadania oddzielnych licencji, wymóg licencyjny zawsze zależy od liczby użytkowników lub OSE mających dostęp, bezpośredni lub pośredni, do produktu, zgodnie z faktycznym użyciem, a nie liczbą kont.

Przykład multipleksingu:

• Autoryzacja kont współdzielonych przez wielu użytkowników (np. recepcja, ochrona, IT etc.) do dostępu do produktu (np. Office, Windows Server RDS etc.) bez zapewnienia indywidualnych licencji dla każdego z użytkowników.

2.5 Wnoszenie własnych licencji Klienta do środowiska (BYOL)

W przypadku środowisk współdzielonych w chmurze, wnoszenie własnych licencji Klienta jest dopuszczalne wyłącznie dla licencji z aktywnym pakietem Software Assurance lub licencji subskrypcyjnych.

Do środowisk dedykowanych, Klient może wnosić własne licencje niezależnie od posiadania pakietu Software Assurance.

Co do zasady licencje w modelu SPLA nie mogą być mieszane z licencjami z innych kanałów licencjonowania w obrębie tego samego produktu oraz tej samej maszyny wirtualnej. Niedopuszczalne jest częściowe spełnienie wymogu licencyjnego dla danej maszyny wirtualnej (np. dla Microsoft SQL Server) przy użyciu licencji SPLA i jednoczesne uzupełnianie brakujących licencji licencjami własności Klienta.

Natomiast w przypadku odrębnych maszyn wirtualnych (utworzonych na środowisku dedykowanym) dozwolone jest ich licencjonowanie w ramach licencji z różnych kanałów (np. SPLA oraz Volume Licensing), pod warunkiem, że każda maszyna jest pokryta licencjami wyłącznie z jednego kanału.

2.6 Disaster recovery (Windows Server i SQL Server)

Rozwiązanie umożliwia tymczasowe uruchamianie zapasowych serwerów wykorzystywanych w scenariuszach odzyskiwania po awarii, zarówno na potrzeby okresowych testów wykonywanych co 90 dni, jak i w sytuacji rzeczywistej awarii serwera produkcyjnego. Zapasowy serwer może zostać uruchomiony na krótko również w trakcie awarii, aby zapewnić płynny transfer obciążenia pomiędzy serwerem produkcyjnym a środowiskiem DR. Warunkiem licencyjnym jest to, aby taki serwer zapasowy nie znajdował się w tym samym klastrze co serwer produkcyjny, co zapewnia właściwą separację środowisk i zgodność z zasadami Disaster Recovery.

3.1 Licencjonowanie Windows Server

Licencje przypisywane są do serwera fizycznego.

W przypadku środowiska fizycznego całkowity wymóg licencyjny zależy od liczby procesorów i rdzeni serwera fizycznego. Minimum: 8 licencji na procesor.

W przypadku środowiska wirtualnego całkowity wymóg licencyjny zależy od liczby procesorów i rdzeni serwera fizycznego. Minimum: 8 licencji na procesor.

Edycja Datacenter umożliwia uruchomienie nielimitowanej liczby maszyn wirtualnych (VM).

Edycja Standard umożliwia uruchomienie 1 VM na zestaw licencji, każda kolejna VM wymaga ponownego zalicencjonowania serwera fizycznego.

• Całkowity wymóg licencyjny zależy od liczby maszyn wirtualnych hostowanych w okresie danego miesiąca kalendarzowego​
• Dopuszczalne jest użycie Hyper-V na serwerze fizycznym przy ograniczeniu, że serwer może być wykorzystywany wyłącznie do hostowania i zarządzania VM
• Uwaga: Przy włączonej migracji VM wymóg licencyjny wyznaczany jest tak, jakby wszystkie VM hostowane były na jednym serwerze fizycznym.

Typowe przypadki niezgodności

• Niekontrolowana migracja VM przy licencjonowaniu Windows Server Standard.
• Pominięcie wyłączonych serwerów podczas kalkulacji wymogu.
• Nieuwzględnienie instalacji oprogramowania (np. SQL Server, Office itp.) na hoście podczas kalkulacji wymogu​

3.2 Licencjonowanie Windows Server RDS SAL

1 licencja = autoryzacja dostępu jednego użytkownika do dowolnej liczby serwerów.

Możliwość autoryzacji do 2 administratorów do serwera( tylko czynności administracyjne), którzy nie wymagają wtedy licencji. Każdy kolejny administrator danego serwera wymaga licencji RDS SAL.

W przypadku wykorzystywania usług pulpitu zdalnego lub GUI serwera (np. wirtualizacja aplikacji przez Citrixa)​ każdy użytkownik rozwiązania wymaga licencji Windows Server RDS SAL.

Typowe niezgodności

• Powszechny dostęp (np. Domain Users)
• Utrzymywanie autoryzacji dla kont archiwalnych
• Współdzielenie kont i brak indywidualnych licencji dla użytkowników
• Autoryzacja większej liczby administratorów niż 2

3.3 Licencjonowanie SQL Server

Edycje

Komercyjne: Enterprise, Standard, Web.

Bezpłatne: Developer, Express.

Modele licencjonowania

Per Core (Enterprise, Standard, Web).

User SAL (tylko SQL Standard).

Licencjonowanie SQL Server Enterprise, Standard oraz Web

Licencje w metryce na rdzeń przypisywane są do serwera fizycznego.

W przypadku instalacji bazy danych bezpośrednio na serwerze fizycznym całkowity wymóg licencyjny zależy od liczby procesorów i rdzeni serwera fizycznego

Minimum: 4 licencje na procesor.

Pokrycie hosta fizycznego licencją SQL Server Enterprise umożliwia uruchomienie nieograniczonej liczby maszyn wirtualnych z zainstalowanym SQL Server na danym hoście.

W przypadku instalacji bazy danych bezpośrednio na maszynie wirtualnej całkowity wymóg licencyjny zależy od liczby rdzeni wirtualnych (vCPU) VM.

Minimum: 4 licencje na VM.

Dozwolona automatyczna migracja VM.

Licencjonowanie SQL Server Standard – model User SAL

1 licencja = autoryzacja dostępu jednego użytkownika do dowolnej liczby serwerów.

Wymagane są wyłącznie licencje dostępowe dla użytkowników autoryzowanych do dostępu (pośredniego i bezpośredniego) do oprogramowania, niezależnie od faktycznego wykorzystania

Model User SAL nie przewiduje żadnych licencji serwerowych.

Wyjaśnienie (przykład):

• Dostęp bezpośredni – wszyscy autoryzowani użytkownicy i administratorzy z możliwością wykonania operacji na bazie SQL Server w tym modelu wymagają stosownej licencji SAL
• Dostęp pośredni – wszyscy autoryzowani użytkownicy z możliwością korzystania z aplikacji trzeciej, która wykorzystuje SQL Server jako bazę danych wymagają indywidualnej licencji dostępowej.

Przykład: księgowi autoryzowani do dostępu do aplikacji do tworzenia faktur, która korzysta z bazy SQL Server rozliczanej w modelu SAL, także wymagają licencji.

Komponenty SQL Server i zależności edycyjne

Zakres funkcjonalny edycji:

• Enterprise oraz Developer, Developer Enterprise (od wersji 2025) – pełny zakres funkcji, w tym m.in. Master Data Services, Machine Learning Services, Data Quality Services oraz wszystkie funkcje dostępne w edycjach niższych.
• Standard, Developer Standard (od wersji 2025) – m.in. Analysis Services, Integration Services, Azure Connected Services oraz funkcjonalności edycji niższych.
• Web oraz Express – wyłącznie Database Engine, Reporting Services (do edycji 2022) oraz Power BI Report Server (dla wszystkich edycji poza Express od wersji 2025).

Instalacja komponentu niedostępnego w danej edycji powoduje obowiązek zastosowania licencji o wyższej edycji.

Przykład: instalacja Integration Services do instancji w edycji Express wymusza licencjonowanie SQL Server Standard etc.

SQL Server Web

Dozwolone wyłącznie dla wsparcia publicznie dostępnych serwisów i aplikacji webowych.

Oprogramowanie nie może być wykorzystywane do wsparcia systemów wewnętrznych np. ERP, CRM itp. i innych rozwiązań operacyjnych podmiotu (np. baza danych SQL Server Web wspierająca rozwiązania SaaS itp.).

SQL Server Developer

Wykorzystanie dozwolone wyłącznie w środowiskach nieprodukcyjnych.

Przeznaczony do projektowania, testowania, demonstrowania działania oprogramowania klienta i testów UAT.

Prawa na wypadek awarii (fail-over) – wyłącznie dla modelu na rdzeń

Pozwala na tymczasowe uruchomienie zapasowych serwerów​

1 OSE do użycia na dowolnym serwerze w dowolnym celu (np. High Availability) + 1 OSE w celach DR

Serwery zapasowe nie mogą udostępniać użytkownikom ani urządzeni danych z bazy.

Serwery zapasowe nie mogą mieć więcej rdzeni niż produkcyjne.

Typowe przypadki niezgodności

• Pominięcie dostępu pośredniego do instancji przy licencjonowaniu w modelu User SAL,
• Instalacja usług z edycji Standard lub Enterprise w instancjach Express lub Web,
• Wykorzystywanie SQL Server Web do niepublicznych rozwiązań SaaS,
• Błędne założenie, że ograniczenie liczby rdzeni przypisanych do instancji zmniejsza wymóg licencyjny,
• Powszechny dostęp użytkowników do instancji SQL Server Standard licencjonowanej w modelu SAL,
• Używanie edycji Developer w środowisku produkcyjnym.

3.4 Licencjonowanie Office (User SAL)

1 licencja = autoryzacja jednego użytkownika do dostępu do dowolnej liczby serwerów. Wymagane są wyłącznie licencje dostępowe dla użytkowników uzyskujących dostęp (pośredni i bezpośredni) do oprogramowania. Model User SAL nie przewiduje żadnych licencji serwerowych. Pojedyncze komponenty (np. Word, Excel itp.) dostępne jako osobne SAL.

W przypadku udostępniania oprogramowania przez RDS wszyscy użytkownicy muszą posiadać przypisaną wymaga Windows Server RDS SAL. Brak prawa do obniżenia edycji (np. licencja dostępowa do Office Professional Plus nie pokrywa wymogu na dostęp do instalacji Office Standard).

3.5 Licencjonowanie Exchange Server (User SAL)

1 licencja = autoryzacja jednego użytkownika do dostępu do dowolnej liczby serwerów.

Wymagane są wyłącznie licencje dostępowe dla użytkowników uzyskujących dostęp (pośredni i bezpośredni) do oprogramowania.

Model User SAL nie przewiduje żadnych licencji serwerowych.

Użytkownicy zewnętrzni licencjonowani na takich samych zasadach jak wewnętrzni.

Poziomy licencji dostępowych SAL

• Basic – podstawowy dostęp.
• Standard – dostęp do funkcjonalności tj.: MAPI, współdzielenie, OWA, synchronizacja mobilna, obsługa wielu domen dla użytkownika itd.
• Enterprise – dostęp do funkcjonalności tj.: archiwum zbiorcze i miejscowe, rozszerzona ochrona informacji, odszyfrowanie dziennika i przeszukiwanie wielu skrzynek.

Szczegółowy podział funkcjonalności w oparciu o edycje:
Licencjonowanie programu Microsoft Exchange Server w SPUR