Ryzyko prawne w IT: najczęstsze błędy w licencjonowaniu oprogramowania w firmach

Jak wygląda typowy „scenariusz kontroli” w polskiej firmie

Punkt zapalny: skąd bierze się kontrola legalności oprogramowania

Najpierw pojawia się sygnał. Telefon z policji lub prokuratury z informacją o zabezpieczeniu sprzętu w ramach postępowania. Pismo od producenta z żądaniem audytu licencyjnego. Mail z centrali międzynarodowego dostawcy, że na podstawie telemetrii system wykrył podejrzanie wysoką liczbę instalacji. Czasem początek jest dużo prostszy – były pracownik, który odchodzi w konflikcie i informuje, że „w firmie korzysta się z nielegalnego softu”.

W polskich realiach impulsem do kontroli legalności oprogramowania są najczęściej:

• donos pracownika lub byłego pracownika (również anonimowy),
• spór z dostawcą IT, który w ramach „rewanżu” zgłasza nieprawidłowości producentowi,
• audyt producenta lub organizacji branżowej (np. po stronie oprogramowania biurowego, CAD, graficznego),
• wewnętrzny przegląd zlecony przez nowy zarząd lub audytora finansowego, który zauważa rozjazd między sprzętem a licencjami.

Jak przebiega pierwsza faza weryfikacji

Po stronie firmy zwykle dzieje się podobny schemat. Zarząd lub właściciel przekazuje temat działowi IT lub office managerowi. Pada klasyczne pytanie: „Czy mamy wszystko legalne?”. Wtedy okazuje się, że nikt nie ma pełnego obrazu. Część faktur jest w księgowości, część u poprzedniego dostawcy IT, część licencji jest „na maile” bez jasnej dokumentacji.

Organ przeprowadzający kontrolę lub producent oprogramowania najczęściej żądają:

• listy zainstalowanego oprogramowania na wszystkich stacjach roboczych i serwerach,
• kopii faktur, umów i potwierdzeń zakupu licencji,
• informacji o modelu użytkowania (kto korzysta, z jakich urządzeń, z jakiego kraju, czy istnieje dostęp zdalny),
• dostępu do wybranych komputerów i serwerów, aby potwierdzić faktyczną liczbę instalacji.

Już na tym etapie wiele firm „wykłada się” na elementarnych kwestiach: brakuje części faktur, nie ma spójnej ewidencji, a z prostego porównania wynika, że licencji jest mniej niż faktycznych instalacji. Albo przeciwnie – zaskakująco dużo oprogramowania pochodzi z „taniego źródła”, którego nikt dziś nie potrafi zidentyfikować.

Typowe potknięcia wychodzące przy pierwszym przeglądzie

Najczęściej wykrywane problemy przy pierwszym, jeszcze wewnętrznym sprawdzeniu to:

• brak kompletnej dokumentacji – są instalacje, brak dowodów ich legalności,
• klucze z nieautoryzowanych źródeł (aukcje, portale z „tanimi licencjami”),
• rozjazd między liczbą licencji a liczbą użytkowników (szczególnie przy modelu per user),
• niejasne użycie w chmurze / zdalnie – np. pracownicy zdalni korzystają z licencji przypisanych do biurowych komputerów,
• komponenty open source w produkcie komercyjnym bez analizy ich licencji.

W efekcie kontrola legalności oprogramowania szybko przestaje być „technicznym detalem” i staje się kwestią ryzyka prawnego i biznesowego. Firma nagle musi odpowiedzieć: co dokładnie jest legalne, czego brakuje i jaki będzie koszt naprawy sytuacji.

Skutki dla biznesu: nie tylko grzywny

Ryzyko prawne w IT to nie tylko możliwe kary finansowe. Skutki źle ułożonego licencjonowania oprogramowania w firmach to także:

• nagłe, nieplanowane wydatki – konieczność dokupienia brakujących licencji w krótkim czasie, często w wyższych cenach,
• przestoje – blokada części systemów lub kont przez dostawcę do czasu wyjaśnienia sytuacji,
• ryzyko reputacyjne – informacja o nielegalnym oprogramowaniu w firmie dostaje się do obiegu,
• odpowiedzialność osób decyzyjnych – członkowie zarządu, właściciel lub manager IT mogą zostać wciągnięci w postępowanie.

Im większa firma, tym wyższe potencjalne koszty – zarówno bezpośrednie (kary, odszkodowania, nadpłaty), jak i pośrednie (czas kadry, prawnicy, negocjacje z dostawcami, wdrażanie nowych procedur pod presją).

Błąd 1 – „Tanie klucze” i licencje z niepewnych źródeł

Jak powstaje ten błąd w praktyce

Scenariusz jest powtarzalny. Firma potrzebuje kilkunastu licencji biurowych lub systemów operacyjnych. Oficjalne oferty z kanału partnerskiego wydają się drogie. Ktoś z działu IT lub administracji wpisuje w wyszukiwarkę nazwę programu i dopisek „tani klucz”. Znajduje aukcję z licencjami kilkukrotnie tańszymi. Na zdjęciu pudełko wygląda „jak prawdziwe”, opis zawiera słowa „oryginalny”, „legalny”, „do użytku komercyjnego”. Decyzja zapada szybko – „oszczędzimy kilka tysięcy złotych”.

Często takie zakupy są robione:

• na prywatne konta pracowników lub z pominięciem standardowej ścieżki zakupowej,
• bez porządnej faktury – jedynie potwierdzenie przelewu lub e-mail,
• przez szare firmy pośredniczące, które nie są na liście partnerów producenta.

Na pierwszy rzut oka wszystko działa. Program się aktywuje, system zgłasza, że licencja jest „oryginalna”. Prawdziwy problem pojawia się dopiero przy kontroli albo kiedy producent zaczyna weryfikować nietypowe wzorce aktywacji tych samych kluczy w wielu krajach.

Jak rozpoznać podejrzaną ofertę licencji

Kilka prostych sygnałów ostrzegawczych pomaga odfiltrować oferty, które generują wysokie ryzyko prawne w IT:

• Brak faktury VAT na firmę – sprzedawca proponuje jedynie paragon, rachunek bez NIP lub fakturę na osobę fizyczną.
• Brak jasnej informacji o rodzaju licencji – nie wiadomo, czy to OEM, BOX, licencja zbiorcza, subskrypcja, licencja używana, nie ma też wskazanego kraju przeznaczenia.
• Dziwny proces aktywacji – sprzedawca wymaga zdalnego połączenia i „aktywuje” oprogramowanie samodzielnie, korzystając z własnych danych, lub prosi o przekazanie loginu do konta producenta.
• Cena rażąco niższa niż u autoryzowanych partnerów – np. 5–10 razy taniej niż standardowy kanał sprzedaży.
• Brak danych sprzedawcy – brak pełnej nazwy firmy, adresu, numeru NIP, regulaminu sprzedaży.

Jeżeli oferta nie zawiera jasnych informacji, jaką licencję kupujesz i na jakich warunkach możesz z niej korzystać komercyjnie, to sygnał, że w razie kontroli trudno będzie obronić legalność takiego oprogramowania.

Ryzyka i skutki przy kontroli legalności oprogramowania

Najpoważniejszy problem polega na tym, że nawet jeśli produkt technicznie działa i przechodzi aktywację, licencja może być nieważna w kontekście prawa autorskiego lub warunków producenta. W praktyce kontrola może ustalić, że:

• sprzedawca odsprzedał klucze z licencji edukacyjnych, które nie mogą być używane komercyjnie,
• licencje pochodzą z nielegalnego źródła (np. z kradzionych kont, z programu MSDN lub z programów testowych),
• klucz jest wielokrotnie użyty na świecie i producent go unieważnił.

Skutki dla firmy:

• uznanie wszystkich takich instalacji za nielegalne,
• konieczność ponownego zakupu wszystkich licencji w krótkim czasie – już w pełnych cenach,
• możliwość roszczeń odszkodowawczych producenta,
• ryzyko postępowania karnego wobec osób, które świadomie zdecydowały o zakupie takiego „oprogramowania”.

Warto też pamiętać, że linia obrony „nie wiedziałem, że to nielegalne” słabo działa, gdy zarząd lub menedżer IT świadomie akceptuje zakupy oprogramowania po 10–20% rynkowej ceny, bez żadnej dokumentacji.

Jak kupować licencje bezpiecznie – minimalne wymagania

Bezpieczny zakup licencji na oprogramowanie w firmie opiera się na kilku prostych zasadach. Nie eliminują one ryzyka całkowicie, ale bardzo je ograniczają:

• Pełna faktura na firmę – z NIP nabywcy i sprzedawcy, dokładną nazwą produktu, rodzajem licencji, liczbą sztuk i informacją, że jest to licencja do użytku komercyjnego.
• Sprawdzony kanał sprzedaży – autoryzowany partner z listy na stronie producenta, dystrybutor lub bezpośredni kanał producenta.
• Jasny opis rodzaju licencji – OEM, BOX, licencja zbiorcza, subskrypcja; informacja, czy dopuszcza odsprzedaż (w przypadku licencji używanych), czy jest przypisana na stałe do urządzenia.
• Umowa lub regulamin – przy większych zakupach warto mieć umowę handlową lub co najmniej zaakceptowany regulamin sprzedaży z opisem warunków licencyjnych.

Przy licencjach używanych pojawia się dodatkowe ryzyko. Aby realnie ograniczyć problem:

• żądaj pełnego łańcucha dowodów – od pierwszego nabywcy do Ciebie,
• upewnij się, że licencja dopuszcza odsprzedaż w Twoim regionie i została trwale odinstalowana u poprzedniego użytkownika,
• w przypadku wątpliwości skonsultuj transakcję z prawnikiem lub bezpośrednio z producentem.

Każda oszczędność na „podejrzanie tanich” licencjach powinna być porównana z potencjalnym kosztem obowiązkowego zakupu nowych licencji, kosztami prawnymi oraz przerwami w pracy na wypadek blokady lub audytu.

Błąd 2 – Zbyt mała liczba licencji względem faktycznego użycia

Dlaczego firmy regularnie „niedoliczają” licencji

Drugim klasycznym błędem jest niedoszacowanie potrzeb. Firma startuje z poprawnym zestawem licencji, ale rozwija się szybciej niż system licencyjny. Dochodzą nowe osoby, nowe stanowiska, kolejne laptopy. Ktoś instaluje oprogramowanie na „chwilę”, ktoś inny na komputerze w magazynie, żeby szybciej załatwić sprawę. Licencji nikt już nie dokupuje, bo „przecież kiedyś kupiliśmy ich sporo”.

Źródła problemu są zwykle podobne:

• brak bieżącej inwentaryzacji – nikt systematycznie nie sprawdza, ile mamy faktycznie zainstalowanego oprogramowania,
• brak procedury przy offboardingu – odchodzący pracownik zabiera laptop, ale jego licencja w systemie nie jest uwolniona i przypisana innemu,
• mylenie modeli licencji – ktoś sądzi, że jedna licencja per urządzenie wystarczy na kilku użytkowników, albo odwrotnie.

W efekcie przy audycie lub wewnętrznym przeglądzie okazuje się, że np. 80 osób korzysta z pakietu biurowego, a faktur jest na 50 licencji. Brakujące 30 to potencjalny koszt natychmiastowego zakupu plus ewentualne roszczenia.

Prosta procedura policzenia zapotrzebowania na licencje

Aby realnie ocenić, czy firma ma odpowiednią liczbę licencji, warto przejść przez kilka kroków:

1. Lista użytkowników
   Zestaw wszystkich osób, które mogą korzystać z oprogramowania: etatowych, B2B, zleceniobiorców, praktykantów, pracowników tymczasowych, osób w pracy zdalnej. Dla każdego: imię, nazwisko, dział, rodzaj współpracy.
2. Lista urządzeń
   Spis komputerów stacjonarnych, laptopów, terminali, serwerów, stanowisk VDI. Dla każdego: nazwa, lokalizacja, właściciel (firma czy leasing), przypisany użytkownik (jeśli stały).
3. Mapa oprogramowania krytycznego
   Określ, które programy wymagają ścisłego licencjonowania (systemy operacyjne, pakiety biurowe, oprogramowanie graficzne, CAD, narzędzia developerskie, specjalistyczne aplikacje branżowe).
4. Przypisanie modelu licencjonowania
   Dla każdego programu ustal, czy licencja jest: per user, per device, per core, per instancja, per serwer. Tę informację znajdziesz w warunkach licencyjnych producenta lub w umowie.
5. Porównanie faktur z rzeczywistym użyciem
   Dla każdego kluczowego programu zestaw liczbę aktywnych użytkowników/urządzeń z posiadanymi licencjami według faktur, umów i portali licencyjnych producentów. Różnica „na minus” to obszar ryzyka, różnica „na plus” – potencjalna przestrzeń do optymalizacji.

Takie ćwiczenie nie musi od razu być pełnym audytem SAM. W małej lub średniej firmie wystarczy prosty arkusz z kilkoma zakładkami: użytkownicy, sprzęt, programy, licencje. Ważne, żeby ktoś faktycznie porównał liczby, a nie zakładał „na oko”, że wszystko się zgadza.

Dobrze działa też jasna odpowiedzialność. W większej organizacji tematem zwykle zajmuje się IT lub bezpieczeństwo, ale biznes (właściciele systemów, kierownicy działów) powinien współdecydować, komu rzeczywiście potrzebne są droższe narzędzia. W przeciwnym razie pojawia się chaos: część osób ma za dużo, część za mało, a licencji i tak brakuje.

Ostatni element to bieżąca aktualizacja danych. Każdy onboarding i offboarding powinien uruchamiać krótką checklistę: przydzielone systemy, konta, licencje, a później ich odebranie i realokacja. Taki prosty proces ogranicza z jednej strony „leżące” niewykorzystane subskrypcje, a z drugiej – ciche doinstalowywanie oprogramowania poza wiedzą IT.

Najczęstszy błąd na końcu całej układanki to traktowanie licencji jak sprawy „na potem”. Tymczasem kontrola, konflikt z producentem albo przymusowy zakup pakietu licencji „od ręki” potrafią uderzyć w płynność finansową bardziej niż zakup poprawnego zestawu od razu – i to zwykle bez żadnej dodatkowej wartości dla biznesu.

Jak szybko wyłapać braki licencji przed kontrolą

Zanim pojawi się audyt, można wykonać prosty „przegląd techniczny” licencji. Chodzi o szybkie wyłapanie czerwonych flag, bez wielomiesięcznego projektu wdrożeniowego.

• Sprawdź 3 kluczowe grupy oprogramowania – systemy operacyjne, pakiety biurowe, specjalistyczne narzędzia (np. grafika, CAD, ERP). Jeżeli w którejkolwiek grupie liczba użytkowników/urządzeń nie zgadza się z fakturami, problem zwykle powtarza się też w innych.
• Zrób próbkę zamiast pełnego audytu – wybierz 1–2 działy (np. sprzedaż i księgowość), porównaj rzeczywiste instalacje z posiadanymi licencjami. Jeśli od razu wychodzą duże rozjazdy, pełny przegląd jest pilny.
• Poproś działy o autodeklarację – prosty formularz: z jakich programów korzystasz codziennie / okazjonalnie / w ogóle nie? Niejednokrotnie wychodzi, że połowa drogich licencji jest „na wszelki wypadek”.
• Porównaj z listą kont w chmurze – w panelach Microsoft 365, Google Workspace, Adobe, Atlassian widać dokładnie, ilu użytkowników jest aktywnych. Jeżeli tu jest 70 kont, a faktura mówi o 50 subskrypcjach – scenariusz kontroli jest oczywisty.

Taki szybki screening zazwyczaj w ciągu kilku dni pokazuje, czy problem jest jednostkowy, czy systemowy. To też dobry moment, żeby w razie czego samodzielnie dokupić brakujące licencje, zanim zrobi to za firmę producent po audycie.

Błąd 3 – Dzielenie kont i subskrypcji (SaaS, chmura, narzędzia online)

Wspólne loginy – wygodne dziś, kosztowne jutro

Dzielenie kont logowania do usług w chmurze to jeden z najczęstszych grzechów przy licencjach subskrypcyjnych. Schemat bywa bardzo podobny: ktoś kupuje jedno konto „premium”, login i hasło krążą po kilku osobach, bo „przecież wszyscy nie korzystają naraz”. W regulaminach większości usług SaaS wyraźnie widnieje zakaz udostępniania kont innym osobom.

Ryzyka są tu podwójne:

• naruszenie warunków licencji – producent w razie wykrycia może zażądać dopłaty za brakujące konta, a przy poważnym naruszeniu wypowiedzieć usługę,
• ryzyko bezpieczeństwa – brak indywidualnych kont oznacza brak śladu, kto co zrobił (np. kto usunął dane, kto wysłał plik na zewnątrz).

W praktyce problem wychodzi na wierzch podczas analizy logów bezpieczeństwa, incydentu bezpieczeństwa albo wewnętrznego audytu. Wtedy zestawienie „1 konto – 10 aktywnych użytkowników z różnych adresów IP” wygląda słabo zarówno od strony licencyjnej, jak i compliance.

Typowe scenariusze nadużycia subskrypcji

Trudności zaczynają się szczególnie przy:

• narzędziach projektowych i kreatywnych (np. oprogramowanie graficzne, edytory wideo, narzędzia UX) – w małych zespołach często jedna osoba kupuje licencję, a pliki obrabia kilka osób na tym samym koncie,
• platformach typu „all-in-one” (CRM, marketing automation, helpdesk) – jedno konto „admin” służy całemu działowi, a poszczególni pracownicy jedynie „podpisują się” w komentarzach imieniem,
• dostępach do narzędzi dla klientów – agencja czy software house przekazuje dane logowania klientowi lub podwykonawcy, choć licencja obejmuje wyłącznie pracowników wykonawcy,
• logowaniu z prywatnych urządzeń w modelu BYOD – gdy jeden login używany jest na wielu urządzeniach, a licencja ma charakter „per device” lub wyraźne ograniczenia co do liczby instalacji.

Producenci coraz częściej stosują automatyczne mechanizmy wykrywania takich praktyk (analiza logowań, liczby sesji, lokalizacji, integracji). Najpierw zwykle przychodzi ostrzeżenie lub prośba o wyjaśnienie, ale przy dużej skali nieprawidłowości kończy się to propozycją uregulowania licencji wstecz.

Jak rozpoznać, czy konto może być współdzielone

Nie każda usługa SaaS zakazuje dzielenia dostępu, ale trzeba to wyczytać z warunków licencyjnych. Dobrym punktem startu są trzy pytania:

1. Czy w licencji mowa jest o „Named User / Assigned User”?
   Jeśli tak, konto jest przypisane do konkretnej osoby, a nie „do zespołu”.
2. Czy regulamin mówi o „no sharing / no concurrent use”?
   Zapis o zakazie udostępniania danych logowania i współdzielenia kont jest jednoznaczny – każdy realny użytkownik powinien mieć własne konto.
3. Czy producent przewiduje konto serwisowe lub techniczne?
   Jeżeli tak, zwykle określa też jego przeznaczenie (np. integracje, automatyzacja), a nie codzienną pracę użytkowników.

Jeśli po lekturze licencji nadal są wątpliwości, bezpieczniej założyć, że model jest per user i zaplanować budżet na dodatkowe konta zamiast kreatywnych obejść.

Lepszy model – mniej kont, ale dobrze zaplanowanych

Żeby nie przepłacać, a jednocześnie nie ryzykować dzielenia kont, można podejść do tematu „od ról”, a nie od nazwisk. Praktycznie wygląda to tak:

• Określ grupy ról – np. „pełny dostęp” (admini, liderzy), „użytkownik standardowy”, „tylko odczyt / raporty”.
• Przypisz rodzaje licencji do ról – jeśli dostawca ma tańsze licencje „view only”, nie ma sensu kupować pełnego pakietu każdemu.
• Ogranicz licencje do osób realnie korzystających – zamiast dawać konto „na wszelki wypadek” każdemu w dziale, ustal proste kryterium: kto używa narzędzia przynajmniej raz w tygodniu.
• Wprowadź rotację dostępów – jeżeli są projekty krótkoterminowe, można czasowo przekierowywać subskrypcje między użytkownikami, zgodnie z regulaminem producenta (często dozwolonym w określonym interwale).

Dobrze skonfigurowany panel administracyjny SaaS (np. w Microsoft 365 czy w systemie CRM) staje się wtedy nie tylko narzędziem bezpieczeństwa, ale i kontrolą kosztów – od razu widać, które konta są nieaktywne od miesięcy i można je wyłączyć.

Błąd 4 – Niewłaściwe licencjonowanie przy pracy zdalnej, BYOD i serwerach terminalowych

Licencja „na biurku” nie zawsze działa „z domu”

Przejście na pracę zdalną i hybrydową obnażyło wiele luk w licencjach. Wiele firm przegapiło, że licencja kupiona lata temu na komputer „w biurze” nie zawsze pozwala na zdalny dostęp z domu, na terminalu czy przez VDI.

Najczęstsze problemy pojawiają się przy:

• dostępie do aplikacji przez Remote Desktop / serwer terminalowy,
• korzystaniu z firmowego oprogramowania na prywatnych laptopach (BYOD),
• udostępnianiu aplikacji przez VDI lub rozwiązania typu „aplikacja zdalna”.

Spora część licencji klasycznych (wieczystych, OEM) zakłada instalację na konkretnym urządzeniu, a nie dowolny dostęp z wielu miejsc. Z kolei część licencji „per user” dopuszcza używanie programu na kilku urządzeniach jednocześnie, ale wyłącznie przez tę samą osobę.

Typowe ryzyka przy dostępie terminalowym i VDI

W środowiskach terminalowych (np. Windows Server + RDS) lub VDI ważne jest, czy producent licencjonuje aplikację:

• per serwer / instancję,
• per użytkownik zdalny,
• per urządzenie końcowe.

Błąd często wygląda tak: firma kupuje 20 licencji na aplikację „na serwer”, a z rozwiązania terminalowego korzysta 50 użytkowników. Dostęp technicznie działa, ale z punktu widzenia licencji 30 użytkowników pracuje na „pusto”. Podczas audytu dostawca porównuje logi z serwera z liczbą licencji i domaga się uzupełnienia braków wstecz.

Drugi scenariusz: licencje przypisane do urządzeń, a użytkownicy logują się z dowolnego komputera w biurze i z domu. W modelu „per device” taka rotacja urządzeń bez dodatkowych licencji może być niezgodna z umową – nawet jeżeli z każdej maszyny korzysta kilka osób naprzemiennie.

BYOD i praca z prywatnych laptopów – gdzie leży granica

Przy polityce BYOD kluczowe jest rozróżnienie, czy:

• instaluje się oprogramowanie firmowe fizycznie na prywatnym urządzeniu,
• użytkownik łączy się zdalnie do środowiska firmowego (VDI, aplikacja w przeglądarce, terminal), nie instalując nic lokalnie.

W pierwszym przypadku trzeba sprawdzić, czy licencja dopuszcza instalację na urządzeniu, którego firma formalnie nie posiada. W drugim – czy licencja obejmuje użytkowanie „z dowolnego miejsca / urządzenia”, a nie tylko z infrastruktury firmowej.

Dość częsta sytuacja: licencja na pakiet biurowy kupiona lata temu „na komputery w biurze” jest wykorzystywana przez pracowników z domu na prywatnych laptopach, na zasadzie „kopia instalatora + klucz z kartki”. W razie kontroli ten model użycia jest dużo trudniejszy do obrony, zwłaszcza jeśli urządzeń domowych nikt nie ewidencjonuje.

Jak zabezpieczyć model pracy zdalnej od strony licencji

Kilka kroków zazwyczaj wystarcza, żeby mocno ograniczyć ryzyko:

1. Rozdziel modele dostępu
   Dla każdego krytycznego systemu określ: czy dostęp zdalny ma być przez VPN + aplikację lokalną, czy przez VDI / aplikację webową. Od tego zależy dobór licencji.
2. Zweryfikuj umowy pod kątem „zamiejscowego użycia”
   Szukaj haseł: „remote access”, „home use”, „Roaming Use Rights”. Jeżeli umowa tego nie reguluje lub wyraźnie ogranicza – lepiej nie zakładać najkorzystniejszej interpretacji.
3. Przy BYOD ogranicz się do dostępu zdalnego
   Zamiast instalować programy lokalnie na prywatnych laptopach, lepiej udostępnić je z serwera lub jako aplikację webową. Łatwiej kontrolować licencje i bezpieczeństwo.
4. Udokumentuj zasady
   Regulamin pracy zdalnej i polityka BYOD powinny zawierać jasny zakaz samodzielnej instalacji oprogramowania firmowego na prywatnym sprzęcie bez zgody IT.

Główna pułapka to założenie, że „skoro użytkownik jest ten sam, to miejsce i sposób dostępu nie mają znaczenia”. Dla producenta zwykle mają – właśnie tam często ukryte są ograniczenia, które wychodzą przy audycie.

Błąd 5 – Nieświadome naruszenia licencji open source

Open source to nie „wszystko wolno”

Wiele zespołów IT korzysta z komponentów open source, bibliotek i gotowych fragmentów kodu. Samo użycie takich rozwiązań nie jest problemem – problemem jest brak świadomości, na jakich warunkach można je wykorzystywać komercyjnie.

Najczęstszy schemat: programista dodaje bibliotekę „bo działa” i jest popularna, ale nikt nie sprawdza, czy to licencja MIT/BSD (zwykle dość liberalna), czy np. GPL / AGPL, które nakładają znacznie poważniejsze obowiązki, szczególnie przy dystrybucji produktu lub udostępnianiu go jako usługi.

Scenariusze ryzyka przy licencjach open source

Problemy pojawiają się zazwyczaj w kilku momentach:

• przy sprzedaży produktu większemu klientowi – klient prosi o listę komponentów open source i ich licencji, a firma nie jest w stanie jej dostarczyć albo wychodzi, że w produkcie siedzi komponent na licencji niekompatybilnej z modelem sprzedaży,
• przy pozyskiwaniu inwestora – due diligence technologiczne ujawnia użycie bibliotek z licencjami „copyleft” tam, gdzie kod miał pozostać zamknięty,
• przy zgłoszeniu naruszenia przez społeczność lub fundację – projekt open source lub organizacja stojąca za nim wzywa firmę do dostosowania się do warunków licencji (np. udostępnienia kodu źródłowego części rozwiązania) albo do zaprzestania używania komponentu.

Jak uporządkować użycie open source w firmie

Pełne zarządzanie komponentami open source bywa dużym tematem, ale nawet mniejsze firmy mogą wdrożyć kilka podstawowych zasad:

1. Lista dozwolonych licencji
   Ustal wewnętrznie, które typy licencji są akceptowalne w produktach komercyjnych (np. MIT, BSD, Apache 2.0), a które wymagają dodatkowej zgody prawnika (np. GPL, AGPL, LGPL).
2. Centralny rejestr komponentów
   Każdy nowy komponent open source użyty w projekcie powinien trafić do wspólnej listy (np. w repozytorium kodu lub prostym arkuszu): nazwa, wersja, licencja, link do repo, projekt, w którym został użyty. Bez takiej prostej ewidencji później trudno odtworzyć „co siedzi w środku” systemu, który rozwijany jest kilka lat.
3. Procedura „check przed produkcją”
   Przed wdrożeniem nowej wersji systemu do klienta ktoś (np. tech lead lub wyznaczona osoba z zespołu) sprawdza listę komponentów i oznacza elementy wymagające analizy prawnej. Chodzi o krótki, ale powtarzalny krok w procesie release’u, a nie jednorazową „wielką inwentaryzację”.
4. Szablony zapisów w umowach
   W umowach z klientami i inwestorami przydają się gotowe klauzule, które opisują użycie open source: jakie licencje są stosowane, jakie obowiązki informacyjne firma realizuje, jaki jest zakres odpowiedzialności. To ułatwia rozmowy, gdy klient zgłasza swoje wymagania compliance.
5. Minimum szkoleń dla zespołu
   Krótka sesja dla programistów i devopsów, która tłumaczy różnice między licencjami „permissive” (MIT, BSD, Apache) i „copyleft” (GPL, AGPL, LGPL), zwykle wystarcza, żeby przestać traktować temat jako „magiczno-prawniczy”. Potem łatwiej wychwycić potencjalne konflikty jeszcze na etapie wyboru biblioteki.

W praktyce lepiej mieć prostą, działającą politykę open source, niż rozbudowany dokument, którego nikt nie czyta. Dobrze też założyć, że przy większych wdrożeniach lub produktach klienci i tak zapytają o skład komponentów, więc uporządkowana lista zależności po prostu oszczędza nerwów przy większych kontraktach.

Jeżeli w istniejącym systemie od lat nikt nie przeglądał bibliotek, sensownym krokiem bywa jednorazowy „skan” – ręczny albo przy pomocy narzędzi typu Software Composition Analysis. Wyniki zwykle odsłaniają kilka „niewygodnych” licencji, którymi można zająć się planowo, zanim temat wypłynie przy audycie zewnętrznym lub negocjacjach sprzedażowych.

Większość ryzyk prawnych w licencjonowaniu oprogramowania nie wynika ze złej woli, lecz z chaosu, braku dokumentacji i zbyt odważnych założeń („na pewno wolno”). Najczęściej wystarczy policzyć to, co rzeczywiście jest używane, spisać kilka prostych zasad i pilnować ich w codziennej pracy. Najgorszy scenariusz to odkładanie tematu „na później” – wtedy kontrola z zewnątrz jako pierwsza pokazuje realny obraz, zwykle w najmniej wygodnym momencie.

Błąd 6 – Brak przygotowania na audyt licencyjny dostawcy

Jak dostawcy faktycznie audytują klientów

Audyt licencyjny rzadko spada jak grom z jasnego nieba. Częściej poprzedza go:

• pismo od producenta lub jego przedstawiciela z powołaniem się na konkretny zapis umowy,
• prośba o wypełnienie formularza samooceny (SAM, ELP, „license review”),
• zapowiedź wizyty konsultantów lub zdalnego skanowania środowiska.

Dostawca zwykle dysponuje już pewnymi danymi: liczbą zakupionych licencji, wielkością firmy, profilem użycia chmury. Audyt nie jest więc „łowieniem w ciemno”, tylko próbą zweryfikowania, czy deklarowany obraz zgadza się z tym, co działa w sieci.

Typowe potknięcia podczas audytu

Ryzyko rośnie nie tylko przez faktyczne braki licencji, ale też przez chaos organizacyjny. W praktyce powtarzają się trzy sytuacje:

• Brak jednej osoby „frontowej” – na pismo od dostawcy odpowiada raz IT, raz księgowość, raz zarząd. Informacje są niespójne, co budzi dodatkowe pytania.
• Samodzielne „porządkowanie” środowiska po otrzymaniu pisma – usuwanie instalacji „na szybko”, bez dokumentacji, może zostać odebrane jako próba zacierania śladów.
• Bezrefleksyjne podpisanie protokołu audytowego – przedstawione wyliczenia nie są weryfikowane, a firma zgadza się na dopłatę za „niezgodności”, które w rzeczywistości są sporne.

Minimalny plan działania na wypadek audytu

Wewnętrzna „procedura awaryjna” mocno ogranicza panikę. Powinna obejmować przynajmniej:

1. Wyznaczenie właściciela tematu
   Jedna osoba (zwykle IT manager lub ktoś z działu prawnego) koordynuje odpowiedzi, zbiera dane, komunikuje się z dostawcą. Reszta organizacji odsyła wszelką korespondencję w jedno miejsce.
2. Wstępny przegląd z własnej strony
   Zanim firma prześle dane producentowi, powinna sama policzyć instalacje i licencje, choćby w uproszczonej formie. Chodzi o to, żeby wiedzieć, w jakim się jest położeniu, zanim liczby wrócą w oficjalnym raporcie.
3. Decyzja: kiedy włączać prawnika lub doradcę
   Przy dużych dostawcach (systemy operacyjne, pakiety biurowe, bazy danych) i wysokiej skali użycia bezpieczniej jest mieć po swojej stronie kogoś, kto zna typowe modele audytów. Małe nieścisłości łatwiej wyjaśnić samodzielnie, ale przy dużych kwotach lepiej nie eksperymentować.
4. Sprawdzenie zapisów umowy przed udostępnieniem danych
   W umowach często opisany jest tryb audytu: zakres danych, terminy, sposób dostępu do systemów. Udostępnianie logów i pełnych zrzutów środowiska „z uprzejmości” może wykraczać poza to, do czego firma jest zobowiązana.
5. Weryfikacja raportu audytowego
   Wyniki audytu to nie wyrok. Zdarzają się błędne założenia (np. co do modelu licencji) lub pomyłki w interpretacji konfiguracji. Trzeba sprawdzić, czy sposób liczenia zgodności odpowiada zapisom faktycznej umowy, a nie standardowym szablonom producenta.

Kontekst lokalny jest prosty: w polskich realiach audyt często bywa też narzędziem sprzedażowym. Producent wykrywa „niedolicencjonowanie” i od razu składa ofertę uzupełnienia z rabatem. Im lepiej firma zna własną sytuację i zapisy swoich umów, tym łatwiej negocjować warunki zamiast przyjmować pierwszą propozycję.

Błąd 7 – Rozmyta odpowiedzialność za licencje w organizacji

„IT kupuje, księgowość płaci, nikt nie pilnuje całości”

W wielu firmach proces wygląda tak: ktoś z biznesu zgłasza potrzebę, IT wybiera narzędzie, zamówienie przechodzi przez zakupy lub office managera, a księgowość księguje fakturę jako „oprogramowanie”. Legalność użycia i zgodność z licencją zostaje „pomiędzy” działami.

Ryzyko szczególnie rośnie, gdy:

• każdy dział kupuje swoje SaaS-y kartą firmową,
• freelancerzy czy software house’y „przywożą” własne narzędzia na projekt,
• nowi pracownicy dostają dostęp „po poprzedniku” bez weryfikacji licencji.

Prosty model ról i odpowiedzialności

Nie trzeba rozbudowanego systemu SAM, żeby uporządkować temat. Wystarczy jasno podzielić zadania:

• Zarząd / właściciel – zatwierdza ogólne zasady: skąd kupujemy oprogramowanie, kto może zawierać umowy z dostawcami, co robimy w razie kontroli.
• IT / dział techniczny – odpowiada za dobór typu licencji do sposobu użycia, utrzymuje listę systemów i użytkowników, blokuje instalacje spoza listy.
• Księgowość / finanse – nie księguje faktur za oprogramowanie bez informacji, do jakiego systemu i ilu użytkowników ma zostać przypisana licencja.
• Office manager / zakupy – pilnuje, żeby każdy zakup przechodził przez krótką „checklistę licencyjną” (źródło, typ licencji, okres, użytkownicy).

Dobrze działa prosta zasada: nikt samodzielnie nie kupuje ani nie subskrybuje oprogramowania, które ma być używane przez więcej niż jedną osobę. Nawet jeżeli chodzi „tylko” o tani SaaS płatny kartą.

Minimum procedur, bez biurokracji

Żeby nie zabić zwinności działania, procedury powinny być krótkie i powtarzalne. Praktycznym minimum jest:

1. Jedna skrzynka e-mail do zgłaszania potrzeb IT
   Każda prośba o nowe oprogramowanie lub usługę SaaS trafia w jedno miejsce. Łatwiej wtedy wychwycić dublujące się narzędzia lub potencjalne konflikty licencyjne.
2. Formularz „nowe narzędzie”
   Kilka pól: do czego, ile osób, dane dostawcy, model płatności, czy jest dostępny regulamin licencyjny. IT na tej podstawie rekomenduje typ licencji i sposób wdrożenia.
3. Rejestr oprogramowania
   Prosty arkusz lub system: nazwa, dostawca, typ licencji, liczba użytkowników, osoby odpowiedzialne po stronie biznesu i IT, data odnowienia. Bez tego trudno prowadzić jakiekolwiek sensowne rozmowy przy audycie.
4. Procedura offboardingu
   Lista kroków przy odejściu pracownika powinna zawierać odebranie dostępu do wszystkich narzędzi i ewentualne „przepisanie” licencji na inną osobę, jeśli to dopuszcza umowa.

Najgroźniej działa tu iluzja „czyimś zadaniem” – każdy zakłada, że kto inny pilnuje legalności licencji. Kontrola pokazuje, że nikt nie miał pełnego obrazu.

Co sprawdzić przed decyzją o zakupie lub zmianie modelu licencjonowania

Krótka lista pytań do dostawcy (i do siebie)

Zanim firma zwiąże się z dostawcą na lata albo przeniesie kluczowy system do chmury, sensownie jest przejść przez zestaw prostych pytań. Dobrze, jeśli padają zarówno po stronie technicznej, jak i biznesowej.

• Jak są licencjonowani użytkownicy?
  Per użytkownik, per urządzenie, na instancję serwera, licencja równoczesna, a może według innego wskaźnika (np. obroty, liczba klientów)? Bez tej odpowiedzi trudno później ocenić, czy rosnąca firma będzie w stanie utrzymać koszty.
• Czy licencja obejmuje pracę zdalną i różne lokalizacje?
  Jeżeli zespół pracuje hybrydowo lub w kilku miastach, trzeba to mieć wprost dopuszczone w dokumentacji licencyjnej, a nie tylko „dogadane z handlowcem”.
• Jakie są zasady dostępu dla podwykonawców i klientów?
  Przy systemach B2B i outsourcingu IT kluczowe jest, czy podwykonawca może korzystać z licencji klienta, czy musi mieć własną, i czy klienci końcowi mogą logować się do systemu w oparciu o licencje nabyte przez firmę.
• Czy przewidziane są audyty i w jakim trybie?
  Warto znać częstotliwość, sposób zgłaszania audytu, zakres danych, do których dostawca ma mieć dostęp. Jeżeli zapis jest bardzo szeroki, bywa to argument na etapie negocjacji.
• Co dzieje się po wygaśnięciu subskrypcji?
  Czy firma traci tylko dostęp do aktualizacji, czy do działania całego systemu? Czy ma możliwość odczytu danych i eksportu w rozsądnym formacie, ile czasu? To szczególnie ważne przy systemach, które przechowują istotne dane operacyjne lub księgowe.
• Czy przewidziane są rabaty przy rozwoju skali?
  Nie chodzi tylko o cenę, ale też o potencjalne „pułapy”, po przekroczeniu których zmienia się model rozliczeń (np. po osiągnięciu określonej liczby użytkowników).

Na jakie zapisy w umowach licencyjnych zwracać szczególną uwagę

Umowy licencyjne i regulaminy dostawców bywają rozbudowane, ale kilka sekcji niemal zawsze ma największy wpływ na ryzyko prawne:

1. Definicje „user”, „seat”, „device”, „instance”
   Niewielka różnica w definicji może oznaczać inny sposób liczenia licencji. Trzeba sprawdzić, czy definicja pasuje do rzeczywistego modelu pracy w firmie (hot-desking, praca zmianowa, podwykonawcy).
2. Postanowienia o sublicencjonowaniu i udostępnianiu
   Jeżeli firma wdraża system klientom lub świadczy usługi na jego bazie, musi wiedzieć, czy może dawać dostęp „dalej”, czy tylko wewnętrznie. To częsty punkt zapalny przy systemach SaaS używanych w roli „silnika” usługi.
3. Ograniczenia terytorialne
   Część licencji formalnie obejmuje tylko określone kraje lub regiony. Gdy zespół jest rozproszony, a serwery stoją poza Polską, trzeba upewnić się, że to nie narusza warunków umowy.
4. Mechanizmy zbierania danych o użyciu
   W niektórych rozwiązaniach producent przewiduje automatyczne zbieranie danych telemetrycznych lub logów. Trzeba wiedzieć, jakie informacje są przesyłane, czy mogą posłużyć do szacowania zgodności licencyjnej i jak to się ma do lokalnych wymogów ochrony danych.
5. Odpowiedzialność za naruszenia licencji
   Czasem dostawca przerzuca na klienta pełną odpowiedzialność za działania użytkowników końcowych, nawet gdy narzędzie „z natury” sprzyja przekraczaniu ograniczeń. Warto ocenić, czy taki zapis jest akceptowalny przy danym profilu działalności.

Jeżeli podczas czytania umowy pojawia się więcej znaków zapytania niż odpowiedzi, to zwykle dobry sygnał, żeby chociaż jednorazowo skonsultować wybór licencji z prawnikiem lub doradcą, zanim system stanie się krytyczny dla działania firmy.

Końcowa checklista – szybki przegląd ryzyk licencyjnych w firmie

Krótki przegląd kilku obszarów pozwala zorientować się, gdzie sytuacja jest pod kontrolą, a gdzie potrzebne są szybkie korekty. Można przejść przez listę w gronie IT + finansów + osoby odpowiedzialnej za zakupy.

• Inwentaryzacja
  Czy istnieje aktualna lista:
  • używanych systemów i aplikacji (lokalnych i SaaS),
  • licencji przypisanych do użytkowników/urządzeń,
  • dowodów zakupu i umów licencyjnych?
• Modele pracy
  Czy sposób użycia (praca zdalna, BYOD, dostęp przez terminale, praca zmianowa) jest zgodny z typem licencji opisanym w umowach?
• Subskrypcje i SaaS
  Czy w organizacji nie ma:
  • wspólnych kont używanych przez wiele osób,
  • udostępniania dostępu klientom lub podwykonawcom bez sprawdzenia licencji,
  • „zapomnianych” subskrypcji, które nikt nie nadzoruje?
• Open source
  Czy ktoś w firmie:
  • prowadzi listę komponentów open source w produktach,
  • rozróżnia licencje liberalne od „copyleft”,
  • sprawdza skład przed większym wydaniem lub sprzedażą systemu?
• Audyt dostawcy
  Czy wiadomo:
  • kto odpowiada za kontakt z producentem w razie audytu,
  • jakie dane firma jest zobowiązana udostępnić,
  • jak wygląda wewnętrzna ścieżka decyzyjna i kto zatwierdza plan działań naprawczych?
• Procesy i odpowiedzialności
  Czy konkretnym osobom przypisano odpowiedzialność za:
  • zatwierdzanie nowych narzędzi i licencji,
  • monitorowanie wykorzystania (użytkownicy, moduły, zasoby),
  • kontakt z działem prawnym lub zewnętrznym doradcą przy wątpliwościach?

Ta checklista nie zastąpi pełnego audytu, ale zwykle po jednym spotkaniu pozwala uchwycić 2–3 obszary, które trzeba „uszczelnić” w pierwszej kolejności. Dla jednych firm będzie to ogarnięcie kont SaaS i porządek w subskrypcjach, dla innych – przegląd komponentów open source przed rozmowami z inwestorem lub dużym klientem.

Praktyczny sposób pracy to podzielić zadania na trzy koszyki: rzeczy do zrobienia natychmiast (np. wyłączenie oczywiście nielegalnych instalacji), działania w ciągu najbliższego kwartału (uporządkowanie rejestru licencji, aktualizacja procedur) oraz zmiany strategiczne (np. migracja na inny model licencjonowania albo konsolidacja kilku narzędzi w jedno). Dzięki temu temat licencji nie ląduje w szufladzie pod etykietą „trzeba się tym kiedyś zająć”.

Najczęstszy błąd to czekanie, aż producent sam upomni się o audyt, zamiast regularnie sprawdzać, czy sposób korzystania z oprogramowania nie rozjechał się z umowami. Im szybciej wychwycisz rozbieżności, tym większy masz wpływ na ich koszt i sposób naprawy – zanim o kształcie rozmowy zaczną decydować wyłącznie paragrafy i terminy z pisma przedsądowego.

Najczęściej zadawane pytania (FAQ)

Jak wygląda kontrola legalności oprogramowania w firmie krok po kroku?

Najczęściej zaczyna się od sygnału z zewnątrz: pisma od producenta z żądaniem audytu, zawiadomienia z policji/prokuratury albo donosu pracownika. Firma dostaje oficjalne pismo z zakresem kontroli i terminami odpowiedzi.

Następnie kontrolujący żądają listy zainstalowanego oprogramowania (stacje robocze, serwery), faktur i umów licencyjnych oraz opisów modelu korzystania (liczba użytkowników, lokalizacje, dostęp zdalny). Często chcą też wejść na wybrane komputery i serwery, aby zweryfikować faktyczną liczbę instalacji. Na tej podstawie porównują stan faktyczny z dokumentacją licencji.

Skąd biorą się kontrole legalności oprogramowania w Polsce?

Impuls zwykle jest bardzo przyziemny. Najczęstsze źródła to donos (także anonimowy) obecnego lub byłego pracownika, konflikt z dostawcą IT, który zgłasza nieprawidłowości producentowi, albo automatyczne wykrycie zbyt dużej liczby instalacji przez systemy telemetrii producenta.

Część kontroli zaczyna się też „od środka” – nowy zarząd, audytor finansowy lub wewnętrzny audyt IT zauważa rozjazd między liczbą komputerów, oprogramowaniem a fakturami. Wtedy firma sama inicjuje przegląd, ale efekty takiego przeglądu często później widzi także producent.

Jakie są konsekwencje używania nielegalnego lub źle licencjonowanego oprogramowania?

Poza oczywistymi karami finansowymi problemem są nagłe, nieplanowane wydatki – trzeba w krótkim czasie kupić brakujące licencje, często w pełnych, wyższych cenach. Dochodzą do tego przestoje, gdy producent blokuje dostęp do części systemów do czasu wyjaśnienia sprawy.

Dla firmy istotne jest też ryzyko reputacyjne (informacja o nielegalnym oprogramowaniu łatwo wypływa) oraz osobista odpowiedzialność decydentów. W skrajnych przypadkach członkowie zarządu lub manager IT mogą zostać wciągnięci w postępowanie karne lub cywilne, jeśli świadomie akceptowali ryzykowne zakupy.

Czy „tanie klucze” z aukcji internetowych są legalne do użycia w firmie?

Bardzo często nie. Nawet jeśli system technicznie się aktywuje, klucz może pochodzić z licencji edukacyjnych, testowych, z kradzionych kont albo być wielokrotnie użyty na świecie. Producent może takie klucze unieważnić, a kontrola uzna wszystkie instalacje za nielegalne.

Typowe sygnały ostrzegawcze to: cena 5–10 razy niższa niż w oficjalnym kanale, brak faktury VAT na firmę, brak jasnego rodzaju licencji (OEM, BOX, zbiorcza, używana), brak pełnych danych sprzedawcy i „dziwny” proces aktywacji wymagający podawania loginów. W takiej sytuacji w razie kontroli obrona legalności jest bardzo trudna.

Jak sprawdzić, czy moja firma ma komplet licencji na zainstalowane oprogramowanie?

Minimalny, praktyczny zestaw kroków to:

• zebrać pełną listę zainstalowanego oprogramowania na wszystkich komputerach i serwerach (narzędzie inwentaryzujące lub skrypt IT),
• zebrać w jednym miejscu wszystkie faktury, umowy i maile potwierdzające zakup licencji (z księgowości, od dostawców IT, z kont firmowych u producentów),
• porównać liczbę instalacji z liczbą licencji oraz ich typem (per urządzenie, per użytkownik, subskrypcja, OEM itp.).

Przy modelu per user trzeba dodatkowo sprawdzić, ilu realnie użytkowników korzysta z danego systemu, w ilu lokalizacjach i z jakich urządzeń (lokalnie, zdalnie, z domu). Rozjazd między użytkowaniem a dokumentacją to pierwszy sygnał, że jest problem.

Na co zwrócić uwagę przy zakupie licencji, żeby nie mieć problemów przy kontroli?

Bezpieczny zakup opiera się na kilku prostych filtrach. Sprzedawca powinien wystawić pełną fakturę VAT na firmę (z NIP obu stron), podać dokładną nazwę produktu, typ licencji, liczbę sztuk i informację o przeznaczeniu komercyjnym. Dobrą praktyką jest kupowanie wyłącznie od autoryzowanych partnerów producenta lub bezpośrednio u niego.

Trzeba unikać ofert, w których nie da się ustalić rodzaju licencji, kraju przeznaczenia czy warunków użycia w firmie. Jeśli cena jest rażąco niższa niż w oficjalnym kanale, a sprzedawca nie potrafi pokazać umowy dystrybucyjnej lub statusu partnera, ryzyko prawne jest wysokie. Najbardziej kosztownym błędem jest „oszczędzanie” na licencjach kosztem rezygnacji z dokumentacji i jasnego pochodzenia oprogramowania.