Zardządzanie oprogramowaniem SAM Software Asset Management

Artykuł

Software Asset Management: Zmiany w licencjonowaniu kolejnych wersji oprogramowania

Styczeń 2019

Duża liczba produktów, skomplikowane zasady licencjonowania oraz mnogość miar licencyjnych są jednymi z głównych przyczyn niezgodności odnotowywanych podczas przeglądów licencji oprogramowania.

Teza ta nasuwa się po przeanalizowaniu wyników ankiety przeprowadzonej podczas warsztatów Akademia SAM (Software Asset Management) organizowanych cyklicznie przez zespół Software Asset Management w Deloitte. W październikowych warsztatach wzięli udział przedstawiciele 27 największych organizacji działających w różnych sektorach polskiego rynku, m. in. finansowym, energetycznym, telekomunikacyjnym i publicznym.

Każdy z producentów oprogramowania określa własne zasady licencjonowania i odnosi je do dostępnych na rynku technologii. W związku z tym, np. w przypadku wirtualizacji, możemy spotkać się z sytuacją, gdzie ta sama konfiguracja środowiska wirtualnego będzie przeliczana w inny sposób przez każdego z producentów. Dlatego tak ważne jest zapoznanie się z warunkami licencyjnymi . To ograniczy ryzyko niezgodności. Co więcej, ten sam produkt może być licencjonowany na więcej niż jeden sposób, np. per autoryzowany użytkownik lub per rdzeń, procesor czy procesorowa jednostka wartości. Dodatkowym utrudnieniem są zmiany w modelach licencjonowania, które następują na przestrzeni lat. Niektóre miary licencyjne ewoluują w nowsze (np. procesor w rdzeń lub procesorową jednostkę wartości), powstają nowe pakiety zawierające kilka produktów z różnymi miarami licencyjnymi (vide IBM FlexPoints) lub produkt przestaje być sprzedawany w dotychczasowej mierze licencyjnej i jeżeli chcemy dalej go wspierać, konieczne jest zastosowanie odpowiednich przeliczników.

By zapewnić zgodność z warunkami umów, pracownicy odpowiedzialni za zarządzanie licencjami powinni – oprócz kontroli zainstalowanego oprogramowania – wziąć pod uwagę model licencjonowania, w jakim zostało ono zakupione oraz przestrzegać ograniczeń (np. sprzętowych) wynikających z licencji.

Zmiany w licencjonowaniu kolejnych wersji

Wyzwań licencyjnych jest oczywiście więcej. Zmiany w licencjonowaniu kolejnych wersji tego samego produktu potrafią – przy braku odpowiedniej kontroli – doprowadzić do pojawienia się istotnych niezgodności licencyjnych. Poniżej przytoczymy przykłady zmian w licencjonowaniu różnych producentów, które mogą wystąpić po aktualizacji oprogramowania do nowszej wersji, wpływając na bilans licencji:

 

1. Wprowadzenie nowej edycji programu oraz włączenie rozszerzeń w pakiet licencyjny

Wprowadzenie przez IBM nowej edycji oprogramowania MQ spowodowało, iż odrębne wcześniej komponenty służące do ochrony danych wrażliwych (MQ Advanced Message Security), połączenia wszystkich urządzeń do Internetu (MQ Telemetry Service) oraz transferu plików pomiędzy systemami (MQ Managed File Transfer Service) zostały udostępnione w programie MQ Advanced. Brak znajomości warunków licencyjnych nowej wersji oprogramowania może prowadzić do sytuacji, w której zainstalowane zostaną komponenty dostępne wyłącznie w ramach nowej, droższej edycji.

 

2. Wykluczenie niektórych komponentów oprogramowania przy określaniu liczby wymaganych licencji

W najnowszej dokumentacji licencyjnej programu IBM Planning Analytics Local TM1 Server pojawił się zapis, iż przy ustalaniu liczby uprawnień wymaganych do instalowania lub używania programu przez licencjobiorcę, bierze się pod uwagę wyłącznie instalowanie lub używanie komponentu TM1 Server. Dodatkowo, nie zostały nałożone ograniczenia dotyczących konfiguracji serwerów, na których produkty wspierające (np. Planning Analytics Workspace Cognos Analytics Administrator) mogą być zainstalowane (dotyczy to także limitu PVU). W dokumentach licencyjnych dla starszych wersji powyższe zapisy nie występowały, w związku z czym istniała konieczność uwzględniania wszystkich komponentów oprogramowania przy określaniu liczby wymaganych licencji. W określonych sytuacjach (np. przy instalacji poszczególnych komponentów oprogramowania na różnych serwerach) wprowadzony zapis może zmniejszać liczbę wymaganych licencji.

 

3. Zmiana podejścia dotycząca serwerów działających w trybie gotowości bezczynnej

Na przykładzie ewolucji oprogramowania IBM Informix Enterprise Edition widzimy, iż wraz z wprowadzaniem nowszych wersji oprogramowania zmieniała się nie tylko nazwa produktu. Dokonano zmian również w ograniczeniach licencyjnych dotyczących w szczególności serwerów pracujących w trybie gotowości bezczynnej. We wcześniejszych wersjach, w przypadku licencjonowania produktu per procesor dla serwerów pracujących w trybie gotowości bezczynnej także należało wykupić licencje per procesor. W kolejnych wersjach wymagano posiadania licencji dla 100 PVU per serwer, niezależnie od jego konfiguracji procesorowej. Natomiast w najnowszych wersjach nie są wymagane dodatkowe licencje dla serwerów w trybie gotowości bezczynnej.

 

4. Zastąpienie dwóch starszych edycji jedną nowszą.

Kolejny przykład zmian dotyczy baz danych Oracle. Wprowadzenie przez Oracle licencji Standard Edition 2, spowodowało zastąpienie dwóch starszych edycji, Oracle Standard Edition oraz Oracle Standard Edition 1, jedną nowszą. Najbardziej zauważalną różnicą jest zmiana dotycząca możliwości instalacji baz danych na maszynach z maksymalnie dwoma gniazdami procesorowymi. Dodatkowo, zmieniła się minimalna liczba wymaganych licencji NUP (Named Per User) - wymaganie wzrosło z 5 NUP do 10 NUP per serwer. W tym przypadku aktualizacja wersji w określonych sytuacjach może wiązać się z wyższymi kosztami licencji.

 

5. Zmiana modelu licencjonowania

Zmianie uległy zasady licencyjne Windows Server 2016 dla edycji Standard oraz Datacenter. Nowy model licencjonowania opiera się na fizycznych rdzeniach procesora, w przeciwieństwie do poprzedniego modelu licencjonowania, który bazował na procesorach. Licencje są sprzedawane w postaci paczki dwóch licencji po osiem rdzeni każda. W związku z tym, w przypadku posiadania procesorów do 8 rdzeni koszty licencji są takie same jak w edycji 2012 R2. Natomiast w przypadku procesorów posiadających więcej niż 8 rdzeni, wymagane są dodatkowe paczki licencyjne, w związku z czym koszty przeznaczone na licencje wzrastają.

 

6. Wprowadzenie uproszczonej miary licencyjnej

Micro Focus w przypadku oprogramowania ArcSight Enterprise Security Manager wprowadził dedykowaną miarę licencyjną – Events per Second (EPS). W poprzednich edycjach produkt mógł być licencjonowany per fizyczny rdzeń procesorowy, użytkownik, GB na dzień lub urządzenie. Ostatnio Micro Focus diametralnie zmienił podejście i uzależnił koszt licencji od średniego wykorzystania, co może istotnie wpłynąć na koszty licencji.  

Powyżej zaprezentowaliśmy jedynie kilka scenariuszy licencjonowania różnych wersji tego samego produktu. Jak widzimy, analiza dokumentów licencyjnych dla oprogramowania oraz śledzenie zmian w nich następujących są kluczowe, by uniknąć niezgodności licencyjnych. Warto je śledzić, by uniknąć zakupu produktów niedostosowanych do potrzeb organizacji. Często zdarza się, że ze względu na mnogość modeli licencjonowania oraz obecność na rynku różnych wersji oprogramowania kupowane są licencje, które później nie są wykorzystywane.

Wyzwań związanych z licencjonowaniem jest wiele, istnieją jednak rozwiązania, które odpowiednio dostosowane do przedsiębiorstwa wspomogą kontrolę oprogramowania. Obecnie na rynku możemy znaleźć narzędzia SAM (Software Asset Management), które ułatwiają zarządzanie licencjami oprogramowania poprzez jego inwentaryzację, utrzymanie spisu umów licencyjnych, tworzenie raportów i obliczanie wymagań licencyjnych. Innym rozwiązaniem jest outsourcing usług SAM (Software Asset Management) lub przeprowadzanie okresowych przeglądów zgodności licencyjnej wewnątrz organizacji. Możliwości jest wiele, dlatego tak ważne jest proaktywne podejście do zarządzania oprogramowaniem. Ciągła zgodność licencyjna oraz optymalizacja kosztów to dodatkowe atuty przemawiające za tego typu rozwiązaniami dla firm.

Czy ta strona była pomocna?