Kto odpowiada za legalność narzędzi przy outsourcingu IT – mapa odpowiedzialności
Główne role: kto realnie decyduje o narzędziach
Przy outsourcingu IT w projekt zaangażowane są co najmniej cztery typy podmiotów, które mają wpływ na legalność i licencjonowanie narzędzi:
Klient biznesowy – właściciel produktu, marki i danych, inicjator projektu.
Software house – główny wykonawca, który organizuje zespół i dobiera stack technologiczny.
Podwykonawcy – inne firmy IT lub specjaliści dostarczający cząstkowe rozwiązania (np. UX, DevOps, integracje).
Freelancerzy / konsultanci – pojedyncze osoby wpięte w łańcuch dostaw.
Każda z tych ról może wprowadzić do projektu narzędzia (oprogramowanie, biblioteki, usługi SaaS), a więc każdy może „wnosić” ryzyko licencyjne. Jednocześnie z perspektywy prawa i kontraktów to nie zawsze ta sama osoba ponosi konsekwencje. Typowy błąd polega na tym, że strony zakładają „przecież to oczywiste, że oni się tym zajmą”, nie zapisując wprost, kto odpowiada za legalność narzędzi w projekcie IT.
Jeśli na pierwszym warsztacie z software house’em nikt nie potrafi jasno powiedzieć, kto zatwierdza nowe narzędzia i kto je dokumentuje, to już na starcie pojawia się sygnał ostrzegawczy – mapa odpowiedzialności jest rozmyta.
Odpowiedzialność cywilna i kontraktowa – kto odpowiada wobec kogo
Odpowiedzialność za legalność narzędzi używanych w projekcie IT rozgrywa się na dwóch poziomach:
Odpowiedzialność cywilna/deliktowa – wobec właścicieli praw autorskich, dostawców licencji, organizacji zbiorowego zarządzania. Jeśli dojdzie do naruszenia licencji, roszczenia mogą być kierowane do tego, kto narusza prawa (np. użytkownik systemu, podmiot czerpiący korzyści).
Odpowiedzialność kontraktowa – wynikająca z umowy między klientem a software house’em (i dalej – umowy software house’a z podwykonawcami). Tu obowiązuje to, co strony świadomie ustalą: kto gwarantuje legalność, kto ponosi koszty ewentualnych roszczeń, kto musi zapewnić audyt legalności oprogramowania u podwykonawcy.
W praktyce oznacza to, że:
klient może zostać pozwany przez posiadacza praw do narzędzia, które zostało nielegalnie użyte w rozwijanym systemie,
ale klient może następnie dochodzić roszczeń od software house’u, jeśli ten wziął odpowiedzialność w umowie i nie dopełnił obowiązków,
a software house – od swojego podwykonawcy lub freelancera, jeśli ich zaniedbanie spowodowało naruszenie.
Łańcuch odpowiedzialności jest więc z natury kaskadowy. Kluczowe jest, żeby w kontraktach jasno wynikało, gdzie ten łańcuch się nie urywa, a gdzie wręcz przeciwnie – klient bierze pewne ryzyka na siebie (np. wymuszając konkretne, obarczone ryzykiem narzędzie).
Zasada „kto używa, ten odpowiada” vs. „kto zarządza projektem, ten nadzoruje”
W projektach outsourcingowych funkcjonują dwie praktyczne zasady, które trzeba ze sobą pogodzić:
„Kto używa, ten odpowiada” – z punktu widzenia prawa autorskiego odpowiedzialność za legalność korzystania z oprogramowania zwykle ponosi podmiot, który go używa lub który zleca jego używanie w swojej działalności (np. klient, który komercyjnie korzysta z systemu).
„Kto zarządza projektem, ten nadzoruje” – z perspektywy stricte projektowej osoba lub podmiot zarządzający zespołem (software house, lead developer, CTO klienta) powinien mieć realną kontrolę nad tym, jakie narzędzia wchodzą do stacku i jak są licencjonowane.
Właśnie w napięciu między tymi dwoma zasadami powstaje większość sporów. Klient wychodzi z założenia: „to software house dobiera biblioteki, więc to jego problem”, a software house: „produkt jest klienta, to on ponosi ryzyka prawne w outsourcingu IT”. Bez precyzyjnego rozpisania, kto i na jakim etapie zatwierdza, monitoruje i dokumentuje narzędzia, obie strony funkcjonują w oparciu o domysły.
Minimum to przypisanie trzech ról:
kto inicjuje użycie nowego narzędzia,
kto sprawdza licencję i warunki komercyjnego użycia,
kto zatwierdza wprowadzenie narzędzia do projektu i bierze to na siebie kontraktowo.
Przepływ ryzyka: od dostawcy narzędzia do klienta
Łańcuch ryzyka licencyjnego w projekcie IT zwykle wygląda następująco:
Dostawca narzędzia (twórca biblioteki, dostawca SaaS, producent IDE) publikuje lub udostępnia narzędzie z określonymi warunkami licencyjnymi (EULA, Terms of Service, licencja OSS).
Software house (lub jego podwykonawca) wybiera to narzędzie do wykorzystania w projekcie. W tym momencie powinien nastąpić audyt legalności i ocena, czy licencja pozwala na użycie zgodne z celem projektu.
Zespół deweloperski implementuje narzędzie, bibliotekę lub integrację w kodzie, build pipeline’ach, infrastrukturze.
Klient wdraża produkt do środowiska produkcyjnego i używa go komercyjnie (lub udostępnia go użytkownikom końcowym).
Jeśli na którymkolwiek etapie warunki licencji zostaną naruszone (np. przekroczona liczba użytkowników, brak opłaconej subskrypcji, niedozwolone modyfikacje, złamanie ograniczeń licencji copyleft), konsekwencje mogą dotknąć każdego z powyższych podmiotów – ale to klient jako widoczny „właściciel” rozwiązania ma najwięcej do stracenia reputacyjnie i biznesowo.
Realistyczny model współpracy zakłada więc, że:
software house bierze na siebie obowiązek prawidłowego doboru i dokumentowania narzędzi,
klient bierze na siebie obowiązek bieżącego nadzoru i reakcji, jeśli pojawią się sygnały ostrzegawcze (np. raport z audytu software house’u, ostrzeżenia dostawcy SaaS).
Skutki braku jasnej mapy odpowiedzialności
Gdy role nie są rozpisane, typowe skutki to:
spory o koszty refaktoringu – gdy trzeba usunąć nielegalną bibliotekę z rdzenia systemu, pojawia się pytanie: kto za to płaci i kto pokrywa opóźnienia release’u,
przestoje wdrożeniowe – wdrożenie na produkcję zostaje wstrzymane, bo dział prawny klienta odkrywa niejasne licencje w ostatnim momencie,
presja na szybkie „łatanie” licencji – kupowanie na szybko dodatkowych licencji, planów SaaS czy migracja na inne narzędzia bez odpowiedniej analizy,
trwałe ograniczenia produktu – gdy z powodu źle dobranej licencji (np. AGPL) produkt nie może być dystrybuowany zgodnie z pierwotną strategią.
Jeśli mapa ról i odpowiedzialności jest na tyle prosta, że można ją narysować w 30 sekund (kto decyduje, kto sprawdza licencje, kto zatwierdza, kto raportuje), projekt ma dużo mniejsze ryzyko licencyjne. Jeżeli do wyjaśnienia „kto za co odpowiada” trzeba długiego „tłumaczenia kontekstu”, to wyraźny sygnał ostrzegawczy – kontrakt i procedury są zbyt ogólne albo wręcz pomijają kluczowe kwestie.
Źródło: Pexels | Autor: RDNE Stock project
Podstawy prawne: licencje, prawa autorskie i odpowiedzialność za naruszenia
Prawo autorskie w projekcie IT – fundament bez żargonu
Dla celów outsourcingu IT kluczowe są trzy filary polskiego i europejskiego prawa autorskiego:
Program komputerowy jako utwór – kod źródłowy, kod wynikowy, dokumentacja techniczna i projektowa są chronione jak utwory literackie.
Pola eksploatacji – zakres tego, co można robić z utworem (utrwalanie, zwielokrotnianie, modyfikacje, rozpowszechnianie, najem, użyczenie itd.), regulowany w umowie lub licencji.
Licencje i przeniesienie praw – sposób „wpuszczenia” utworu do obrotu, określający kto, na jakich zasadach i w jakim zakresie może z niego korzystać.
Dozwolony użytek (np. prywatny, edukacyjny) praktycznie nie ma zastosowania w komercyjnych projektach IT. Projekt realizowany przez software house dla klienta biznesowego z definicji nie mieści się w ramach „użytku prywatnego”. Wszelkie działania zespołu developerskiego i klienta muszą mieć pokrycie w licencjach lub umowach.
Minimum po stronie PM-ów i CTO to rozumienie, że każda biblioteka, każde narzędzie SaaS, każdy snippet kodu zewnętrznego ma swojego twórcę i swoje warunki licencyjne – i nie ma „domyślnego” prawa do dowolnego użycia tylko dlatego, że coś jest dostępne w internecie.
Różnica między licencją, przeniesieniem praw a dostępem SaaS
W projektach outsourcingowych często myli się trzy różne konstrukcje prawne:
Nabycie licencji – uzyskanie prawa do korzystania z utworu w określonym zakresie. Może być licencja wyłączna lub niewyłączna; na określony czas lub bezterminowa; odpłatna lub nieodpłatna.
Przeniesienie praw autorskich – twórca (np. software house) przenosi majątkowe prawa autorskie do utworu na klienta. Od tego momentu klient staje się „właścicielem” utworu w określonych polach eksploatacji.
Dostęp SaaS – klient nie otrzymuje ani licencji na oprogramowanie w klasycznym sensie, ani przeniesienia praw. Korzysta z usługi, której warunki reguluje regulamin, EULA lub Terms of Service. Często nie dostaje kodu źródłowego, a jedynie „prawo do użycia funkcjonalności” w modelu abonamentowym.
W kontekście legalności narzędzi używanych w projekcie IT ma to kilka konsekwencji:
jeśli software house używa komercyjnych narzędzi developerskich (IDE, narzędzia DevOps) na podstawie swoich licencji – klient nie jest stroną tych licencji, ale powinien mieć gwarancję, że korzystanie jest legalne,
jeśli do produktu wbudowywana jest biblioteka na licencji open source – klient musi wiedzieć, na jakich polach eksploatacji będzie mógł korzystać z całego produktu,
jeśli architektura systemu opiera się na zewnętrznym SaaS – klient realnie uzależnia swój produkt od warunków regulaminu tego SaaS i musi znać ich konsekwencje (np. ograniczenia terytorialne, zakaz resellingu).
Odpowiedzialność za naruszenie licencji: użytkownik, zlecający, zarząd
Przy naruszeniu licencji do oprogramowania, odpowiedzialność może dotknąć kilku poziomów:
Bezpośredni użytkownik – podmiot, który realnie korzysta z programu niezgodnie z licencją (np. firma, która używa nielegalnie oprogramowania na swoich serwerach produkcyjnych).
Zlecający projekt – jeśli to on zorganizował korzystanie z narzędzia w ramach projektu (np. udostępnił software house’owi własne nielegalne środowisko lub wymusił użycie pirackiej kopii).
Osoby z zarządu – w skrajnych przypadkach, gdy naruszenia są rażące i umyślne, ryzyko może dotyczyć również odpowiedzialności osób zarządzających (np. w kontekście odpowiedzialności karnej lub odpowiedzialności wobec wspólników/akcjonariuszy).
W outsourcingu IT praktyczne znaczenie ma też odpowiedzialność kontraktowa wobec drugiej strony umowy. Software house, który w umowie zobowiązał się zapewnić legalność narzędzi używanych przy realizacji projektu, a następnie korzystał z narzędzi niezgodnie z licencją, może być zobowiązany do:
zapewnienia planu naprawczego (np. wymiana komponentu, refaktoring),
zwrotu wynagrodzenia za wadliwie wykonane prace.
Rola regulaminów, EULA i Terms of Service
Narzędzia chmurowe, platformy SaaS, marketplace’y z komponentami (np. szablony, pluginy) rzadko mają klasyczną „umowę licencyjną” podpisywaną papierowo. Zamiast tego obowiązują:
EULA (End User License Agreement),
Terms of Service / Terms of Use,
regulaminy platform.
Akceptacja tych dokumentów zwykle następuje przez kliknięcie checkboxa lub samo korzystanie z usług. W praktyce to tam kryją się ograniczenia typu:
zakaz użycia w określonych branżach (np. finanse, medycyna, sektor publiczny bez dodatkowych umów),
zakaz budowania produktów konkurencyjnych do samego SaaS,
limity użytkowników, wywołań API, środowisk,
Granice odpowiedzialności a łańcuch podwykonawców
W typowym projekcie outsourcingowym rzadko występują tylko dwie strony. Po drodze pojawiają się podwykonawcy, freelancerzy, zewnętrzni konsultanci, integratorzy systemów, a czasem oddzielny dostawca infrastruktury. Każdy z nich może wnieść do projektu własne narzędzia, biblioteki i własne „przyzwyczajenia” licencyjne.
Kilka praktycznych punktów kontrolnych przy projektowaniu łańcucha podwykonawców:
obowiązek stosowania tych samych standardów licencyjnych – umowa z podwykonawcą powinna wprost wymagać przestrzegania zasad narzędziowych przyjętych w kontrakcie głównym (np. zakaz określonych licencji copyleft, wymóg katalogowania komponentów open source),
prawo audytu łańcucha – klient z reguły ma prawo audytować software house, ale rzadziej zadba o możliwość sięgnięcia „w głąb” do podwykonawców. Brak takiego zapisu to poważny sygnał ostrzegawczy przy złożonych projektach,
back-to-back indemnity – jeśli software house udziela klientowi gwarancji (np. odszkodowania) za naruszenia licencji, musi mieć analogiczną ochronę od swoich podwykonawców, inaczej bierze na siebie cały ciężar ryzyka cudzych naruszeń,
spójny proces onboardingowy – każdy nowy podwykonawca lub freelancer powinien przejść krótką „checklistę licencyjną”: jakie IDE, jakie biblioteki, jakie marketplace’y wykorzystuje na co dzień i które z nich zamierza wnieść do projektu.
Jeżeli w łańcuchu pojawiają się „szare strefy” – podwykonawcy działający na luźnych mailach, brak umów back-to-back, brak prawa audytu – ryzyko licencyjne nie rozprasza się, lecz kumuluje i na końcu uderza w klienta oraz software house jako głównego kontrahenta.
Źródło: Pexels | Autor: RDNE Stock project
Jakie narzędzia w projekcie generują ryzyko licencyjne
Biblioteki i komponenty open source
Największe ryzyko nie wynika zazwyczaj z pirackich kopii komercyjnego oprogramowania, ale z masowego, niekontrolowanego użycia open source. Problemem nie jest samo użycie, lecz brak analizy licencji i sposobu integracji.
Kluczowe punkty kontrolne przy bibliotekach open source:
rodzaj licencji – licencje copyleft (GPL, AGPL, LGPL w pewnych konfiguracjach) mogą wymuszać otwarcie kodu lub narzucać ograniczenia dystrybucji; licencje permissive (MIT, BSD, Apache) są zwykle mniej restrykcyjne, ale też mają swoje wymogi,
forma włączenia do projektu – statyczne linkowanie, dynamiczne linkowanie, korzystanie jako usługa zewnętrzna (np. biblioteka wyłącznie po stronie serwera dostawcy) mają różne konsekwencje w kontekście copyleft,
forki i nieoficjalne dystrybucje – komponent z GitHuba nie zawsze jest oficjalnym repozytorium projektu; używanie forka z niejasnym statusem licencyjnym to klasyczny sygnał ostrzegawczy,
modyfikacje kodu – w niektórych licencjach warunki dla użytkownika końcowego różnią się w zależności od tego, czy kod był modyfikowany; brak dokumentacji zmian utrudnia wykazanie zgodności.
Jeśli w projekcie nie istnieje zcentralizowana lista użytych bibliotek z informacją o licencji i wersji, trudno w ogóle mówić o świadomym zarządzaniu ryzykiem licencyjnym – to minimum, od którego należy zacząć.
Narzędzia developerskie i środowiska CI/CD
Drugą grupą są narzędzia, które na pierwszy rzut oka „nie wchodzą do produktu”: IDE, narzędzia testowe, systemy CI/CD, skanery bezpieczeństwa, platformy low-code używane tylko do generowania fragmentów kodu. To, że nie są dystrybuowane z produktem, nie oznacza, że nie generują ryzyka.
Przy tych narzędziach sprawdza się kilka prostych kryteriów:
model licencjonowania użytkowników – licencja per seat, per concurrent user, per build agent; niezgodność liczby użytkowników lub agentów z zakupionym planem bywa jednym z najczęstszych naruszeń w działach R&D,
zakres dozwolonego użycia – część narzędzi ma inne warunki dla użytku komercyjnego i niekomercyjnego, a także wyklucza użycie w usługach świadczonych na rzecz osób trzecich (co uderza bezpośrednio w software house’y),
dzielenie kont i licencji – współdzielone konta CI/CD, „konta zespołowe” w narzędziach, które tego zabraniają, lub korzystanie z prywatnych kont deweloperów w ramach projektu komercyjnego,
wykorzystanie wersji community – darmowe „community edition” często jest ograniczone do projektów open source albo ma limit przychodów użytkownika.
Jeżeli software house nie ma polityki licencyjnej dla narzędzi developerskich (kto kupuje, kto monitoruje, jak często są weryfikowane licencje), trudno oczekiwać, że w projekcie klienta ryzyko będzie faktycznie kontrolowane.
Platformy chmurowe i zewnętrzne API
Architektura oparta na usługach zewnętrznych (cloud, API, PaaS, FaaS) przenosi część ryzyk poza klasyczną definicję „licencji na oprogramowanie”, ale nie usuwa ich – zmienia tylko ich charakter.
Przy usługach chmurowych i API warto systematycznie przechodzić przez następujące punkty:
zakres uprawnień do dalszej odsprzedaży/usług – wiele API dopuszcza jedynie „internal use”, a komercyjne oferowanie funkcjonalności opartej na tym API wymaga dodatkowej umowy,
limity i model rozliczeń – przekroczenie limitów (requesty, użytkownicy, środowiska) i kontynuowanie użycia bez aktualizacji planu to naruszenie warunków, nawet jeśli rachunek został opłacony,
terytorium i kategorie danych – część usług chmurowych zakazuje przetwarzania określonych kategorii danych bez dodatkowych umów (np. dane zdrowotne, dane finansowe, dane dzieci),
subprocesorzy i łańcuch dostawców – dostawca SaaS/Cloud często opiera swoją infrastrukturę na innych dostawcach; ich regulaminy również mają wpływ na legalność rozwiązania.
Jeśli architektura systemu jest silnie związana z pojedynczym dostawcą SaaS lub API, a jednocześnie brak jest przeglądu jego regulaminów pod kątem komercyjnego modelu klienta, ryzyko blokady produktu lub konieczności szybkiej migracji do alternatywy rośnie wykładniczo.
Marketplace’y z pluginami, szablonami i „gotowcami”
Sklepy z motywami, pluginami, szablonami UI, komponentami do CMS lub e‑commerce często wydają się „szybką drogą” do przyspieszenia projektu. Problem zaczyna się wtedy, gdy licencja jest dopasowana do indywidualnego użytku, a nie do modelu „software house + klient + kolejni użytkownicy końcowi”.
W tego typu komponentach koniecznie trzeba sprawdzić:
czy licencja jest przenaszalna – niektóre marketplace’y przyznają licencję osobie kupującej (software house), a nie końcowemu klientowi; potem pojawia się pytanie, kto może legalnie aktualizować i używać komponentu,
liczbę instalacji / projektów – licencja „single use” przy produkcie wielotenantowym lub multi‑brand to klasyczny punkt zapalny przy audytach,
zakaz re‑distribution – część komponentów można użyć w jednym wdrożeniu, ale nie można ich dystrybuować jako elementu pakietowanego produktu SaaS,
aktualizacje i wsparcie – brak prawa do aktualizacji w nowym projekcie lub po przekazaniu kodu klientowi bywa ukrytą konsekwencją pozornie taniej licencji.
Jeśli zespół „ściąga gotowce” z marketplace’ów bez centralnego rejestru i akceptacji, proces weryfikacji licencji przy końcowym przekazaniu produktu klientowi staje się niemal niewykonalny w rozsądnym czasie.
Źródło: Pexels | Autor: Kindel Media
Odpowiedzialność klienta: co zawsze zostaje po stronie zlecającego
Decyzje biznesowe o modelu produktu i rynku
Nawet najlepszy software house nie zastąpi klienta przy decyzjach o tym, na jakich rynkach, w jakich segmentach i w jakim modelu komercyjnym ma działać produkt. Te decyzje definiują, czy dane narzędzia i licencje są w ogóle dopuszczalne.
Po stronie klienta zostają w szczególności:
docelowy model dystrybucji – on‑premise, SaaS, white‑label, licencjonowanie do innych partnerów; każdy model może być w konflikcie z określonymi licencjami open source lub regulaminami SaaS,
branża i typ danych – produkt dla instytucji finansowych czy podmiotów medycznych nie może opierać się na dowolnym narzędziu chmurowym; klient zna regulacje sektorowe i musi je zestawić z wyborem narzędzi,
geografia użytkowników końcowych – jeśli planowana jest ekspansja poza UE lub do jurysdykcji o szczególnych wymogach (np. dane rezydujące w kraju), architektura i dobór narzędzi muszą ten fakt odzwierciedlać.
Jeżeli klient nie dostarcza software house’owi jasnej mapy: gdzie, komu i w jakim modelu będzie oferowany produkt, odpowiedzialność za niedopasowanie licencji do realiów rynku w praktyce wraca do klienta – bo decyzje biznesowe były po jego stronie.
Legalność środowisk, danych i licencji dostarczonych przez klienta
Częsta sytuacja: klient dostarcza środowisko (np. własny cluster Kubernetes, licencje bazodanowe, narzędzia BI) i oczekuje, że software house po prostu „będzie z nich korzystał”. Wtedy to klient jest podmiotem, który musi zadbać o legalność tych składników.
Minimalny zestaw obowiązków klienta w tym obszarze:
legalne licencje na własne oprogramowanie – bazy danych, serwery aplikacyjne, narzędzia analityczne, do których software house uzyskuje dostęp, muszą być używane zgodnie z licencją (w tym: liczba instancji, procesorów, użytkowników pośrednich),
prawa do danych – dane testowe pochodzące z systemów produkcyjnych, importowane z innych źródeł, muszą być użyte w sposób zgodny z prawem; fakt, że „są to dane klienta” nie zwalnia z posiadania praw do ich przetwarzania w projekcie,
zarządzanie dostępami – konta udostępnione software house’owi (do chmury, narzędzi BI, repozytoriów) nie mogą naruszać warunków licencyjnych, np. być współdzielonymi kontami osobistymi pracowników klienta.
Jeżeli audyt licencyjny wykaże, że to klient udostępnił software house’owi „nielegalne” środowisko lub dane, trudno oczekiwać, że odpowiedzialność zostanie przerzucona na wykonawcę – ten mógł opierać się w dobrej wierze na oświadczeniach klienta.
Nadzór, akceptacja i reakcja na raporty ryzyka
Nawet jeśli operacyjne decyzje narzędziowe leżą po stronie software house’u, klient nie jest zwolniony z nadzoru. Brak jakiejkolwiek reakcji na sygnały ryzyka może zostać oceniony jako niedochowanie należytej staranności.
Po stronie klienta powinny znaleźć się co najmniej:
wyznaczone osoby odpowiedzialne – rola po stronie klienta (np. właściciel produktu, prawnik wewnętrzny), który czyta raporty z przeglądu licencji i potrafi podjąć decyzję,
procedura reagowania na incydenty licencyjne – co się dzieje, gdy software house raportuje bibliotekę o nieakceptowalnej licencji lub zmianę regulaminu kluczowego narzędzia SaaS,
okresowe przeglądy – minimum to przegląd licencji i narzędzi przy kluczowych kamieniach milowych (MVP, wejście na produkcję, wejście na nowy rynek).
Jeżeli klient nie otwiera raportów i nie reaguje na rekomendacje software house’u, ciężar ryzyka przesuwa się na niego – szczególnie w sytuacjach, gdy wykonawca wprost ostrzega o potencjalnych naruszeniach.
Świadome akceptowanie kompromisów licencyjnych
Zdarza się, że dla osiągnięcia określonego celu biznesowego klient decyduje się na narzędzia z „ostrzejszymi” licencjami (np. komponent na licencji AGPL przy produkcie SaaS). W takiej sytuacji software house może jedynie rekomendować alternatywy i opisać konsekwencje – decyzja należy do klienta.
W takich przypadkach przydaje się:
pisemna akceptacja ryzyka – klient potwierdza, że rozumie skutki użycia danego narzędzia (np. konieczność udostępnienia kodu w określonych scenariuszach) i akceptuje je,
udokumentowane rekomendacje alternatyw – software house przedstawia możliwe inne komponenty, ich koszty i ograniczenia, tak aby było jasne, że wybór był świadomy,
plan wyjścia – choćby ramowy opis, jak można będzie w przyszłości zastąpić dany komponent, jeśli ryzyko stanie się nieakceptowalne (np. zmiana strategii, inwestor wymagający „czystej” własności intelektualnej).
Jeżeli klient naciska na rozwiązania licencyjnie ryzykowne, a jednocześnie odmawia ich formalnej akceptacji, jest to wyraźny sygnał ostrzegawczy – odpowiedzialność może być następnie przerzucana na software house w sporze, choć decyzje faktycznie podejmował klient.
Odpowiedzialność software house’u: zakres, który powinien być pod jego kontrolą
Dobór technologii, bibliotek i narzędzi developerskich
Software house odpowiada za to, czym faktycznie buduje produkt klienta. Nie chodzi jedynie o aspekt techniczny, ale o ocenę, czy wybrane narzędzia można legalnie zastosować w zakładanym modelu biznesowym i skali projektu.
Przy doborze stosu technologicznego po stronie software house’u powinny znaleźć się co najmniej:
polityka dozwolonych licencji – wewnętrzna lista licencji open source i modeli komercyjnych, które mogą być stosowane w projektach komercyjnych (np. wykluczenie AGPL przy SaaS B2B),
weryfikacja kompatybilności licencji – sprawdzenie, czy połączenie kilku komponentów (np. różne biblioteki front‑end i back‑end) nie tworzy konfliktu licencyjnego,
spójność ze scenariuszem użycia – inne ryzyka licencyjne generuje system wewnętrzny używany przez jedną firmę, a inne produkt white‑label sprzedawany wielu podmiotom,
kontrola wersji narzędzi – część licencji zmienia się między wersjami; aktualizacja do nowego major release’u może pociągnąć za sobą ostrzejsze warunki,
wykluczenie „nieznanego pochodzenia” – zakaz wciągania do kodu komponentów bez jasno określonej licencji (np. „znalezione na GitHub Gist”).
Jeżeli software house pozostawia wybór bibliotek w pełni „swobodny” programistom, bez wspólnego standardu licencyjnego, ryzyko niespójności i ukrytych naruszeń rośnie z każdym nowym modułem.
Proces zarządzania komponentami open source (OSS)
Open source jest dziś standardem, ale wymaga kontrolowanego użycia. Software house odpowiada za stworzenie i utrzymanie procesu, który pozwala identyfikować, zatwierdzać i aktualizować komponenty OSS wykorzystywane w projektach klientów.
Przyzwoity proces OSS po stronie wykonawcy powinien obejmować:
rejestr komponentów – narzędzia typu Software Composition Analysis (SCA) lub przynajmniej centralna lista bibliotek z przypisanymi licencjami,
procedurę zatwierdzania nowych komponentów – mechanizm, który wymaga świadomej akceptacji nowej biblioteki o bardziej restrykcyjnej licencji (np. przez osobę prawną lub architekta),
monitoring podatności i zmian licencji – regularne skanowanie projektu pod kątem nowych wersji, CVE i istotnych zmian warunków licencyjnych,
zasady usuwania / zastępowania komponentów – opisany proces, co zrobić, gdy wykryty zostanie komponent nieakceptowalny licencyjnie (np. zakazany typ copyleft) lub podatny krytycznie,
przygotowanie SBOM – możliwość wygenerowania Software Bill of Materials dla klienta przy przekazaniu produktu lub na potrzeby audytu.
Jeżeli software house nie jest w stanie w rozsądnym czasie powiedzieć, jakich bibliotek OSS użyto w projekcie i na jakich licencjach, trudno mówić o dochowaniu należytej staranności po jego stronie.
Konfiguracja i legalne użycie narzędzi dostarczanych przez software house
Często software house wykorzystuje swoje własne subskrypcje (IDE, systemy CI/CD, monitoring, test management) także w projektach dla klientów. Wtedy to on odpowiada za zgodność korzystania z warunkami licencji tych narzędzi.
Obszary, które powinny być pod kontrolą wykonawcy:
liczba użytkowników i instancji – licencje przypisane do konkretnych stanowisk, serwerów buildowych, agentów CI muszą odpowiadać faktycznemu użyciu,
rodzaj użycia – część narzędzi ma inne warunki dla użytku niekomercyjnego/open source, a inne dla usług świadczonych odpłatnie na rzecz klientów,
separacja projektów – brak „przenikania” licencji przeznaczonych dla jednego klienta do prac dla innego (np. wspólny serwer licencji do narzędzia, na które zapłacił konkretny klient),
zarządzanie kontami i dostępami – zakaz współdzielenia kont osobistych przez wielu programistów lub podwykonawców, jeśli licencja tego zabrania.
Jeżeli audyt wykaże, że software house masowo nadużywa własnych licencji narzędziowych, trudno będzie obronić tezę, że klient miał wpływ na ten sposób pracy – odpowiedzialność będzie wprost po stronie wykonawcy.
Szkolenie zespołów i polityki wewnętrzne dotyczące licencji
Nawet najlepsze regulaminy wewnętrzne nie zadziałają, jeśli zespół nie rozumie, co jest dopuszczalne, a co stanowi naruszenie. Software house, który świadomie zarządza ryzykiem, buduje podstawową świadomość licencyjną wśród programistów, DevOpsów i PM‑ów.
Elementy, które powinny znaleźć się w standardzie organizacyjnym:
proste zasady „co wolno, czego nie wolno” – np. zakaz korzystania z bibliotek bez jawnej licencji, zakaz kopiowania kodu z losowych repozytoriów bez weryfikacji,
krótkie szkolenia wdrożeniowe – minimum raz na wejściu nowej osoby do projektu lub do firmy, z przykładami typowych naruszeń,
kanał konsultacji – jasno wskazana osoba lub zespół (np. architekt, prawnik), do którego można zgłosić wątpliwość przed użyciem nowego narzędzia,
polityka pracy z AI i generatorami kodu – zasady wstawiania generowanego kodu do repozytorium klienta, w tym ograniczenia wynikające z warunków korzystania z narzędzia AI.
Jeżeli jedyną „polityką licencyjną” w software house jest nieformalna wiedza kilku seniorów, organizacja de facto nie zarządza ryzykiem – funkcjonuje na zasadzie przypadku.
Dokumentowanie decyzji licencyjnych w projekcie
Przy sporach i audytach kluczowe jest nie tylko to, co zrobiono, ale też co zostało udokumentowane. Software house powinien prowadzić ślad decyzyjny związany z użyciem istotnych narzędzi, bibliotek i usług.
Praktyczny zestaw dokumentów po stronie wykonawcy to zazwyczaj:
lista głównych komponentów i narzędzi – z oznaczeniem typu licencji, linkiem do warunków i informacją, kto je zatwierdził,
protokół „wyjątków” – osobny rejestr decyzji o zastosowaniu komponentów o podwyższonym ryzyku (np. copyleft, nietypowe regulaminy SaaS),
notatki z konsultacji z klientem – krótkie podsumowania spotkań, na których omawiano konkretne wybory narzędziowe i ich ryzyka,
snapshot regulaminów – archiwizowanie wybranych regulaminów SaaS/API w dacie rozpoczęcia korzystania (printscreen/PDF), tak aby w razie sporu można było odtworzyć ich treść.
Jeżeli decyzje narzędziowe zapadają jedynie „na Slacku” bez odpowiedniej archiwizacji, po kilku miesiącach trudno będzie wykazać, kto i na jakiej podstawie zaakceptował konkretne ryzyko licencyjne.
Minimalizacja vendor lock‑in z perspektywy prawnej
Vendor lock‑in jest nie tylko problemem technicznym. W wielu przypadkach to warunki licencyjne i regulaminy usług powodują, że migracja z danego rozwiązania staje się prawnie skomplikowana lub kosztowna. Software house, projektując architekturę, powinien zidentyfikować takie punkty.
W praktyce oznacza to m.in.:
świadome użycie komponentów „fundamentalnych” – narzędzia, od których zależy możliwość działania całego produktu (np. silnik bazy danych, kluczowy serwis SaaS), wymagają dokładniejszej analizy licencyjnej niż „drobne” biblioteki pomocnicze,
ocenę ograniczeń eksportu danych – część dostawców SaaS utrudnia lub formalnie ogranicza masowe eksportowanie danych w formatach użytecznych poza ich platformą,
sprawdzenie klauzul o opłatach za migrację – niektórzy dostawcy zastrzegają dodatkowe opłaty za dostęp do narzędzi migracyjnych lub extended support przy wyjściu,
zaplanowanie „warstwy izolacji” – np. własny adapter do zewnętrznego API, aby przy ewentualnej zmianie dostawcy wymiana była możliwa bez naruszania licencji oryginalnych komponentów.
Jeżeli software house buduje produkt całkowicie zależny od jednego dostawcy pod kątem prawnym i technicznym, bez sygnalizowania tego klientowi, odpowiedzialność za skutki takiego lock‑inu nie będzie mogła zostać w całości przerzucona na zlecającego.
Zarządzanie podwykonawcami i ich licencjami
Wiele software house’ów korzysta z podwykonawców: freelancerów, mniejszych zespołów, firm specjalistycznych. Z punktu widzenia klienta to software house odpowiada za ich działania, również w obszarze legalności narzędzi.
Minimalny zestaw mechanizmów kontrolnych wobec podwykonawców to zazwyczaj:
umowy obejmujące prawa autorskie i licencje – jasne zobowiązanie podwykonawcy, że dostarczany kod i narzędzia nie naruszają praw osób trzecich oraz że ma on prawa do ich udzielania dalej,
obowiązek stosowania polityki OSS wykonawcy – podwykonawca nie może dowolnie wciągać do projektu komponentów spoza zatwierdzonej listy,
prawo audytu – możliwość zażądania listy użytych bibliotek/narzędzi i ich licencji, a w projektach o wyższym ryzyku także dostępu do repozytoriów,
wyraźne zakazy – np. zakaz korzystania z „pękniętych” narzędzi, kont testowych do użycia komercyjnego, triali w projektach komercyjnych.
Jeżeli software house nie kontroluje sposobu pracy swoich podwykonawców, a jednocześnie firmuje projekt własną marką, klient ma pełne prawo oczekiwać, że to wykonawca poniesie konsekwencje ewentualnych naruszeń.
Reagowanie na zgłoszenia naruszeń i incydentów licencyjnych
Ryzyko naruszeń licencji nigdy nie da się wyeliminować do zera. Istotne jest, jak software house reaguje, gdy sygnał o potencjalnym problemie już się pojawi – czy to od klienta, dostawcy narzędzia, czy w wyniku własnego audytu.
Skuteczna reakcja po stronie wykonawcy powinna obejmować co najmniej:
szybką wstępną kwalifikację – określenie, czy zgłoszenie dotyczy elementu krytycznego (np. komponent w kluczowej ścieżce użytkownika) czy marginalnego,
tymczasowe środki ograniczające ryzyko – zawieszenie wdrażania nowego modułu, wyłączenie spornego komponentu w środowisku testowym, ograniczenie zasięgu użycia,
przejrzystą komunikację z klientem – informację o skali problemu, możliwych konsekwencjach oraz wariantach rozwiązań, wraz z orientacyjną wyceną czasu i kosztów,
korektę procesów wewnętrznych – aktualizację polityk i szkoleń, jeżeli incydent ujawnił lukę systemową (np. brak kontroli nad jednym typem narzędzi).
Jeśli software house ignoruje sygnały o naruszeniach, przeciąga temat lub bagatelizuje ryzyko przed klientem, trudno będzie potem dowodzić, że dochował profesjonalnej staranności branżowej.
Wkład w kształt zapisów umownych dotyczących licencji
Choć tekst umowy ostatecznie negocjują prawnicy po obu stronach, to software house powinien wnosić do tych negocjacji realną wiedzę operacyjną: jakie narzędzia są planowane, jakie licencje generują ryzyko i jak rozłożyć odpowiedzialność za ich legalność.
W praktyce oznacza to m.in.:
dostarczanie materiału do załączników technicznych – listy klas narzędzi (np. typy usług chmurowych, kategorie OSS), które będą używane wraz z opisem typowych modeli licencyjnych,
wskazywanie granic odpowiedzialności – np. zapisy, że software house odpowiada za legalność narzędzi, które sam wybiera i opłaca, a klient – za środowisko i licencje, które on dostarcza,
propozycje mechanizmów współdzielenia ryzyka – np. procedura podejmowania decyzji o zmianie narzędzi w razie nieakceptowalnej zmiany regulaminu po stronie dostawcy SaaS,
realistyczne oświadczenia i gwarancje – unikanie klauzul typu „pełna czystość licencyjna w każdych okolicznościach” bez ograniczeń czasowych i finansowych.
Jeżeli software house akceptuje skrajnie szerokie klauzule odpowiedzialności bez odniesienia do faktycznego modelu pracy i stosu narzędzi, w razie sporu może się okazać, że przejął na siebie ryzyko, którym realnie nie mógł zarządzać.
Najczęściej zadawane pytania (FAQ)
Kto formalnie odpowiada za legalność oprogramowania przy outsourcingu IT – klient czy software house?
Co do zasady, z punktu widzenia prawa autorskiego odpowiada ten, kto korzysta z oprogramowania w swojej działalności – czyli najczęściej klient jako właściciel produktu i podmiot czerpiący z niego korzyści. To on jest „na widoku” wobec właścicieli praw, organizacji zbiorowego zarządzania czy dostawców SaaS.
Jednocześnie w umowie outsourcingowej można (i trzeba) przenieść część odpowiedzialności na software house. Typowy model: software house gwarantuje, że dobierane przez niego narzędzia są legalne i zapewnia odszkodowanie (indemnity), jeśli to jego błąd licencyjny wygeneruje roszczenia. Punkt kontrolny: sprawdź w kontrakcie, czy jest wprost zapisane, kto „gwarantuje legalność narzędzi” i kto pokrywa koszty roszczeń.
Jak rozpisać w umowie odpowiedzialność za licencje między klientem, software house’em i podwykonawcami?
Minimum to czytelna „mapa odpowiedzialności” od klienta aż po ostatniego freelancera. W praktyce oznacza to: w umowie głównej (klient–software house) wskazujesz, kto dobiera narzędzia, kto je weryfikuje pod kątem licencji i kto odpowiada za szkody wobec klienta. W umowach z podwykonawcami software house kopiuje te obowiązki dalej – tak, aby łańcuch odpowiedzialności się nie urywał.
Lista kontrolna do umowy:
kto ma obowiązek dokumentowania użytych narzędzi i licencji,
kto ponosi koszty refaktoringu, gdy narzędzie okaże się nielegalne lub niewłaściwie licencjonowane,
kto zapewnia audyt legalności u podwykonawców,
jakie są limity odpowiedzialności finansowej (cap) za naruszenia licencyjne.
Jeśli po lekturze umowy nie potrafisz w 30 sekund narysować tej mapy ról, to sygnał ostrzegawczy – zapisy są zbyt ogólne.
Jak w praktyce ustalić, kto zatwierdza nowe narzędzia i biblioteki w projekcie?
Dobrą praktyką jest przypisanie trzech ról: (1) kto inicjuje użycie nowego narzędzia (np. developer, DevOps, architekt), (2) kto weryfikuje licencję pod kątem komercyjnego użycia (zwykle software house + prawnik po stronie klienta przy kluczowych komponentach), (3) kto ostatecznie zatwierdza narzędzie i bierze odpowiedzialność kontraktową (np. CTO klienta lub wskazana osoba po stronie software house’u).
Warto to opisać nie tylko w umowie, ale też w procedurze projektowej: np. „żadna nowa biblioteka w core systemu nie wchodzi bez akceptacji X i adnotacji w repozytorium / rejestrze narzędzi”. Jeśli w czasie warsztatu kick-off nikt nie umie odpowiedzieć, kto pełni te trzy role, masz jasny sygnał ostrzegawczy: projekt startuje bez kontroli nad ryzykiem licencyjnym.
Jakie są najczęstsze problemy z legalnością narzędzi w projektach z software house’em?
Najbardziej typowe problemy to: użycie OSS z licencją copyleft (np. AGPL) niezgodnie z modelem dystrybucji produktu, przekroczenie limitów licencji (liczba użytkowników, instancji, środowisk), brak ważnej subskrypcji na kluczowe komponenty SaaS lub naruszenie warunków EULA przy modyfikacjach. Często wychodzi to dopiero przy audycie prawnym tuż przed wdrożeniem.
Konsekwencje są kosztowne: przestoje wdrożeniowe, przymusowy refaktoring i wymiana bibliotek w rdzeniu systemu, pośpieszne dokupowanie licencji „na wczoraj” albo trwałe ograniczenia strategii produktu. Jeśli przy planowaniu releasu pojawia się nagły spór „kto płaci za usunięcie tej biblioteki”, to oznacza, że mapa odpowiedzialności była źle zdefiniowana od początku.
Czy klient może całkowicie przerzucić odpowiedzialność za legalność narzędzi na software house?
W praktyce – nie w 100%. Można mocno obciążyć software house kontraktowo (gwarancje, odszkodowanie, obowiązki audytu), ale wobec właścicieli praw klient i tak pozostaje kluczowym adresatem roszczeń, bo to on eksploatuje system komercyjnie. Model „to problem dostawcy” kończy się zwykle późniejszymi sporami i trudnymi regresami.
Bezpieczniejszy model to podział ról: software house odpowiada za prawidłowy dobór, weryfikację i dokumentowanie narzędzi, a klient za nadzór, świadome akceptowanie ryzyk (np. przy narzędziach wymuszonych przez jego wewnętrzne standardy) i reagowanie na sygnały ostrzegawcze z audytów. Jeśli klient nie ma w ogóle żadnych punktów kontrolnych po swojej stronie, zostaje „ślepy” na ryzyka, które uderzają przede wszystkim w jego reputację i biznes.
Jak ograniczyć ryzyko licencyjne przy pracy z podwykonawcami i freelancerami w projekcie IT?
Podstawą jest spójny łańcuch umów i wiążące procedury narzędziowe. Każdy podwykonawca i freelancer powinien mieć w umowie: zakaz używania narzędzi bez zgodności z polityką licencyjną projektu, obowiązek zgłaszania nowych narzędzi do zatwierdzenia oraz odpowiedzialność za szkody wynikające z użycia oprogramowania sprzecznego z licencją. Dodatkowo przy większych projektach rozsądny jest okresowy audyt legalności u kluczowych podwykonawców.
Przykład z praktyki: freelancer „z przyzwyczajenia” wykorzystał bibliotekę z licencją niekompatybilną z modelem SaaS klienta. Brak procedury zgłaszania narzędzi sprawił, że problem wyszedł dopiero na etapie negocjacji z inwestorem. Gdyby od początku istniał obowiązek rejestracji bibliotek i krótkiej weryfikacji licencji przy każdym merge’u do głównej gałęzi, ryzyko byłoby wychwycone na etapie kod review.
Jakie zapisy w umowie outsourcingu IT są kluczowe z perspektywy legalności oprogramowania?
Po stronie prawa autorskiego i licencji kluczowe są przynajmniej: precyzyjne określenie, kto zapewnia legalność narzędzi i ponosi odpowiedzialność za naruszenia, opis procesu zatwierdzania nowych komponentów, obowiązek dokumentowania stacku technologicznego oraz zasady postępowania w razie wykrycia naruszenia (kto inicjuje audyt, w jakim czasie usuwa nielegalny komponent, kto pokrywa koszty refaktoringu i opóźnień).
Dobrze, jeśli umowa wskazuje też limity odpowiedzialności, ale z wyłączeniem rażącego niedbalstwa w obszarze praw autorskich, oraz reguluje, kto jest zobowiązany do współpracy przy ewentualnym sporze z właścicielem praw (np. przekazanie dokumentacji, logów, potwierdzeń zakupionych licencji). Jeśli tych punktów brakuje albo są opisane jednym, ogólnym zdaniem, to mocny sygnał ostrzegawczy przed podpisaniem kontraktu.
