Prawa autorskie w projektach IT- o różnicach między przeniesieniem praw a licencjami

Pomysł, aby ochronę rozwiązań branży IT oprzeć na prawie autorskim nie był specjalnie szczęśliwy. Kłopoty sprawiają ciągle te same, wydawałoby się znane i wielokrotnie omówione tematy, takie jak pola eksploatacji, zasady wypowiadania umów czy dylemat przeniesienie praw vs. licencja.

Prawo autorskie stworzono z myślą o twórcach oraz odbiorcach. Jednym przyznano stosunkowo daleko idącą, choć nader specyficzną, ochronę, drugim – szereg uprawnień mających na celu możliwość korzystania z dzieł twórców. Dla rozwijającego się przemysłu softwarowego było to nie do zaakceptowania – specyfika ochrony twórców zbyt często działała wbrew interesom ich pracodawców, specyfika uprawnień użytkowników była groźna jeszcze częściej (vide: dozwolony użytek osobisty). Zrobiono to, co było najłatwiejsze – wprowadzono do systemu szereg wyjątków i zmian, które pozbawiły sensu wiele instytucji prawa autorskiego. Na dodatek zmieniono interpretację klasycznych przepisów – to, co było dozwolone jeszcze przed chwilą, okazało się nielegalne. I teraz żyjemy w tym właśnie świecie – z szeregiem zmian, nowych przepisów, nowego rozumienia wiekowych konstrukcji prawnych. Jeżeli dołożymy do tego nieintuicyjność ochrony tzw. własności intelektualnej, nie można się dziwić, że zagadnienia prawa autorskiego przysparzają i przysparzać będą wiele kłopotów. To, co może dziwić, to fakt, że na czele listy kłopotów są ciągle te same, wydawałoby się znane i wielokrotnie omówione tematy, takie jak pola eksploatacji, zasady wypowiadania umów czy dylemat przeniesienie praw vs. licencja.

Więcej na temat różnic między przeniesieniem praw a licencjami autor artykułu, Marcin Maruta opowie podczas warsztatów „Prawa autorskie w projektach informatycznych” 12 czerwca 2014 w Warszawie. Szczegóły dotyczące warsztatów dostępne są na stronie: http://www.computerworld.pl/konferencja/autorskie2.

Chciałbym zacząć od ostatniego, bo z mitem „lepiej kupić prawa, niż wziąć licencję” walczy się trudno. Co zabawne, nabycie praw rzeczywiście jest „lepsze” aniżeli nabycie licencji, tylko że z innych powodów niż się często uważa. Pierwsze i zasadnicze nieporozumienie to zakres uprawnień – nie wiem, na ile na to nieporozumienie miał wpływ Prezes UZP wydając swoje rekomendacje, w których możemy znaleźć silne zalecenie „nabywajcie prawa”, a na ile rzeczywistość tzw. vendor lock-ingu. Uzależnienie się od dostawców jest obiektywnie olbrzymim problemem, ale nabycie praw niekoniecznie jest lekarstwem.

Zobacz również:

Prawo autorskie przewiduje dwie konstrukcje: przeniesienie praw oraz licencje. Nie będę wchodził w dość zawiłe (choć pasjonujące) rozważania teoretyczne. Istotą tych umów jest – w pierwszym przypadku – wyzbycie praw po stronie twórcy, w tym drugim – wyłącznie upoważnienie danego podmiotu do korzystania z utworu, bez naruszenia praw twórców. Ze względu na swoiste ukształtowanie praw majątkowych do programu komputerowego (art. 74.4 p.a.) przeniesienie praw przez twórcę oznacza dla niego de facto brak możliwości dalszego dysponowania kodem. Nie może on go nie tylko dalej rozpowszechniać (co jest naturalną konsekwencją oddania praw), lecz także zwielokrotniać czy modyfikować. Nie da się sprzedać „wersji 3.12” jednemu klientowi i „wersji 3.13” drugiemu, jeżeli mają wspólny kod. Taka operacja wymagałaby zgody nabywcy kodu 3.12 na wykorzystanie go w wersji 3.13, co jest mało prawdopodobne. Z tego powodu jest to transakcja jednorazowa i wersję 3.13 trzeba opracować od podstaw, z nowym kodem, aczkolwiek sam pomysł z wersji 3.12 można swobodnie zaczerpnąć – prawo autorskie pomysłów nie chroni (na marginesie: ultraciekawym zagadnieniem jest granica ochrony – wiemy, że kody są chronione, wiemy, że pomysły nie, ale nie wiemy, co zrobić z tym, co leży pośrodku – czy można kopiować architekturę, algorytmy, struktury?).

Nic dziwnego, że z punktu widzenia dostawcy taka operacja zawiera olbrzymi koszt, który wpływa na wycenę tych praw lub w ogóle wyklucza daną transakcję. Przeniesienie praw jest dość powszechne w umowach z pracownikami czy zleceniobiorcami przy opracowywaniu własnych produktów, zdarza się przy dużych jednorazowych transakcjach dedykowanych oraz przy opracowywaniu dedykowanych dla danego zamawiającego rozszerzeń rozwiązań standardowych (np. w SAP). W tych dwóch ostatnich przypadkach dostawca, przenosząc prawa do kodu, jednak ryzykuje – rozwiązanie bardzo dedykowane może okazać się atrakcyjne i gotowe do użycia w innym przypadku – wdrożenie systemu do obsługi banku centralnego w Polsce jest zapewne jednorazową transakcją, bo innego banku centralnego nie znajdziemy. Ale nie znajdziemy go w Polsce, w każdym innym kraju taki istnieje. Sprzedaż praw wyklucza więc łatwy eksport systemu.

Licencja (niewyłączna, ale wyłączne są w IT niezwykle rzadkie) nie niesie za sobą tego ryzyka. Można udzielić tysiące licencji, a wciąż pełna kontrola nad programem jest po stronie twórcy. Powoli dochodzimy do głównego wątku – czy rzeczywiście licencja jest „słabszym” rozwiązaniem dla zamawiającego? Jeżeli pytamy o vendor lock-in i możliwość rozwoju systemu, odpowiedź jest negatywna – jest obojętne to, jaką umowę nabywca zawrze. To, co jest kluczowe, to zakres uprawnień jakie nabędzie, a ten zakres uprawnień (zwany też polami eksploatacji) określa nam art. 74.4 prawa autorskiego i jest dokładnie taki sam w obu umowach. Zarówno przeniesienie praw, jak i licencja mogą dotyczyć prawa do zwielokrotniania kodu, jego modyfikacji czy rozpowszechniania. Nie ma znaczenia typ umowy – znaczenie ma to, co strony wynegocjują. Prawdą jest, że w przypadku sprzedaży praw z reguły umowa obejmuje wszystkie pola eksploatacji, a licencje często są ograniczone do zwielokrotnienia kodu, ale to tylko praktyka rynku. Jeżeli celem zamawiającego jest zapewnienie sobie praw do modyfikacji i swobodnego rozwoju oprogramowania, odpowiednio ukształtowana licencja jest całkowicie wystarczająca. Teoretycznie nawet licencja może być szersza niż przeniesienie praw. To tylko negocjacyjna zabawa z triadą uprawnień: zwielokrotnienie-modyfikacje-rozpowszechnienie.


TOP 200