Dlaczego wyrok TSUE z 6 października 2021 r. (C-13/20) to cenna wskazówka dla softwarehouse’ów, licencjobiorców oraz nabywców programów komputerowych?
Znajdą w nim odpowiedzi na pytania takie jak:
- czy można dekompilować program, do którego nabyło się licencję?
- czy strony mogą wyłączyć prawo do dekompilacji w umowie licencyjnej w całości?
- jakie są ewentualne ograniczenia w dekompilacji programu i czy strony umowy licencyjnej mają na to jakiś wpływ?
Praktyka pokazuje, że prawo do dekompilacji programu komputerowego to często oś sporów między stronami umów licencyjnych.
Po jednej stronie stoją software house’y / twórcy, którzy chcą zagwarantować sobie ochronę własnego know-how oraz integralności programów, a po drugiej nabywcy programów, chcący mieć pewność, że dostali oprogramowanie, które w 100% spełnia warunki umowne i jest w pełni funkcjonalne. W razie błędów chcą mieć możliwość podjęcia działań, które pozwolą im na dalsze korzystanie z programu zgodnie z zamierzonym celem.
Co więc w przypadku, kiedy oprogramowanie nie funkcjonuje tak, jak powinno, a kończy nam się cierpliwość?
Odpowiedzi udziela TSUE: można dekompilować…
Zanim przejdziemy do omówienia wyroku, wyjaśnimy kilka pojęć związanych z zagadnieniem, takich jak kod źródłowy czy dekompilacja właśnie.
[Jeśli jesteś programistą lub chcesz przejść od razu do omówienia wyroku, kliknij TU i przejdź do dalszej części artykułu, tj. do właściwej „kotwicy”].
Po pierwsze: czym jest kod źródłowy? Jest to zestaw operacji, które w kolejnych krokach ma wykonać program komputerowy na dostarczonych mu danych wejściowych. Operacje te są zapisane w określonym języku programowania (C++, JavaScript, Python, PHP itp.) Kod źródłowy jest więc efektem pracy programisty, który mówi o tym, co program ma zrobić, czyli jak przetworzyć dane.
Kod źródłowy ma też tę cechę, że jest „zrozumiały” dla ludzi. Dla przykładu, w języku C++, kod źródłowy dla wykonania popularnej komendy „Hello world!” wygląda tak:
| include int main() { std::cout << „Hello World!”; return 0; } |
Kod źródłowy nie jest jednak czytelny dla komputerów.
Aby to zmienić, trzeba go odpowiednio przetłumaczyć. Proces taki nazywany jest kompilacją. W jego wyniku powstaje tzw. kod obiektowy, nie do odczytania przez człowieka.
Powyższy przykład komendy „Hello world!” wyrażony tym kodem będzie wyglądał tak:
| b8 21 0a 00 00 #moving „!\n” into eax a3 0c 10 00 06 #moving eax into first memory location b8 6f 72 6c 64 #moving „orld” into eax a3 08 10 00 06 #moving eax into next memory location b8 6f 2c 20 57 #moving „o, W” into eax a3 04 10 00 06 #moving eax into next memory location b8 48 65 6c 6c #moving „Hell” into eax a3 00 10 00 06 #moving eax into next memory location b9 00 10 00 06 #moving pointer to start of memory location into ecx ba 10 00 00 00 #moving string size into edx bb 01 00 00 00 #moving „stdout” number to ebx b8 04 00 00 00 #moving „print out” syscall number to eax cd 80 #calling the linux kernel to execute our print to stdout b8 01 00 00 00 #moving „sys_exit” call number to eax cd 80 #executing it via linux sys_call |
Czym jest więc dekompilacja? Jest to proces poniekąd odwrotny do kompilacji. Polega na odszyfrowaniu zapisu maszynowego i uzyskaniu z niego kodu quasi-źródłowego.
Dlaczego quasi-źródłowego? Ponieważ w efekcie dekompilacji nie uzyskujemy 1:1 kodu źródłowego, który służył programiście do stworzenia programu – dostajemy nieco zmienioną, odtworzoną wersję kodu źródłowego, która jednak zawiera „core” programu i dzięki niej pozwala na poznanie zasad jego działania.
Jaka jest realna wartość możliwości naprawienia błędu?
Według raportu Undo oraz Cambridge Judge Business School MBA, 26% czasu programisty poświęca się na naprawianie oprogramowania w ramach debugowania (czynności mających na celu identyfikację błędów oprogramowania i ich usunięcie) – odpowiada to 620 milionom godzin pracy programistów w Ameryce Północnej rocznie.
Całkowita wartość wynagrodzenia wydanego na te godziny wynosi 61 miliardów dolarów rocznie i równa się 1,2 trylionów dolarów utraty wartości przedsiębiorstw w ciągu roku.[1]
Proces debugowania z założenia nie wymaga osobnej dekompilacji – w procesie tym kod źródłowy programu raczej powinien być dostępny dla debuggera. Co więc, jeśli kodu źródłowego nie mamy i musimy jeszcze dekompilować program? Skala „fatygi” i wydatków rośnie.
Nie dziwi wiec, dlaczego każdej ze stron umowy licencyjnej może zależeć na właściwym uregulowaniu praw do dekompilacji w umowie.
Wyrok TSUE z dnia 6 października 2021 r. w sprawie Top System SA p-ko État belge (C-13/20) daje nam w tym zakresie zestaw cennych narzędzi.
Tło sprawy
- Top System (producent oprogramowania) dostarczał przez ostatnie lata Selor, (belgijskiemu urzędowi ds. doboru kadr administracji federalnej) oprogramowanie komputerowe, w tym aplikacje, umożliwiające zgłaszanie kandydatur on-line. Dostarczone aplikacje obejmują z jednej strony komponenty dedykowane, tj. skrojone pod potrzeby Selor, a z drugiej strony komponenty „pudełkowe”, zaczerpnięte z frameworka opracowanego przez Top System – tzw. Top System Framework („TSF”);
- W 2008 r. Top System dostał zadanie, aby wdrożyć i skonfigurować nowe środowisko programistyczne dla Selor. Wykonawca napotyka jednak szereg problemów, których nie może naprawić w sposób satysfakcjonujący Selor. Urzędowi kończy się cierpliwość i dekompiluje oprogramowanie na własną rękę, w celu wyłączenia wadliwych funkcjonalności.
- Top System wnosi pozew przeciwko Selor o:
- ustalenie, że dekompilacji dokonano z naruszeniem praw wyłącznych Top System;
- zasądzenie odszkodowania tytułem dekompilacji i powielenia kodów źródłowych.
- Top System argumentuje, że poza możliwością dekompilacji zastrzeżonej w umowie, jest ona dozwolona wyłącznie w celu zapewnienia interoperacyjności oprogramowania, a nie w celu naprawy błędów – zgodnie z art. 6 dyrektywy w sprawie ochrony prawnej programów komputerowych (Dyrektywa Rady 91/250/EWG[2], dalej: „Dyrektywa”).
Sąd belgijski drugiej instancji zawiesza sprawę i kieruje poniższe pytania prejudycjalne do TSUE:
1. czy i w jakim zakresie legalny nabywca programu komputerowego ma prawo do dekompilacji programu, jeżeli taka dekompilacja jest konieczna, aby umożliwić skorygowanie błędów mających wpływ na działanie programu;
Po rozpoznaniu sprawy, TSUE staje na stanowisku, że:
- zarówno kod obiektowy, jak i kod źródłowy są dwiema różnymi postaciami wyrażenia kodu programu i zasługują na niezależną ochronę na gruncie prawa autorskiego;
- sam termin dekompilacji nie pojawia się w art. 4 Dyrektywy, który wymienia wyłączne prawa uprawnionego / twórcy. Niemniej, w procesie dekompilacji zachodzi konieczność powielenia kodu źródłowego oraz jego translacji, które należą do praw wyłącznych licencjodawcy = dekompilacja należy więc do wyłącznych praw uprawnionego / twórcy;
- dyrektywa umożliwia wprost (art. 6) dekompilowanie programu przez nabywcę programu, jeśli jest to konieczne do zachowania interoperacyjności (współdziałania z innymi programami);
- prawo do dekompilacji może być także wyinterpretowane z art. 5 Dyrektywy. Zgodnie z tym przepisem, nabywca programu może dekompilować program także jeśli jest to konieczne do używania go, włącznie z poprawianiem jego błędów mających wpływ na jego funkcjonowanie;
- art. 5 i art. 6 Dyrektywy mają odmienne cele i powinny być więc interpretowane jako niezależne podstawy dokonywania dekompilacji.
2. jakie są wymogi dot. dekompilacji i czy warunki dekompilacji z art. 6 Dyrektywy stosuje się również do art. 5 Dyrektywy?
TSUE w wyroku podkreśla, że:
- nie jest wymagane spełnianie wymogów dekompilacji z art. 6 Dyrektywy, jeśli podstawą dekompilacji jest naprawa błędów oprogramowania, o której mowa w art. 5 Dyrektywy.
Niemniej prawo do dekompilacji w celu naprawy błędów nie może być oderwane od okoliczności i musi spełniać następujące warunki:
- dekompilacja powinna służyć wyłącznie naprawieniu błędów w funkcjonowaniu programu, w celu zapewnienia jego działania zgodnie z zamierzonym celem; nie można dokonywać dekompilacji w innych celach (np. prywatnych);
- jeśli kod źródłowy lub jego translacja z kodu obiektowego jest dostępna dla nabywcy programu bez konieczności odrębnej dekompilacji, wówczas prawo do dekompilacji z art. 5 Dyrektywy nie aktualizuje się;
- prawo do dekompilacji nie może być wyłączone w umowie w całości przez Strony, jednak,
- można wprowadzić szczególne obwarowania skorzystania z prawa do dekompilacji, w celu naprawienia błędów w umowie. Przykładem jest np. zastrzeżenie obowiązku dokonywania poprawek oprogramowania przez licencjodawcę w umowie licencyjnej;
- prawo do dekompilacji nie oznacza automatycznie prawa nabywcy programu do dokonywania innych czynności zastrzeżonych na rzecz uprawnionego / twórcy – np. publicznego rozpowszechniania kodu źródłowego lub prawie-źródłowego (quasi-źródłowego), czy też jego dalszego powielania.
Powołany wyżej wyrok:
- porządkuje dotychczasowy pogląd w zakresie możliwości dokonywania dekompilacji programów,
- ma niebagatelne znaczenie dla podmiotów, które zastanawiają się, jakie przysługują im prawa do programów, które nabyły, a które nie działają lub posiadają błędy wpływające na ich funkcjonalność.
- odpowiada na potrzeby rynku, na którym ostatnimi czasy mnożą się spory pomiędzy dostawcami narzędzi IT, a nabywcami oprogramowania i stanowi mocny argument na korzyść tych ostatnich.
Mimo że część palących praktykę kwestii zostało uporządkowanych, wyrok TSUE pozostawia nadal pewien margines nieostrości, który wymaga doprecyzowania na etapie praktyki – na takim marginesie pozostaje np. dopuszczalna granica obwarowań umownych, którymi uprawnieni do programów będą mogli ograniczyć prawa do dekompilacji, tak aby nie wpaść w ryzyko uznania, że prawo to zostało całkowicie wyłączone. Dodatkowo, ciekawie z perspektywy omawianego wyroku może wyglądać kwestia celowego zaciemniania kodu, tak aby utrudnić jego odczytanie po dekompilacji.
Z pełną treścią wyroku
można zapoznać się pod tym linkiem.
[1] https://undo.io/the-cost-of-software-failures/#failing-tests-cost-enterprises-61-billion-annually.
[2] Wnioski TSUE znajdują zastosowanie również na gruncie dyrektywy Parlamentu Europejskiego i Rady 2009/24/WE z dnia 23 kwietnia 2009 r. w sprawie ochrony prawnej programów komputerowych (Wersja skodyfikowana) (Tekst mający znaczenie dla EOG), która zastąpiła Dyrektywę 91/250/EWG.
