Europejskie standardy

Ustawodawca europejski również wykazał zainteresowanie tematem dekompilacji. Odzwierciedleniem tego pozostają przepisy dyrektywy Rady z dnia 14 maja 1991 r. w sprawie ochrony prawnej programów komputerowych. Dopuszczalność reverse engineering przewiduje art. 6 tego aktu prawnego. Ogólnie rzecz biorąc, celem dekompilacji powinno być zapewnienie współdziałania różnych komponentów informatycznych. Wspomniane regulacje zostały w całości przeniesione na rodzimy grunt. W lipcu 2004 r. opublikowano robocze opracowanie Komisji Europejskiej poświęcone potrzebom zmian w zakresie prawa autorskiego i praw pokrewnych. Wśród wielu zagadnień wypunktowano również dekompilację. Dokument nie zawiera sprecyzowanych propozycji zmian. Autorzy ograniczają się do stwierdzenia, że dopuszczalny obecnie zakres reverse engineering zdaniem niektórych może okazać się zbyt wąski. Wiąże się to głównie z warunkiem dopuszczalności dekompilacji, której pozostaje zapewnienie kompatybilności oprogramowania komputerowego. Ze względu na to w przyszłości może zaistnieć konieczność rozważenia zagadnień związanych z prawnymi ramami dekompilacji.

Dekompilacja w Polsce

W ustawie z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych znalazł się odrębny rozdział poświęcony ochronie programów komputerowych. Art. 75 ustawy wskazuje na wiele uprawnień przysługujących legalnemu użytkownikowi aplikacji. Wśród nich znalazła się możliwość zwielokrotnienia kodu programu lub tłumaczenia jego formy. Warunkiem dopuszczalności takiej czynności jest ich niezbędność z punktu widzenia zapewnienia kompatybilności. Ustawa wskazuje, iż chodzi o "uzyskanie informacji koniecznych do osiągnięcia współdziałania niezależnie stworzonego programu komputerowego z innymi programami komputerowymi". Rodzime regulacje pozostają więc odpowiednikiem europejskich regulacji w kwestii reverse engineering.

Warto dodać, że użytkownik nie musi samodzielnie dokonywać dekompilacji. Może zlecić to innej osobie lub firmie. Ustawa warunkuje dopuszczalność odtworzenia kodu źródłowego okolicznością, iż informacje istotne z punktu widzenia kompatybilności nie są łatwo dostępne dla użytkowników. Nie sprecyzowano przy tym okoliczności, które mają przesądzać o "dostępności" takich danych. Bez wątpienia zajdzie to w sytuacji, gdy dokumentacja oprogramowania będzie zawierać szczegółowy opis zasad i idei, na których oparto proces tworzenia produktu informatycznego.

Obecnie trudno jednak znaleźć w dokumentacjach wszelkie informacje użyteczne dla programistów. Aplikacje są zbyt rozbudowane, by ich opis techniczny uwzględniał najdrobniejsze detale. Samodzielna analiza rozwiązań wykorzystanych w trakcie opracowywania oprogramowania z pewnością okaże się bardziej użyteczna niż skupienie się jedynie na informacjach udostępnianych przez producenta. Zresztą większość firm programistycznych nie będzie skłonna do ujawniania swojego know-how w tak przejrzystej formie.

W przypadku produktów open source problem dekompilacji całkowicie odpada, bo kod źródłowy jest powszechnie dostępny. Jeszcze więcej trudności może sprawiać pytanie, czy odpłatne oferowanie przez producenta informacji koniecznych do zapewnienia kompatybilności jest równoznaczne z ich "łatwą dostępnością". Teoretycznie można udzielić na nie dwóch wykluczających się odpowiedzi. Z jednej strony potencjalna dostępność danych dla każdego licencjonobiorcy może być argumentem przeciwko dopuszczalności dekompilacji programu. Druga strona medalu to stosowanie przez producenta swego rodzaju cen zaporowych. Żądanie wysokiej opłaty za przekazanie takich informacji ograniczy krąg zainteresowanych. Jednocześnie nie będą mogli oni skorzystać z reverse engineering. Choć trudno rozstrzygać jednoznacznie problem bez odwołania się do konkretnych przypadków, to warto zaryzykować tezę, że wygórowane opłaty będą otwierać drogę do korzystania z narzędzi służących do odtworzenia kodu źródłowego. Konieczne jest przy tym zaznaczenie, że przed dokonaniem dekompilacji nie trzeba zwracać się z jakąkolwiek prośbą o zezwolenie czy też udostępnienie określonych materiałów do producenta oprogramowania. Przepisy nie traktują bowiem reverse engineering jako ostateczności, która jest możliwa dopiero po wyczerpaniu wszelkich innych sposobów na rozwiązanie problemów kompatybilności programów.

Podsumowanie

Wydaje się, że najbardziej istotnym zagadnieniem pozostaje dopuszczalność dekompilacji w celu stworzenia programu konkurencyjnego w stosunku do poddawanego analizie. Właśnie na tej kwestii zasadza się większość obaw i kontrowersji związanych z reverse engineering. Przepisy wskazują na cel takich czynności sprowadzający się do osiągnięcia współdziałania z innym niezależnie stworzonym programem. Innym, nie oznacza dekompilowanym. Otwiera to drogę do analizy elementów, które nie są chronione prawem autorskim, a następnie wykorzystywania ich w walce o klienta. Na myśl niemal intuicyjnie przychodzi przykład analizy plug-ina w celu stworzenia wtyczki o podobnych zastosowaniach. Ograniczeniem pozostaje wyraźne zastrzeżenie, iż informacje uzyskane w wyniku reverse engineering nie mogą być "wykorzystane do rozwijania, wytwarzania lub wprowadzania do obrotu programu komputerowego o istotnie podobnej formie wyrażenia lub do innych czynności naruszających prawa autorskie". Inaczej mówiąc, odtworzenie kodu źródłowego nie może być ułatwieniem dla osób dopuszczających się plagiatu. Trzeba zwrócić jednak uwagę na to, że analogiczne funkcje spełniane przez dwa programy komputerowe nie są dostateczną przesłanką do uznania, że doszło do naruszenia praw autorskich. Jest to oczywiste, ponieważ przepisy nie chronią idei i pomysłów będących u podstaw kreacji aplikacji, a jedynie formy ich ekspresji.

Rodzime przepisy nie pozwalają przy tym na wprowadzenie klauzuli umownych wyłączających dopuszczalność dekompilacji. Ograniczenie opisanych uprawnień użytkownika będzie po prostu nieważne.