5 dni temu
Kod źródłowy nowej aplikacji, projekt interfejsu, teksty na stronę, prezentacja dla inwestorów, grafika wygenerowana z pomocą AI – w firmie cyfrowej niemal codziennie powstają rezultaty, którym można przypisać wartość autorską. Prawa autorskie pracownika nie przechodzą jednak na pracodawcę automatycznie tylko dlatego, iż praca została wykonana w godzinach pracy, na firmowym sprzęcie albo dla klienta spółki. O skutku prawnym decyduje przede wszystkim charakter utworu, podstawa współpracy, zakres obowiązków oraz treść umowy.
To rozróżnienie ma bezpośrednie znaczenie dla transakcji inwestycyjnych, audytów due diligence, sprzedaży przedsiębiorstwa, wdrożeń systemów IT i sporów z byłymi członkami zespołu. Brak uporządkowanego łańcucha praw może oznaczać, iż spółka korzysta z kluczowego rozwiązania bez wystarczającego tytułu prawnego.
Kiedy prawa autorskie pracownika nabywa pracodawca?
Punktem wyjścia jest art. 12 ustawy o prawie autorskim i prawach pokrewnych. o ile pracownik stworzył utwór w wyniku wykonywania obowiązków ze stosunku pracy, pracodawca – co do zasady – nabywa autorskie prawa majątkowe z chwilą przyjęcia utworu. Nabycie następuje w granicach wynikających z celu umowy o pracę i zgodnego zamiaru stron.
To rozwiązanie nie oznacza, iż każda twórcza aktywność zatrudnionej osoby należy do firmy. Utwór musi pozostawać w związku z obowiązkami pracowniczymi. Programista zatrudniony do rozwoju produktu SaaS tworzy kod w ramach tych obowiązków. o ile natomiast po pracy tworzy własną grę lub narzędzie niezwiązane z zakresem stanowiska, sam fakt zatrudnienia w spółce technologicznej nie powinien przesądzać o nabyciu praw przez pracodawcę.
Kluczowa jest też chwila przyjęcia utworu. Pracodawca może utwór przyjąć, uzależnić przyjęcie od zmian albo go odrzucić. o ile strony nie określiły terminu, ustawa przewiduje sześć miesięcy na zawiadomienie twórcy o przyjęciu, uzależnieniu przyjęcia od zmian albo odmowie przyjęcia. Brak informacji w tym czasie prowadzi do uznania utworu za przyjęty bez zastrzeżeń.
W praktyce firmy często nie dokumentują tego etapu. Przy prostych, powtarzalnych rezultatach bywa to operacyjnie zrozumiałe, ale przy istotnym oprogramowaniu, materiałach brandingowych lub dokumentacji produktowej warto pozostawić ślad: zgłoszenie w systemie projektowym, odbiór sprintu, protokół albo akceptację osoby uprawnionej po stronie pracodawcy. Taka dokumentacja porządkuje nie tylko proces wytwórczy, ale także dowód przyjęcia utworu.
Cel zatrudnienia wyznacza granice nabycia
Ustawa odwołuje się do celu umowy o pracę i zgodnego zamiaru stron, a nie do abstrakcyjnej zasady, iż firma nabywa „wszystko”. Dlatego opis stanowiska, zakres obowiązków, regulamin pracy oraz postanowienia umowy mają realne znaczenie interpretacyjne.
W umowie warto jasno wskazać, iż do obowiązków danego pracownika należy tworzenie określonych kategorii rezultatów: oprogramowania, dokumentacji technicznej, materiałów marketingowych, projektów UX/UI, analiz czy treści edukacyjnych. Nie zastąpi to ustawowych przesłanek, ale ogranicza pole do późniejszego sporu o to, czy dany utwór powstał w ramach zatrudnienia.
Należy przy tym unikać pozornie szerokich klauzul, które mają obejmować każdą przyszłą twórczość pracownika, niezależnie od jej związku z pracą. Taki mechanizm może być nieskuteczny albo stać się zarzewiem konfliktu. Z perspektywy governance lepiej precyzyjnie określić obszar działalności, projekty i typy rezultatów niż formułować nieograniczone roszczenie do cudzej aktywności twórczej.
Autorskie prawa majątkowe to nie prawa osobiste
Pracodawca może nabyć autorskie prawa majątkowe, czyli w szczególności prawo do korzystania z utworu i rozporządzania nim w określonych polach eksploatacji. Autorskie prawa osobiste pozostają natomiast przy twórcy. Są niezbywalne i co do zasady nie można się ich skutecznie zrzec.
W praktyce chodzi między innymi o autorstwo utworu, oznaczenie go nazwiskiem lub pseudonimem, decydowanie o pierwszym udostępnieniu publiczności oraz nadzór nad sposobem korzystania z utworu. Pracodawca nie staje się więc „autorem” kodu czy projektu tylko dlatego, iż nabył prawa majątkowe.
To nie musi utrudniać działalności biznesowej. Umowa lub regulamin mogą zawierać zgody i zobowiązania dotyczące wykonywania praw osobistych w sposób, który pozwala spółce normalnie rozwijać, modyfikować i publikować produkt. Trzeba jednak rozróżniać takie uzgodnienia od deklaracji przeniesienia praw osobistych, która nie odpowiada konstrukcji polskiego prawa autorskiego.
Program komputerowy: istotny wyjątek dla zespołów IT
W przypadku programu komputerowego obowiązuje szczególna reguła. o ile program został stworzony przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy, autorskie prawa majątkowe przysługują pracodawcy już z mocy ustawy, o ile umowa nie stanowi inaczej. Nie trzeba więc oczekiwać na przyjęcie programu w trybie adekwatnym dla ogólnej regulacji utworów pracowniczych.
Dla spółek technologicznych jest to ważne ułatwienie, ale nie powinno prowadzić do fałszywego poczucia pełnego bezpieczeństwa. Po pierwsze, wyjątek dotyczy programu komputerowego, a nie automatycznie wszystkich elementów projektu: tekstów, grafik, makiet, baz materiałów szkoleniowych czy nagrań. Po drugie, przez cały czas trzeba wykazać związek między stworzeniem programu a obowiązkami pracownika.
W projektach produktowych kod rzadko powstaje w izolacji. Jedna osoba tworzy bibliotekę, inna konfigurację infrastruktury, kolejna dokumentację lub model danych. W razie inwestycji albo sprzedaży spółki trzeba umieć wykazać, kto tworzył poszczególne elementy i na jakiej podstawie firma nabyła do nich prawa. Repozytorium bez spójnej dokumentacji współpracy nie zawsze rozwiązuje ten problem.
Umowa o pracę, B2B i kooperacja z freelancerem
Najczęstszy błąd polega na przenoszeniu zasad dotyczących pracownika na współpracownika B2B. Art. 12 ustawy odnosi się do stosunku pracy. Kontraktor prowadzący działalność gospodarczą, członek zespołu na umowie zlecenia czy freelancer nie staje się pracownikiem tylko dlatego, iż pracuje wyłącznie dla jednej spółki, korzysta z jej narzędzi i uczestniczy w codziennych spotkaniach.
W relacji B2B prawa autorskie majątkowe pozostają zasadniczo przy twórcy, chyba iż umowa wyraźnie przewiduje ich przeniesienie albo odpowiednio szeroką licencję. Przeniesienie praw wymaga formy pisemnej pod rygorem nieważności. W obrocie elektronicznym zwykła wymiana e-maili, kliknięcie akceptacji regulaminu czy wiadomość w komunikatorze nie zawsze spełni ten wymóg.
Umowa powinna określać pola eksploatacji, czyli sposoby korzystania z utworu. W przypadku systemu trzeba rozważyć co najmniej utrwalanie i zwielokrotnianie, wprowadzanie zmian, rozpowszechnianie, udostępnianie w modelu chmurowym oraz korzystanie w ramach produktów oferowanych klientom. Nie wystarczy ogólne zdanie o przeniesieniu „wszelkich praw”. Zakres powinien odpowiadać rzeczywistemu modelowi biznesowemu spółki.
Warto również pamiętać o ograniczeniu dotyczącym nieznanych pól eksploatacji. Umowa nie może skutecznie obejmować pól, które w chwili jej zawarcia nie są znane. W gwałtownie zmieniającym się otoczeniu technologicznym nie oznacza to bezradności, ale potrzebę okresowego przeglądu wzorców umownych, zwłaszcza gdy firma zaczyna komercjalizować produkt w nowym kanale.
AI, materiały wejściowe i cudze komponenty
Generatywna AI komplikuje ocenę, ale nie zmienia podstawowego pytania: czy rezultat jest utworem i kto wniósł twórczy wkład? Obraz wygenerowany wyłącznie przez system, bez twórczego wkładu człowieka w finalną postać rezultatu, może nie korzystać z ochrony prawa autorskiego. Inaczej może wyglądać sytuacja, gdy pracownik dokonuje autorskiej selekcji, edycji, kompozycji lub łączy wiele elementów w samodzielną całość.
Dla pracodawcy istotne są także warunki korzystania z narzędzia AI, legalność materiałów wejściowych, poufność promptów oraz ryzyko wykorzystania cudzych elementów. Nabycie praw od pracownika nie usuwa problemu, o ile pracownik włączył do produktu kod na licencji niezgodnej z modelem dystrybucji, skopiował cudzą grafikę albo przesłał do zewnętrznego modelu dane objęte tajemnicą przedsiębiorstwa.
Zarządzanie prawami autorskimi powinno więc być połączone z polityką open source, zasadami używania AI i ochroną informacji poufnych. Są to odrębne reżimy, ale w praktyce ryzyka spotykają się w tym samym produkcie.
Co powinien sprawdzić zarząd przed wdrożeniem lub transakcją?
Najbardziej użyteczny audyt nie zaczyna się od deklaracji, iż „wszystko należy do spółki”, ale od mapy twórczości. Należy ustalić, kto tworzył najważniejsze elementy produktu, na jakiej podstawie współpracował ze spółką, czy jego obowiązki obejmowały tę twórczość oraz czy istnieją dokumenty potwierdzające nabycie lub licencję.
Szczególnej uwagi wymagają założyciele, byli członkowie zarządu, programiści B2B, agencje kreatywne oraz osoby pracujące na pograniczu etatu i kontraktu. W tych relacjach najczęściej ujawniają się luki, gdy produkt zaczyna mieć istotną wartość gospodarczą.
Dobrze przygotowana dokumentacja nie służy wyłącznie na wypadek sporu. Ułatwia licencjonowanie, negocjacje z inwestorem, rozwój produktu przez nowy zespół i wykazanie, iż spółka kontroluje podstawowe aktywa niematerialne. Najlepszy moment na uporządkowanie praw to chwila przed rozpoczęciem projektu, a nie dzień, w którym potencjalny inwestor pyta, kto rzeczywiście jest właścicielem kodu.
