Korzystanie z generatywnej AI przy tworzeniu gry wideo

Korzystanie z generatywnej AI przy tworzeniu gry wideo

Czytaj: 8 min

Wiele mówi się o nadchodzących regulacjach dotyczących korzystania z systemów AI. Sporo uwagi poświęca się również sporom sądowym między właścicielami praw własności intelektualnej a spółkami trenującymi modele na treściach chronionych tymi prawami. Znacznie mniej uwagi poświęca się natomiast bardziej przyziemnym wyzwaniom prawnym i organizacyjnym wynikającym z korzystania z systemów AI służących do generowania treści syntetycznych.

W tym artykule skupię się na dwóch takich wyzwaniach:

  • braku praw własności intelektualnej do wyników, treści syntetycznych – wygenerowanych przez systemy generatywnej AI;
  • ryzyku naruszenia praw własność intelektualnej przez korzystanie z treści syntetycznych.

Treści syntetyczne nie są własnością intelektualną

Źródłem pierwszego z tych wyzwań jest to, że zasadniczo treści syntetycznych generowanych przez systemy AI nie uważa się za własność intelektualną. Przede wszystkim nie uważa się ich za utwory chronione prawem autorskim, bo to one są przytłaczającą większością własności intelektualnej w grach wideo [1]. Nie ma znaczenia, czym jest wynik – grafiką, muzyką, kodem źródłowym, czy tekstem. Jednym słowem, gdyby system AI wygenerował na podstawie promptu całą grę wideo, taka gra w ogóle nie będzie własnością intelektualną. Jeśli w grze będą elementy, które zostały tak wygenerowane, to tylko te elementy nie będą własnością intelektualną.

Dlaczego tak się uważa? Głównym argumentem jest brak wpływu człowieka na postać treści syntetycznej, a nawet wiedzy o przebiegu procesu jej generowania [2]. Takiego wpływu nie mają ani osoby trenujące lub dostrajające model AI ani te, które napisały oprogramowanie służące do korzystania z systemu AI. Przeważnie takiego wpływu nie ma też osoba, która wydała polecenie wygenerowania danej treści – napisała prompt. Oczywiście niewykluczone są przypadki promptów tak rozbudowanych i precyzyjnych, że dających autorowi na tyle duży wpływ na postać treści, że uznamy ją za naturalną (stworzoną przez człowieka) a nie syntetyczną [3]. Jednak taki wysiłek nie zawsze będzie uzasadniony, na przykład gdy chodzi o możliwie szybkie wygenerowanie zestawu concept artów. Nie każdy użytkownik oprogramowania będzie też chciał taki wysiłek podjąć, zwłaszcza jeśli „prosty” prompt przyniesie zadowalający rezultat [4].

Korzystanie z systemu generatywnej AI w tworzeniu gry wideo może znacząco zmienić zakres ilość własności intelektualnej w grze. Dotychczas bowiem gra wideo składała się niemal wyłącznie z własności intelektualnej – zwłaszcza utworów będących programami komputerowymi, modelami 3D, teksturami, ikonami, tekstem dialogów i opisów, muzyką, dźwiękiem lub assetami innego rodzaju. Oczywiście w przepisach prawa autorskiego nie ma domniemania, że coś jest utworem – jest to fakt, który musi zostać udowodniony. Jednak zazwyczaj nie stanowi to problemu, gdyż poprzeczka spełnienia przesłanek oryginalności oraz indywidualnego charakteru jest zawieszona dość nisko [5]. Poza tym prawa autorskie powstają automatycznie, ani twórca ani studio nie musi dokonać żadnych formalności. Dlatego w praktyce niemal wszystko co tworzyli artyści, programiści, kompozytorzy, czy pisarze uznawało się za własność intelektualną – utwory chronione prawem autorskim – także szkicowane „na szybko” grafiki koncepcyjne.

Teraz dochodzą dwie dodatkowe możliwości. Po pierwsze, brak własności intelektualnej do assetów w całości wygenerowanych przez system AI. Po drugie, własność intelektualna do fragmentów assetów tworzonych z pomocą systemu AI – treści wspomagane przez AI (AI-assisted output). W tym przypadku prawa autorskie mogą powstać, o ile wkład wniesiony przez człowieka jest twórczy. Tu oczywiście powstaje pytanie, co jest takim twórczym wkładem? Zaprojektowanie nowego modelu twarzy postaci wygenerowanej przez AI – pewnie tak. Usunięcie szóstego palca w takim modelu postaci, korekta kolorystyki tekstury – pewnie nie. Te części wyniku wygenerowanego przez system AI, które zostały „dotknięte” działalnością twórczą stają się własnością intelektualną. Te części, które nie zostały przerobione, własnością intelektualną nie będą.

Dobry przykład podsunęła spółka Ubisoft, producent i wydawca gry „Anno 117: Pax Romana”. Niektóre ilustracje do ekranów ładowania gry zostały przynajmniej w części wygenerowane przez system AI. Świadczyły o tym typowe dla takich systemówa błędy, zwłaszcza w przedstawianiu rąk postaci (przykład poniżej) [6]. Ostatecznie błędy te zostały poprawione, nie wiemy czy przez ludzi czy przez AI, lecz nawet w tym pierwszym przypadku takie poprawki trudno uznać za mające charakter twórczy [7].

"Korzystanie

Co w praktyce dla studia oznacza brak praw własności intelektualnej? Jeżeli asset jest chronionymi prawami autorskimi to zasadniczo nie można go używać bez zgody studia np. wykorzystać w swojej grze lub zamieścić na stronie internetowej. Po drugie, nabycie praw autorskich przez studio od pracownika jest podstawą do zastosowania podniesionych kosztów uzyskania przychodów (KUP 50%). Poza tym, sprzedaż takich praw albo udzielanie licencji pozwala na rozliczanie części przychodu na zasadach określonych w IP Box. Dotąd najczęstszym problemem było niepełne nabycie praw przez studio albo brak ich nabycia od twórcy np. jakieś assety graficzne zostały pominięte w umowie albo umowa została nieprawidłowo sformułowana [8].

W przypadku assetów generowanych przez system AI nie ma ani praw wyłącznych ani możliwości zastosowania ulg podatkowych, które wymagają istnienia takich praw [9]. Jeżeli okoliczności nie pozwolą na sięgnięcie po inne narzędzia prawne niż prawo własności intelektualnej, np. przepisy o zwalczaniu nieuczciwej konkurencji, oznacza to możliwość korzystania przez innych z niechronionych assetów studia, także ich przerabiania. Jednym słowem, jeżeli cała gra zostałaby wygenerowana przez system AI, to korzystanie z niej nie wymagałoby licencji od studia.

Istnieją dwa sposoby na zachowanie wyłączności przynajmniej dla niektórych assetów wygenerowanych przez system AI:

  • zachowanie ich w tajemnicy i ochrona jako tajemnica przedsiębiorstwa studia – dotyczy to zwłaszcza kodu źródłowego gry, przynajmniej w tym zakresie w jakim nie składa się z oprogramowania udostępnianego przez dostawców np. silnika gry. Jako tajemnicę przedsiębiorstwa można też traktować niektóre, szczególnie bardziej rozbudowane, prompty lub serie promptów;
  • zarejestrowanie jako znak towarowy – dotyczy to z kolei tylko tych assetów, które będą używane do identyfikacji gry.

Jak więc studio może sobie poradzić z tym wyzwaniem? W procesie zarządzania assetami studio powinno wprowadzać opcję ich oznaczania jako (i) stworzonych przez człowieka (treści naturalne); (ii) całkowicie wygenerowanych przez system AI (treści syntetyczne) oraz (iii) wygenerowanych przez system AI przynajmniej w istotnej części (treści wspomagane przez AI). Informacji powinni dostarczać pracownicy, współpracownicy oraz podwykonawcy. To z kolei może wymagać aktualizacji regulaminów pracowniczych oraz umów ze współpracownikami i podwykonawcami.

Treści syntetyczne nie powinny być oczywiście raportowane w programach KUP 50%. Co do treści wspomaganych przez AI, studio powinno sprawdzić rodzaj i zakres tego wspomagania, żeby wykluczyć przypadki, gdy wkład pracownika w postać treści nie miał charakteru twórczego. Studio powinno się też zastanowić, czy ewentualna zmiana w charakterze pracy danego pracownika – dostarczanie treści syntetycznych kosztem treści naturalnych wymaga ponownej analizy udziału honorarium autorskiego w całości wynagrodzenia pracownika.

Korzystanie z treści syntetycznych może naruszać prawa własności intelektualnej

Drugim istotnym wyzwaniem korzystania z systemów AI do generowania assetów jest ryzyko naruszenia praw własności intelektualnej osób trzecich. Treści syntetycznej wygenerowanej przez system AI przeważnie nie uważa się za własność intelektualną, jednak ta treść może zawierać własność intelektualną osób trzecich – grafikę, kompozycję, tekst lub ich fragment – choćby w postaci nieco zmodyfikowanej niż oryginał.

W przypadku tworzenia assetów przez pracowników studia wiedzą oni skąd biorą poszczególne elementy, np. wzorując się na cudzych treściach, i powinni kontrolować, żeby ostateczny efekt ich pracy nie zawierał twórczych fragmentów cudzych treści. W przypadku wyniku generowanego przez system AI wiemy, że na pewno w jakimś stopniu korzysta ono z wcześniejszej twórczości, ale nie wiemy jak bardzo. Może być to trudne do ustalenia zwłaszcza w przypadku kodu źródłowego. Oczywiście niektóre prompty rodzą wyższe ryzyko skorzystania z cudzej twórczości np. gdy prompt nawiązuje do znanej postaci popkultury. Cudza własność intelektualna to jednak nie tylko bardzo znane i popularne postacie, ale mnóstwo twórczości fanowskiej albo dzieł niszowych artystów, na których modele AI zostały wytrenowane [10]. Ujmując rzecz obrazowo, dla osób obeznanych z branżą gier wideo prompt „wygeneruj obraz z postacią włoskiego, wąsatego hydraulika”, jest oczywiście problematyczny, ale dla innych osób – neutralny.

Kluczowe ryzyko korzystania z treści zawierających cudzą własność intelektualną polega na tym, że uprawniony może żądać od studia jej usunięcia z gry. Nie ma znaczenia, że może to być element używany do promocji gry, albo, że „wyciągnięcie” elementu z gry nie jest łatwe. Nie ma też znaczenia, czy studio wiedziało, że korzystanie z tego elementu może naruszać cudze prawa albo czy studio dołożyło należytej staranności w sprawdzaniu tej kwestii [11]. Jak zmniejszyć opisywane ryzyko?

  • Unikać formułowania takich promptów, które mogą prowadzić do korzystania z cudzej własności intelektualnej, zwłaszcza polecenia wzorowania się np. na projektach orków z „World of Warcraft” albo „rycerzy Jedi”.
  • Jeśli to możliwe, ustawić w oprogramowaniu filtry blokujące użycie w treści syntetycznej cudzej własności intelektualnej. Różne programy mogą mieć filtry działające z różną skutecznością, ich skuteczność może się zresztą zmieniać w czasie.
  • Sprawdzać treści wygenerowane przez system AI – zwłaszcza kluczowe assety albo takie assety, które trudno podmienić po premierze gry. Można to zrobić chociażby przez reverse searching.
  • Używać systemu AI wykorzystującego model trenowany wyłącznie na własnych materiałach lub danych należących do domeny publicznej.

Niektórzy dostawcy systemów AI zobowiązują się do wzięcia na siebie zaspokojenia roszczeń osób trzecich z tytułu naruszenia ich praw własności intelektualnej przez korzystanie z treści wygenerowanych przez AI. Jest to jednak rozwiązanie tylko części potencjalnych problemów. Po pierwsze, nie jest ono oferowane przez każdego dostawcę. Po drugie, warunkiem dla tego zobowiązania jest stosowanie się przez studio do warunków określonych w regulaminie danego dostawcy, w tym określonego ustawienia filtrów treści i formułowania promptów [12]. Po trzecie, zaspokojenie roszczeń dotyczy zwykle tylko roszczeń pieniężnych, a więc np. zapłaty odszkodowania na rzecz uprawnionego a nie wspomnianego wcześniej obowiązku zaniechania naruszeń. Po czwarte, regulaminy dostawców nierzadko są zmieniane, studio nie ma więc pewności, że takie zobowiązanie będzie obowiązywało wszystkie assety powstające w toku produkcji gry.

Korzystanie z systemów generatywnej AI – co warto uzgodnić w umowach?

Faktyczne zmniejszenie ryzyka prawnego wynikającego z przedstawionych wyżej wyzwań jest skuteczne o tyle, o ile zespół (pracownicy i współpracownicy) oraz podwykonawcy będą stosować zasady uzgodnione ze studiem. Dlatego warto te zasady odzwierciedlić w umowach – proponujemy zwłaszcza postanowienia dotyczące następujących kwestii:

  • zgoda studia na używanie systemów AI – w ogóle albo systemów lub oprogramowania spoza uzgodnionej listy. Oczywiście różne zasady można przewidzieć dla tworzenia materiałów roboczych i tych, które zostaną włączone do gry [13];
  • korzystanie z systemów AI na takich licencjach, które nie zawierają ograniczeń korzystania z wygenerowanych treści ani „własności” tych treści po stronie dostawcy;
  • zapewnienie kompetencji posługiwania się systemami AI przez ludzi, którzy z niego korzystają. Studio powinno zapewnić jego przestrzeganie zarówno u siebie, jak i u podwykonawców – jeśli korzystają z systemów AI na potrzeby studia. Do studia należy decyzja jak te wymagania spełnić, np. przez szkolenia lub zapoznanie się z materiałami dostarczonymi przez dostawców systemów AI [14];
  • zobowiązanie do stosowania określonych ustawień i filtrów oprogramowania, zwłaszcza jeśli pozwalałoby to korzystać z takich zobowiązań jak „Copilot Copyright Commitment”;
  • oznaczanie treści wygenerowanych przez system AI, a w przypadku treści wspomaganych przez AI –roli człowieka w ich stworzeniu;
  • sprawdzanie czy treści wygenerowane przez system AI zawierają własność intelektualną osób trzecich. Oczywiście tam gdzie jest to potrzebne ta weryfikacja powinna obejmować inne aspekty np. dokładność, spójność tłumaczenia tekstu z oryginałem, czy zgodność z faktami wygenerowanych informacji;
  • jeśli to możliwe i potrzebne objęcie promptów tajemnicą przedsiębiorstwa i wyłączności w korzystaniu z nich dla studia;
  • zasady używania materiałów przekazanych przez studio do generowania treści przez system AI np. wykluczenie zezwalania dostawcom lub ich kontrahentom na wykorzystywanie materiałów studia do trenowania modeli AI.

Propozycje takich postanowień umownych zamieściliśmy w prezentacji z konferencji Game Industry Conference, która jest dostępna do pobrania pod tym linkiem.

Jak możemy pomóc w omawianym zakresie?

  • zaproponujemy modyfikacje regulaminów pracy lub przygotujemy dla studia politykę korzystania z systemów generatywnej AI;
  • doradzimy zmiany w procedurach programu KUP 50% lub korzystania z ulg podatkowych wymagających istnienia praw własności intelektualnej;
  • przygotujemy aneksy do umów z członkami zespołu i dostawcami, w razie potrzeby będziemy reprezentować studio w negocjacjach;
  • przeanalizujmy regulaminy dostawców systemów AI używanych przez studio i wyjaśnimy ewentualne ryzyka;
  • przeszkolimy zespół studia w zakresie takiego korzystania z systemów generatywnej AI, które pozwoli zminimalizować opisane wyżej ryzyka prawne.

Przypisy:

[1] Zgodnie z art. 1 ust. 1 PrAut utworem jest przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia. Więcej o utworach w grach wideo pisałem w poradniku „Własność intelektualna w branży gier wideo”, dostępnym na stronie internetowej Urzędu Patentowego RP, https://uprp.gov.pl/sites/default/files/2023-04/Własność%20intelektualna%20w%20branży%20gier%20wideo.PDF.

[2] Chodzi tutaj o tzw. black box systemów AI, czyli brak przejrzystości działania modelu wykorzystywanego do generowania treści.

[3] Z. Okoń podaje w tym kontekście przykład wygenerowania w programie Midjourney „fotografii”, której parametry wykonania zostały szczegółowo określone https://cyberprawo.org/midjourney-mozna-stworzyc-utwor/ [dostęp: 5.5.2026 r.] Podobne stanowisko zajął Sąd Rejonowy w Monachium w sprawie dotyczącej logo wygenerowanych przez system AI. Wyrok Amtsgericht München  13 lutego 2026 r. (sygn. 142 C 9786/25), https://www.gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2026-N-1513?hl=true [dostęp: 5.5.2026 r.].

[4] Tym bardziej więc sytuacje odmienne warto dokumentować zachowaniem oryginalnego promptu.

[5] Przykładem zbyt liberalnego podejścia do spełnienia tych przesłanek jest wyrok Sądu Najwyższego z dnia 6 marca 2014 r. (sygn. V CSK 202/13), w którym za utwór uznano projekt dość prostego znicza. Cylindryczna obudowa koloru czerwonego i pokrywa koloru złotego z geometrycznym ornamentem.

[6] Źródło: https://imgur.com/a/urdnIZk, https://www.pcgamer.com/games/city-builder/ubisoft-touches-up-ai-art-placeholder-that-slipped-into-anno-117-but-fans-are-not-happy-it-was-there-to-begin-with-of-all-the-video-games-not-anno/ [dostęp: 18.11.2025 r.].

[7] Pomijam inne różnice między tymi dwoma postaciami, których wprowadzenie nie miało związku z poprawianiem błędu.

[8] Nieraz te problemy są odkrywane podczas due dilligence studia.

[9] Dyrektor Krajowej Izby Skarbowej potwierdził, że brak praw autorskich do grafik wygenerowanych przez oprogramowanie AI przekłada się na niemożność kwalifikowania przychodu z ich sprzedaży jako przychód z tytułu praw autorskich. Pismo Dyrektora KIS z dnia 29 kwietnia 2025 roku (0115-KDIT1.4011.190.2025.1.MN).

[10] Stosowanie odpowiednich ustawień filtrów w oprogramowaniu AI zmniejsza a nie wyklucza możliwość odzwierciedlenia w wygenerowanej treści cudzej własności intelektualnej.

[11] Przynajmniej w prawie polskim może to mieć znaczenie dla ewentualnej odpowiedzialności odszkodowawczej, ale nie dla obowiązku zaniechania naruszeń.

[12] https://blogs.microsoft.com/on-the-issues/2023/09/07/copilot-copyright-commitment-ai-legal-concerns/.

[13] Spółka Ubisoft tłumaczyła „niedoskonałości” wspomnianych wcześniej ilustracji wygenerowanych przez program AI tym, że były to wersje, które nie miały znaleźć się w ostatecznej wersji gry, pełniły rolę tzw. placeholderów.

[14] Obowiązek posiadania takich kompetencji – AI literacy wynika z art. 4 Aktu w sprawie sztucznej inteligencji.

Napisz do autora:

dr Marcin Balicki SPCG

dr Marcin Balicki

adwokat
Counsel

Ustawowe prawo odstąpienia od umowy wdrożeniowej – cz. 2

Ustawowe prawo odstąpienia od umowy wdrożeniowej – cz. 2

Czytaj: 5 min

W pierwszej części publikacji dotyczącej ustawowego prawa odstąpienia od umowy wdrożeniowej szeroko omówiliśmy zasady korzystania przez strony z ogólnych podstaw odstąpienia wynikających z Kodeksu Cywilnego (art. 491 § 1, art. 492, art. 492[1] KC).

W części drugiej skupimy się na podstawach szczególnych (art. 631, art. 635, art. 636, art. 640 oraz art. 644 KC), które – tak jak sygnalizowaliśmy w poprzedniej części – przysługują wyłącznie jednej ze stron umowy wdrożeniowej. I tak dostawcy mogą skorzystać z podstawy wynikającej z art.  640 KC, zaś zamawiający z art. art. 631, art. 635, art. 636 oraz art. 644 KC. W niniejszej części opiszemy pokrótce każdą z tych podstaw, w tym przesłanki niezbędne do skorzystania przez stronę z uprawnienia do odstąpienia od umowy.

Uprawnienia przysługujące dostawcom

W praktyce, art. 640 KC to podstawa, na którą wykonawcy powołują się bardzo często. Zgodnie z treścią przepisu: „Jeżeli do wykonania dzieła potrzebne jest współdziałanie zamawiającego, a tego współdziałania brak, przyjmujący zamówienie może wyznaczyć zamawiającemu odpowiedni termin z zagrożeniem, iż po bezskutecznym upływie wyznaczonego terminu będzie uprawniony do odstąpienia od umowy”. Zasadniczo przesłanki te są podobne do tych, które reguluje art. 491 § 1 KC (w kontekście wyznaczenia dodatkowego „odpowiedniego” terminu i uchybieniu temu dodatkowemu terminu). Artykuł 640 KC nie dotyczy jednak zwłoki w wykonania zobowiązania wzajemnego, lecz braku wykonania przez zamawiającego wierzycielskiego obowiązku współdziałania. Nie chodzi tu o każdy brak współdziałania, lecz o brak takiego współdziałania, które jest potrzebne do wykonania dzieła w postaci wdrożonego systemu spełniającego wymagania określone w umowie np. brak zapewnienia przez zamawiającego infrastruktury opisanej przez dostawcę, która uniemożliwia kontynuowanie prac wdrożeniowych.

W razie odstąpienia przez dostawcę od umowy na podstawie art. 640 KC, będzie mógł on domagać się – zgodnie z art. 639 KC – całości wynagrodzenia wynikającego umowy z odliczeniem, jednakże tego, co wykonawca zaoszczędził z powodu niewykonania dzieła (np. koszty angażowania personelu) [1]. Wobec tego zamawiający powinien zawsze zadbać o uwzględnienie w umowie odpowiednich mechanizmów umownych, które umożliwią w pewnym zakresie mitygować ryzyko odstąpienia od umowy przez dostawcę na podstawie art. 640 KC, w tym np. wprowadzenie do umowy katalogu współdziałania (o tym pisaliśmy więcej w poprzednim naszym artykule na blogu dotyczącym kluczowych obszarów w umowach wdrożeniowych) czy obowiązku informowania zamawiającego o sposobie oczekiwanego współdziałania.

Uprawnienia przysługujące zamawiającym

Przepisy szczególne dla umowy o dzieło zawierają kilka przepisów, na podstawie których zamawiający mogą odstąpić od umowy, tj.:

  1. Art. 631 KC – zgodnie z tym przepisem zamawiający może odstąpić od umowy w przypadku podwyższenia wynagrodzenia kosztorysowego na podstawie art. 629 lub art. 630 KC, przy czym: i) odstąpienie powinno zostać dokonane niezwłocznie po podwyższeniu wynagrodzenia; oraz ii) zamawiający powinien zapłacić za dotychczas zrealizowane przez wykonawcę prace. W praktyce wynagrodzenie kosztorysowe nie jest wykorzystywane w umowach wdrożeniowych, dlatego też art. 631 KC jest rzadko stosowany przez zamawiających jako podstawa odstąpienia.
  2. Art. 635 KC – zamawiający może też odstąpić umowy wdrożeniowej, jeżeli dostawca opóźnia się z rozpoczęciem lub realizacją wdrożenia na tyle, że nie jest prawdopodobne, iż zdoła wykonać je w umówionym terminie wynikającym z harmonogramu. Zamawiający nie musi też wyznaczać dostawcy dodatkowego terminu, a odstąpić może przed upływem terminu końcowego realizacji umowy. Istotne jest to, że samo opóźnienie w realizacji danego etapu (np. wykonania analizy) nie zawsze uzasadnia odstąpienie od umowy, zwłaszcza w sytuacji, gdy prace mogą zostać przez dostawcę „nadrobione” w dalszych fazach realizacji projektu (np. dostawca może oddelegować do realizacji projektu dodatkowy personel). Zamawiający musiałby wykazać w takiej sytuacji, że opóźnienie w wykonaniu danego etapu jest na tyle duże, że wykonawca – obiektywnie – nie zrealizuje wdrożenia zgodnie z harmonogramem (tak więc nawet w sytuacji, gdyby zaangażował dodatkowy personel). Jeżeli bowiem okaże się, że opóźnienie nie jest istotne i dostawca mógłby zrealizować prace w terminie (np. nadrabiając je w dalszych etapach projektu) odstąpienie nie wywoła zamierzonych skutków. W praktyce ciężko jest wykazać, że opóźnienie w realizacji etapu jest na tyle istotne, iż uniemożliwi dostawcy wykonanie całego wdrożenia w terminie. Dlatego też rekomendujemy, aby zamawiający bardzo ostrożnie korzystali z tej podstawy prawnej [2].
  3. Art. 636 § 1 KC – jeśli dostawca wykonuje wdrożenie w sposób wadliwy albo sprzeczny z umową, zamawiający może wezwać go do zmiany sposobu wykonania oraz wyznaczyć mu odpowiedni termin. Po bezskutecznym upływie tego terminu zamawiający ma dwie możliwości, tj. i) odstąpić od umowy, albo ii) powierzyć wykonanie wdrożenia osobie trzeciej na koszy i ryzyko dostawy (tzw. wykonanie zastępcze). Co istotne, prawo do odstąpienia powstanie wyłącznie wtedy, gdy zamawiający jest w stanie wykazać, że realizacja prac jest wadliwa albo sprzeczna umową. Samo przeświadczenie zamawiającego o wadliwym wykonywaniu prac jest niewystarczające. Dlatego też istotne jest: (i) w miarę możliwości precyzyjnie określenie wymogów zamawiającego (punkt odniesienia oceny wykonywania wdrożenia) oraz (ii) zapewnienie w umowie mechanizmów, które umożliwiają zamawiającemu wgląd i weryfikację prac, które realizuje dostawca np. wprowadzenie do umowy prawa kontroli jakości prac, z możliwością angażowania specjalistycznego podmiotu trzeciego.
  4. Art. 644 KC – zamawiający ma również prawo odstąpić od umowy w każdej chwili, bez podania przyczyny, jeżeli dzieło nie zostało wykonane (ustawowe odstąpienie „for convenience”). W takim przypadku zamawiający powinien zapłacić dostawcy całość wynagrodzenia za projekt, przy czym zamawiający może odliczyć to, co dostawca zaoszczędził z powodu niewykonania umowy, np. koszty angażowania personelu [3].

Podsumowanie

Zawsze należy dokonać rzetelnej analizy czy okoliczności faktyczne danej sprawy rzeczywiście uzasadniają złożenie oświadczenia o odstąpieniu. Nieprzemyślane działanie, niemające uzasadnienia w faktach, może rodzić dalsze ryzyka, tzn. ryzyko uznania złożonego oświadczenia o odstąpieniu od umowy za bezskuteczne. W przypadku zamawiających złożenie oświadczenia o odstąpieniu, bezskutecznie bazującym na jednej z następujących podstaw: art. 631 KC, 635 KC, 636 § 1 KC, może zostać potraktowane przez sąd jako dokonane na podstawie art. 644 KC [4]. To zaś oznacza, że dostawca zachowa prawo do wynagrodzenia za projekt (stosownie pomniejszonego zgodnie z art. 644 KC). Z kolei bezskuteczne złożenie oświadczenia o odstąpieniu od umowy przez dostawcę może powodować, że umowa pozostanie w mocy, pomimo złożenia oświadczenia o „odstąpieniu”. Jednocześnie w takiej sytuacji oświadczenie o odstąpieniu będzie mógł złożyć zamawiający na podstawie art. 492[1] KC.

Wskutek skorzystania przez stronę z jednego z uprawnień do odstąpienia od umowy, strony są co do zasady zobowiązane są do zwrotu tego, co wzajemnie sobie świadczyły (skutek wsteczny odstąpienia) [5]. Nie zawsze to będzie jednak skutek pożądany przez strony. W pewnych przypadkach tak dostawcy, jak też zamawiającemu będzie zależeć na tym, aby odstąpienie miało skutek na przyszłość. Stąd też w praktyce umów wdrożeniowych rynkowym mechanizmem jest uwzględnienie umownego prawa odstąpienia, które kompleksowo reguluje podstawy jego dokonania i skutki prawne takiej czynności (tj. zasady rozliczeń pomiędzy stronami). Zagadnienie te opiszemy wkrótce w oddzielnym artykule.

Przypisy:

[1] Tak wyrok Sądu Najwyższego z dnia 7 lipca 1999 r., sygn. akt II CKN 426/98. Odmiennie jednak K. Zagrobelny, w: Gniewek, Machnikowski, Komentarz, 2016.

[2] Dużo bardziej optymalnym rozwiązaniem jest skonstruowanie w umowie tzw. umownego prawa odstąpienia w taki sposób, aby uprawniało ono zamawiającego do odstąpienia od umowy w przypadku ew. opóźnień w realizacji projektu. Kwestię tę poruszymy w kolejnym artykule dotyczącym umownego prawa odstąpienia.

[3] Tak m.in. wyrok Sądu Najwyższego z dnia 26 stycznia 2001 r., sygn. akt II CKN 365/00, wyrok Sądu Najwyższego z dnia 19 grudnia 2002 r., sygn. akt II CKN 1334/00 lub wyrok Sądu Najwyższego z dnia 22 maja 2003 r., sygn. akt II CK 367/02. Inaczej Sąd Najwyższy w wyroku z dnia 14 października 1998 r., sygn. akt II CKN 5/98, który wskazuje, że zapłata wynagrodzenia jest warunkiem odstąpienia przez zamawiającego na podstawie art. 644 KC.

[4] Tak między innymi wyrok Sądu Apelacyjnego w Szczecinie z dnia 28 maja 2013 r., sygn. akt I ACa 75/13, wyrok Sądu Apelacyjnego w Warszawie z dnia 23 lutego 2017, sygn. akt VI ACa 1936/16.

[5] Nie jest tak jednak zawsze. Jak wskazał Sąd Najwyższy w wyroku z dnia 19 września 2018 r., sygn. I CSK 587/17: „W razie odstąpienia od umowy na podstawie art. 635 KC, do rozliczeń pomiędzy zamawiającym i przyjmującym zamówienie nie odnosi się reguła wyrażona w art. 644 KC. Rozwiązań w tym przedmiocie należy poszukiwać na gruncie ogólnych przepisów regulujących odstąpienie od umów wzajemnych (art. 494 KC, względnie art. 491 § 2 KC, w kontekście podzielności świadczenia w rozumieniu art. 379 § 1 KC). W związku z czym, odstąpienie od umowy o dzieło, w okolicznościach konkretnej sprawy, nie zawsze wywiera skutek ex tunc (wsteczny).” Dlatego kwestię odstąpienia od umowy wdrożeniowej zawsze najlepiej skonsultować uprzednio z kancelarią prawną, którą oceni skuteczność planowanych działań, jak również wskaże na wszelkie skutki i ryzyka prawne związane z dokonaniem tej czynności.

 

Napisz do autora:

Aleksandra Modzelewska

adwokat
Associate

Ustawowe prawo odstąpienia od umowy wdrożeniowej – cz. 2

Ustawowe prawo odstąpienia od umowy wdrożeniowej – cz. 1

Czytaj: 8 min

Umowa wdrożeniowa jest co do zasady kwalifikowana jako umowa o dzieło, do której zastosowanie mają przepisy art. 627 – art. 646 KC. Istotą umowy wdrożeniowej jest bowiem stworzenie oznaczonego z góry rezultatu w postaci rozwiązania IT (np. systemu informatycznego) wdrożonego w przedsiębiorstwie zamawiającego, spełniającego wymagania zamawiającego określone w umowie.

Taką też kwalifikację prawną umowy wdrożeniowej przyjmują co do zasady sądy powszechne w Polsce. Przykładowo, Sąd Apelacyjny w Łodzi w wyroku z dnia 24 października 2012 r., sygn. I ACa 745/12 zaznaczył, że umowa zawierana pomiędzy stronami, która opisuje określony skutek (np. wdrożenie systemu), jest umową o dzieło (a przynajmniej umową zbliżoną do umowy o dzieło) [1].

Model umowy wdrożeniowej

Nie oznacza to jednak, że na gruncie prawa polskiego umowa wdrożeniowa zawsze będzie umową o dzieło. Strony mogą zgodnie zadecydować o innym modelu kontraktowym, np. o modelu umowy o świadczenie usług. Potwierdza to wyrok Sądu Apelacyjnego w Poznaniu z dnia 17 lipca 2018 r., sygn. III AUa 113/17. W orzeczeniu tym Sąd słusznie zauważył, iż: „W praktyce, umowę wdrożeniową można skonstruować zarówno w modelu umowy o dzieło, jak w modelu umowy o świadczenie usług. Różnica między tymi modelami sprowadza się w uproszczeniu do tego, że o ile w pierwszym z nich gotowy system jest rezultatem, za którego osiągnięcie odpowiada wykonawca, to w drugim modelu tak jak miało to miejsce w stanie faktycznym niniejszej sprawy, wykonawca ma jedynie z należytą starannością wspierać proces wdrażania systemu przez zamawiającego”.

Innymi słowy, „dziełowym” charakterem wdrożenia mamy do czynienia w sytuacji, w której: (i) określono w umowie oznaczony rezultat (efekt), który ma zostać osiągnięty (np. wdrożony system, który spełnia wymienione w umowie wymagania), a także (ii) rezultat ten będzie możliwy do weryfikacji w ramach procedur odbioru pod kątem występowania wad. Jednocześnie przy takiej kwalifikacji umowy, to wykonawca bierze odpowiedzialność za wykonanie rezultatu, który ma być zgodny z umową.

Umowę wdrożeniową będziemy zaś kwalifikować jako umowę o świadczenie usług, jeżeli taka umowa nie będzie określać wymagań lub oczekiwań zamawiającego co do ostatecznego kształtu systemu. Taki charakter umowy daje stronom w większą swobodę w kształtowaniu rozwiązania IT w trakcie realizacji wdrożenia (np. dostosowania do potrzeb zamawiającego). Może się więc okazać, że końcowy produkt zrealizowany w modelu usługowym jest bliższy rzeczywistym wymaganiom zamawiającego, aniżeli ten realizowany w sztywnym reżimie modelu umowy o dzieło. Z drugiej zaś strony, przy przyjęciu modelu umowy o świadczenie usług dostawca nie odpowiada za końcowy rezultat zrealizowanych prac, a jedynie za dochowanie należytej staranności w procesie wdrażania systemu.

Niemniej, większość umów wdrożeniowych na rynku polskim jest konstruowana w modelu umowy o dzieło. Dotyczy to również umów wdrożeniowych realizowanych w metodykach zwinnych, w ramach których oznaczenie końcowego rezultaty bywa trudne, choć nie niemożliwe (np. oznaczenie systemu może nastąpić poprzez odesłanie do inicjalnego backlogu produktu, który będzie w trakcie realizacji umowy rozwijany). Kwalifikacja umowy wdrożeniowej oznacza zaś możliwość zastosowania przepisów Kodeksu Cywilnego, które to umożliwiają stronom dokonanie odstąpienia od łączącego je stosunku prawnego. W tym artykule przyjrzymy się uprawnieniom ustawowym stron do odstąpienia od umowy (pomijamy natomiast zagadnienie dotyczące umownego prawa odstąpienia – kwestie te są niezwykle istotne dla umów wdrożeniowych i będziemy jeszcze o nich pisać na blogu). Znajomość tych przepisów pozwala tak dostawcom, jak też zamawiającym mitygować ryzyka prawne związane z odstąpieniem od umowy przez drugą ze stron.

Kodeksowe podstawy odstąpienia

W przypadku umów wdrożeniowych skonstruowanych w modelu umowy o dzieło ustawowe podstawy do odstąpienia od umowy regulują dwie kategorie postanowień, tj. (i) postanowienia ogólne, które mają zastosowanie do wszystkich umów wzajemnych, w tym umów o dzieło (art. 491 § 1, art. 492 oraz art. 492[1] KC), a także (ii) postanowienia szczególne mające zastosowanie wyłącznie do umów o dzieło (art. 631, art. 635, art. 636, art. 640 i art. 644 KC). Ogólne podstawy odstąpienia określone w art. 491 § 1, art. 492, art. 492[1] KC przysługują obu stronom, tj. każda ze stron może odstąpić na podstawie tych przepisów. Z kolei przepisy szczególne regulują podstawy odstąpienia, które przysługują jednej ze stron umowy, tj. i tak art. 640 KC jest podstawą, z której może skorzystać wyłącznie wykonawca, zaś art. 631, art. 635, art. 636 oraz art. 644 KC są podstawami, z których może skorzystać wyłącznie zamawiający.

W niniejszej (pierwszej) części publikacji skupimy się na omówieniu ogólnych podstaw odstąpienia od umowy, które przysługują obu stronom. W części drugiej przyjrzymy się szczególnym podstawom odstąpienia.

Zwłoka dłużnika w wykonaniu zobowiązania wzajemnego (art. 491 § 1 Kodeksu Cywilnego)

W pierwszej kolejności omówimy art. 491 § 1 KC, tj. podstawę odstąpienia z powodu zwłoki dłużnika w wykonaniu zobowiązania wzajemnego. Aby strona mogła odstąpić na tej podstawie muszą zostać spełnione następujące warunki:

  1. dłużnik dopuszcza się zwłoki – tj. „kwalifikowanego opóźnienia” w wykonaniu świadczenia w terminie, za które odpowiedzialność ponosi dłużnik;
  2. zwłoka dotyczy wykonania zobowiązania wzajemnego, tj. takiego świadczenia strony, które jest odpowiednikiem świadczenia drugiej strony. W przypadku umowy wdrożeniowej skonstruowanej w modelu umowy o dzieło takimi świadczeniami wzajemnymi są (i) zapłata wynagrodzenia przez oraz (ii) wykonanie dzieła w postaci wdrożonego systemu spełniającego wymagania określone w umowie. Oznaczałoby to, że brak spełnienia jednego z ww. świadczeń wzajemnych uprawniałoby daną stronę do odstąpienia od umowy (np. brak wykonania wdrożenia w terminie końcowym określonym w harmonogramie uprawniałby zamawiającego do odstąpienia, o ile zamawiający spełniłby pozostałe wymogi określone w art. 491 § 1 KC). Jednakże, jak wskazuje Sąd Najwyższy w wyroku z dnia 24 czerwca 2014 r., sygn. I CSK 392/12, w art. 491 § 1 KC nie chodzi tylko o „niespełnienie świadczenia, które zgodnie z treścią zobowiązania należy się wierzycielowi, ale mogą także to być niewykonane obowiązki nawet funkcjonalnie związane z długiem”;
  3. wierzyciel wezwał dłużnika do wykonania zobowiązania wzajemnego w odpowiednim terminie pod rygorem odstąpienia od umowy. Wymóg oznaczenia terminu i rygoru uchybienia takiemu terminowi jest niezwykle ważny. Zdarza się (choć raczej rzadko), że strona chcąc odstąpić od umowy wyznacza drugiej stronie dodatkowy termin do wykonania danego zobowiązania, ale bez zagrożenia, iż bezskuteczny upływ takiego terminu będzie skutkować odstąpieniem od umowy. Natomiast brak takiej informacji w wezwaniu oznacza brak możliwości odstąpienia po upływie oznaczonego w wezwaniu terminu. W takim przypadku oświadczenie będzie traktowane jako zgoda wierzyciela (zamawiającego / dostawcy) na odroczenie spełnienia świadczenia. Po drugie istotne jest, aby dodatkowy termin był „odpowiedni”, tj. realnie umożliwiający spełnienie przez dłużnika świadczenia. Przykładowo, wyznaczenie terminu 2 dni roboczych, w sytuacji, gdy zakres prac pozostałych do wykonania, obiektywnie rzecz biorąc, nie pozwala na spełnienie świadczenia w postaci wykonania wdrożenia w tak krótkim czasie, może zostać uznany za nieodpowiedni (tę kwestię będzie oceniał sąd);
  4. nastąpił bezskuteczny upływ wyznaczonego terminu.

Dopiero po spełnieniu wskazanych powyżej przesłanek dana strona będzie mogła złożyć oświadczenie o odstąpieniu od umowy w sposób skuteczny. Oświadczenie powinno zostać sporządzone w formie, którą przewiduje umowa (tak będzie w większości przypadków) lub dokumentowej (jeżeli umowa nie przewiduje obowiązku zachowania formy, zaś umowa została zawarta w formie pisemnej, dokumentowej lub elektronicznej) i wysłane na adres siedziby drugiej strony.

Warto jeszcze zaznaczyć, iż art. 491 § 2 KC przewiduje pewne ograniczenie uprawnienia opisywanego powyżej. Jeżeli świadczenie jest podzielne, zaś dłużnik pozostaje w zwłoce tylko do części świadczenia, wierzyciel może odstąpić od umowy albo co do tej części (tj. części, co do której dłużnik pozostaje w zwłoce) albo też do całej reszty niespełnionego świadczenia. Co do zasady wykonanie dzieła w postaci wdrożonego systemu spełniającego określone w umowie wymagania nie będzie miało charakteru świadczenia podzielnego (nie jest to jednak zasada absolutna, a kwestia podzielności świadczenia powinna być zawsze badana w ramach okoliczności danej sprawy [2]). Przepis ten mógłby natomiast znaleźć zastosowanie w sytuacji, w której przedmiotem umowy jest wykonanie analizy poprzedzającej prace wdrożeniowe. Zwłoka z wykonaniem analizy mogłaby uzasadniać odstąpienie zamawiającego od umowy „na przyszłość” (tj. co do pozostałej części umowy).

Lex commissoria (art. 492 Kodeksu Cywilnego)

Przepis art. 492 KC uprawnia do odstąpienia od umowy, jeżeli takie uprawnienie zostało zastrzeżone w umowie na wypadek niewykonania zobowiązania w terminie ściśle określonym. W takim przypadku strona uprawniona w razie zwłoki dłużnika (tj. rozumianego jak wyżej – „kwalifikowanego opóźnienia” w wykonaniu świadczenia w terminie, za które odpowiedzialność ponosi dłużnik) może odstąpić od umowy bez wyznaczania dodatkowego terminu drugiej stronie [3].

Skorzystanie z tego prawa przez stronę jest jednak uzależnione od prawidłowego skonstruowania postanowień umownych. Strony powinny wskazać w umowie, że odstąpienie jest możliwe na wypadek niewykonania zobowiązania w oznaczonym terminie. Termin musi być określony ściśle jako konkretna data lub poprzez wskazanie momentu następującego z upływem określonego czasu (np. 24 miesięcy od zawarcia umowy). Postanowienia typu: „zamawiający może odstąpić od umowy w przypadku, gdy dostawca opóźni się z przedstawieniem prawidłowo wykonanego wdrożenia do odbioru w terminie 3 miesięcy od dnia odbioru Etapu I” są nieprawidłowe. Takie zastrzeżenie, z punktu widzenia prawnego, stanowi warunek. Strony nie są bowiem w stanie z całą pewnością określić, kiedy nastąpi odbiór Etapu I (planowany odbiór może się opóźnić).

Oświadczenie o niespełnieniu świadczenia (art. 492[1] Kodeksu Cywilnego)

Ciekawa, choć rzadko spotykana w praktyce podstawa odstąpienia. Zgodnie z treścią art. 492[1] KC, „jeżeli strona obowiązana do spełnienia świadczenia oświadczy, że świadczenia tego nie spełni, druga strona może odstąpić od umowy bez wyznaczenia terminu dodatkowego, także przed nadejściem oznaczonego terminu spełnienia świadczenia”. Odstąpienie na podstawie omawianego przepisu będzie więc możliwe tylko w przypadku, jeżeli dłużnik oświadczy, że nie spełni swojego świadczenia w ogóle – niewystarczające jest, gdy oświadczenie dotyczy braku spełnienia świadczenia w danym terminie. Przepis nie wymaga również wyznaczania dłużnikowi dodatkowego terminu do spełnienia takiego świadczenia.

W jednej ze spraw, w których brałam udział, Klient skorzystał właśnie z omawianej podstawy. Cały spór rozpoczął się wraz z pojawiającymi się problemami dotyczącymi odbioru dokumentu analizy. Dłużnik (dostawca) pozostawał w zwłoce z przedstawieniem do odbioru prawidłowo wykonanego dokumentu. Jednocześnie dostawca zarzucał brak współdziałania zamawiającego przy realizacji prac związanych z analizą z uwagi na: i) brak przekazania potrzebnych dostawcy informacji; ii) brak udostępnienia plików określonych w Opisie Przedmiotu Zamówienia w odpowiednim formacie (zamawiający kwestionował zarzuty dostawcy, ponieważ udostępniał na bieżąco posiadane informacje oraz pliki w formacie opisanym w umowie). W wyniku postępującego konfliktu dostawca złożył oświadczenie o odstąpieniu od umowy na podstawie art. 640 KC. Klient uznał oświadczenie te za złożone bezskutecznie, a następnie sam odstąpił na podstawie art. 492[1] KC, podnosząc, że oświadczenie dostawcy o odstąpieniu od umowy należało traktować jako oświadczenie dłużnika o odmowie spełnienia świadczenia „w ogóle” [4].

Powyższa sprawa jasno pokazuje, że strona przed złożeniem oświadczenia o odstąpieniu od umowy powinna zweryfikować, czy jej oświadczenie w danych okolicznościach faktycznych byłoby skuteczne. W przeciwnym wypadku strona odstępująca może narazić się na „kontratak” kontrahenta w postaci złożenia oświadczenia o odstąpieniu na podstawie art. 492[1] KC. Przy czym taki „kontrakt” może mieć daleko idące konsekwencje prawne, bowiem – zgodnie z art. 494 § 1 in fine KC – strona, która pierwsza odstępuje od umowy skutecznie, może żądać nie tylko zwrotu tego, co świadczyła (tj. skutek wsteczny odstąpienia), lecz również naprawienia szkody wynikłej z niewykonania zobowiązania na zasadach ogólnych (tj. o ile wykaże spełnienie przesłanek, które uprawniają stronę do dochodzenia ww. szkody).

Należy jednocześnie zaznaczyć, że art. 492[1] KC jest stosunkowo nowym przepisem, bowiem wszedł w życie w dniu 25 grudnia 2014 r. [5]). Orzecznictwo, które dotyczyłoby interpretacji art. 492[1] KC nie jest więc dość obszerne. Należy to mieć na uwadze rozważając skorzystanie z ustawowego prawa odstąpienia na podstawie omawianego art. 492[1] KC.

Podsumowanie

Ogólny katalog podstaw odstąpienia (art. 491 § 1, art. 492 i art. 492[1] KC) jest rzadko wykorzystywany przez strony umowy wdrożeniowej. W przypadku sporów związanych z umowami zarówno dostawcy, jak też zamawiający powołują się najczęściej na przepisy szczególne lub na postanowienia umowy, o ile strony uregulują umowne prawo odstąpienia w umowie (o umownym prawie odstąpienia będziemy pisać w oddzielnym wpisie na blogu). Nie oznacza to jednak, że są to przepisy „martwe”. Ich znajomość może być kluczowa dla procesu wychodzenia z umowy. Obrazuje to spór naszego Klienta, który swoje oświadczenie o odstąpieniu oparł na podstawie art. 492[1] KC. Stąd też warto uprzednio skonsultować z kancelarią prawną możliwości swojej organizacji w kontekście planowanego odstąpienia, jak również w celu analizy skuteczności dokonania takiej czynności i ryzyk prawnych z tym związanych.

Przypisy:

[1] Podobną kwalifikację przyjął np.: Sąd Okręgowy w Szczecinie w wyroku z dnia 13 sierpnia 2015 r., sygn. akt VIII GC 312/13; Sąd Apelacyjny w Białymstoku w wyroku z dnia 14 listopada 2013 r., sygn. akt I ACa 491/13; Sąd Apelacyjny w Białymstoku w wyroku z dnia 30 stycznia 2019 r., sygn. akt I AGa 184/18, i wiele innych.

[2] Przykładowo Sąd Apelacyjny w Warszawie w wyroku z dnia 10.07.2017 r., sygn. akt VI ACa 2064/15 uznał, że świadczenie w postaci wdrożenia systemu jest podzielne, ponieważ wykonawca zobowiązał się do sukcesywnego przenoszenia autorskich praw majątkowych do wykonywanych części oprogramowania. Taka treść zobowiązania zawarta w umowie zdaniem Sądu uzasadniała ocenę, że strony uznawały, iż każdorazowo wykonana część prac spełnia kryteria utworu i może być traktowana jako spełnienie samodzielnej części świadczenia.

[3] To samo dotyczy wypadku, gdy wykonanie zobowiązania przez jedną ze stron po terminie nie miałoby dla drugiej strony znaczenia ze względu na właściwości zobowiązania albo ze względu na zamierzony przez nią cel umowy, wiadomy stronie będącej w zwłoce. Przy czym taka sytuacja w przypadku umów wdrożeniowych występuje dosyć rzadko, wobec tego nie będziemy rozwijać tego wątku.

[4] Podobny stan faktyczny w wyroku Sądu Okręgowego w Szczecinie – VIII Wydział Gospodarczy z dnia 29 października 2020 r., sygn. akt VIII GC 363/19.

[5] Przepis ten został dodany do KC w ramach ustawy z dnia 30 maja 2014 r. o prawach konsumenta (Dz.U. z 2014 r. poz. 827).

 

Napisz do autora:

Aleksandra Modzelewska

adwokat
Associate

Dekompilacja oprogramowania w celu naprawy błędów

Dekompilacja oprogramowania w celu naprawy błędów

Czytaj: 3 min

Legalny użytkownik może dekompilować kod wynikowy oprogramowania na potrzeby naprawy błędów. Taki wniosek płynie z wyroku Trybunału Sprawiedliwości Unii Europejskiej („TSUE”) z dnia 6 października 2021 r. (sygn. C-13/20; „Wyrok”). Nie jest to jednak uprawnienie absolutne. Prawo do legalnej dekompilacji całości lub części oprogramowania jest obarczone kilkoma warunkami, które postaramy się Państwu przybliżyć w niniejszej publikacji.

Tło sprawy – dekompilacja oprogramowania bez zgody uprawnionego

Rozstrzygana sprawa dotyczyła sporu pomiędzy belgijską spółką Top System, oferującą rozwiązania IT oraz belgijskim organem administracji publicznej „Selor”. W ramach wieloletniej współpracy Top System dostarczyło Selor oprogramowanie, które składało się z oprogramowania standardowego „Top System Framework” („TFS”) oraz oprogramowania dedykowanego, skrojonego na potrzeby Selor. Selor korzystało z TFS na podstawie licencji, nie mając jednocześnie dostępu do kodu źródłowego rozwiązania. Z uwagi na pojawiające się błędy oprogramowania TFS, których Top System nie usunęło, Selor samodzielnie dokonało dekompilacji części dostarczonego oprogramowania w celu wyłączenia funkcji, która okazała się wadliwa. W odpowiedzi na zachowanie zamawiającego Top System złożyło skargę, zarzucając Selor naruszenie wyłącznych praw autorskich spółki. W ocenie dostawcy czynność dekompilacji oprogramowania w celu naprawienia jego błędów mogła zostać dokonana jedynie po uzyskaniu uprzedniej zgody uprawnionego z tytułu praw autorskich. Takiej zaś zgody Top System nie udzieliło.

Sprawa trafiła do Sądu Apelacyjnego w Brukseli, który następnie postanowił zwrócić się do TUSE z dwoma pytaniami prejudycjalnymi, tj.:

  1. Czy art. 5 ust. 1 [dyrektywy 91/250] należy interpretować w ten sposób, że zezwala on uprawnionemu nabywcy programu komputerowego na dokonanie dekompilacji całości lub części tego programu, jeżeli dekompilacja ta jest konieczna, aby pozwolić mu na poprawienie błędów mających wpływ na funkcjonowanie tego programu, również w przypadku, gdy poprawka polega na wyłączeniu funkcji zakłócającej prawidłowe funkcjonowanie aplikacji, której program ten jest częścią?
  2. W przypadku udzielenia odpowiedzi twierdzącej na pytanie pierwsze, czy ponadto muszą zostać spełnione warunki określone w art. 6 dyrektywy lub jakieś inne warunki?

Treść wyroku

W ocenie TSUE dekompilacja całości lub części oprogramowania w celu naprawy jego błędów jest dopuszczalna, również bez zgody uprawnionego z tytułu praw autorskich. Taka możliwość wynika z art. 5 ust. 1 Dyrektywy Rady z dnia 14 maja 1991 r. w sprawie ochrony prawnej programów komputerowych („dyrektywa”), zgodnie z którym: „W braku szczególnych przepisów umownych czynności określone w art. 4 lit. a) i b) nie wymagają zezwolenia uprawnionego, jeżeli są konieczne do użycia programu przez uprawnionego nabywcę zgodnie z zamierzonym celem, włącznie z poprawianiem błędów[1].

Takiemu wnioskowaniu nie sprzeciwia się brzmienie art. 6 dyrektywy [2], który reguluje wymogi dekompilacji oprogramowania w celu osiągnięcia interoperacyjności stworzonych niezależenie programów. W ocenie Trybunału oba ww. przepisy są od siebie niezależne i spełnią inne cele. Celem art. 6 dyrektywy jest uregulowanie szczególnego przypadku dekompilacji, tj. dla zapewnienia interoperacyjności programów komputerowych (lex specialis). Natomiast art. 5 ust. 1 dyrektywy wprowadza generalną zasadę, która uprawnia legalnego nabywcę software’u do jego powielania, translacji, adaptacji, porządkowania i modyfikacji, jak też powielania wyników tych działań bez zgody uprawnionego, o ile jest to konieczne do korzystania z oprogramowania zgodnie z jego celem (lex generalis).

Dekompilacja oprogramowania w celu naprawy jego błędów nie jest nieograniczona. Nabywca oprogramowania (w tym przypadku licencjobiorca) powinien spełnić następujące wymogi:

  • dekompilacja jest przeprowadzona na potrzeby błędów rozumianych jako wady mające wpływ na program komputerowy, które są przyczyną jego niewłaściwego działania, oraz uniemożliwiają korzystanie z oprogramowania w sposób zgodny z zamierzonym celem;
  • dekompilacja musi być „konieczna”, by zapewnić nabywcy oprogramowania możliwość korzystania z produktu zgodnie z jego celem. Jeżeli błąd można naprawić w inny sposób, bez dokonywania dekompilacji, to czynność dekompilacji naruszy prawa wyłączne osoby uprawnionej (np. gdy licencjobiorca dysponuje kodem źródłowym rozwiązania);
  • nabywca oprogramowania nie może wykorzystać wyników dekompilacji do innych celów niż naprawa błędów.

Niezwykle istotnym dla praktyki (o ile nie najważniejszym) jest spostrzeżenie TSUE, zgodnie z którym strony nie mogą umownie wyłączyć jakiejkolwiek możliwości poprawiania błędów przez legalnego użytkownika. Strony mogą jedynie uregulować umownie zasady korzystania z tego uprawnienia.

Podsumowanie i wnioski dla praktyki

Wyrok ma praktyczne znaczenie zarówno dla dostawców i zamawiających, którzy w ramach relacji umownej uzgadniają zasady dostarczania oprogramowania standardowego, bez kodu źródłowego i bez prawa do modyfikacji oprogramowania. W takim przypadku legalny nabywca ma prawo, bez uprzedniej zgody uprawnionego, do dokonania dekompilacji części lub całości produktu, w celu usunięcia błędów mających wpływ na jego działanie, o ile taka czynność dekompilacji jest konieczna do zapewnienia zgodnego z celem korzystania z oprogramowania.

Strony powinny też pamiętać, że nie jest możliwe wyłączenie prawa legalnego użytkownika do poprawiania błędów oprogramowania. W świetle omawianego Wyroku takie klauzule należy uznać za nieważne. Trybunał dopuszcza jedynie możliwość umownego regulowania zasad korzystania z ww. uprawnienia, przy czym nie wskazuje jak daleko taka regulacja może sięgać. I tu pojawiają się wątpliwości – tj. czy odpłatna umowa serwisowa wyłącza prawo legalnego użytkownika do dokonania samodzielnej dekompilacji w celu usuwania błędów? Tego wątku Trybunał nie rozstrzyga. Niemniej warto mieć na uwadze omawiane orzeczenie TSUE przy konstruowaniu zobowiązań umownych stron w zakresie licencji oprogramowania.

Przypisy:

[1] Na gruncie prawa polskiego odpowiednikiem art. 5 ust. 1 dyrektywy jest art. 75 ust. 1) ustawy o prawie autorskim i prawach pokrewnych.

[2] Na gruncie prawa polskiego odpowiednikiem art. 5 dyrektywy jest art. 75 ust. 2 pkt 3) ustawy o prawie autorskim i prawach pokrewnych.

 

Napisz do autora:

Aleksandra Modzelewska

adwokat
Associate

Ustawowe prawo odstąpienia od umowy wdrożeniowej – cz. 2

Kluczowe obszary w umowach wdrożeniowych

Czytaj: 6 min

Truizmem jest już twierdzenie, że sektor IT w Polsce rozwija się dynamicznie. Pandemia wirusa Sars-Cov-2 ten prężny rozwój jeszcze przyspieszyła. Jak pokazuje raport „Wpływ Covid-19 na Branżę Software House w Polsce”, przygotowany przez organizację SoDA, mediana tempa wzrostu polskich spółek IT utrzymuje się na poziomie 20% [1]. Co więcej, jak wskazują autorzy, aż „jedna trzecia firm stwierdziła, że pandemia COVID-19 miała na nie pozytywny wpływ[2].

Przejście pracowników i kontrahentów na pracę zdalną, ograniczenia epidemiologiczne i inne czynniki związane z pandemią, wymusiły digitalizację działania wielu organizacji. Zauważalny i niezwykle ciekawy jest zwłaszcza „trend” migracji przedsiębiorstw do chmury [3] (o zaletach i ryzykach prawnych migracji do chmury będziemy jeszcze pisać). Wciąż jednak znaczna część projektów stanowią wdrożenia oprogramowania w modelu on-premise (tj. na infrastrukturze organizacji), które mają wiele niepodważalnych zalet (np. pełna kontrola nad danymi, kontrola na aktualizacjami, mniejsze ryzyko vendor lock-in, możliwość modyfikacji rozwiązań pod konkretne potrzeby zamawiającego).
Co z punktu widzenia prawnego jest kluczowe, aby zapewnić sukces projektom wdrożeniowym lub przynajmniej zmniejszyć szanse ich niepowodzenia?
O jakie obszary należy zadbać, aby implementacja rozwiązania IT zakończyła się powodzeniem?
W niniejszej publikacji postaramy się odpowiedzieć na te pytania.

Zakres prac

Zakres prac to istotny obszar umów wdrożeniowych. Zakres prac determinuje bowiem „CO” i „JAK” ma być zrealizowane w ramach projektu.
„CO”, czyli jakie dokładnie oprogramowanie wchodzi w skład oferowanego przez dostawcę rozwiązania (oprogramowanie standardowe, oprogramowanie dedykowane, oprogramowanie open source etc.), jakie wymagania funkcjonalne lub pozafunkcjonalne ma spełniać rozwiązanie, czy też jakie procesy biznesowe ma ono obsługiwać.
„JAK”, czyli określenie koncepcji i sposobu zrealizowania ww. wymagań zamawiającego, oraz opisanie jakie cele muszą zostać osiągnięte bądź warunki spełnione, aby wdrożenie zostało uznane za wykonane prawidłowo.

Dla obu stron umowy powinno być jasne co ma zostać osiągnięte w wyniku realizacji wdrożenia (tzn. „CO” i „JAK” ma być wdrożone w przedsiębiorstwie zamawiającego). Tyle że dokładne sprecyzowanie zakresu prac na etapie zawierania umowy będzie często niemożliwe (i nie zawsze potrzebne). Dobrą praktyką jest załączanie do umowy wymagań zamawiającego odnoszących się do rozwiązania IT będącego przedmiotem wdrożenia (określenie „CO”) oraz zobowiązanie wykonawcy do realizacji analizy przedwdrożeniowej, której celem będzie m.in. określenie koncepcji i sposobu implementacji ww. wymagań w konkretnym środowisku informatycznym (opisanie „JAK”). Często dopiero po wykonaniu takiej analizy będzie znany dokładny kształt wdrażanego rozwiązania, zakres prac i związana z tym zakresem wysokość wynagrodzenia lub sposób jego kalkulowania. Warto też zadbać, aby analiza: i) opierała się na wymaganiach zamawiającego, a nie założeniach dostawcy; ii) nie zmieniała wymagań zamawiającego (chyba że zamawiający wyrazi zgodę na taką zmianę); iii) była maksymalnie precyzyjna i nie posługiwała się pojęciami nieostrymi. Prawidłowo wykonana analiza powinna być bowiem podstawą dalszej współpracy stron. Podkreślamy, że chodzi tutaj o analizę wykonaną prawidłowo – błędy popełnione przy okazji wykonywania analizy mogą położyć się cieniem na dalszych fazach realizacji projektu. Stworzenie analizy przedwdrożeniowej może też zawczasu uchronić strony przed zaangażowaniem się w projekt, który nie przyniesie rezultatów zakładanych przez zamawiającego – np. w granicach założonego budżetu nie będzie możliwe wdrożenie rozwiązania IT oferowanego przez dostawcę [4].

Wagę dokumentu analizy obrazuje jedna z prowadzonych przeze mnie spraw, w której Klient zwrócił się o pomoc prawną w związku z przedłużającym się odbiorem analizy. Klient odmawiał dokonania jej odbioru z uwagi na nieprecyzyjność treści dokumentu. Analiza w wielu miejscach nie opisywała koncepcji wdrożenia funkcji rozwiązania (tzn. „JAK”), lecz zawierała wprost skopiowane fragmenty z Opisu Przedmiotu Zamówienia dotyczące wymagań zamawiającego lub odsyłała do dalszych ustaleń w ramach wdrożenia. Kolejne iteracje odbiorowe zakończyły się niepowodzeniem, a strony zajęły przeciwne stanowiska (dostawca zarzucał Klientowi nieprzekazywanie potrzebnych mu informacji, zaś Klient dostawcę o nienależyte wykonanie analizy). Spór zakończył się złożeniem przez Klienta oświadczenia o odstąpieniu od umowy i rozliczeniem dotychczas wykonanych prac przez dostawcę. Decyzja Klienta podyktowana była dużym opóźnieniem w realizacji analizy, a także obawą, iż – z uwagi na nieprecyzyjność analizy – wdrożenie zostanie wykonane nieprawidłowo. Dlatego tak ważny jest moment odbioru analizy. Po akceptacji dokumentu analizy przez zamawiającego, nawet jeżeli zawiera ona nieścisłości, wykonanie umowy przez dostawcę zgodnie z jej treścią będzie co do zasady prawidłowym wykonaniem umowy.

Niedokładne określenie zakresu prac często prowadzi również do sporów w trakcie realizacji prac wdrożeniowych (tj. czy sporne prace są lub nie są objęte zakresem prac). Stosunkowo rzadko jednak konflikty pomiędzy stronami kończą się sporami sądowymi. Jednakże wszelkie tego rodzaju nieporozumienia hamują realizację projektu i angażują czas pracowników stron, ich zewnętrznych dostawców lub nawet doradców.

Zarządzanie zmianą

Nawet maksymalnie precyzyjne opisanie zakresu prac lub zobowiązań dostawcy nie powinno oznaczać, że ich zmiana w trakcie realizacji projektu nie będzie możliwa. Wręcz przeciwnie. Tego rodzaju sztywność byłaby dla projektów wdrożeniowych niepraktyczna. W trakcie wdrożenia okazuje się często, że niektóre funkcje wdrażanego rozwiązania nie mają dla zamawiającego uzasadnienia ekonomicznego lub technicznego, albo zamawiający jest zainteresowany implementacją dodatkowych funkcji. Dlatego też dobrze napisana umowa wdrożeniowa powinna zapewniać stronom pewną dozę swobody w zmianie zakresu prac. Na poziomie umownym taka swoboda jest gwarantowana poprzez postanowienia określające tzw. procedurę zarządzania zmianą.

Celem procedur zarządzania zmianą jest jak najszybsze i zarazem najprostsze umożliwienie dokonania zmian umowy, najczęściej w zakresie dotyczącym: i) zakresu prac, ii) budżetu oraz iii) harmonogramu. Należy przy tym pamiętać, że zakres, budżet oraz harmonogram są ściśle powiązane. Zmiana zakresu prac pociąga za sobą zmianę wysokości wynagrodzenia oraz harmonogramu realizacji projektu. I odwrotnie, zmiana wysokości wynagrodzenia (np. zmniejszenie budżetu na projekt) powoduje zazwyczaj konieczność rezygnacji przez zamawiającego z niektórych prac w ramach wdrożenia (ograniczenie zakresu prac).

Tym samym postanowienia związane z procedurą zarządzania zmianą to kolejny kluczowy obszar, o który strony powinny zadbać w ramach negocjacji umowy. Zarządzanie zmianą jest szczególnie ważne, gdy projekt jest realizowany zwinnie. Zakres prac w metodykach zwinnych (backlog) jest bowiem „żywy” i ulega ciągłym zmianom. Temu tematowi poświęcimy oddzielny wpis na blogu.

Klarowny podział obowiązków stron (obowiązek współdziałania)

W naszej praktyce widzieliśmy już wiele sporów, których powodem był niejasny podział obowiązków stron w ramach umowy. Skutek takiego niejasnego podziału prac może być przeróżny, czasem wręcz katastrofalny dla całego przedsięwzięcia… Od gigantycznych opóźnień, aż po złożenie przez jedną ze stron oświadczenia o odstąpieniu od umowy (wykonawca opierając się na art. 640 KC, tj. braku współdziałania zamawiającego; zamawiający zazwyczaj na art. 491 KC czy art. 635 KC, tj. zwłoki wykonawcy).

Dlatego też warto zadbać o klarowny i maksymalnie precyzyjny podział obowiązków stron w ramach umowy. Postanowienia typu „Zamawiający zobowiązuje się do współdziałania z Wykonawcą”, „Zamawiający będzie należycie współpracował przy realizacji Umowy” czy „Zamawiający udzieli wszelkich informacji, których zażąda Wykonawca, w terminie nie dłuższym niż X dni roboczych od dnia wystosowania żądania” mogą okazać się niewystarczające i prowadzić do wielu sporów.

Dobrym rozwiązaniem jest opracowanie kompleksowego załącznika, który wprost przesądzi zakres wymaganego od zamawiającego współdziałania [5]. W ramach takiego załącznika dostawca powinien wyczerpująco określić, jakich działań oraz informacji oczekuje od zamawiającego w trakcie wdrożenia (np. infrastruktury lub zdalnego dostępu o określonych przez dostawcę parametrach, wskazanej przez dostawcę liczby licencji oprogramowania, sal projektowych). Zamawiający powinien również uzyskać zapewnienie dostawcy, iż zakres jego współdziałania określony w umowie będzie wystarczający do prawidłowego wykonania umowy.

Dobrą praktyką jest również rozstrzygnięcie z góry o dostępności personelu zamawiającego, którego obecność jeść niezbędna do współpracy z pracownikami dostawcy. Nie chodzi tutaj tylko o koordynatorów projektu oraz dział IT, ale również o pracowników, którzy docelowo będą korzystać z wdrażanego oprogramowania (interesariuszy).

Sposób realizacji wdrożenia

Często zdarza się, że treść umowy wdrożeniowej rozmija się z rzeczywistością projektową. Natomiast w razie ewentualnego sporu sąd i prawnicy będą wykładali umowę literalnie (tak jak jest napisana), a nie przez pryzmat praktyki realizacji projektu. Wobec tego, aby uniknąć ewentualnych nieporozumień, sposób realizacji wdrożenia opisany w umowie (tj. opis przebiegu prac, podział ról, kompetencje pracowników) powinien jak najlepiej odzwierciedlać rzeczywistość i założenia biznesowe stron. Istotne jest w szczególności prawidłowe opisanie kompetencji kierowników projektu lub komitetu sterującego oraz sposobu podejmowania decyzji (np. w formie wiadomości e-mail lub poprzez odpowiednie wpisy w narzędziu zarządzania projektem). Brak przestrzegania przez strony postanowień umowy w zakresie sposobu realizacji wdrożenia może prowadzić do wielu problematycznych sytuacji, np. takich, w których decyzje kierowników projektu okazują się dla stron niewiążące (w sytuacji, gdy decyzje zostały podjęte niezgodnie z procedurą opisaną w umowie).

Podsumowanie

Prawidłowe oraz możliwie pełne i precyzyjne opisanie przedmiotu umowy, jasny podział obowiązków między stronami i pewna doza elastyczności co do warunków współpracy znacząco podnoszą szanse na zakończenie projektu sukcesem. Nasza praktyka pokazuje, że spory wokół umów wdrożeniowych dotyczą najczęściej wątpliwości co do zakresu prac oraz współdziałania wymaganego od zamawiającego. Warto tym wątpliwościom zapobiegać już na etapie pisania umowy.

Biznesowo oraz prawnie newralgicznych obszarów istotnych dla powodzenia wdrożenia jest oczywiście więcej (np. prawa autorskie, odpowiedzialność stron, w tym kary umowne, klauzule indemnifikacyjne, odstąpienie od umowy, exit plan). Poświęcimy im kolejne wpisy na naszym blogu.

Przypisy:

[1] Źródło: https://sodapl.com/storage/reports/June2021/53LY4721e7GjlWYjgOBt.pdf, str. 11 (dostęp: 02.03.2022 r.).

[2] Ibidem, str. 3.

[3] O ciekawym trendzie migracji przedsiębiorstw do chmury więcej w raporcie „The evolving path to cloud adoption” przygotowanym przez Colt Technology Services (źródło: https://www.colt.net/go/cloud-research-report/, dostęp 02.03.2022 r.). Analitycy Gartnera również przewidują, że wydatki przedsiębiorstw związane z migracją rozwiązań IT do chmury wzrosną, a w 2024 r. wydatki przedsiębiorstw związane z korzystaniem rozwiązań chmurowych będą stanowić 14,2% wszystkich (globalnych) wydatków organizacji na rozwiązania IT (źródło: https://www.information-age.com/public-cloud-end-user-spending-grow-18-2021-gartner-123492692/).

[4] Stąd też dobrą praktyką jest wprowadzenie do umowy tzw. umownego prawa odstąpienia zamawiającego, z którego zamawiający może skorzystać po wykonaniu analizy. Tego rodzaju odstąpienie powinno odnieść skutek „na przyszłość” oraz nie powinno pozbawiać dostawcy wynagrodzenia za już wykonane prace (odstąpienie nie jest bowiem związane z nienależytym wykonaniem umowy przez dostawcę, lecz uznaniem przez zamawiającego, że wdrożenie danego rozwiązania jest niecelowe).

[5] Czasami strony dołączają do umowy zaawansowane macierze odpowiedzialności RACI, które w sposób bardzo wyczerpujący przypisują określone zadania odpowiednim rolom projektowym.

 

Napisz do autora:

Aleksandra Modzelewska

adwokat
Associate

Pin It on Pinterest