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 bardzo 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 negatywnym 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 – mogą automatycznie być wymagane nawet, jeśli administrator na to nie zezwolił na konsoli, ale nieświadomy użytkownik to uruchomił, nawet 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 – 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, przeanalizować środowiska testowe i developerskie. Czasem jeden dobrze przygotowany raport pozwala zaoszczędzić setki tysięcy złotych.

Zarządzanie licencjami jak aktywem

Najbezpieczniejsze organizacje to te, które traktują licencje strategicznie: przypisują właścicieli i osoby odpowiedzialne za zarządzanie licencjami, dokumentują decyzje, 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 czy wdrożeniach nowych środowisk. Czasem wystarczy kilka godzin szkolenia rocznie, by uniknąć naprawdę 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 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 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

.

.

.