Prawa autorskie w projektach IT

Głównie 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. 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.

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.

Prawo autorskie przewiduje dwie konstrukcje:

  • przeniesienie praw,
  • 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: ultra ciekawym 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, bo 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.

Czym więc różnią się te umowy?

Dwoma podstawowymi parametrami – trwałością nabytego uprawnienia oraz wspomnianym pozbawieniem twórcy praw do kodu w przypadku przeniesienia praw.

Trwałość jest – z punktu widzenia prawnika – największą różnicą.

Przeniesienie praw jest transakcją jednorazową, a skutek tej transakcji jest prosty – wczoraj prawa były po stronie A, dziś są po stronie B. B jest „właścicielem” kodu.

Pomijając rzadką możliwość odstąpienia od umowy, A nie ma już wpływu na dysponowanie programem przez B. W przypadku licencji zawsze istnieje ryzyko jej wypowiedzenia lub wygaśnięcia – zapomina się m.in. o tym, że o ile umowa nie stanowi inaczej, licencja automatycznie wygasa po pięciu latach.

Jeżeli jest udzielona na czas nieoznaczony, można ją wypowiedzieć – twórca może to zrobić z rocznym terminem wypowiedzenia na koniec roku kalendarzowego, chyba że umowa ten termin zmieni. W interesie zamawiającego jest wprowadzenie jak najdłuższego terminu wypowiedzenia, choć termin absurdalnie długi (99 lat) zostałby zapewne uznany za próbę obejścia prawa. Niestety nie da się stworzyć takiej licencji na czas nieoznaczony, która byłaby niewypowiadalna. Choć, jak słusznie wskazał Trybunał Sprawiedliwości UE, transakcja taka – jeżeli zapłata za licencję jest jednorazowa i uiszczona z góry – jest zbliżona do umowy sprzedaży, polskie przepisy traktują licencję jako zobowiązanie ciągłe i możliwość przerwania tego zobowiązania jest wbudowana w jego konstrukcję.

W przypadku zgody na umowę licencyjną, zamawiający musi zabezpieczyć to ryzyko – jest ku temu kilka środków, od zobowiązania do niewypowiadania, przez długie okresy wypowiedzenia, po kary umowne. To, o czym się często zapomina, to „zaszyta” w wielu umowach możliwość natychmiastowego wypowiedzenia w przypadku naruszenia praw licencyjnych. O ile sama zasada jest trudna do zakwestionowania, to termin natychmiastowy, np. w przypadku systemu ERP, jest z punktu widzenia biznesu nie do zaakceptowania. Zapłata odszkodowania jest zrozumiała, ale konieczność wyłączenia systemu z dnia na dzień (nawet jeżeli naruszono warunki licencji) zazwyczaj nie jest możliwa – minimum przyzwoitości to okres wypowiedzenia pozwalający na migrację do nowego systemu.

Po to, żeby bardziej skomplikować sytuację, nie ma jasności co się dzieje z licencjami w przypadku sprzedaży praw majątkowych przez licencjodawcę czy w przypadku wypowiedzenia licencji dystrybutorowi, który wcześniej udzielił sublicencji zamawiającemu. Jest poważne ryzyko, że umowy licencyjne (sublicencyjne) wygasają.

Czy powyższe zagrożenia powinny skłaniać nas do nabycia praw zamiast licencji?

Wydaje się, że wyłącznie w skrajnych przypadkach, kiedy system jest kluczowy i ryzyko tego typu byłoby nie do zaakceptowania. Bywa tak przy dedykowanych umowach. Mimo że z teoretycznego punktu widzenia ryzyko jest istotne i, co gorsza, nie do zabezpieczenia w 100%, to jak pokazuje praktyka w rzeczywistości nie jest aż tak groźne. Mieliśmy wiele przejęć i transferów na rynku IT i nie znam przypadku, kiedy nabywca próbował dowieść użytkownikowi, że prawa licencyjne wygasły. Znam jednak przypadki, że groźba wypowiedzenia licencji była użyta przez dostawcę w sporze z klientem, nawet wtedy, gdy spór ten dotyczył umów serwisowych a nie samej licencji. Ale rozsądny mechanizm umowy, z odpowiednio długim okresem wypowiedzenia wydaje się wystarczająco zabezpieczać interesy zamawiającego.

Mniej „prawna”, ale nie mniej istotna jest druga różnica, czyli utrudnienie rozpowszechniania kodu. Nie da się ukryć, że w czasie wdrożeń dostawca zapoznaje się z przedsiębiorstwem zamawiającego i informacjami poufnymi. Niejednokrotnie prawdziwy know how w projekt wdrożeniowy wnosi nie dostawca, a właśnie zamawiający. W takiej sytuacji może mu zależeć, żeby rozwiązanie wdrożone w jego firmie, w szczególności przebieg procesów, nie został przekazany konkurencji w kolejnym wdrożeniu. Prawa do tej warstwy „kastomizacyjnej” stosunkowo często przenosi się na zamawiającego – w ten sposób uniemożliwiając proste powielenie kodu w innym projekcie. Oczywiście to tylko półśrodek, bo nie blokuje możliwości wykorzystania przez dostawcę zdobytej wiedzy i doświadczenia – ale przynajmniej wymusza dość istotny wysiłek ponownego kodowania. Oczywiście warto go połączyć z klauzulą zakazu konkurencji.

Czy jest wyjście pośrednie?

Poniekąd takim rozwiązaniem jest nabycie udziału w prawie, coś na kształt współwłasności. Wymaga to zawarcia dość wyrafinowanej umowy opisującej sposób korzystania ze wspólnego prawa, ale gwarantuje, że i dostawca i zamawiający są „właścicielami” kodu – znika ryzyko wypowiedzenia, pozostają bardzo szerokie możliwości dysponowania kodem (jeśli się dobrze umowę napisze). Oczywiście konstrukcja ta nie załatwia problemu poufności, ale ten można zabezpieczyć przez odpowiednie postanowienia umowne.

Podsumowując: zbyt często widzę SIWZ-y czy negocjacje, których celem jest nabycie praw. Bardzo często argumentem za takim SIWZ-em czy wymaganiem jest „prawo do modyfikacji i swobodnego rozwoju systemu”. To nieporozumienie – prawo modyfikacji bez problemu można nabyć umową licencyjną (pytanie czy warto, ale to kwestia i biznesowa, i faktycznej możliwości modyfikacji, jak i samej architektury – nikt nie modyfikuje bezpośrednio kodu SAP). Prawa warto nabywać, jeżeli opracowujemy własny produkt oraz w tych przypadkach, kiedy na 100% chcemy wykluczyć ryzyko wypowiedzenia czy wygaśnięcia umowy oraz jako instrument pomocniczy przy kontroli poufności przekazanych dostawcy informacji.


Zobacz inne artykuły Marcina Maruty