Kod Da Vinci i Kod binarny - Dan Brown a programy komputerowe

Kilkanaście dni temu media podały informację o oddaleniu przez angielski sąd apelacyjny powództwa Michaela Baigenta i Richarda Leigha przeciwko Danowi Brownowi (a konkretnie przeciw jego wydawcy) o rzekomy plagiat ich książki „Święta Krew i Święty Graal” (“The Holy Blood and the Holy Grail”). Autorzy zarzucali, że obecna megagwiazda pisarstwa skopiowała ich pomysł, akcje i rozwiązania twórcze, a nader sławny „Kod Leonarda Da Vinci” to tylko przeróbka ich dzieła. Wiadomość przemknęła przez media, wywołała chwilę zaciekawienia i sprawa ucichła. A szkoda.

Problem, który poruszyli Baigent i Leigh, to Święty Graal prawa autorskiego – odpowiedź na pytanie, jak daleko ma sięgać ochrona prawna, w jakim stopniu wolno czerpać z pracy innych osób. Jak wiemy, prawo autorskie nie chroni pomysłów, chroni sposób ich wyrażenia. W praktyce rozstrzygnięcie gdzie leży granica ochrony jest bardzo trudne. Przyjmijmy, że faktycznie pomysł związku Jezusa i Marii Magdaleny, ich ukrytego dziecka, tajnego stowarzyszenia chroniącego owa tajemnicę, to pomysł przegranych powodów. Czy gdyby książka Michaela Baigenta i Richarda Leigha opowiadała nie tylko o „świętej krwi”, ale była historią morderstwa kustosza muzeum i pościgu naukowca za mordercą, konfliktu z tajnymi stowarzyszenia i Opus Dei, to czy opisanie jej innymi słowami przez Dana Browna też uznalibyśmy za „inspirację pomysłem” (w końcu nie przepisano żadnej linijki wprost), czy jednak stwierdzilibyśmy, że takie kopiowanie nie może być chronione?

Problem dotyczy także IT. W przypadku programów komputerowych kwestia jest podwójnie zawiła, gdyż mamy do czynienia z teoretycznie niedostępną warstwą literalną (kod źródłowy) i niepoznawalnym bezpośrednio dla człowieka kodem wynikowym. Klasyczny plagiat polega na skopiowaniu warstwy literalnej – jeżeli tak uczynimy z kodem źródłowym, zarzut naruszenia praw jest bardzo prawdopodobny i stosunkowo łatwy do dowodzenia (choć też różnie oceniano zakres „kradzieży” w orzecznictwie zachodnim – w wielkim skrócie: musi to być zapożyczenie „znaczne” co do jakości lub ilości). Jeżeli nie dokonamy (niedozwolonej w większości przypadków) dekompilacji, nie mamy jak dokonać takiego literalnego plagiatu. Jedyne co możemy robić to dokładnie badać funkcjonowanie programu i odczytać stojące za nim pomysły i algorytmy. Podobnie, korzystając z kodów źródłowych, nie musimy ich kopiować, często największą wartością jest poznanie sposobu rozwiązania. Możemy więc tworzyć bardzo podobne programy, realizujące te same funkcje, posiadające ten sam interfejs (Apple vs Microsoft) nie naruszając warstwy literalnej. Takie działania są stosunkowo częste, nie zawsze wynikają ze złej woli – klasycznym przypadkiem są pracownicy wykorzystujący w nowej pracy swoje doświadczenia i wypracowane rozwiązania. Nie można wykluczyć, że w takiej sytuacji dojdzie do takiego skopiowania układu funkcjonalnego i algorytmów, że uzasadni to roszczenia o naruszenie praw autorskich. Dowodem takich zdarzeń jest stosunkowo duża ilość pozwów i spraw w sądach, przede wszystkim amerykańskich. Wydano tam kilka ważnych wyroków, niejednokrotnie sięgając bardzo głęboko w poszukiwaniu rozwiązania – omówienie poglądów judykatury wykracza poza ramy niniejszej notatki, ale kiedyś do tego chciałbym wrócić. Sprawa nie tylko o doniosłym znaczeniu praktycznym, ale prawniczo nader ciekawa.

Jaki wniosek wypływa ze sprawy Browna? Jak dla mnie, jest to kolejny przykład umacniania się praw autorskich i próby rozszerzenia ich ochrony (choć tym razem nieskutecznej). Prędzej czy później na polskim rynku IT dojdzie do podobnych sporów, a obserwując praktykę tworzenia softwaru nie mogę wykluczyć, że część takich roszczeń – w odróżnieniu od powództwa Baigenta i Leigha – zakończy się sukcesem. Rozmyślając nad ewentualnym pozwem warto jednak mieć na uwadze, że wspomniani powodowie muszą zwrócić koszty postępowania w wysokości 3 milionów funtów. Co nie zachęca do bezpodstawnych oskarżeń.