Twój pracodawca używa twoich prywatnych projektów czy może tak robić zasady utworów pracowniczych

Po co ci wiedza o utworach pracowniczych i projektach prywatnych

Twórcy zatrudnieni na etacie – programiści, graficy, fotografowie, copywriterzy, researcherzy – coraz częściej mają własne poboczne projekty. Portfolio, blog, wtyczka open source, kurs online czy własna marka graficzna potrafią być więcej warte niż miesięczna pensja. Gdy pracodawca zaczyna korzystać z takich projektów albo zgłasza do nich roszczenia, zwykle jest już za późno na spokojną rozmowę.

Różnica między „utworem pracowniczym” a „projektem prywatnym” decyduje o tym, kto ma prawa do kodu, grafik, zdjęć, tekstów czy baz danych, które tworzysz. Od tego zależy, czy możesz legalnie rozwijać własne portfolio, sprzedawać licencje, a nawet założyć kiedyś własną firmę, nie ryzykując sporu z byłym pracodawcą.

Czym jest „utwór pracowniczy” i dlaczego to ma znaczenie

Definicja utworu w prawie autorskim

Podstawa to rozróżnienie, co w ogóle jest „utworem” w rozumieniu prawa autorskiego. Ustawa o prawie autorskim i prawach pokrewnych (dalej: pr.aut.) mówi w uproszczeniu, że utwór to każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci.

Przekładając na praktykę: utworem może być kod źródłowy modułu aplikacji, projekt logo, zdjęcie produktu, artykuł blogowy, scenariusz kampanii reklamowej, projekt UX, dokumentacja techniczna, a czasem nawet specyficzny raport z badań, jeśli ma indywidualny charakter. Zwykłe, powtarzalne, szablonowe czynności – jak wklepywanie danych do Excela, wypisywanie etykiet czy przenoszenie treści bez modyfikacji – nie tworzą utworu w rozumieniu prawa.

Kluczowe cechy utworu w codziennej pracy twórcy:

• jest efektem twoich decyzji twórczych (wybór rozwiązań, styl, treść),
• ma indywidualny charakter – nie jest mechanicznym powieleniem cudzego wzoru,
• jest utrwalony – zapisany w pliku, wysłany mailem, zapisany w repozytorium, opublikowany.

To oznacza, że w jednym dniu pracy możesz wykonać zarówno czynności całkiem nietwórcze (np. kopiowanie danych), jak i tworzyć utwory (np. skrypt do automatyzacji, projekt materiałów reklamowych). Prawa autorskie powstają tylko tam, gdzie jest utwór.

Różnica między utworem a zwykłą czynnością służbową

Granica między „utworem” a „zwykłą czynnością” bywa rozmyta, ale dla relacji pracownik–pracodawca ma ogromne znaczenie. Przykłady:

• Wypełnianie arkusza Excela według otrzymanego wzoru – to realizacja polecenia służbowego, ale bez własnego wkładu twórczego. Brak utworu, brak praw autorskich.
• Stworzenie złożonego arkusza z formułami, makrami i strukturą raportową, którą samodzielnie zaprojektowałeś – to już może być utwór, bo angażuje twórcze myślenie, dobór rozwiązań, sposób prezentacji.
• Przepisanie tekstu z PDF do edytora – bez twórczości.
• Redakcja tekstu z istotnymi zmianami w strukturze, stylu i treści – może być nowym utworem zależnym.

To rozróżnienie odpowiada na częsty błąd: „skoro coś zrobiłem w pracy, to pracodawca ma do tego prawa autorskie”. Nie zawsze. Jeśli to nie jest utwór, prawa autorskie w ogóle nie powstają. Jeśli jest utworem, dopiero wtedy wchodzimy w analizę, czy jest to utwór pracowniczy, czy też projekt prywatny.

Utwór pracowniczy w ustawie o prawie autorskim

Polskie prawo wprowadza szczególną konstrukcję dla utworów tworzonych przez pracowników. Ogólna zasada (w dużym skrócie): jeśli utwór stworzysz w ramach wykonywania obowiązków ze stosunku pracy, to pracodawca nabywa majątkowe prawa autorskie w chwili przyjęcia utworu, chyba że umowa stanowi inaczej.

To jest tzw. utwór pracowniczy. Ma on trzy kluczowe elementy:

• jest utworem w ogóle (czyli przejawem twórczości),
• został stworzony przez pracownika zatrudnionego na umowie o pracę,
• powstał w ramach wykonywania obowiązków pracowniczych.

Dopiero spełnienie tych warunków „odpala” domniemanie, że pracodawca z automatu dostaje majątkowe prawa autorskie. Nie ma go przy umowach zlecenia czy B2B (chyba że wpisano podobną konstrukcję w kontrakt). Nie obejmuje ono praw osobistych – o tym dalej.

Czym utwór pracowniczy różni się od dzieła freelancera

Jeśli tworzysz jako freelancer (B2B, umowa o dzieło, zlecenie), domyślna zasada jest inna: to ty jako twórca zachowujesz prawa majątkowe, a zamawiający musi je od ciebie wyraźnie nabyć (poprzez przeniesienie praw lub licencję). Bez odpowiednich klauzul prawa majątkowe zostają przy tobie.

W przypadku pracownika etatowego ustawodawca odwrócił logikę. Domyślnie to pracodawca staje się uprawniony do korzystania z utworów powstałych w ramach obowiązków pracowniczych, nawet jeśli umowa milczy na temat praw autorskich.

Porównanie można ująć w prostej tabeli:

Cecha	Pracownik etatowy (utwór pracowniczy)	Freelancer / B2B (dzieło zewnętrzne)
Domyślne przypisanie praw majątkowych	Pracodawca, jeśli utwór powstał w ramach obowiązków	Twórca (wykonawca), chyba że przeniesie prawa
Moment nabycia praw	Chwila przyjęcia utworu przez pracodawcę	Określony w umowie (np. w chwili zapłaty)
Konieczność szczegółowej umowy IP	Nie jest wymagana dla minimum, ale zwykle ją się rozszerza	W praktyce konieczna, inaczej prawa zostają przy twórcy
Dalsze wykorzystanie w portfolio	Ograniczone przez interes pracodawcy i tajemnicę	Zależy od umowy – często możliwe z anonimizacją

Z tego powodu ten sam twórca – raz jako etatowiec, raz jako freelancer – funkcjonuje pod zupełnie odmiennym reżimem prawnym, nawet jeśli robi podobne rzeczy. To rodzi konflikty, gdy zaczyna budować własne projekty równolegle z pracą na etacie.

Dlaczego samo „bycie w firmie” nie oznacza, że wszystko należy do pracodawcy

Częsty mit mówi: „skoro jesteś zatrudniony jako programista/grafik/fotograf, wszystko co stworzysz w czasie zatrudnienia należy do firmy”. Tak nie jest. Musi być spełnione kryterium w ramach obowiązków pracowniczych. Sam fakt istnienia umowy o pracę nie sprawia, że twój prywatny blog, autorski kurs online czy portfolio ilustracji automatycznie stają się własnością pracodawcy.

Owszem, niektóre umowy próbują rozszerzać przejęcie praw na „wszelkie utwory stworzone w czasie trwania stosunku pracy”, ale takie postanowienia trzeba czytać z uwzględnieniem kodeksu pracy, zasady swobody pracy i ograniczeń prawa autorskiego. Bardzo szerokie klauzule mogą być w praktyce niewykonalne, niezgodne z zasadami współżycia społecznego, a czasem po prostu nieskuteczne wobec części utworów.

Zanim więc zgodzisz się, by pracodawca korzystał z twoich prywatnych projektów, trzeba sprawdzić, czy rzeczywiście mają status „utworów pracowniczych”, czy są odrębną twórczością, do której to ty zachowujesz prawa majątkowe.

Granica między projektem służbowym a prywatnym

Kryterium zakresu obowiązków

Najważniejszym punktem rozgraniczenia jest to, czy dany utwór powstał w zakresie twoich obowiązków pracowniczych. „Zakres” nie oznacza wyłącznie tego, co nazwane jest w tytule stanowiska. Liczy się:

• opis stanowiska w umowie o pracę lub załączniku,
• zakres obowiązków wręczony przy zatrudnieniu,
• realne, utrwalone w czasie polecenia przełożonych,
• typowe zadania działu, w którym pracujesz.

Jeśli jesteś zatrudniony jako frontend developer, to tworzenie interfejsów aplikacji firmowej, komponentów, stylów i skryptów będzie co do zasady mieścić się w obowiązkach. Jeśli jednak w wolnym czasie napisałeś grę mobilną, która nie ma żadnego związku z produktami pracodawcy, trudno mówić, że to utwór pracowniczy – nawet jeśli wykorzystałeś umiejętności nabyte w firmie.

Granica bywa cienka np. u grafików: projekt layoutu kampanii dla klienta agencji – utwór pracowniczy. Cykl ilustracji fantasy publikowanych na twoim Instagramie – z reguły projekt prywatny, o ile nie korzystasz bezprawnie z materiałów klientów ani nie realizujesz zleceń konkurencyjnych w godzinach pracy.

Kryterium czasu i miejsca tworzenia

Czas i miejsce nie są decydujące same w sobie, ale mocno ważą w ewentualnym sporze. Można wyróżnić kilka sytuacji:

• Twórczość w godzinach pracy, na firmowym sprzęcie, do zadań służbowych – najsilniejsza przesłanka za uznaniem utworu za pracowniczy.
• Twórczość po godzinach, w domu, na własnym sprzęcie – silny argument za tym, że to projekt prywatny, choć nie przesądza, jeśli ewidentnie wykonujesz zadania służbowe „po godzinach”.
• Twórczość w czasie pracy, ale niezwiązana z zadaniami – np. piszesz prywatny e-book w biurze zamiast robić projekt dla klienta. Prawa autorskie do tego e-booka nie przechodzą automatycznie na pracodawcę, ale możesz narazić się na konsekwencje pracownicze (naruszenie obowiązków, dyscyplinarka).

Sam fakt, że coś powstało „w czasie pracy” nie decyduje jeszcze o losie praw. Jednak w praktyce pracodawca w sporze będzie powoływał się właśnie na logikę: skoro tworzysz w godzinach służbowych, to znaczy, że wykonujesz obowiązki pracownicze. Dobrze, by prywatne side projects miały wyraźne ślady powstawania po godzinach i poza środowiskiem firmowym.

Kryterium związku z profilem działalności pracodawcy

Istotny jest także związek tematyczny i funkcjonalny utworu z działalnością firmy. Programista zatrudniony w software house tworzący aplikację dla branży finansowej może po godzinach napisać narzędzie do zarządzania budżetem domowym. Czy to projekt prywatny, czy już zbyt blisko działalności firmy?

Tu wchodzi kryterium: czy w ten sposób realizujesz obowiązki wobec pracodawcy, czy tworzysz niezależny produkt. Samo pokrewieństwo branży nie zamienia automatycznie prywatnego projektu w utwór pracowniczy. Jednak im bardziej twoje dzieło przypomina produkty, których tworzenie jest twoim etatowym zadaniem, tym łatwiej pracodawca może próbować twierdzić, że jest to rozwinięcie pracy służbowej.

Znaczenie ma także to, czy wykorzystujesz:

• tajemnice przedsiębiorstwa (nietypowe rozwiązania, know-how, dane klientów),
• niewydane jeszcze pomysły firmy,
• elementy kodu lub plików, do których masz dostęp jako pracownik.

Sądy patrzą surowo na sytuacje, gdy ktoś „wynosi” know-how i produkty z pracy, nawet jeśli formalnie robi to po godzinach. Z drugiej strony, sama znajomość branży czy ogólnych rozwiązań technologicznych nie jest jeszcze tajemnicą przedsiębiorstwa.

Różnice branżowe: gdzie najczęściej iskrzy

Granice między projektem służbowym a prywatnym są różne w zależności od zawodu.

Programiści i inżynierowie oprogramowania

Typowe konflikty pojawiają się przy:

• własnych frameworkach i bibliotekach podobnych do rozwiązań firmowych,
• wtyczkach i modułach do tych samych systemów, które rozwija pracodawca,
• projektach open source tworzonych po godzinach, ale inspirowanych zadaniami z pracy.

Pracodawcy nieraz próbują twierdzić, że skoro coś „wynika z pracy zawodowej” i służy podobnym celom, to jest ich. Sąd będzie badał m.in. zakres obowiązków i to, czy projekt jest bezpośrednim rozwinięciem kodu firmowego.

Graficy, UX designerzy, ilustratorzy

U grafików problemem jest zwłaszcza korzystanie dwa razy z tych samych pomysłów czy layoutów. Projekt logo dla klienta agencji jest utworem pracowniczym, ale cykl ilustracji w tym samym stylu dla prywatnego zleceniodawcy to co do zasady nowy utwór. Spór pojawia się, gdy:

Fotografowie, filmowcy, twórcy contentu

Przy pracy z obrazem zderzają się dwa światy: komercyjne zlecenia i prywatne portfolio. Sesja zdjęciowa wykonana dla klienta agencji reklamowej – wraz z obróbką – to utwór pracowniczy. Jednak ta sama fotografka, która w weekend robi prywatny projekt street photo, tworzy odrębne utwory, nawet jeśli używa tego samego aparatu i podobnej techniki.

Iskry lecą wtedy, gdy:

• materiały z sesji komercyjnej „wpadają” do prywatnego portfolio bez zgody pracodawcy lub klienta,
• pracownik robi „na boku” zlecenia dla klientów konkurencyjnych wobec pracodawcy, używając tego samego stylu i kontaktów,
• filmowiec montuje prywatny showreel z ujęć, do których prawa majątkowe ma wyłącznie pracodawca.

Różnica między „materiałem referencyjnym” a „nowym utworem” bywa kluczowa. Pokazanie samego efektu końcowego (np. reklamy, przy której pracowałeś w agencji) jako części CV jest czym innym niż sprzedawanie fragmentów tego materiału jako własnego stock footage.

Naukowcy, R&D, branża medyczna i techniczna

Osobną kategorią są osoby tworzące rozwiązania badawcze i wynalazki. Tu zbiegają się przepisy prawa autorskiego, prawa własności przemysłowej i często regulaminy uczelni lub centrów badawczo-rozwojowych.

Typowe zapalniki to:

• publikacje naukowe oparte na wynikach badań finansowanych przez pracodawcę,
• oprogramowanie lub urządzenia wywodzące się z projektów grantowych,
• założenie prywatnego startupu komercjalizującego rozwiązanie podobne do tego rozwijanego w instytucie.

W odróżnieniu od klasycznego „utworu pracowniczego” kwestie te często są regulowane dodatkowo w politykach własności intelektualnej danej jednostki. Kto ma prawa do patentu, kto do kodu, a kto do publikacji – to osobne zagadnienie, ale wspólny mianownik jest ten sam: jeśli dane rozwiązanie powstało w ramach obowiązków pracowniczych i z użyciem infrastruktury badawczej pracodawcy, trudno traktować je jako całkowicie prywatny side project.

Co pracodawca dostaje „z automatu”, a co wymaga wyraźnych ustaleń

Automatyczne nabycie praw do utworu pracowniczego

W przypadku umowy o pracę, jeśli powstaje utwór w ramach obowiązków, pracodawca nabywa majątkowe prawa autorskie z mocy ustawy. Dzieje się to w momencie przyjęcia utworu, czyli gdy pracodawca akceptuje rezultat pracy (np. zatwierdza projekt, wdraża kod do produkcji, publikuje grafikę).

Ten „automat” ma jednak kilka ograniczeń:

• obejmuje tylko utwory stworzone w zakresie obowiązków,
• dotyczy tylko pól eksploatacji odpowiadających celowi umowy o pracę i charakterowi zakładu,
• nie pozwala na „zawłaszczenie na przyszłość” wszystkiego, co kiedykolwiek stworzysz, bez związku z pracą.

Jeśli więc programista zatrudniony w software house tworzy kod aplikacji dla klienta – pracodawca nabywa do niego prawa majątkowe. Ale już autorski skrypt do automatyzacji domowych finansów, pisany po godzinach i niewchodzący do produktów firmy, nie jest objęty tym mechanizmem.

Zakres pól eksploatacji: gdzie kończy się „automat”

Kluczowe jest pytanie: w jaki sposób pracodawca może korzystać z utworu pracowniczego bez dodatkowych ustaleń. Ustawa zakłada, że zakres ten wyznacza:

• cel umowy o pracę (np. tworzenie oprogramowania na zlecenie klientów),
• rodzaj działalności pracodawcy (np. agencja reklamowa, wydawnictwo, dom produkcyjny).

Jeśli pracodawca zaczyna wykorzystywać utwór w sposób jakościowo inny – np. sprzedaje ilustracje pracownika jako wzory na produktach konsumenckich, choć firma dotąd zajmowała się wyłącznie kampaniami B2B – pojawia się pytanie, czy mieści się to jeszcze w domyślnym zakresie nabycia praw, czy wymaga dodatkowej zgody lub wynagrodzenia.

W praktyce pracodawcy, którzy planują szeroką monetyzację treści (np. platformy e-learningowe, wydawcy gier, fintechy), wprowadzają do umów bardzo szerokie wyliczenie pól eksploatacji, aby zminimalizować ryzyko sporów o „nowe zastosowania” utworu.

Czego pracodawca nie dostaje bez wyraźnej umowy

Są obszary, które bez osobnej umowy są dla pracodawcy zamknięte lub mocno ograniczone:

• prawo do modyfikowania niektórych utworów osobistych – np. w przypadku niektórych dzieł artystycznych ingerencja w formę może naruszać prawa osobiste twórcy,
• wykorzystanie wizerunku pracownika – jeśli oprócz utworu utrwalono czyjąś twarz, potrzebna jest odrębna zgoda na rozpowszechnianie wizerunku,
• przeniesienie praw do utworów niepracowniczych – blog, kurs online, prywatna aplikacja nadal należą do pracownika, dopóki nie podpisze umowy przekazującej prawa lub licencję,
• przyszłe, nieokreślone utwory – ogólnikowe sformułowania typu „wszystko, co stworzysz kiedykolwiek podczas zatrudnienia” będzie interpretowane zawężająco.

Rozróżnienie jest proste: to, co powstało w ramach obowiązków, pracodawca dostaje „w pakiecie” z umową o pracę (w rozsądnym zakresie). Wszystko inne wymaga dodatkowego, świadomego przeniesienia praw lub udzielenia licencji.

Licencja vs przeniesienie praw – dwa modele współpracy

Pracodawca może chcieć czerpać korzyści także z twoich prywatnych projektów. Służą temu dwa podstawowe instrumenty:

• przeniesienie autorskich praw majątkowych – pracodawca staje się nowym właścicielem praw; ty tracisz możliwość swobodnego decydowania o komercyjnym wykorzystaniu utworu,
• licencja (wyłączna lub niewyłączna) – nadal jesteś właścicielem praw, ale udzielasz pracodawcy upoważnienia do określonych form korzystania.

Jeśli twój side project ma dla ciebie duże znaczenie (np. planujesz go dalej rozwijać lub sprzedawać), licencja – najlepiej niewyłączna, na konkretnych polach eksploatacji – daje więcej bezpieczeństwa. Pełne przeniesienie praw ma sens raczej wtedy, gdy to pracodawca przejmuje rozwój produktu, finansuje go i bierze na siebie ryzyko biznesowe.

Projekty poboczne (side projects) pracownika – typowe scenariusze

Side project z innej bajki niż działalność firmy

Najczystsza sytuacja to projekt zupełnie oderwany od obszaru działalności pracodawcy. Programista fintechowy, który po godzinach tworzy aplikację do nauki języków, albo grafik z agencji reklamowej robiący grę planszową.

Jeśli przy takim projekcie:

• pracujesz po godzinach,
• używasz własnego sprzętu lub legalnie nabytego oprogramowania,
• nie korzystasz z danych, kodu ani materiałów pracodawcy,
• nie łamiesz zakazu konkurencji (jeśli go masz),

to ryzyko roszczeń pracodawcy jest stosunkowo niewielkie. Konflikty powstają zwykle dopiero wtedy, gdy projekt osiąga komercyjny sukces i pracodawca „przypomina sobie”, że twórca jest jego pracownikiem. W sporze i tak kluczowa będzie analiza, czy projekt mieścił się w zakresie obowiązków lub działalności konkurencyjnej.

Side project „w tej samej branży” co pracodawca

Trudniejszy przypadek to poboczny projekt dotykający tej samej branży, w której działa pracodawca. Przykłady:

• developer z e-commerce tworzy własną wtyczkę do popularnej platformy sklepowej,
• analityk danych z firmy marketingowej pisze narzędzie do raportowania kampanii social media,
• UX designer z software house projektuje po godzinach szablony UX sprzedawane na marketplace.

Tutaj kluczowe są trzy pytania:

1. Czy projekt jest bezpośrednim rozwinięciem lub modyfikacją rozwiązań firmowych? Jeśli bazuje na tym samym kodzie lub unikalnym know-how, pracodawca ma silniejsze argumenty.
2. Czy stanowi realną konkurencję dla produktów lub usług firmy? Zakaz konkurencji – umowny lub ustawowy – może ograniczać możliwość samodzielnej komercjalizacji projektu.
3. Czy był tworzony faktycznie w ramach obowiązków? Jeżeli przełożony nie wiedział o projekcie i nie zlecał go, trudniej przypisać mu status „utworu pracowniczego”, choć profil branżowy może rodzić spór.

Im bliżej projektowi do „miniaturowej wersji” produktu pracodawcy, tym rozsądniej rozważyć otwartą rozmowę i ewentualne uregulowanie zasad na piśmie – choćby po to, by uniknąć zarzutu nielojalności lub działania na szkodę firmy.

Side project rozwijany z wiedzą i przy cichym przyzwoleniu przełożonego

Dość typowy scenariusz: pracownik rozwija swój projekt, szef o nim wie, nawet go chwali, ale żadna ze stron nie spisuje ustaleń. Dopóki projekt jest mały, wszystko działa na zasadzie „jakoś to będzie”. Problemy startują, gdy:

• projekt zaczyna generować realne przychody,
• pojawia się inwestor zewnętrzny i robi due diligence praw autorskich,
• drogi pracownika i pracodawcy się rozchodzą w nie najlepszej atmosferze.

W takim układzie brak umowy działa na niekorzyść obu stron. Pracownik nie ma pisemnego potwierdzenia, że pracodawca zrzeka się roszczeń do side projectu; pracodawca nie ma kontroli nad tym, czy projekt nie „podbierze” mu klientów lub zespołu.

Dla obu praktyczniejsze jest krótkie porozumienie, które rozdziela pola eksploatacji: np. pracodawca zgadza się na prywatny projekt w zamian za gwarancję braku konkurencji na określonym rynku lub prawo współdecydowania, gdyby projekt był sprzedawany dużemu konkurentowi.

Side project budowany na technologii open source

Open source dodatkowo komplikuje obraz. Programista może jednocześnie:

• kontrybuować do open source w ramach obowiązków służbowych,
• rozwijać własny projekt open source lub komercyjny, oparty o te same biblioteki.

Tu znaczenie ma:

• czy wkład do projektu open source jest elementem etatowych obowiązków (np. firma utrzymuje bibliotekę),
• jakie warunki licencyjne ma używane oprogramowanie (np. copyleft vs permissive),
• czy pracownik nie przenosi do prywatnego repozytorium kodu, który powstał w ramach pracy.

Jeśli część kodu pisałeś wyłącznie na potrzeby firmy, w czasie pracy i w ramach obowiązków, przeniesienie go 1:1 do własnego side projectu może być naruszeniem praw pracodawcy, nawet gdy sam projekt ma otwartą licencję. Z drugiej strony, używanie tych samych publicznych bibliotek open source w pracy i w projektach prywatnych jest co do zasady dopuszczalne, o ile respektujesz ich licencję.

Side project zamienia się w biznes: kiedy zapala się czerwona lampka

Dopóki side project jest hobbystyczny, większość pracodawców nie wnika w szczegóły. Sytuacja zmienia się, gdy:

• pojawiają się inwestorzy lub wspólnicy z zewnątrz,
• projekt wymaga pełnego zaangażowania twórcy i wpływa na jego dyspozycyjność w pracy,
• firma zaczyna postrzegać projekt jako realną konkurencję lub „ucieczkę” know-how.

Na tym etapie różnica między umową o pracę a B2B staje się szczególnie widoczna. Etatowy pracownik jest związany szeregiem obowiązków lojalnościowych wobec pracodawcy; kontraktor B2B – poza zakazem konkurencji i tajemnicą przedsiębiorstwa – ma większą swobodę budowania własnego biznesu. W obu przypadkach brak klarownych ustaleń na początku bywa jednak kosztowny.

Umowa o pracę i B2B: kluczowe zapisy decydujące o losie prywatnych projektów

Konstrukcja typowej umowy o pracę pod kątem praw autorskich

Standardowa umowa o pracę w zawodach kreatywnych zawiera zwykle:

• ogólny opis stanowiska i obowiązków,
• klauzulę o przejściu majątkowych praw autorskich do utworów stworzonych w ramach obowiązków,
• wyliczenie pól eksploatacji, na których pracodawca może korzystać z utworów,
• postanowienia o tajemnicy przedsiębiorstwa i ewentualnym zakazie konkurencji.

To, czego często brakuje, to rozróżnienie między twórczością służbową a prywatną. Jeśli umowa mówi wyłącznie o „utworach stworzonych w ramach obowiązków”, pozostawia więcej pola do interpretacji na korzyść pracownika. Gdy pojawiają się szerokie sformułowania o „wszelkich utworach stworzonych w czasie trwania stosunku pracy”, trzeba dokładnie analizować, jak są wpuszczane w obieg przez praktykę sądową.

B2B i umowy cywilnoprawne: większa swoboda, większa odpowiedzialność

Jak B2B zmienia rozkład sił między stronami

W relacji B2B teoretycznie spotykają się dwa podmioty profesjonalne. Ustawowe „automaty” z Kodeksu pracy nie działają, więc o losie praw autorskich decyduje głównie umowa i przepisy ogólne prawa autorskiego. Zwykle oznacza to:

• większą swobodę negocjacji – strony mogą precyzyjnie ustalić, które utwory są „dla klienta”, a które zostają przy wykonawcy,
• większe ryzyko nadmiernie szerokich cesji – agencje i software house’y próbują często „wciągnąć” w umowę wszystko, co kontraktor tworzy w ogóle,
• brak domyślnej ochrony pracownika – sąd nie będzie patrzył przez pryzmat prawa pracy, tylko równości profesjonalnych stron.

W praktyce wiele umów B2B zawiera klauzule kopiujące etatowe rozwiązania („utwory stworzone w ramach świadczenia usług przechodzą na zamawiającego”), ale dorzuca się do nich postanowienia dotyczące także projektów pobocznych. Różnica polega na tym, że kontraktor może – i powinien – te zapisy negocjować, szczególnie gdy równolegle buduje własny produkt.

Jak czytać klauzule o „wszelkich utworach” w kontraktach B2B

W umowach B2B często pojawia się sformułowanie typu:

„Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do wszelkich utworów stworzonych w okresie obowiązywania umowy.”

Na pierwszy rzut oka wygląda to groźniej niż w etacie, bo nie odwołuje się do „obowiązków służbowych”, tylko do samego okresu współpracy. Kluczowe różnice między etatem a B2B są tutaj trzy:

1. Cel gospodarczy umowy – w B2B łatwiej wykazać, że klauzula powinna dotyczyć tylko utworów związanych z realizacją świadczeń, nie prywatnego bloga czy aplikacji do medytacji.
2. Możliwość negocjacji – kontraktor może domagać się doprecyzowania: np. dodania frazy „w ramach wykonywania usług objętych niniejszą umową”.
3. Brak automatyzmu przejścia praw – bez prawidłowo opisanych pól eksploatacji przeniesienie może być nieskuteczne, podczas gdy w etacie część rzeczy „domyka” przepis o utworach pracowniczych.

Rozwiązaniem pośrednim bywa wprowadzenie dwóch kategorii twórczości: „Deliverables” (produkty tworzone dla klienta, z pełną cesją) i „Background IP” (narzędzia, biblioteki, frameworki, side projects należące do wykonawcy). Dobrze skonstruowana umowa jasno mówi, że Background IP pozostaje przy wykonawcy, a klient otrzymuje co najwyżej ograniczoną licencję na korzystanie w ramach projektu.

Side projects przy B2B: kiedy kontraktor ma łatwiej niż etatowiec

Przy umowie B2B kontraktor jest z reguły postrzegany bardziej jako niezależny przedsiębiorca niż „część organizmu” klienta. To powoduje, że:

• łatwiej obronić prowadzenie równoległego biznesu (np. SaaS sprzedawany wielu podmiotom) jako odrębnej działalności,
• ograniczenia zwykle wynikają wyłącznie z zakazu konkurencji i klauzul o poufności, a nie z ogólnego obowiązku lojalności pracowniczej,
• można wprost wpisać w umowę, że wykonawca utrzymuje swoje produkty i ma prawo je rozwijać niezależnie.

Z drugiej strony, klient może uzależnić współpracę od bardzo daleko idących cesji i zakazów konkurencji, licząc, że kontraktor zaakceptuje je „dla świętego spokoju”. Różnica w porównaniu z etatem jest taka, że przy B2B odrzucenie niekorzystnej klauzuli jest w praktyce częstsze i mniej stygmatyzujące – negocjacje są po prostu elementem gry rynkowej.

„Portfolio clause” i prawo do wykorzystania projektów w celach marketingowych

W kontraktach B2B pojawia się też inny rodzaj postanowień: prawo wykonawcy do pokazywania efektów pracy w portfolio lub w materiałach promocyjnych. Z perspektywy prywatnych projektów ta klauzula potrafi działać w obie strony:

• wykonawca chce pokazywać projekty dla klienta jako referencje – klient często się zgadza, ale zastrzega anonimizację danych,
• klient może chcieć chwalić się sukcesem produktu kontraktora, który powstał niejako „przy” współpracy (np. wspólny projekt R&D, który potem kontraktor rozwija samodzielnie).

Dobrze jest oddzielić w umowie: kto, w jakim zakresie i w jakiej formie może prezentować projekty powstałe w trakcie współpracy. Inaczej spór o prawa autorskie bardzo szybko miesza się ze sporem o reputację i wykorzystanie marki.

Sprzęt firmowy, oprogramowanie służbowe i czas pracy – czy to zmienia prawa autorskie

Czy korzystanie ze służbowego sprzętu odbiera ci prawa do projektu

Sam fakt, że piszesz kod na służbowym laptopie lub szkicujesz ilustracje na tablecie firmy, nie przenosi automatycznie praw autorskich na pracodawcę. Liczy się przede wszystkim:

• czy utwór mieści się w zakresie obowiązków,
• czy powstał na zlecenie lub za wiedzą i w interesie pracodawcy,
• jakie postanowienia zawiera umowa i regulamin korzystania ze sprzętu.

Pracodawca może natomiast podnieść inne argumenty. Jeśli regulamin wyraźnie zakazuje używania sprzętu służbowego do celów prywatnych, a side project powstał głównie w takich warunkach, może tu wchodzić w grę naruszenie obowiązków pracowniczych – choć niekoniecznie automatyczne przejęcie praw.

Konflikt wygląda inaczej, gdy projekt nie jest „z innej bajki”, lecz dotyczy tego samego segmentu co produkt firmy. Wtedy użycie służbowego sprzętu staje się kolejnym elementem układanki, wskazującym, że projekt powstawał jednak „w ramach” pracy, a nie obok niej.

Oprogramowanie licencjonowane na firmę a prywatny projekt

Przy tworzeniu side projectów pojawia się kwestia legalności korzystania z narzędzi, do których dostęp zapewnia pracodawca: płatne IDE, pakiety graficzne, narzędzia chmurowe. Tu nakładają się dwa porządki:

• prawo autorskie do utworu – komu przysługują prawa do efektu pracy,
• prawo licencyjne – czy w ogóle wolno było użyć danego narzędzia do celów prywatnych.

Typowe problemy powstają wtedy, gdy:

• licencja oprogramowania ogranicza użycie do celów firmowych, a projekt ma charakter stricte komercyjny dla pracownika,
• konto firmowe w chmurze jest wykorzystywane do hostowania prywatnej aplikacji, co generuje koszty dla pracodawcy,
• szablony, fonty lub zdjęcia z banków ilustracji licencjonowane są na rzecz firmy, a lądują w produkcie sprzedawanym przez pracownika.

W takich sytuacjach pracodawca może domagać się usunięcia elementów stworzonych z użyciem nieuprawnionych narzędzi, a licencjodawca – rościć sobie prawa za naruszenie licencji. To wciąż nie jest automatyczne przejęcie praw do całego projektu, ale realne ryzyko odpowiedzialności kontraktowej i odszkodowania.

Czas pracy: „po godzinach” kontra „na służbie”

Często pojawia się intuicja: „jeśli robię to po godzinach, to jest moje”. Godziny pracy są ważną, ale nie jedyną przesłanką. Trzeba patrzeć na kilka równoległych osi:

1. Czas – czy projekt powstaje w deklarowanych godzinach pracy czy poza nimi.
2. Miejsce – czy tworzysz w biurze lub z korzystaniem z infrastruktury firmy, czy na własnym sprzęcie.
3. Zakres obowiązków – czy prace mieszczą się w opisie stanowiska, czy wykraczają poza to, za co dostajesz wynagrodzenie.
4. Wiedza przełożonych – czy projekt jest ukryty, czy zaakceptowany (choćby ustnie).

Side project robiony po godzinach, z domu, ale idealnie mieszczący się w twoim oficjalnym „pipe-line’ie” zadań, budzi większe wątpliwości niż coś tworzonego w czasie pracy, lecz zupełnie oderwanego od profilu firmy. Sąd w sporze będzie patrzył na całość okoliczności, a nie tylko na ewidencję czasu.

„Kreatywne przerwy” w pracy a powstawanie utworu

Praktyczny przykład: developer ma w pracy tzw. bench, okres bez projektu. W tym czasie, zamiast szlifować wewnętrzne narzędzia firmy, pisze własną bibliotekę i publikuje ją na GitHubie pod swoją marką. Kluczowe pytanie brzmi: czy w okresie bencha jego obowiązkiem było „czekać na zlecenia”, czy aktywnie rozwijać narzędzia dla pracodawcy.

Jeśli w mailach lub zadaniach w systemie pojawiały się polecenia typu „proponuję, żebyś w tym czasie rozwinął moduł X do naszego produktu”, pracodawca ma argument, że energia twórcza powinna być ukierunkowana na produkt firmowy. Utwór, który zamiast tego powstał, może być postrzegany jako „ucieczka” z pola pracodawcy – nawet jeśli formalnie powstał podczas „luzu projektowego”.

Sprzęt hybrydowy i model BYOD (Bring Your Own Device)

Coraz częściej używa się jednego laptopa czy telefonu zarówno do spraw służbowych, jak i prywatnych. To zaciera dawną, prostą linię „komputer firmowy vs mój komputer”. W modelu BYOD istotne są:

• polityki bezpieczeństwa i prywatności (np. MDM, dostęp administratora do danych),
• zasady instalowania oprogramowania i przechowywania kodu źródłowego,
• sposób rozliczania kosztów (np. firma dopłaca do urządzenia lub abonamentu).

Pracodawca może mieć techniczną możliwość wglądu do zawartości urządzenia, co rodzi ryzyko, że prywatny projekt trafi do jego radarów wcześniej, niż byś się spodziewał. Jednocześnie nie oznacza to, że może bezkarnie „przejąć” kod – naruszenie prywatności i tajemnicy korespondencji to osobne, poważne zagadnienia. Różnica w porównaniu z klasycznym sprzętem firmowym polega na tym, że przy BYOD linia sporu biegnie także przez pytanie, gdzie kończy się słuszny interes pracodawcy w ochronie danych, a zaczyna sfera prywatna twórcy.

Infrastruktura firmy: serwery, repozytoria, komunikatory służbowe

Nawet jeśli kod powstaje na prywatnym laptopie, nierzadko ląduje na firmowych serwerach – w repozytorium Git, na serwerze CI/CD czy w środowisku testowym. Do tego dochodzą komunikatory (Slack, Teams), gdzie omawia się pomysły i fragmenty kodu.

Taka sytuacja spojona z side projectem niesie kilka skutków:

• ułatwia pracodawcy dokumentowanie związku między projektem a pracą (logi commitów, wątki na kanale projektowym),
• tworzy pole do zarzutu wykorzystania zasobów firmy niezgodnie z przeznaczeniem,
• może prowadzić do mieszania kodu firmowego z prywatnym w jednym repozytorium – co potem trudno oczyścić.

Jeśli firmowe repozytoria są używane do czegoś więcej niż tylko pracy dla pracodawcy, warto wyraźnie rozdzielić gałęzie, projekty i konta (np. osobne konto GitHub na prywatne projekty, nawet jeśli korzystasz z tego samego komputera). Im czytelniejszy podział środowisk, tym łatwiej później wykazać, które fragmenty kodu powstały „dla kogo”.

Porównanie: ten sam projekt przy różnym sprzęcie i czasie pracy

Ten sam side project może być postrzegany zupełnie inaczej w zależności od tego, jak był realizowany. Porównanie dwóch wariantów pomaga uchwycić różnice:

• Wariant A: aplikacja powstała w całości w domu, na prywatnym laptopie, wieczorami i w weekendy; kod nigdy nie był na firmowych serwerach; projekt nie pokrywa się z linią biznesową firmy.
• Wariant B: aplikacja zaczęła jako „eksperyment” podczas sprintu R&D w pracy, pierwsze commity znalazły się w firmowym GitLabie, projekt korzysta z tych samych bibliotek wewnętrznych i tej samej architektury co produkt firmy, a część funkcji była omawiana na zespołowych stand-upach.

W wariancie A pracodawca ma niewiele narzędzi, aby skutecznie domagać się przejęcia praw; może co najwyżej podnosić kwestię konfliktu interesów. W wariancie B dochodzi mocna przesłanka, że mamy do czynienia przynajmniej z utworem, który wyrósł na gruncie obowiązków służbowych, a nie był od nich całkowicie oderwany. Nawet jeśli finalna wersja powstała już „po godzinach”, korzenie projektu tkwią w środowisku pracy, co w sporze ma duże znaczenie.

Najczęściej zadawane pytania (FAQ)

Czy pracodawca ma prawa do każdego utworu, który stworzę w czasie zatrudnienia?

Nie. Pracodawca nabywa majątkowe prawa autorskie tylko do tzw. utworów pracowniczych, czyli takich, które powstały w ramach wykonywania twoich obowiązków ze stosunku pracy. Sam fakt, że jesteś zatrudniony na etacie, nie oznacza, że firma ma prawa do twojego prywatnego bloga, kursu online czy aplikacji stworzonej po godzinach.

Dla porównania: raport przygotowany na polecenie przełożonego, zgodnie z twoim zakresem obowiązków, będzie zwykle utworem pracowniczym. Natomiast autorski e-book o fotografii ślubnej, pisany wieczorami i niezwiązany z działalnością firmy, pozostaje twoim prywatnym projektem.

Co to dokładnie jest „utwór pracowniczy” w prawie autorskim?

Utwór pracowniczy to utwór w rozumieniu prawa autorskiego (czyli przejaw działalności twórczej o indywidualnym charakterze, utrwalony w jakiejkolwiek postaci), który został stworzony przez pracownika na umowie o pracę w ramach wykonywania jego obowiązków. Dopiero przy spełnieniu tych trzech warunków pracodawca z mocy ustawy nabywa majątkowe prawa autorskie w chwili przyjęcia utworu.

Jeśli pracujesz na B2B, umowie zlecenia albo o dzieło, to co tworzysz, nie jest „utworem pracowniczym” w tym sensie. Wtedy standardowo to ty zatrzymujesz prawa majątkowe, chyba że wyraźnie przeniesiesz je w umowie lub udzielisz licencji.

Jak odróżnić projekt prywatny od utworu pracowniczego?

Kluczowe jest to, czy dana rzecz została stworzona w ramach twoich obowiązków pracowniczych. Liczy się nie tylko nazwa stanowiska, ale też opis obowiązków, realne polecenia przełożonych i typowe zadania działu. Jeśli tworzysz coś, co realizuje cele firmy i jest efektem służbowych poleceń, to z dużym prawdopodobieństwem będzie to utwór pracowniczy.

Projekt prywatny to z kolei utwór:

• nienależący do twoich codziennych zadań służbowych,
• realizowany z własnej inicjatywy, poza strukturą zadań i procesów firmy,
• często skierowany do innego rynku lub odbiorcy niż pracodawca.

Przykład: frontend developer tworzący w pracy komponenty do firmowego panelu – to utwory pracownicze. Ten sam developer piszący po godzinach grę 2D, niezwiązaną z produktami firmy – to projekt prywatny.

Czy projekt zrobiony po godzinach zawsze jest moją wyłączną własnością?

Nie zawsze, choć często tak będzie. Godziny pracy nie są jedynym kryterium. Znaczenie ma przede wszystkim, czy projekt realizuje twoje obowiązki służbowe i czy powstał na rzecz pracodawcy. Możliwa jest sytuacja, w której robisz coś „po godzinach”, ale na wyraźne polecenie przełożonego i w ramach zadania służbowego – taki utwór nadal może być uznany za pracowniczy.

Jeśli jednak projekt powstaje:

• z twojej inicjatywy,
• bez powiązania z konkretnymi zadaniami firmowymi,
• bez korzystania z tajemnicy przedsiębiorstwa czy poufnych danych firmy,

to najczęściej zachowasz do niego majątkowe prawa autorskie jako twórca, nawet jeśli terminowo zbiega się to z okresem zatrudnienia.

Czy pracodawca może żądać praw do mojego portfolio, bloga lub wtyczki open source?

Zasadniczo nie, jeśli te projekty nie są tworzone w ramach twoich obowiązków ze stosunku pracy i nie korzystają z zasobów lub tajemnicy przedsiębiorstwa w sposób naruszający umowę. Portfolio z twoimi ilustracjami, blog z autorskimi tekstami czy wtyczka open source tworzona niezależnie od zadań firmowych są zwykle projektami prywatnymi.

Inaczej wygląda sytuacja, gdy:

• portfolio prezentuje utwory pracownicze – wtedy musisz liczyć się z ograniczeniami (tajemnica przedsiębiorstwa, NDA, zgoda na publikację),
• blog lub wtyczka powielają rozwiązania, kod lub treści, które stanowią własność pracodawcy,
• umowa o pracę zawiera szczególne, rozszerzone postanowienia o prawach autorskich.

W takiej sytuacji każde roszczenie pracodawcy trzeba analizować na tle konkretnej treści umowy i realnego zakresu twoich obowiązków.

Czy szeroka klauzula w umowie („wszystko, co stworzysz w czasie zatrudnienia należy do firmy”) jest skuteczna?

Takie klauzule pojawiają się w praktyce, ale nie działają „magicznie” na każdą sytuację. Muszą być interpretowane w świetle kodeksu pracy, podstawowych zasad prawa autorskiego i swobody pracy. Zbyt szerokie postanowienia mogą być w części niewykonalne, sprzeczne z zasadami współżycia społecznego albo po prostu nieskuteczne wobec niektórych utworów, zwłaszcza całkowicie prywatnych.

Różnica między rozsądnym a nadmiernie szerokim zapisem jest podobna jak między:

• „przeniesienie praw do utworów wykonanych w ramach obowiązków pracowniczych na rzecz pracodawcy” – co co do zasady odpowiada ustawie,
• „przeniesienie praw do wszelkich utworów stworzonych w okresie zatrudnienia, niezależnie od miejsca i czasu ich powstania” – co budzi poważne wątpliwości i zwykle wymaga ostrożnej interpretacji.

Przed podpisaniem takiej umowy warto ją skonsultować, bo później spory o granicę między życiem zawodowym a prywatną twórczością bywają kosztowne.