Program komputerowy stworzony przez pracownika – komu przysługują prawa?

Reguła szczególna dla software

Art. 74 ust. 3 prawa autorskiego ustanawia szczególną zasadę dla programów komputerowych. Prawa majątkowe do programu stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy, chyba że strony umówiły się inaczej. To rozwiązanie trzeba odróżnić od ogólnych reguł dotyczących innych utworów pracowniczych.

Najważniejsze jest źródło obowiązku

Sam fakt pozostawania w zatrudnieniu nie wystarcza. Trzeba zbadać umowę, zakres obowiązków, polecenia służbowe, rzeczywistą organizację pracy i cel projektu. Program napisany prywatnie po godzinach nie staje się automatycznie własnością pracodawcy tylko dlatego, że twórca jest jego pracownikiem. Z drugiej strony brak słowa „programowanie” w nazwie stanowiska nie przesądza sprawy, jeżeli tworzenie kodu rzeczywiście należy do obowiązków.

Co jest chronione?

Ochrona programu obejmuje formy jego wyrażenia; idee i zasady leżące u podstaw elementów programu nie są objęte ochroną prawnoautorską jako takie. W projekcie IT trzeba więc oddzielać kod i inne chronione formy ekspresji od koncepcji funkcjonalnej, algorytmicznej czy biznesowej.

Pracownik, B2B i podwykonawca to nie to samo

Art. 74 ust. 3 dotyczy stosunku pracy. Nie wolno automatycznie przenosić tej reguły na kontrakt B2B, umowę zlecenia lub dzieło. W relacjach z niezależnym programistą konieczne jest odpowiednie uregulowanie praw w umowie, z uwzględnieniem wymogów prawa autorskiego i rzeczywistego modelu współpracy.

Repozytorium nie rozstrzyga własności

To, że kod znajduje się na firmowym GitHubie, komputerze lub serwerze, jest dowodem organizacyjnym, ale samo w sobie nie rozstrzyga praw autorskich. Analogicznie użycie prywatnego sprzętu nie wyłącza automatycznie praw pracodawcy, jeżeli program powstał w wykonaniu obowiązków pracowniczych.

Jak ograniczyć spór?

Zakres obowiązków powinien jasno opisywać tworzenie i rozwój software, a dokumentacja projektu wskazywać autorów, komponenty zewnętrzne i licencje open source. Przy odejściu pracownika warto wykonać audyt repozytoriów i zależności. Szczególnej kontroli wymagają elementy stworzone wcześniej, biblioteki osób trzecich i kod pochodzący z innych projektów.

Najpierw trzeba ustalić, czy program powstał w ramach obowiązków pracowniczych

Art. 74 ust. 3 ustawy przewiduje szczególną regułę dla programu stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy, jeżeli umowa nie stanowi inaczej. W praktyce kluczowe jest więc nie samo korzystanie ze sprzętu pracodawcy ani miejsce napisania kodu, lecz związek tworzenia programu z obowiązkami pracownika. Zakres stanowiska, polecenia służbowe, backlog projektu, dokumentacja repozytorium i sposób rozliczania pracy mogą być ważniejsze niż nazwa pliku lub osoba, która dokonała ostatniego commitu.

Kod tworzony „po godzinach” nie zawsze jest prywatny

Jeżeli pracownik rozwija komponent wieczorem lub w domu, ale realizuje w ten sposób zadanie należące do jego obowiązków, sam czas pracy nie przesądza o prawach. Odwrotna sytuacja też jest możliwa: program powstały na prywatnym sprzęcie może pozostawać poza zakresem obowiązków służbowych. Dlatego spór trzeba rekonstruować przez cel projektu, polecenia, umowę o pracę i rzeczywisty zakres obowiązków, a nie przez pojedyncze okoliczności techniczne.

Biblioteki zewnętrzne i open source tworzą osobną warstwę praw

Nawet jeśli prawa do kodu pracowniczego przysługują pracodawcy, produkt może zawierać komponenty objęte licencjami open source albo komercyjnymi. Przed wdrożeniem, sprzedażą spółki lub rundą inwestycyjną trzeba zinwentaryzować zależności i warunki licencji. Ryzyko nie polega wyłącznie na „kradzieży kodu”; istotne są również obowiązki informacyjne, udostępnienia kodu źródłowego albo ograniczenia dalszej dystrybucji wynikające z konkretnej licencji.

Repozytorium powinno pozwalać odtworzyć autorstwo i historię zmian

Dobre zarządzanie IP obejmuje konta imienne, historię commitów, code review i dokumentację zadań. Jeżeli wiele osób pracuje nad jednym systemem, po latach trudno rekonstruować, kto stworzył konkretny moduł i w jakiej relacji prawnej działał. Ma to znaczenie zwłaszcza przy freelancerach, kontraktorach B2B i byłych pracownikach, wobec których automatyczna reguła pracownicza może nie znaleźć zastosowania.

Umowa powinna regulować także elementy inne niż sam kod źródłowy

System może obejmować dokumentację, grafiki, bazy danych, modele, konfiguracje, materiały szkoleniowe i know-how. Nie wszystkie te elementy są programem komputerowym w rozumieniu art. 74. Dlatego profesjonalna dokumentacja zatrudnienia i współpracy powinna rozdzielać prawa do kodu, innych utworów, baz danych, tajemnicy przedsiębiorstwa oraz materiałów dostarczanych przez podmioty trzecie.

Przeczytaj również

• Dziennikarstwo śledcze a tajemnica dziennikarska: ochrona informatora i granice ujawnienia
• Zdjęcia stockowe na stronie firmy: licencja, wizerunek i ryzyko roszczeń

Warto przeczytać także

• Utwór pracowniczy: kiedy prawa majątkowe nabywa pracodawca?
• Umowa przeniesienia autorskich praw majątkowych: forma i pola eksploatacji