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 SPCG

Aleksandra Modzelewska

adwokat
Associate

Kluczowe obszary w umowach wdrożeniowych

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 SPCG

Aleksandra Modzelewska

adwokat
Associate

Pin It on Pinterest