Biorąc pod uwagę odrębność oprogramowa-nia komputerowego od innych form twór-czości, pojawia się problem, gdy mamy do czynienia z utworem zależnym.

Tradycyjnie rzecz ujmując, w systemie prawa autorskiego pojawia się kategoria "dzieł zależnych". Wykorzystują one w zakresie szerszym niż inspiracja istniejące już efekty pracy twórczej, bazując na nich bezpośrednio. Utworem takim będzie tłumaczenie, adaptacja.

Biorąc pod uwagę odrębność oprogramowania komputerowego od innych form twórczości, pojawia się problem, gdy mamy do czynienia z utworem zależnym. Zwłaszcza że w świetle polskiego prawa autorskiego niezbędna jest zgoda twórcy (twórców) na rozpowszechnianie tego typu dzieła. Przy aplikacjach dochodzi dodatkowy warunek. Wśród majątkowych praw autorskich do oprogramowania znalazło się uprawnienie do tłumaczenia, modyfikowania i zmiany układu aplikacji. Tak więc już na etapie tworzenia dzieła zależnego będziemy ingerować w cudze prerogatywy twórcze. Waga oceny, kiedy mamy do czynienia z utworem zależnym, wzrasta, jeśli weźmiemy pod uwagę rozpowszechnienie się licencji open source. Dla przykładu, omawiana niedawno na łamach Computerworld licencja GPL nakazuje stosować klauzulę copyleft w stosunku do utworów zależnych wobec pierwowzoru.

Zaznaczyć trzeba, że odrębnie traktujemy prawa do pierwotnego programu oraz do opartego na nim dzieła zależnego. W tym ostatnim przypadku prawa autorskie będą przysługiwać tworzącemu nowe rozwiązanie. Jest to istotne z punktu widzenia komercyjnych przedsięwzięć. Utwór zależny opiera się na gotowym już rozwiązaniu, które jest poddawane modyfikacjom. Najprostszym przykładem jest uzupełnienie dotychczasowego kodu programu o nowe komendy. Bez wątpienia nawet niewielki fragment aplikacji może diametralnie zmienić funkcjonalność produktu. Warunkiem jest jednak to, że owe uzupełnienia będą spełniały warunek oryginalności. Dodanie jednej linijki kodu bądź poprawienie błędu nie doprowadzi do stworzenia nowej aplikacji. Nie będzie więc mowy o utworze zależnym.

Biblioteki

Niestety, klasyczne definicje prawa autorskiego nie zdają się na wiele w realiach programowania. Weźmy pod uwagę choćby biblioteki, po które sięgają uruchamiane aplikacje. W istocie stanowią one zestawienie komend użytecznych przy pracy programu. Technicznie rzecz ujmując, możemy spotkać się ze statycznym bądź dynamicznym powiązaniem komponentów programu i elementów zawartych w bibliotekach. Zwłaszcza ostatni z zabiegów, sprowadzający się do sięgania do nich tylko przy wczytywaniu aplikacji, może rodzić pytania o relacje program - biblioteka.

Powiązania, statyczne bądź dynamiczne, pomiędzy aplikacjami a bibliotekami wkroczyły na stałe do arkanów programowania. Z kolei ocena czy poprzez połączenie programu z biblioteką, udostępnianą na zasadach wyrażonych w licencji GPL, dochodzi do powstania dzieła zależnego, niesie ze sobą konsekwencje praktyczne. Pozytywna odpowiedź na to zagadnienie będzie nakazywać udostępnienie aplikacji na zasadach wolnego oprogramowania. Nie jest to więc jedynie teoretyczne zagadnienie.

Statyczne powiązanie programu ze strukturą biblioteki nie budzi większych wątpliwości. W istocie rzeczy mamy bowiem do czynienia z permanentnym łączeniem ze sobą komponentów programistycznych. Inaczej sytuacja przedstawia się w drugim przypadku. Zaznaczyć trzeba, że dynamiczne połączenia z biblioteką nie powodują modyfikacji programu istotnych z prawnego punktu widzenia. Są one wykorzystywane każdorazowo przy funkcjonowaniu aplikacji. "Wywoływanie" komponentów biblioteki w trakcie dynamicznego łączenia się z nią programu nie prowadzi więc do powstania utworu zależnego. Zagadnienie to wywołuje jednak mieszane uczucia. Wśród zwolenników szerokiego stosowania zasady copyleft (w świetle licencji GPL) istnieje tendencja do traktowania na równi statycznego i dynamicznego łączenia programów z bibliotekami.

Kompilowanie programu

Niezbędnym elementem programowania jest kompilowanie kodu źródłowego. Sięgnięcie po kompilator nie spowoduje automatycznie powstania nowego utworu zależnego. Kompilację traktować trzeba jako proces stricte techniczny, który nie niesie ze sobą uzupełniania kodu o fragmenty chronione na mocy prawa autorskiego. Jest to o tyle istotne, że niezbyt często zdarza się, aby dokonujący kompilacji był jednocześnie uprawnionym z tytułu praw autorskich do samego kompilatora.

Sięganie po istniejące moduły

Ciekawym zagadnieniem jest sytuacja, w której na rynku pojawi się aplikacja sięgająca po moduły wcześniej dostępnego programu, np. jego bazy danych. Trudno uznać to za tradycyjne uaktualnienie programu, bo jego producentem jest inny przedsiębiorca. Sprawa komplikuje się jeszcze bardziej, gdy programiści owej aplikacji są zarazem współtwórcami programu, na którym ona "żeruje". Można uznać takie rozwiązanie za utwór zależny, choć jeśli program będzie działał nawet bez "cudzej" bazy danych, bo połączenie takie jest tylko opcjonalne. W takich sytuacjach, bardziej zasadne od roszczeń opartych na przepisach prawa autorskiego, będą żądania związane z naruszeniem zasad uczciwej konkurencji, np. wykorzystania cudzej renomy.

Innym problemem jest programowanie obiektowe, gdzie sięganie po istniejące moduły jest po prostu koniecznością. Jednakże z uwagi na to, że parametry poszczególnych modułów mogą być zmieniane stosownie do aktualnych potrzeb, samo ich wykorzystywanie nie będzie automatycznie prowadzić do powstania utworu zależnego. Inaczej ma się rzecz ze stworzeniem podkategorii istniejącej już klasy. Tutaj można rozważać zaistnienie dzieła zależnego. Na nic nie zda się jednak wypracowanie ogólnych zasad. Niektóre z klas obiektów tworzonych w ramach programowania obiektowego są na tyle ogólne, że nie będą pretendować do miana utworu chronionego prawem autorskim.

Warto dodać przy tym, że od dzieł zależnych trzeba odróżnić efekty pracy, dla których obecne na rynku produkty były tylko inspiracją. Odwoływanie się przez programistów do standardów z zakresu funkcjonalności aplikacji, wykorzystania popularnych języków programowania nigdy nie będzie traktowane jako tworzenie utworu zależnego.