Jeżeli specjalista IT (nie tylko programiści rozumieni jako Software Developerzy, ale też inni specjaliści, tacy jak UX/UI Designerzy, Data Engineerowie itp.) zostaje zatrudniony w oparciu o umowę o pracę, to sytuacja przeniesienia praw własności intelektualnej – autorskich praw majątkowych oraz praw własności przemysłowej – jest rozwiązana przez ustawę. Wtedy zastosowanie ma domyślny, ustawowy mechanizm, gdzie prawa własności intelektualnej automatycznie nabywa pracodawca.
Co innego, gdy specjalista zatrudniany jest jako niezależny kontraktor albo freelancer i pracuje na tzw. „kontrakcie”. Wówczas sytuacja dla firmy jest trochę bardziej skomplikowana. Prawa własności intelektualnej, w tym w szczególności autorskie prawa majątkowe (tj. prawo do osiągania zysków z utworu) nie przechodzą automatycznie. Jeśli umowa nie będzie o tym w ogóle traktować (lub zostanie to uregulowane nieprawidłowo), to prawa do własności intelektualnej nie przejdą na firmę. Dlatego ważne jest, aby uregulować to w umowie.
>To może również Cię zainteresować: OVEREMPLOYMENT – PRACOWNIK NA (NIE)WYŁĄCZNOŚĆ
Jak zawrzeć taką umowę?
Przede wszystkim należy pamiętać, aby zawrzeć odpowiednią klauzulę w samym kontrakcie lub zawrzeć ją w osobnym dokumencie (np. załącznik dotyczący własności intelektualnej). Musi ona przewidywać, że wykonujący zlecenie (kontraktor) przenosi na firmę autorskie prawa majątkowe do utworzonych utworów. Ponadto, zgodnie z ustawą o prawach autorskich i prawach pokrewnych takie przeniesienie ma skutek na tzw. „polach eksploatacji”. Pola eksploatacji to nic innego jak pewne sposoby dozwolonego korzystania z utworu.
Na przykład, jeżeli programista tworzy fragmenty kodu źródłowego do całej aplikacji, to jest to jedno z pól eksploatacji. Przeniesienie praw na tym polu będzie pozwalało firmie na komercyjne wykorzystanie pracy programisty. Natomiast nie będzie to automatycznie uprawniało do innego wykorzystania utworu, choćby wydawało się ono oczywiste, np. do prowadzenia szkoleń i dydaktyki. Nie wystarczy stwierdzić, że przeniesienie dotyczy wszystkich pól eksploatacji. Pola takie trzeba wyraźnie wskazać w umowie – albo wymieniając je, albo poprzez odesłanie do odpowiednich przepisów.
Umowa musi określać wysokość wynagrodzenia za przeniesione prawa. Może być to oczywiście wynagrodzenie ryczałtowe, niezależne od liczby stworzonych w danym okresie rozliczeniowym utworów. Można też postanowić, że wynagrodzenie za przeniesienie wliczone jest w ogólną kwotę wynagrodzenia, otrzymywaną przez kontraktora.
Skuteczność przeniesienia praw
Aby zapewnić firmie bezpieczeństwo z punktu widzenia skuteczności przejścia praw autorskich trzeba pamiętać o tym, aby utwory w odpowiedni sposób rejestrować. Potrzebny jest dowód na to, że ten konkretny utwór został stworzony przez oznaczonego twórcę i przeniesiony na firmę. Takie rejestrowanie może odbywać się przy użyciu istniejących narzędzi, takich jak Git, Azure DevOps czy Confluence. Odpowiednio sformułowana umowa pozwoli połączyć te narzędzia z przejściem praw autorskich.
Umowa musi być również zawarta w formie pisemnej pod rygorem nieważności. Podpis własnoręczny może zastąpić tylko kwalifikowany podpis elektroniczny. Usługi typu DocuSign czy AdobeSign są niewystarczające i skutkują tym, że umowa jest traktowana jak nieistniejąca i firma nie nabywa praw autorskich. Ułatwieniem może być podpisanie umowy podpisem kwalifikowanym przez przedstawiciela firmy, podczas gdy kontraktor prześle podpisaną papierową kopię pocztą lub kurierem.
>To może Cię zainteresować: Podpis podpisowi nierówny
Co z bazami danych?
Sytuacja odrobinę komplikuje się w przypadku specjalistów zajmujących się pracą z danymi. W polskim porządku prawnym obowiązuje mało znana ustawa z dnia 27 lipca 2001 r. o ochronie baz danych. Zgodnie z tą ustawą, bazy danych podlegają dwóm odrębnym reżimom ochronnym – prawnoautorskim oraz szczególnemu reżimowi z ww. ustawy.
Bazą danych jest zbiór danych lub jakichkolwiek innych materiałów i elementów zgromadzonych według określonej systematyki lub metody, indywidualnie dostępnych w jakikolwiek sposób, w tym środkami elektronicznymi, wymagający istotnego, co do jakości lub ilości, nakładu inwestycyjnego w celu sporządzenia, weryfikacji lub prezentacji jego zawartości. Jakie konsekwencje płyną z tego dla firm IT?
Przede wszystkim oznacza to, że przepisy odróżniają od siebie cztery zasadnicze elementy działającej bazy danych, będącej finalnym produktem – dokumentację, kod źródłowy bazy, silnik bazy danych oraz samą bazę, rozumianą jako zbiór danych. Każdy z tych elementów podlega całkowicie różnej ochronie – i co za tym idzie, innemu przenoszeniu praw.
W przypadku specjalistów zajmujących się projektowaniem i tworzeniem baz danych (typowego stanowiska Database Developer), istotne jest przeniesienie praw autorskich do dokumentacji bazy danych oraz do kodu źródłowego. Zakładając na przykład, że baza danych tworzona jest w najpopularniejszych technologiach relacyjnych baz danych, opartych na SQL odrębnym przedmiotem ochrony i przeniesienia praw będzie sama dokumentacja, zawierająca językowy i graficzny opis bazy, schematu tabel i relacji między nimi, a odrębnym kod SQL, za pomocą którego developer „zakodował” te tabele, relacje, funkcje operujące na danych itp.
Silnik bazy danych jest natomiast elementem niezależnym od developera i firma musi zakupić odpowiednią licencję, np. Microsoft SQL Server lub korzystać z rozwiązań open source, tj. MariaDB, SQLite czy PostreSQL. Umowa między firmą a specjalistą nie może w żaden sposób dotyczyć tych aspektów.
Prawa do samej bazy danych, czyli już konkretnego zbioru posegregowanych i uporządkowanych danych, załadowanych do zaprojektowanych wcześniej tabel, na których operacje wykonuje silnik bazy danych, mogą nastręczać trudności. Ustawa o ochronie baz danych przewiduje, że prawa do bazy przysługują producentowi, czyli podmiotowi który ponosi ryzyko inwestycyjne związane z rozwojem bazy. W przypadku relacji opartych na umowach cywilnoprawnych, z założenia specjalista jest niezależny od firmy – a w szczególności w przypadkach umów B2B jest odrębnym przedsiębiorcą, działający na własny rachunek i własne ryzyko.
Podczas, gdy sam Database Developer nie będzie miał zazwyczaj związku z populowaniem bazy danymi, tak rezultatem prac Data Scientistów czy Data Engineerów mogą być nowe, odrębne bazy danych. DS czy DE mogą mieć za zadanie tworzyć analizy przy wykorzystaniu danych pochodzących z baz firmy, których efektem będzie powstanie nowych, uporządkowanych zestawów danych, noszących cechy nowej bazy danych. W takiej sytuacji może powstać wątpliwość kto jest inwestorem – decydujące mogą być niuanse dotyczące modelu współpracy.
Na marginesie należy dodać, że z punktu widzenia przepisów prawa nie ma różnicy między hurtownią danych a bazą danych.
Autor:
Jakub Grabowski, aplikant radcowski, prawnik w PCS Paruch Chruściel Schiffter Stępień Kanclerz | Littler