Jak nie wpaść w pułapkę nieświadomego naruszenia licencji Oracle?

Licencjonowanie Oracle uchodzi za jedno z najbardziej złożonych na rynku. W dużych firmach – szczególnie tych z rozbudowaną infrastrukturą, środowiskami wirtualnymi i projektami migracyjnymi – nietrudno przekroczyć warunki umowy, nawet nie zdając sobie z tego sprawy. Nie chodzi o celowe nadużycia.

Najczęściej problem wynika z niepełnej wiedzy, niejasności w zapisach licencyjnych albo z braku odpowiedniej dokumentacji po stronie IT.

Co grozi za nieświadome naruszenia?

Konsekwencje bywają kosztowne. Firmy, które przekroczą zakres licencji, często muszą dokupić brakujące uprawnienia w trybie compliance, zwykle po pełnych stawkach katalogowych i z ograniczonymi możliwościami negocjacji. Niekiedy Oracle inicjuje przegląd środowiska (tzw. review), który w praktyce bywa bardzo zbliżony do formalnego audytu. Poza bezpośrednim wpływem na budżet IT pojawiają się też inne skutki: stres po stronie działu IT, osłabienie relacji między zespołami i – niekiedy – poważny cios w reputację działu odpowiedzialnego za zgodność licencyjną.

W mojej praktyce spotykam firmy, które były przekonane, że wszystko mają pod kontrolą. Do czasu.

Licencje Oracle: najczęstsze pułapki

1. Nieświadome uruchomienie płatnych opcji

Niektóre funkcje – np. Diagnostic czy Tuning Pack – mogą być wymagane nawet, jeśli zabronimy ich wykorzystania na konsoli administratora – wystarczy dostęp do niewłaściwego widoku.

2. Automatyczne uruchomienie płatnych opcji

Są płatne opcje – np. Advanced Compression czy Advanced Security – które mogą automatycznie wymagać licencji, nawet jeśli administrator na to nie zezwolił, a nieświadomy użytkownik je uruchomił przez przypadek.

3. Brak spójnej dokumentacji

Firmy często nie mają kompletnej dokumentacji zakupionych licencji, ich przypisania do środowisk ani wewnętrznych zasad zarządzania. Przy zmianach kadrowych lub projektowych jest to gotowy przepis na ryzyko.

4. Wirtualizacja bez pełnej zgodności

Oracle oficjalnie nie wspiera rozliczeń sub-capacity w wielu popularnych środowiskach. W praktyce oznacza to, że jeśli baza działa na jednym nodzie klastra, a cały klaster liczy 10 serwerów fizycznych, to licencje mogą być wymagane dla każdego z nich.

Co robić, żeby nie wpaść w tę pułapkę?

Przegląd środowisk

Przynajmniej raz w roku warto wykonać wewnętrzny przegląd techniczny: policzyć instancje, sprawdzić aktywne opcje oraz przeanalizować środowiska testowe i developerskie. Jeden dobrze przygotowany raport może pozwolić zaoszczędzić setki tysięcy złotych.

Zarządzanie licencjami jak aktywem

Najbezpieczniejsze organizacje traktują licencje strategicznie: przypisują właścicieli i osoby odpowiedzialne za zarządzanie licencjami, dokumentują decyzje i wdrażają jasne zasady przy zmianach środowisk.

Edukacja i czujność

Zespoły IT i zakupowe powinny znać podstawowe zasady licencjonowania Oracle – szczególnie przy projektach migracyjnych i wdrożeniach nowych środowisk. Czasem wystarczy kilka godzin szkolenia rocznie, by uniknąć poważnych błędów.

Na co zwrócić szczególną uwagę?

Przy zmianach infrastruktury (np. migracja do chmury) – warunki licencyjne mogą się zmienić. Sprawdzenie ich z wyprzedzeniem to podstawa.

„To tylko środowisko testowe” – często to nie wystarczy. Wiele licencji Oracle ma konkretne wymagania dla środowisk dev/test.

Aktualizacja oprogramowania – może uruchomić nowe funkcje, które generują obowiązek licencyjny. Bardzo często zdarza się w środowiskach test/dev.

Dlaczego warto działać wcześniej?

Wczesne przygotowanie tzw. pozycji licencyjnej (Effective License Position) i współpraca z niezależnym doradcą to nie tylko zabezpieczenie przed ryzykiem. To także szansa na uporządkowanie środowiska, kontrolę kosztów i usprawnienie współpracy między IT, finansami i zarządem.

W świecie Oracle nie warto czekać na pismo z zapowiedzią audytu. Lepiej samemu wiedzieć, na czym stoimy – zanim zrobi to ktoś inny.

Autor: Andrzej Orłowski, Senior SAM Manager in4mates