Spółka czy freelancer: kto ma prawa i licencję do kodu, gdy programista zmienia pracę

Krótka scenka z życia: „to mój kod” kontra „to własność firmy”

Programista z kilkuletnim doświadczeniem odchodzi z software house’u. Przed wypowiedzeniem, z przyzwyczajenia, robi prywatny fork firmowego repozytorium na GitHubie, „żeby mieć portfolio i zajrzeć kiedyś do ciekawych rozwiązań”.

Spółka po kilku dniach blokuje mu dostęp do narzędzi, zauważa prywatny fork i grozi pozwem, żądając natychmiastowego usunięcia kodu oraz złożenia oświadczeń. Zespół jest w szoku, a atmosfera gęstnieje. Na horyzoncie pojawia się jeszcze trudniejsze pytanie od kluczowego klienta: kto może dalej rozwijać i utrzymywać system oraz kto faktycznie ma do niego prawa – spółka, programista, a może obie strony?

Takie sytuacje najczęściej nie wynikają ze złej woli, lecz z niejasnych umów o prawa autorskie do kodu. Zwykła zmiana pracy lub zakończenie kontraktu B2B potrafi w kilka dni zamienić się w prawny thriller, jeśli wcześniej nie uporządkowano kwestii licencji, przeniesienia praw oraz zasad korzystania z repozytoriów.

Podstawy praw autorskich do kodu: co jest „utworem” programistycznym

Kod źródłowy, architektura, dokumentacja – kiedy w ogóle powstaje ochrona

W polskim prawie kod komputerowy jest traktowany jako utwór w rozumieniu ustawy o prawie autorskim i prawach pokrewnych, pod warunkiem, że ma indywidualny i twórczy charakter. Nie ma znaczenia, czy to wielka aplikacja SaaS, czy prosta biblioteka – istotny jest poziom oryginalności, a nie rozmiar projektu.

Za potencjalne utwory programistyczne uznaje się między innymi:

• kod źródłowy (np. w Java, Python, JavaScript, C#, PHP),
• kod wynikowy (zależnie od kontekstu, np. skompilowany, jeśli możliwe jest odtworzenie struktury),
• architekturę systemu (diagramy, specyfikacje), jeśli są twórcze,
• dokumentację techniczną i użytkową (manuale, opisy API, instrukcje),
• testy automatyczne (np. testy jednostkowe), jeśli zawierają własną twórczą strukturę i dobór przypadków testowych.

Ochrona powstaje automatycznie z chwilą stworzenia utworu, czyli w praktyce – gdy kod zostanie zapisany w formie umożliwiającej odtworzenie (plik, repozytorium, nawet notatnik). Nie trzeba nic rejestrować, zgłaszać ani oznaczać copyrightem.

Twórca a pracodawca / zleceniodawca – osobiste i majątkowe prawa autorskie

W prawie autorskim wyróżnia się dwie grupy praw:

• osobiste prawa autorskie – przysługują zawsze twórcy (osobie fizycznej) i są niezbywalne. Obejmują m.in. prawo do autorstwa, oznaczenia nazwiskiem (w kodzie często niewykonywane, ale istnieje), nienaruszalność treści i formy utworu w zakresie istotnych zniekształceń,
• majątkowe prawa autorskie – to prawo do korzystania z utworu i decydowania, kto może go wykorzystywać, na jakich polach eksploatacji oraz za jakim wynagrodzeniem. Te można przenieść (sprzedać) lub licencjonować.

Programista – czy to pracownik etatowy, czy freelancer – zawsze jest twórcą kodu w sensie osobistych praw autorskich. Nawet jeśli umowa przewiduje przeniesienie majątkowych praw na spółkę, jego status „autora” nie znika. Zmienia się jedynie to, kto może komercyjnie decydować o wykorzystaniu kodu.

Pracodawca lub zleceniodawca nigdy nie staje się twórcą. Może być nabywcą majątkowych praw autorskich (albo licencjobiorcą), ale autorstwo – w sensie prawnym – zawsze pozostaje przy programiście lub zespole programistów jako współtwórcach.

Pomysł na funkcjonalność a konkretna implementacja

Częsta pułapka w sporach o kod: mylenie pomysłu z implementacją. Sam pomysł na funkcję, moduł czy aplikację – np. „zróbmy aplikację do rezerwacji wizyt online” – nie podlega ochronie prawnoautorskiej. Chroniona jest konkretna forma wyrażenia tego pomysłu, czyli:

• konkretny kod źródłowy,
• konkretny układ ekranów i UX (do pewnego stopnia),
• konkretna architektura i struktura modułów,
• konkretne treści w dokumentacji i opisach.

Dzięki temu kilka firm może stworzyć oddzielne, podobne funkcjonalnie systemy, o ile nie kopiują wprost cudzej implementacji. To istotne zwłaszcza przy odejściu programisty do konkurencji – samo posiadanie wiedzy o działaniu systemu nie oznacza automatycznie naruszenia praw autorskich, o ile nie dochodzi do kopiowania chronionych elementów.

Czas trwania ochrony i znaczenie dla software’u komercyjnego

Ochrona majątkowych praw autorskich co do zasady trwa 70 lat od śmierci twórcy (lub ostatniego z współtwórców). Dla software’u znaczy to w praktyce, że:

• kod napisany dziś będzie formalnie chroniony jeszcze długo po tym, jak przestanie mieć techniczne znaczenie,
• spółka, która nabyła prawa lub licencję, ma obowiązek pilnować, by nie naruszać cudzych praw (np. bibliotek open source na licencji GPL), bo roszczenia mogą być wysuwane wiele lat później,
• długowieczność ochrony sprzyja wartości firmy – dobrze uregulowane prawa do kodu mogą być istotnym aktywem przy sprzedaży spółki, wejściu inwestora czy audycie due diligence.

W praktyce biznesowej najwięcej problemów rodzi nie sam czas ochrony, ale brak jasnych umów na początku. To on sprawia, że po zmianie pracy lub zakończeniu projektu strony różnie interpretują, kto i co może jeszcze robić z kodem.

Spółka vs freelancer: różne modele współpracy, różne domyślne zasady

Umowa o pracę i utwór pracowniczy: co przechodzi automatycznie

W przypadku umowy o pracę obowiązuje szczególny reżim tzw. utworu pracowniczego. W dużym uproszczeniu – jeśli programista tworzy kod:

• w ramach obowiązków pracowniczych,
• pod kierownictwem pracodawcy,
• w czasie pracy (zwykle) i z wykorzystaniem narzędzi firmy,

to majątkowe prawa autorskie do tego kodu przechodzą na pracodawcę z chwilą jego przyjęcia (co w praktyce najczęściej jest domniemane: commit do repo, przyjęcie PR, włączenie kodu do produktu). Nie wymaga to dodatkowej umowy przenoszącej prawa – ustawa przewiduje to automatycznie.

Istotne zastrzeżenie: przejście praw dotyczy konkretnych pól eksploatacji związanych z celem umowy o pracę i profilem działalności pracodawcy. Gdyby firma zaczęła wykorzystywać ten sam kod na całkowicie nowym polu eksploatacji, nieobjętym umową i celem zatrudnienia, pojawia się pole do sporu.

Umowa B2B / zlecenie: nic nie przechodzi bez zapisu w umowie

Przy współpracy z freelancerem (kontraktor B2B, zleceniobiorca, wykonawca) domyślna zasada jest odwrotna: majątkowe prawa autorskie pozostają przy twórcy, jeśli umowa nie stanowi inaczej. Samo zapłacenie faktury nie oznacza przejęcia własności praw do kodu.

Żeby spółka mogła legalnie:

• modyfikować kod,
• sprzedawać produkt oparty na tym kodzie,
• udostępniać go swoim klientom,

musi mieć w umowie jednoznaczne postanowienia dotyczące przeniesienia majątkowych prawa autorskich albo udzielenia licencji (wyłącznej lub niewyłącznej) na odpowiednich polach eksploatacji. Bez tego spółka ma co najwyżej „fakt, że zapłaciła”, ale nie solidny tytuł prawny do korzystania z oprogramowania w szerokim zakresie.

Zespół mieszany: etat, kontraktorzy, podwykonawcy

Coraz częściej projekty IT realizuje się w modelu mieszanym:

• seniorzy i część developerów – na umowę o pracę,
• specjaliści od niszowych technologii – na kontrakt B2B,
• część prac – zlecana podwykonawcom (np. zewnętrznym agencjom, jednoosobowym firmom).

W takim środowisku prawa do kodu są rozproszone. Do części kodu spółka nabywa prawa automatycznie (utwory pracownicze), do części – tylko na podstawie dobrze skonstruowanych umów z kontraktorami. Jeśli umowy te są niekompletne lub ogólnikowe, powstaje poważne ryzyko prawne.

Tego typu nieuporządkowana sytuacja może zablokować:

• wejście inwestora,
• sprzedaż spółki,
• podpisanie większego kontraktu z klientem korporacyjnym, który wymaga gwarancji co do praw do oprogramowania.

Mini-wniosek: status formalny programisty (etat vs freelance) bezpośrednio wpływa na to, kto ma prawa do kodu. W jednej i tej samej aplikacji można mieć moduły, które spółka posiada w całości, oraz moduły, gdzie jedynie „wydaje się”, że wszystko jest w porządku – dopóki ktoś nie zajrzy w treść umów.

Kto ma prawa do kodu, gdy programista pracuje na etacie

Zakres obowiązków a utwór pracowniczy: praca vs projekt „po godzinach”

Kluczem jest to, czy dany fragment kodu powstał w ramach obowiązków pracowniczych. Jeśli w umowie o pracę lub w opisie stanowiska wpisano zadania typu „rozwój i utrzymanie oprogramowania X”, to co do zasady kod tworzony w ramach tego projektu będzie utworem pracowniczym.

Jednocześnie nie wszystko, co napisał programista zatrudniony w spółce, automatycznie staje się własnością pracodawcy. Kod napisany:

• po godzinach,
• na własnym sprzęcie,
• w oderwaniu od zadań służbowych,

może być samodzielnym utworem programisty. Problem pojawia się, gdy:

• tematyka jest bardzo bliska działalności spółki,
• w kodzie pojawiają się elementy rozwiązań powstałych w pracy,
• pracodawca twierdzi, że projekt poboczny w praktyce jest kontynuacją obowiązków służbowych.

Im bardziej side project jest powiązany z tym, co robi się na co dzień dla spółki, tym większe ryzyko sporu co do tego, kto ma prawa do takiego kodu.

Moment nabycia praw przez pracodawcę i rola pól eksploatacji

Pracodawca nabywa majątkowe prawa autorskie z chwilą przyjęcia utworu. W świecie IT przyjęcie ma zazwyczaj formę faktyczną: kod został zmergowany do głównego repozytorium, wdrożony na produkcję, włączony do produktu. Nie potrzeba formalnego „protokółu przyjęcia utworu”, choć w niektórych firmach takie dokumenty się stosuje (zwłaszcza przy większych projektach).

Jednak nawet przy utworach pracowniczych kluczowe jest, na jakich polach eksploatacji pracodawca nabywa prawa. Typowe pola eksploatacji dla oprogramowania to np.:

• utrwalanie i zwielokrotnianie w pamięci komputera,
• rozpowszechnianie w formie sprzedaży/licencjonowania klientom,
• udostępnianie w modelu SaaS (świadczenie usług drogą elektroniczną),
• modyfikowanie, adaptowanie, tłumaczenie, łączenie z innym oprogramowaniem.

Jeżeli umowa o pracę albo regulamin pracy nie wskazuje precyzyjnie pól eksploatacji, stosuje się interpretację rozsądną: pracodawca może korzystać z kodu w zakresie wynikającym z charakteru jego działalności. Lepiej jednak, gdy te pola eksploatacji są jasno wymienione w umowie – wtedy przy odejściu programisty nie ma wątpliwości, że spółka może nadal rozwijać i licencjonować produkt bez pytania byłego pracownika o zgodę.

Kod do prywatnego projektu na służbowym sprzęcie – szara strefa

Typowy obrazek: developer ma chwilę „luzu” między sprintami, otwiera prywatny projekt na firmowym laptopie, korzysta z zainstalowanego IDE i w przerwach rozwija swoje narzędzie. Czasem nawet wrzuca je na GitHuba w godzinach pracy. Z punktu widzenia prawa powstają tu trzy potencjalne pola konfliktu:

1. czas pracy – czy tworzenie prywatnego projektu w godzinach pracy nie jest wykonaniem kodu „w związku z wykonywaniem obowiązków”,
2. sprzęt i oprogramowanie – czy użycie narzędzi firmowych do własnego projektu nie rodzi roszczeń spółki do efektów,
3. zakres podobieństwa – czy side project nie jest w istocie konkurencyjnym produktem opartym na know-how firmy.

Firmowe polityki i klauzule „wynalazkowe” wobec kodu

W niektórych spółkach HR wręcza przy zatrudnieniu pakiet dokumentów, w którym oprócz regulaminu pracy jest jeszcze „polityka własności intelektualnej”. Wielu developerów klika „akceptuję” bez czytania, a to tam kryją się często najbardziej dolegliwe postanowienia.

Takie polityki i klauzule potrafią przewidywać m.in., że:

• wszystko, co programista stworzy w czasie trwania umowy, należy do spółki – niezależnie od miejsca i czasu,
• pracownik ma obowiązek niezwłocznie informować o każdym pomyśle, który mógłby zostać wdrożony komercyjnie,
• spółce przysługuje pierwszeństwo do nabycia praw do rozwiązań powstałych nawet poza zakresem obowiązków.

Nie każda taka klauzula utrzyma się przed sądem. Prawo pracy i przepisy o prawie autorskim ograniczają możliwość „zawłaszczenia” wszystkiego, co zrobi pracownik w życiu prywatnym. Z drugiej strony, im bardziej projekt poboczny zahacza o realny biznes spółki, tym większe szanse, że pracodawca powoła się na te postanowienia i spróbuje przejąć przynajmniej część korzyści.

Mini-wniosek: zanim wyśle się pierwszego commita do własnego produktu SaaS, lepiej przeczytać nie tylko umowę o pracę, ale też załączniki i regulaminy, które często „wchłaniają” to, co robisz po godzinach.

Odejście z etatu a „zabieranie” kodu ze sobą

Klasyczna scena: programista przed odejściem z firmy robi „backup na wszelki wypadek” – kopiując na prywatny dysk kawałki kodu, skrypty, a czasem całe repo. Uzasadnienie bywa proste: „przecież ja to pisałem, przyda mi się jako portfolio”. Tu zaczyna się konflikt między naturalnym odruchem a przepisami.

Z perspektywy prawa autorskiego:

• pracownik nie traci osobistych praw autorskich – nadal ma prawo wskazać się jako autor,
• majątkowe prawa autorskie do kodu pracowniczego z reguły ma już jednak pracodawca,
• kopiowanie i wykorzystywanie tego kodu poza zakresem uzgodnionym z pracodawcą może naruszać jego prawa, a czasem także tajemnicę przedsiębiorstwa.

Przykładowo: zabranie fragmentów algorytmu wyceny i wklejenie ich do rozwiązania konkurencji to nie jest „inspiracja” ani „moje know-how”, tylko potencjalne naruszenie praw i czyn nieuczciwej konkurencji. W portfolio bezpieczniej używać:

• publicznie dostępnych fragmentów projektów (np. open source firmy),
• anonimizowanych zrzutów ekranu,
• opisów problemów i sposobu myślenia, a nie pełnego kodu.

Mini-wniosek: etatowiec odchodzący z firmy powinien zakładać, że kod zostaje w spółce. Zabrać może doświadczenie i wzorce myślenia, ale nie całe pliki z repo, które chce później rozwijać na własną rękę.

Kto ma prawa do kodu, gdy programista jest freelancerem (B2B)

Domyślna zasada: kod należy do freelancera

Freelancer wchodzi do biura klienta, siada przy ich laptopie, commit robi na ich GitLaba, ale fakturę wystawia ze swojej działalności. W odróżnieniu od etatu, brak tu domyślnego „utworu pracowniczego”. Jeżeli umowa nie stanowi inaczej, majątkowe prawa autorskie co do zasady pozostają przy nim.

W praktyce oznacza to, że bez wyraźnych postanowień umownych klient ma kłopot z:

• samodzielnym rozwijaniem oprogramowania po zakończeniu współpracy,
• odsprzedażą produktu lub licencjonowaniem go dalej,
• wykonaniem forka kodu do innego projektu, jeśli wykracza to poza dozwolony użytek.

Nie oznacza to jednak, że freelancer może „wyłączyć” klientowi system następnego dnia. Często w umowach pojawiają się klauzule licencyjne – choćby lakoniczne – które przyznają klientowi prawo korzystania z kodu w określonym zakresie. Problem polega na tym, że im bardziej ogólnikowy zapis, tym więcej nieporozumień, gdy strony się rozchodzą.

Przeniesienie praw vs licencja – realna różnica w B2B

Przy kontraktach B2B przewijają się dwa główne modele: przeniesienie majątkowych praw autorskich oraz udzielenie licencji. Dla klienta i freelancera to nie jest tylko kwestia słownictwa, ale innej konstrukcji prawnej.

Przeniesienie praw oznacza, że:

• klient staje się nowym właścicielem majątkowych praw do kodu,
• freelancer traci możliwość samodzielnego komercyjnego korzystania z tego konkretnego utworu (chyba że strony przewidziały coś innego),
• w umowie trzeba jasno określić pola eksploatacji, bo bez tego przeniesienie jest wadliwe.

Licencja, zwłaszcza niewyłączna, daje natomiast klientowi prawo korzystania z kodu, ale:

• freelancer nadal pozostaje właścicielem praw,
• może ten sam kod lub jego część wykorzystać w innym projekcie (o ile nie narusza to zobowiązań poufności lub zakazu konkurencji),
• zakres korzystania, czas i terytorium muszą być jasno opisane, żeby uniknąć sporów.

W praktyce software house’y często stosują mieszane modele: klient dostaje przeniesienie praw do konkretnej implementacji, ale dostawca zachowuje prawo do używania ogólnych komponentów, bibliotek i frameworków we wszystkich następnych projektach.

Mini-wniosek: freelancer, który „zawsze przenosi wszelkie prawa na klienta”, powinien sprawdzić, czy nie sprzedaje dwa razy tego samego kodu w sposób, który przeczy treści jego umów. Klient z kolei powinien upewnić się, że przenoszone prawa faktycznie obejmują to, co biznesowo jest dla niego kluczowe.

Standardowe klauzule w umowach B2B i ich skutki

W kontraktach z freelancerami pojawiają się powtarzalne sformułowania. Niby brzmią „szablonowo”, ale każdy niuans zmienia realne prawa do kodu. Najczęściej stosuje się postanowienia, że:

• wykonawca przenosi na zamawiającego autorskie prawa majątkowe z chwilą zapłaty wynagrodzenia,
• wykonawca udziela licencji niewyłącznej na czas nieoznaczony do korzystania z kodu w zakresie określonych pól eksploatacji,
• klient nabywa prawa wyłącznie do „wyniku prac”, a nie do narzędzi i komponentów użytych przy tworzeniu oprogramowania.

Diabeł kryje się w szczegółach. Jeśli np. przeniesienie praw jest uzależnione od zapłaty, to do czasu uregulowania faktur klient formalnie może nie mieć pełnych praw do korzystania z kodu. Z kolei licencja udzielona „na czas trwania umowy” może wygasnąć wraz z jej rozwiązaniem, jeśli strony nie opiszą mechanizmu dalszego korzystania z oprogramowania.

Mini-wniosek: jednolinijkowa klauzula o „przeniesieniu praw do wszystkiego, co powstanie” jest kusząca, ale w razie poważniejszego sporu bywa zbyt ogólna, by faktycznie chronić którąkolwiek ze stron.

Zmiana pracy lub zakończenie kontraktu: co dzieje się z prawami do kodu

Odejście z etatu – co zostaje w spółce, co zostaje przy programiście

Wyjście z pracy developerskiej rzadko jest spektakularne: ostatni stand-up, zdany laptop, pożegnalne ciasto. Pytanie, które pojawia się później, brzmi: czy można dalej „ciągnąć” pomysły z poprzedniego miejsca?

W modelu etatowym:

• spółka zachowuje majątkowe prawa autorskie do kodu stworzonego w ramach obowiązków,
• programista zachowuje prawa osobiste (np. autorstwo, zakaz zniekształcania utworu),
• programista zabiera know-how – wiedzę, jak pisać podobne rozwiązania, ale nie gotowy kod.

To oznacza, że napisanie po odejściu „podobnego” modułu od zera nie jest automatycznie naruszeniem prawa autorskiego – prawo nie zabrania uczynić „drugiego Photoshopa”, zabrania jedynie kopiowania chronionych elementów cudzego programu. Ryzykowna robi się sytuacja, gdy:

• nowy produkt jest zbyt blisko starego nie tylko funkcjonalnie, ale także na poziomie rozwiązań technicznych,
• programista ma skłonność do „przepisywania z pamięci” całych fragmentów rozwiązań,
• w grę wchodzą tajemnice przedsiębiorstwa (algorytmy, konfiguracje, dane klientów).

Zakończenie kontraktu B2B – kod w repo klienta, prawa u freelancera

Freelancer kończy projekt, przekazuje dostęp do repozytorium, wystawia ostatnią fakturę. Z perspektywy klienta „wszystko działa”, więc temat jest zamknięty. Dopiero po kilku miesiącach pojawia się pytanie: czy możemy bez wykonawcy rozwijać i refaktorować ten kod?

Jeżeli w umowie:

• nastąpiło skuteczne przeniesienie majątkowych praw autorskich – klient może swobodnie modyfikować i rozwijać kod bez pytania freelancera o zgodę,
• jest tylko licencja – zakres dopuszczalnych modyfikacji zależy od treści licencji; brak wyraźnego prawa do modyfikacji bywa interpretowany na niekorzyść zamawiającego,
• brakuje jakichkolwiek postanowień o prawach – formalnie to freelancer jest właścicielem, a klient może naruszać jego prawa, rozwijając kod poza zakresem dozwolonego korzystania.

W praktyce wiele sporów udaje się wygasić dodatkową ugodą: klient płaci za szersze uprawnienia, freelancer godzi się na przeniesienie praw lub rozszerzenie licencji. Taka „doklejona” umowa bywa tańsza niż proces, ale negocjacje są znacznie trudniejsze, gdy projekt jest już ukończony, a strony w konflikcie.

Klauzule „post-contractualne”: zakaz konkurencji, pochodne utwory

Przy wychodzeniu z relacji – zarówno etatowej, jak i B2B – ujawniają się klauzule, które wcześniej wydawały się drugorzędne. Chodzi przede wszystkim o:

• zakaz konkurencji – ograniczający możliwość tworzenia podobnych rozwiązań dla innych podmiotów,
• zakaz tworzenia utworów zależnych – czyli rozwijania kodu w oparciu o bazowy produkt klienta bez jego zgody,
• obowiązek zwrotu lub usunięcia materiałów – obejmujący lokalne kopie repozytoriów, backupy, exporty baz danych.

Programista, który chce po zmianie pracy rozwijać „spokrewniony” produkt, powinien przeanalizować te klauzule bardzo uważnie. Nawet jeśli z czysto autorskiego punktu widzenia stworzy zupełnie nowy kod, może ponieść odpowiedzialność kontraktową (za naruszenie umowy) lub z tytułu czynów nieuczciwej konkurencji, jeśli nowy projekt praktycznie kopiuje model biznesowy starego pracodawcy lub klienta.

Własne projekty programisty vs projekty firmowe: cienka granica

Side project jako poligon doświadczalny – kiedy robi się niebezpiecznie

Developerkę często napędza ciekawość: ktoś wraca do domu, odpalą edytor i buduje „własną, lepszą wersję” narzędzia, którego używał w pracy. Tak rodzą się świetne open source’y i przyszłe startupy, ale też konflikty z obecnym lub byłym pracodawcą.

Punkty zapalne najczęściej dotyczą tego, że:

• cel side projektu pokrywa się z core biznesem pracodawcy lub klienta,
• w kodzie pojawiają się kopie rozwiązań implementowanych służbowo,
• side project korzysta z danych, konfiguracji lub środowisk testowych firmy.

Jeśli dodatkowo w umowie znajduje się zakaz konkurencji albo klauzula o rozpowszechnianiu rozwiązań powstałych „w związku z wykonywaniem obowiązków”, pracodawca może próbować podważyć prawo programisty do swobodnego rozwijania takiego projektu lub żądać udziału w korzyściach.

Mini-wniosek: bezpieczniejszy side project to taki, który idzie w inną domenę lub rozwiązuje ten sam problem inaczej i bez kopiowania służbowych rozwiązań technicznych.

Reusable components: biblioteki, snippet’y, własne frameworki

Wielu programistów ma „pudełko z klockami”: prywatne repo z helperami, komponentami UI, utilami do API. Z biegiem lat ta skrzynka narzędziowa staje się cenną przewagą – można szybciej dowozić projekty, bo gotowe elementy są pod ręką.

Kłopot w tym, że granica między „prywatnym toolboxem” a kodem tworzonym dla konkretnego klienta bywa rozmyta. Kilka praktycznych zasad, które pomagają ją wyostrzyć:

• komponenty, które powstały długo przed rozpoczęciem konkretnej współpracy, łatwiej obronić jako własne narzędzie – warto mieć historię w repo,
• jeżeli biblioteka jest tworzona „pod klienta” i finansowana z jego budżetu, to bez wyraźnych zastrzeżeń w umowie będzie mu przysługiwał co najmniej szeroki zakres praw do jej użycia,
• udostępnienie uniwersalnego komponentu jako open source przed lub w trakcie współpracy klaruje jego status – klient wie, że korzysta z czegoś, co nie jest szyte wyłącznie na jego miarę.

„Po godzinach” w kodzie służbowym – kuszący skrót, który drogo kosztuje

Piotr miał ambitny plan: wieczorami rozwijał własny SaaS, w pracy dłubał przy korporacyjnej aplikacji. Gdy termin gonił, wrzucił kilka modułów z prywatnego projektu prosto do służbowego repo, „żeby szybciej poszło”. Po roku, przy rozmowach o inwestycji, prawnik funduszu zapytał: czy w kodzie nie ma fragmentów, do których prawa może rościć sobie były pracodawca?

Takie sytuacje wychodzą na wierzch zawsze wtedy, gdy projekt robi się „prawdziwy”: wchodzi inwestor, pojawia się duży klient, trzeba sprzedać spółkę. Wtedy każdy commit z pracy mieszający się z prywatnym projektem zaczyna boleć. Jeżeli z logów Gita wynika, że:

• kompatybilna biblioteka powstała w czasie pracy, na sprzęcie pracodawcy,
• ta sama paczka trafiła zarówno do repo firmy, jak i do prywatnego GitHuba,
• nie ma w umowach klauzuli o wyłączeniu side projectów spod praw pracodawcy,

to argument, że „to zawsze było moje” traci wiarygodność. Pracodawca może twierdzić, że biblioteka jest efektem wykonywania obowiązków służbowych, a więc to on ma majątkowe prawa autorskie i decyduje, kto jej używa.

Bezpieczniejsze ustawienie jest odwrotne: osobne środowiska, osobne repozytoria, wyraźne rozdzielenie commitów służbowych od prywatnych. Jeżeli prywatna biblioteka ma trafić do kodu firmowego, warto mieć na to prostą, pisemną zgodę (choćby mailową) z opisaniem, na jakich zasadach firma może z niej korzystać i kto pozostaje właścicielem.

Mini-wniosek: największym ryzykiem dla side projectu nie jest sam kod, tylko jego historia i kontekst powstania – gdy jest spleciony ze służbowymi repozytoriami, rozplątanie praw bywa koszmarem.

Kiedy pracodawca może rościć prawa do prywatnego repozytorium

Anna przez kilka lat prowadziła własne konto na GitLabie. Dołączała do niego tylko prywatny mail, w README podkreślała, że to „projekty osobiste”. Po odejściu z firmy otrzymała pismo, w którym pracodawca żądał usunięcia części repo, twierdząc, że to utwory służbowe – katalogi były bowiem tworzone dokładnie w okresie intensywnego sprintu w pracy nad podobnym narzędziem.

Sam fakt, że repo jest „prywatne” i prowadzone pod osobistym adresem e-mail, nie przesądza o przynależności praw. Liczy się, czy dany kod:

• powstał w ramach wykonywania obowiązków pracowniczych lub B2B (co wynika z umowy i zakresu zadań),
• odtwarza funkcjonalnie i technicznie rozwiązania tworzone służbowo,
• powstał z wykorzystaniem zasobów firmy (czas, sprzęt, narzędzia, dokumentację, dane).

Jeżeli odpowiedź na dwa z trzech pytań jest twierdząca, pracodawca (lub klient) może mieć podstawy do roszczeń. Często nie chodzi od razu o proces, tylko o wymuszenie ugody: udział w projekcie, korektę licencji, ograniczenie publicznego dostępu do części repo.

Mini-wniosek: prywatne repo to nie magiczna tarcza. Przy sporze liczy się zgodność kodu z zakresem obowiązków i sposobem pracy, nie kolor avatara na GitHubie.

Open source, zewnętrzne licencje i tajemnica przedsiębiorstwa

Open source w kodzie komercyjnym – kto komu co licencjonuje

Marek rozwijał produkt SaaS dla klientów B2B. Żeby nie wymyślać koła na nowo, podpiął kilka bibliotek na licencji GPL i AGPL, bo „to tylko backend, nikt tego nie zobaczy”. Pierwszy większy klient przysłał ankietę compliance z pytaniem: jakie komponenty open source są wbudowane w system i na jakich licencjach?

Włączenie open source do produktu nie kasuje praw autorskich autora produktu, ale miesza w licencjach. W typowym modelu:

• autorem całości jest zespół (firma lub freelancer),
• części kodu są objęte licencjami OSS, które narzucają warunki korzystania, modyfikacji i dalszej dystrybucji,
• komercyjny licencjobiorca (klient) musi liczyć się z tym, że jego prawa do dalszego obrotu lub zamknięcia kodu mogą być ograniczone przez te licencje.

W praktyce oznacza to, że:

• przy licencjach typu MIT/BSD/Apache najczęściej wystarczy zachować informacje o autorach i klauzule odpowiedzialności,
• przy copyleft (GPL, AGPL, LGPL) sposób integracji może wymuszać udostępnienie kodu źródłowego lub ujawnienie modyfikacji,
• przy „egzotycznych” licencjach (np. różne warianty Creative Commons, zakazy użycia komercyjnego) produkt może w ogóle nie być zgodny z modelem biznesowym klienta.

Mini-wniosek: to, że biblioteka jest darmowa, nie oznacza, że można ją „przepisać” do komercyjnego produktu bez konsekwencji dla dalszych praw do kodu. Open source to też licencja, a nie wolna amerykanka.

Firmowy kod jako open source – kto może go wypuścić i na jakich zasadach

W jednym z fintechów zespół inżynierski chciał otworzyć narzędzie do migracji danych, stworzone pierwotnie jako wewnętrzne CLI. Produktowi bardzo się to podobało: „będziemy widoczni w community, przyciągniemy kandydatów”. Prawnik zadał jedno pytanie: kto ma prawa do całego kodu w tym repo i jakie umowy B2B stoją za poszczególnymi commitami?

Wypuszczenie kodu na GitHuba pod liberalną licencją wymaga uporządkowania praw do każdego wkładu. Główne pułapki to:

• fragmenty tworzone przez freelancerów, przy których umowa nie przewidywała przeniesienia praw albo przewidywała licencję ograniczoną do zastosowań wewnętrznych,
• kawałki kodu pochodzące z innych projektów klientów (np. wycięte z poprzedniego wdrożenia i „uogólnione”),
• domieszki kodu importowanego z innych OSS, ale przeniesione bez zachowania warunków pierwotnej licencji.

W firmach, które poważnie traktują open source, standardem staje się procedura klaryfikacji praw (Contributor License Agreement albo wewnętrzne oświadczenia), zanim fragment trafi do publicznego repo. Dla programisty oznacza to często, że nie może samodzielnie wypuścić na świat rozwiązania, które opracował w pracy, bo jego autorskie prawa majątkowe do tego kodu leżą po stronie spółki.

Mini-wniosek: to, że technicznie możesz zrobić „git push origin public”, nie znaczy, że masz do tego prawo. O licencjonowaniu firmowego kodu decyduje właściciel praw, nie autor commita.

Tajemnica przedsiębiorstwa a prawo autorskie – dwa równoległe światy

Startup logistyczny zbudował algorytm optymalizacji tras, który dawał mu przewagę nad konkurencją. Kod nie był szczególnie „piękny”, ale działał wyśmienicie. Jeden z developerów odszedł do innej firmy z branży i w ciągu kilku miesięcy pomógł jej osiągnąć bardzo podobne wyniki. Poprzedni pracodawca nie był w stanie udowodnić kopiowania linijka po linijce, ale mógł pokazać, że przekazano informacje objęte tajemnicą przedsiębiorstwa.

Prawo autorskie chroni sposób wyrażenia – konkretny kod źródłowy, strukturę programu. Tajemnica przedsiębiorstwa (i przepisy o zwalczaniu nieuczciwej konkurencji) chroni coś innego:

• know-how: konkretne algorytmy, heurystyki, strategie wdrożeń,
• dane: zbiory treningowe, konfiguracje, listy klientów, parametry,
• procedury: wewnętrzne guidelines, dokumentacje, diagramy architektury.

To oznacza, że można naruszyć interesy byłego pracodawcy, nawet jeśli napisze się „swój” kod od zera, ale wykorzysta przy tym poufne informacje, do których dostęp był tylko służbowo. Z drugiej strony, jeżeli firma nie zabezpiecza tych informacji (brak NDA, brak procedur poufności, dane latają po prywatnych Slackach), trudniej będzie udowodnić, że w ogóle doszło do naruszenia tajemnicy.

Mini-wniosek: granica legalnego „zabrania doświadczenia” jest gdzie indziej niż granica legalnego „zabrania kodu”. Autorskie prawa majątkowe dotyczą plików, ale odpowiedzialność za ujawnienie tajemnic firmowych dotyczy też tego, co siedzi w głowie.

Licencje zewnętrzne a sprzedaż spółki lub produktu

Wyobraźmy sobie, że kilkuosobowy zespół buduje produkt, który po trzech latach ma zostać sprzedany dużemu graczowi. Due diligence techniczne nie skupia się tylko na jakości kodu – równie ważna jest mapa licencji. Inwestor pyta: czy którykolwiek fragment produktu jest „zainfekowany” licencją, która ogranicza jego późniejsze użycie?

Ryzyka, które najczęściej wychodzą na jaw przy takich transakcjach:

• brak jasnego przeniesienia praw od freelancerów i byłych wspólników – część kodu jest de facto obciążona współwłasnością lub licencjami osobistymi,
• użycie bibliotek z licencjami zakazującymi komercyjnego wykorzystania lub wymagającymi publicznego udostępnienia źródeł,
• kopiowanie stacków „na dziko” z innych projektów, co może naruszać prawa osób trzecich (np. poprzedniego klienta software house’u).

Jeżeli takie problemy zostaną wykryte, zwykle kończy się to renegocjacją ceny, obowiązkiem refaktoryzacji lub koniecznością uzyskania dodatkowych zezwoleń od poszczególnych autorów. Z punktu widzenia inwestora każde „niejasne” źródło kodu obniża wartość całego produktu – nawet jeśli spór nigdy nie trafi do sądu, już sama możliwość roszczeń jest traktowana jak dług prawny.

Mini-wniosek: konsekwentne porządkowanie praw autorskich i licencji może wydawać się nadmiarem formalności na starcie projektu, ale przy wyjściu – sprzedaży spółki, wejściu inwestora – bywa jednym z głównych czynników decydujących o tym, ile ten kod faktycznie jest wart.

Najczęściej zadawane pytania (FAQ)

Czy mogę zabrać kod z poprzedniej pracy do portfolio albo na GitHuba?

Scenariusz jest prosty: kończysz współpracę, robisz prywatny fork, bo „to w końcu mój kod” – a potem dzwoni prawnik firmy. Kluczowe pytanie brzmi: kto ma majątkowe prawa autorskie do tego kodu.

Jeśli byłeś na umowie o pracę i pisałeś kod w ramach obowiązków, to co do zasady majątkowe prawa do tego kodu przeszły na pracodawcę. Wtedy nie możesz samodzielnie kopiować repozytorium, forknąć go na swój prywatny GitHub ani używać fragmentów w innych projektach, chyba że masz wyraźną zgodę firmy lub w umowie jest przewidziany taki wyjątek (np. zanonimizowane fragmenty do portfolio). Przy B2B sytuacja zależy od umowy: jeśli przekazałeś majątkowe prawa albo dałeś licencję wyłączną, twoje „prawo do chwalenia się kodem” też może być mocno ograniczone.

Kto ma prawa autorskie do kodu: spółka czy programista?

Na poziomie osobistym autor jest jeden – programista (lub zespół). Nawet jeśli wszystko zostało sprzedane, autorstwo nie przechodzi na spółkę i nikt nie staje się „twórcą zamiast ciebie”. Zmienia się tylko to, kto decyduje o komercyjnym wykorzystaniu kodu.

Przy umowie o pracę majątkowe prawa do kodu stworzonego w ramach obowiązków pracowniczych przechodzą automatycznie na pracodawcę w zakresie pól eksploatacji wynikających z umowy i profilu firmy. Przy współpracy B2B prawa majątkowe z zasady zostają przy programiście, dopóki umowa wprost nie przewiduje ich przeniesienia lub udzielenia licencji. Spółka bez takiej umowy może być wyłącznie „użytkownikiem z grzeczności”, a nie właścicielem praw.

Co się dzieje z prawami do kodu, gdy zmieniam pracę jako programista etatowy?

Wylogowujesz się z firmowego Slacka, oddajesz laptopa i myślisz: „ale wiedzę i kod w głowie przecież mam”. I tu pojawia się granica między doświadczeniem a prawami autorskimi. Możesz korzystać z know-how i ogólnej wiedzy, ale nie z konkretnego kodu należącego do byłego pracodawcy.

Jeśli kod powstał jako utwór pracowniczy, majątkowe prawa autorskie zostają przy spółce również po twoim odejściu. Nie możesz zabierać repozytoriów, kopiować modułów „1:1” do nowego pracodawcy ani oferować klientom dalszego rozwoju tego samego systemu bez udziału firmy, która ma prawa. Możesz natomiast wykorzystać zdobyte doświadczenie, wzorce architektoniczne czy ogólne podejście – byle nie kopiować chronionych, konkretnych rozwiązań.

Czy freelancer (B2B) automatycznie przekazuje prawa do kodu klientowi?

Typowa sytuacja: freelancer wystawia fakturę, klient uważa, że „kupił projekt” i może robić z nim wszystko. Problem pojawia się przy pierwszej większej aktualizacji, gdy ktoś pyta o przeniesienie praw, a w umowie – cisza.

Przy B2B nic nie przechodzi automatycznie. Jeśli w umowie nie ma jasno zapisanej klauzuli o przeniesieniu majątkowych praw autorskich lub udzieleniu licencji (z określeniem pól eksploatacji), to prawa pozostają przy twórcy. Klient może wtedy mieć prawo korzystać z oprogramowania tylko w bardzo wąskim zakresie, a np. odsprzedaż, modyfikacje przez innego wykonawcę czy sublicencjonowanie mogą już naruszać prawo. Dlatego przy zleceniach B2B precyzyjna regulacja praw do kodu jest absolutnie kluczowa.

Czy mogę po odejściu z firmy rozwijać podobny system dla innego klienta lub konkurencji?

Często wygląda to tak: pracowałeś przy systemie do rezerwacji wizyt, po zmianie pracy nowy klient chce „coś podobnego, ale lepszego”. Ryzyko naruszenia praw autorskich zależy od tego, czy przenosisz tylko pomysł, czy również konkretną implementację.

Pomysł na funkcjonalność – sam koncept aplikacji, ogólny model działania, logikę biznesową – możesz wykorzystać. Ochronie podlega natomiast konkretna forma: kod źródłowy, struktura modułów, dokumentacja czy charakterystyczny UX. Jeśli zaczniesz przepisywać „z pamięci” całe funkcje, kopiować strukturę plików punkt w punkt albo powielać unikalne rozwiązania, ryzyko naruszenia rośnie. Bezpieczny kierunek to stworzenie nowej implementacji od zera, inspirowanej doświadczeniem, ale bez kopiowania konkretnych rozwiązań.

Czy firma może używać mojego kodu bezterminowo, jeśli przeniosłem prawa lub dałem licencję?

Przy przeniesieniu majątkowych praw autorskich (sprzedaży praw) spółka staje się ich nabywcą na czas trwania ochrony, czyli w praktyce na dziesiątki lat. Ty jako twórca zachowujesz osobiste prawa autorskie, ale nie możesz już komercyjnie decydować o losach sprzedanego kodu, chyba że umowa przewiduje jakieś wyjątki.

Przy licencji wszystko zależy od jej treści. Licencja może być:

• czasowa (np. na 3 lata) lub bezterminowa,
• wyłączna (tylko jeden podmiot może z niej korzystać określonym sposobem) albo niewyłączna,
• odpłatna jednorazowo lub z abonamentem/royalties.

Jeśli w umowie nie ma ograniczenia w czasie, w polskim prawie przyjmuje się z reguły, że licencja jest udzielona na 5 lat, a po tym okresie wygasa – co w przypadku software’u może mieć ogromne skutki dla obu stron.

Co zrobić, żeby uniknąć sporu o prawa do kodu przy zmianie pracy lub zakończeniu projektu?

Najgorzej jest, gdy temat praw do kodu wraca dopiero przy wylogowaniu z Jiry albo przy pierwszym większym kontrakcie klienta. Dużo taniej i spokojniej jest poukładać to wcześniej – jeszcze na etapie podpisywania umowy.

Po stronie programisty dobrym ruchem jest:

• sprawdzenie w umowie, które utwory i na jakich polach eksploatacji przekazujesz,
• ustalenie, czy możesz używać zanonimizowanych fragmentów w portfolio,
• oddzielenie własnych projektów (np. open source) od kodu tworzonego dla firmy.

Po stronie spółki kluczowe jest jasne uregulowanie przeniesienia praw lub licencji z kontraktorami B2B, a także uporządkowanie kwestii dostępu do repozytoriów przy zakończeniu współpracy. Dzięki temu odejście jednego developera nie uruchamia lawiny prawniczych maili.

Bibliografia i źródła

• Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Dziennik Ustaw Rzeczypospolitej Polskiej (1994) – Podstawowe regulacje praw autorskich, utwór pracowniczy, czas ochrony
• Komentarz do ustawy o prawie autorskim i prawach pokrewnych. C.H. Beck – Szczegółowa wykładnia pojęcia utworu, pól eksploatacji, przeniesienia praw
• Prawo autorskie i prawa pokrewne. Komentarz. Wolters Kluwer Polska – Komentarz praktyczny, m.in. programy komputerowe i utwory pracownicze
• Programy komputerowe w prawie autorskim. Oficyna a Wolters Kluwer business – Monografia o ochronie kodu, dokumentacji i architektury systemu