Prawa autorskie do aplikacji: co wpisać w umowie, żeby kod źródłowy był Twój

Kto jest właścicielem kodu aplikacji, którą zamówiłeś?

Na starcie prawa do kodu aplikacji ma osoba, która go napisała, a nie firma, która za niego zapłaciła. Jedyny wyjątek ustawowy dotyczy pracownika, który pisze program w ramach obowiązków służbowych.

Według art. 8 ust. 1 ustawy o prawie autorskim i prawach pokrewnych prawo do utworu przysługuje twórcy, o ile ustawa nie stanowi inaczej. Program komputerowy jest utworem i podlega ochronie jak utwór literacki (art. 74 ust. 1). Ochrona powstaje w chwili ustalenia, czyli zapisania kodu, nawet jeśli program jest nieukończony, i nie wymaga rejestracji ani żadnych formalności (art. 1 ust. 3 i 4). Bez umowy kod, za który zapłaciłeś, prawnie należy więc do kogoś innego.

Wyjątek z art. 74 ust. 3 brzmi tak: prawa majątkowe do programu komputerowego stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej. Przepis dotyczy wyłącznie stosunku pracy, czyli w praktyce zwykle etatu. Programista na B2B, zleceniobiorca, autor pracujący na podstawie dzieła, freelancer i software house zostają przy swoich prawach, dopóki nie przeniosą ich na Ciebie na piśmie.

Ochrona obejmuje wszystkie formy wyrażenia programu, czyli kod źródłowy i wynikowy, ale nie idee i zasady, na których opiera się którykolwiek jego element (art. 74 ust. 2). Nawet najlepsza umowa nie da Ci więc wyłączności na pomysł ani na sposób działania aplikacji; przed konkurentem, który napisze podobną funkcję własnym kodem, chroni raczej umowa o poufności i tempo wdrożenia.

Piszę ten przewodnik jako programista, który buduje aplikacje na zamówienie firm, a nie jako prawnik. Przepisy cytuję za tekstem jednolitym ustawy ogłoszonym w Dz.U. z 2025 r. poz. 24. To nie jest porada prawna: umowę na większy projekt powinien przeczytać radca prawny albo adwokat, zanim ją podpiszesz.

Do kogo należą autorskie prawa majątkowe do kodu, zależnie od tego, kto go pisze. Na podstawie art. 8, 53 i 74 ust. 3 ustawy o prawie autorskim.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Osiem zapisów, które sprawdzam przed podpisaniem

Dokument przenoszący prawa do kodu musi być pisemny, wymieniać pola eksploatacji i dokładnie opisywać, czego dotyczy; resztę zapisów dobierasz do tego, co chcesz z aplikacją robić. Poniżej lista, którą przechodzę z klientem przed podpisaniem, z przepisami, na których się opiera.

Szkielet takiego zapisu, który warto dać prawnikowi jako punkt wyjścia, może wyglądać tak: „Z chwilą zapłaty wynagrodzenia za Etap Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do Programu w wersji wskazanej w protokole odbioru Etapu, na polach eksploatacji wymienionych w Załączniku A, wraz z wyłącznym prawem zezwalania na wykonywanie praw zależnych. Wynagrodzenie obejmuje korzystanie na wszystkich tych polach. Wykonawca oświadcza, że nabył prawa do Programu od wszystkich jego twórców.” To nie jest gotowa klauzula, tylko pokazanie, ile decyzji mieści się w jednym paragrafie.

Każdy punkt z tej listy rozwijam w dalszej części przewodnika. Jeśli masz przed sobą projekt umowy od wykonawcy, przyłóż go do listy i zaznacz, czego brakuje; to szybsze niż czytanie całości od początku. Ostateczne brzmienie zapisów ustal z prawnikiem.

Jeśli to Ty piszesz kod i przenosisz prawa na klienta, ta sama lista działa w drugą stronę. Pilnuj, żeby prawa przechodziły dopiero z zapłatą za etap, żeby umowa wymieniała moduły, które zostają Twoje, bo używasz ich w wielu projektach, i żeby było jasne, czy możesz pokazać projekt w portfolio. Zapis o wynagrodzeniu obejmującym wszystkie pola eksploatacji chroni obie strony przed sporem o dopłatę.

• FormaUmowa wymaga formy pisemnej pod rygorem nieważności (art. 53), czyli podpisu własnoręcznego albo kwalifikowanego podpisu elektronicznego (art. 78 i 78¹ Kodeksu cywilnego).
• PrzedmiotOpis tego, co przechodzi na Ciebie, wskazuje repozytorium, moduły i wersję, na przykład tag w Gicie, a także projekt graficzny i dokumentację, jeśli są częścią zamówienia.
• Pola eksploatacjiUmowa obejmuje tylko pola wyraźnie w niej wymienione (art. 41 ust. 2), dlatego wpisz co najmniej zwielokrotnianie, zmiany i rozpowszechnianie programu z art. 74 ust. 4 oraz pola z art. 50 dla grafik i tekstów.
• Prawa zależneBez osobnego zapisu twórca zachowuje wyłączne prawo zezwalania na wykonywanie praw zależnych (art. 46), co utrudnia powierzenie rozwoju aplikacji innej firmie.
• Moment przejściaGdy umowa milczy, prawa przechodzą z chwilą przyjęcia utworu (art. 64), a przy projekcie dzielonym na etapy lepiej powiązać je z zapłatą za każdy etap.
• WynagrodzenieZapisz, że cena obejmuje wszystkie wymienione pola eksploatacji, bo inaczej twórcy przysługuje odrębne wynagrodzenie za korzystanie na każdym z nich (art. 45).
• Prawa od współtwórcówWykonawca oświadcza, że ma prawa od wszystkich osób, które pisały kod, a jeśli utwór ma wady prawne, możesz od umowy odstąpić i żądać naprawienia szkody (art. 55 ust. 2).
• Wydanie kodu źródłowegoZapisz osobno, że wykonawca przekazuje repozytorium z pełną historią zmian, dokumentację i dostępy. Samo przejście praw nie przenosi własności egzemplarza (art. 52 ust. 2).

Przeniesienie praw czy licencja: co wybrać?

Przeniesienie wybierz, gdy aplikacja jest rdzeniem Twojej firmy albo ma kiedyś trafić do inwestora lub kupca; licencja wystarcza, gdy wykonawca konfiguruje dla Ciebie swój gotowy produkt. W pierwszym wariancie stajesz się właścicielem praw majątkowych, w drugim dostajesz tylko zgodę na korzystanie.

W pierwszym wariancie wykonawca traci prawa na wymienionych polach eksploatacji, a Ty możesz je zbyć dalej, chyba że strony ustaliły inaczej (art. 41 ust. 1 pkt 2). Przy licencji prawa zostają u wykonawcy, a granice Twojego korzystania wyznaczają uzgodnione pola eksploatacji, zakres, miejsce i czas (art. 67 ust. 1).

Pełne przeniesienie nie zawsze jest warte swojej ceny. Jeśli wykonawca wdraża swój gotowy system albo budujesz na cudzej platformie, na przykład na sklepie w abonamencie czy w narzędziu no-code, nikt nie przeniesie na Ciebie praw do samej platformy. Przy małej integracji albo skrypcie, który łatwo napisać od nowa, zwykle wystarczy licencja niewyłączna z prawem do zmian i do powierzenia rozwoju innej firmie. Przeniesienie wybierz tam, gdzie kod jest Twoją przewagą albo ma być przedmiotem sprzedaży.

Najważniejsze są reguły, które działają, gdy dokument milczy. Jeśli nie ma w nim wyraźnego zapisu, że prawa przechodzą na Ciebie, ustawa przyjmuje, że twórca udzielił licencji (art. 65). Taka licencja uprawnia do korzystania przez pięć lat na terytorium państwa, w którym masz siedzibę, a potem wygasa (art. 66). Bez zastrzeżenia wyłączności wykonawca może udzielać licencji na ten sam kod innym (art. 67 ust. 2), a Ty bez wyraźnej zgody nie upoważnisz nikogo innego do korzystania z programu w zakresie licencji (art. 67 ust. 3). To ostatnie ma znaczenie, gdy rozwój ma przejąć inna firma.

Słowo „bezterminowa” w licencji nie daje spokoju na zawsze. Licencję udzieloną na czas nieoznaczony twórca może wypowiedzieć z zachowaniem terminów umownych, a w ich braku na rok naprzód, na koniec roku kalendarzowego, jeżeli umowa nie stanowi inaczej (art. 68 ust. 1). Licencję na okres dłuższy niż pięć lat po upływie tych pięciu lat uważa się za udzieloną na czas nieoznaczony (art. 68 ust. 2). Jeśli zostajesz przy licencji, wpisz, kiedy wykonawca może ją wypowiedzieć, a kiedy nie.

W praktyce często łączy się oba modele. Prawa do kodu pisanego specjalnie dla Ciebie przechodzą na Ciebie, a do gotowych modułów wykonawcy, których używa w wielu projektach, dostajesz licencję niewyłączną z prawem do zmian i do powierzenia rozwoju innej firmie. To uczciwy układ dla obu stron, pod warunkiem że umowa wymienia, które moduły są którymi. O tym, kiedy w ogóle warto pisać system na zamówienie, a kiedy wziąć gotowy produkt, piszę w przewodniku oprogramowanie dedykowane czy gotowe.

Przeniesienie autorskich praw majątkowych a licencja, gdy umowa nie reguluje danej kwestii inaczej. Ustawa o prawie autorskim, tekst jednolity Dz.U. z 2025 r. poz. 24.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Jakie pola eksploatacji wpisać dla programu komputerowego?

Dla programu komputerowego wpisz trzy pola z art. 74 ust. 4: zwielokrotnianie, wprowadzanie zmian i rozpowszechnianie, a do nich sposoby korzystania, których naprawdę potrzebuje Twój model biznesowy. Umowa obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2).

Ustawa wymienia dla programów trzy grupy uprawnień: trwałe lub czasowe zwielokrotnienie programu w całości lub w części, jakimikolwiek środkami i w jakiejkolwiek formie; tłumaczenie, przystosowywanie, zmianę układu i jakiekolwiek inne zmiany; oraz rozpowszechnianie, w tym użyczenie lub najem programu lub jego kopii (art. 74 ust. 4). Zwrot „wykonawca przenosi wszelkie prawa autorskie” albo „na wszystkich polach eksploatacji” tego nie zastępuje, bo ustawa wymaga wyraźnego wymienienia.

Trzy ograniczenia warto znać przed negocjacjami. Ani przeniesienie, ani licencja nie obejmą pól eksploatacji nieznanych w chwili podpisania (art. 41 ust. 4), więc nie kupisz z góry sposobów korzystania, których jeszcze nie ma. Nieważny jest zapis obejmujący wszystkie przyszłe utwory tego samego twórcy albo wszystkie jego przyszłe utwory określonego rodzaju (art. 41 ust. 3), dlatego kontrakt ramowy powinien przenosić prawa do konkretnych etapów i modułów opisanych w protokołach. Twórcy przysługuje też odrębne wynagrodzenie za korzystanie na każdym odrębnym polu eksploatacji, chyba że strony ustaliły inaczej (art. 45), więc dopisz, że cena obejmuje wszystkie wymienione pola.

Część ogólnych przepisów nie dotyczy programów: art. 77 ust. 1 wyłącza dla nich między innymi art. 43 i 44 o wynagrodzeniu twórcy oraz art. 47¹ o informacji dla twórcy o przychodach z utworu. Art. 45 nie jest na tej liście, stąd zapis o cenie obejmującej wszystkie pola.

Aplikacja to nie tylko program. Projekt graficzny, ikony, teksty, zdjęcia i dokumentacja mogą być osobnymi utworami, bo art. 1 ust. 2 wymienia między innymi utwory plastyczne i wyrażone słowem, a pola z art. 74 ust. 4 do nich nie pasują. Dla nich wpisz pola z art. 50: utrwalanie i zwielokrotnianie, obrót egzemplarzami oraz publiczne udostępnianie w taki sposób, aby każdy mógł mieć dostęp w miejscu i czasie przez siebie wybranym.

Od celu biznesowego do zapisu w umowie: przykładowe pola eksploatacji dla aplikacji webowej. Ostateczne brzmienie ustal z prawnikiem.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Czy wystarczy podpis online albo wymiana maili?

Tak, ale tylko kwalifikowanym podpisem elektronicznym, bo taka umowa wymaga formy pisemnej pod rygorem nieważności (art. 53). Wymiana maili, akceptacja oferty w wiadomości albo kliknięcie w serwisie do podpisu bez podpisu kwalifikowanego tej formy nie spełniają.

Kodeks cywilny mówi, że czynność dokonana bez zachowania formy zastrzeżonej pod rygorem nieważności jest nieważna (art. 73 § 1). Do formy pisemnej wystarcza własnoręczny podpis na dokumencie, a do zawarcia umowy wystarcza wymiana dokumentów, z których każdy jest podpisany przez jedną ze stron (art. 78 § 1); możecie więc podpisać dwa egzemplarze osobno i odesłać je pocztą. Formę elektroniczną zachowuje oświadczenie opatrzone kwalifikowanym podpisem elektronicznym, a jest ona równoważna z pisemną (art. 78¹).

Ta sama forma dotyczy licencji wyłącznej (art. 67 ust. 5 ustawy o prawie autorskim). Dla licencji niewyłącznej ustawa formy nie zastrzega, ale i tak warto mieć ją w dokumencie, bo bez niego trudno potem wykazać zakres. Zmiana umowy wymaga zachowania takiej formy, jaką ustawa lub strony przewidziały w celu jej zawarcia (art. 77 § 1 Kodeksu cywilnego), więc aneks dopisujący nowe pole eksploatacji też podpisujecie odręcznie albo kwalifikowanym podpisem.

Stan prawny sprawdziłem w bazie aktów prawnych Sejmu (ELI). Po tekście jednolitym z 2025 r. ustawę zmienia jeszcze ustawa z 4 września 2026 r. (Dz.U. z 2026 r. poz. 1296), ale tylko w art. 22¹ ust. 3, który dotyczy udostępniania treści przez platformy internetowe; nowe brzmienie obowiązuje od 6 listopada 2026 r. Art. 53 i pozostałe przepisy cytowane w tym przewodniku zostają bez zmian. Przed podpisaniem większej umowy sprawdź to jeszcze raz w aktualnym tekście ustawy.

Polecam prosty podział dokumentów. Umowę o współpracę, zakres i harmonogram możesz podpisywać wygodnie w serwisie, a zapisy o prawach do kodu trzymasz w osobnym dokumencie, z podpisem kwalifikowanym albo na papierze. Jak dobrać podpis do wymaganej formy i nie pomylić podpisu zaufanego z kwalifikowanym, opisuję w przewodniku umowy z szablonu i podpis online.

Jak odebrać kod źródłowy, repozytorium i dostępy?

Obowiązek wydania kodu źródłowego z pełną historią zmian, dokumentacji i dostępów wpisz do umowy osobno od przeniesienia praw, bo własność kodu źródłowego w sensie praktycznym to coś innego niż prawa autorskie. Najlepiej, żeby repozytorium od pierwszego dnia było na koncie Twojej firmy, a wykonawca miał do niego dostęp jako członek zespołu.

Przepisy o przejściu autorskich praw majątkowych nie mówią nic o wydaniu kodu źródłowego. Możesz mieć skutecznie przeniesione prawa i nie mieć ani jednej linii kodu, jeśli repozytorium zostało na koncie wykonawcy. Dlatego umowa powinna mówić, co dokładnie dostajesz, kiedy i w jakiej postaci.

Gdy repozytorium jest na koncie wykonawcy w GitHubie, przeniesienie go do Twojej organizacji jest proste, ale ma skutki, o których warto wiedzieć. Według dokumentacji GitHuba razem z repozytorium przechodzą zgłoszenia, pull requesty, wiki, gwiazdki i obserwujący, a webhooki, sekrety i klucze wdrożeniowe pozostają z nim powiązane. Poprzedni właściciel zostaje dodany jako współpracownik przeniesionego repozytorium. Po przekazaniu usuń więc zbędnych współpracowników, wymień sekrety i klucze, a lokalne kopie przepnij na nowy adres.

Konta w usługach, z których korzysta aplikacja, zakładaj na swoją firmę: domenę, hosting, bazę w chmurze, bramkę płatności, wysyłkę maili i klucze do zewnętrznych API. To nie są utwory wykonawcy, tylko umowy z dostawcami na ich warunkach, więc nie przejdą na Ciebie razem z prawami autorskimi. Jeśli wykonawca założył je na siebie, przejęcie zależy od regulaminu danej usługi i od jego dobrej woli. Tak samo jest z płatnymi czcionkami, ikonami i zdjęciami: licencję ma mieć Twoja firma albo umowa ma mówić, że wykonawca kupuje ją w Twoim imieniu i przekazuje dokument licencji.

Przy szybkim starcie kusi, żeby wszystko założyć na prywatne konto programisty i ruszyć tego samego dnia; o tym, na czym w pierwszej wersji nie warto oszczędzać, piszę w przewodniku MVP aplikacji: koszt i zakres. Najlepszy test przekazania jest praktyczny: ktoś spoza zespołu wykonawcy stawia aplikację z repozytorium i instrukcji, bez telefonu do autora. Uporządkowane repozytorium i instrukcja to realna praca, którą warto mieć w wycenie; z czego składa się koszt całego projektu, opisuję w przewodniku ile kosztuje aplikacja webowa.

• Repozytorium z historiąPełna historia zmian, a nie archiwum z ostatnią wersją. Historia pokazuje, kto co napisał, co przydaje się przy sprawdzaniu, od kogo wykonawca musiał nabyć prawa.
• Instrukcja uruchomieniaJak zbudować aplikację, postawić bazę i odtworzyć środowisko oraz jakie zmienne konfiguracji są potrzebne. Same sekrety przekazuje się osobnym kanałem, nigdy w repozytorium.
• Schemat danych i migracjeOpis bazy i skrypty migracji, żeby kolejna zmiana struktury nie wymagała zgadywania, co autor miał na myśli.
• Wykaz zależnościLista bibliotek i usług zewnętrznych z wersjami i licencjami, najlepiej jako plik generowany automatycznie przy każdym wydaniu.
• Lista kont i dostępówPrzy hostingu, domenie, poczcie, płatnościach, mapach i usługach AI zapisz, kto jest właścicielem konta, kto za nie płaci i kto ma do niego dostęp.

Kiedy prawa przechodzą: przy odbiorze czy przy zapłacie?

Jeśli umowa nic nie mówi, prawa przechodzą z chwilą przyjęcia utworu, czyli odbioru (art. 64); w umowie na aplikację warto powiązać je z zapłatą za dany etap. Ważne, żeby moment przejścia dało się jednoznacznie udokumentować.

Według art. 64, jeśli strony nie postanowiły inaczej, nabywca dostaje prawo do wyłącznego korzystania z utworu na polach eksploatacji z umowy z chwilą przyjęcia utworu. Przyjęcie może nastąpić także przez milczenie: jeśli zamawiający w ciągu sześciu miesięcy od dostarczenia utworu nie zawiadomi twórcy o jego przyjęciu, nieprzyjęciu albo uzależnieniu przyjęcia od zmian, uważa się, że utwór został przyjęty bez zastrzeżeń (art. 55 ust. 4). Strony mogą ustalić inny termin.

Zapis „prawa przechodzą po odbiorze końcowym” jest ryzykowny dla zamawiającego przy długim projekcie. Jeśli współpraca skończy się po czterech opłaconych etapach, a do odbioru końcowego nie dojdzie, możesz zostać z kodem, za który zapłaciłeś, i bez praw do niego. Zapis „z chwilą zapłaty za etap” chroni obie strony: wykonawca nie oddaje praw przed zapłatą, a Ty masz prawa do wszystkiego, co już opłaciłeś.

Między dostarczeniem a zapłatą potrzebujesz licencji na testy i korzystanie, inaczej przez kilka tygodni używasz kodu bez żadnej podstawy. Pamiętaj też, że jeśli umowa nie stanowi inaczej, nabycie egzemplarza nie daje praw (art. 52 ust. 1), a nabycie praw nie daje własności egzemplarza (art. 52 ust. 2). Pendrive z kodem to jeszcze nie prawa, a prawa to jeszcze nie kod.

1. Podziel projekt na etapyKażdy etap kończy się protokołem z listą modułów i oznaczeniem wersji w repozytorium, na przykład tagiem. Bez tego trudno później wykazać, do czego przeszły prawa.
2. Powiąż przejście praw z zapłatąPrawa do kodu z danego etapu przechodzą z chwilą zapłaty za ten etap, na polach eksploatacji wymienionych w umowie.
3. Zapewnij sobie licencję na okres przejściowyOd dostarczenia do zapłaty korzystasz z kodu na podstawie licencji niewyłącznej opisanej w tej samej umowie.
4. Ustal termin na uwagiWpisz, ile dni masz na zgłoszenie zastrzeżeń po dostarczeniu etapu. Bez tego działa sześciomiesięczny termin z art. 55 ust. 4.
5. Zamknij projekt protokołem końcowymProtokół wymienia wszystkie przeniesione elementy: kod, projekt graficzny, dokumentację i wykaz komponentów na cudzych licencjach.

Aplikacja już działa, a w umowie nic o prawach: co teraz?

Podpisz z wykonawcą osobną, pisemną umowę przenoszącą prawa, z polami eksploatacji i listą elementów, zanim pojawi się spór, inwestor albo zmiana wykonawcy. Do tego czasu korzystasz z aplikacji najpewniej na podstawie licencji, którą ustawa przyjmuje przy braku wyraźnego postanowienia o przeniesieniu (art. 65).

Taka licencja ma ograniczenia z art. 66: pięć lat i terytorium kraju Twojej siedziby, jeśli umowa nie mówi inaczej. Gdy umowa nie określa sposobu korzystania z utworu, ma on być zgodny z charakterem i przeznaczeniem utworu oraz przyjętymi zwyczajami (art. 49 ust. 1). To słaba podstawa do sprzedaży firmy albo powierzenia rozwoju komuś innemu.

Zacznij od sprawdzenia, kto faktycznie pisał kod. Historia repozytorium podaje autorów zmian i ich adresy e-mail, choć dane autora w Gicie wpisuje sam programista, więc to wskazówka, a nie dowód. Jeśli wśród autorów są osoby spoza firmy wykonawcy, wykonawca musi najpierw mieć od nich prawa, żeby móc przenieść je na Ciebie.

W nowej umowie wykonawca powinien oświadczyć, że ma prawa od wszystkich twórców, i odpowiadać za wady prawne. Ustawa daje zamawiającemu w takim przypadku konkretne narzędzie: jeżeli utwór ma wady prawne, zamawiający może od umowy odstąpić i żądać naprawienia poniesionej szkody (art. 55 ust. 2). Jeśli wykonawca nie odpowiada albo firma już nie istnieje, nie kombinuj sam, tylko od razu idź z dokumentami do prawnika.

1. Zbierz dokumentyPołóż obok siebie umowę, zamówienia, protokoły odbioru, faktury i korespondencję o zakresie. Zaznacz, czy w którymkolwiek dokumencie jest wyraźny zapis o przejściu praw i lista pól eksploatacji.
2. Zrób listę elementówWypisz repozytoria, moduły, projekt graficzny i dokumentację, każdą pozycję z oznaczeniem wersji, której ma dotyczyć nowa umowa.
3. Ustal autorówSprawdź w historii repozytorium, kto wprowadzał zmiany, i poproś wykonawcę o informację, na jakiej podstawie współpracował z każdą z tych osób.
4. Podpisz umowę przenoszącą prawaUmowa ma formę pisemną albo podpis kwalifikowany i obejmuje pola eksploatacji, prawa zależne, wynagrodzenie, oświadczenie o nabyciu praw od twórców oraz odpowiedzialność za wady prawne.
5. Uporządkuj kod i dostępyPrzenieś repozytorium na konto firmy, wymień sekrety i klucze, a przy każdym koncie w usługach zewnętrznych zapisz, kto jest jego właścicielem.

# -s: tylko liczba zmian, -n: sortowanie od najaktywniejszego, -e: adresy e-mail
git shortlog -sne --all

Biblioteki open source i kod z AI: czego wykonawca nie przeniesie?

Wykonawca nie przeniesie praw do bibliotek open source ani cudzych komponentów, bo ich nie ma: korzystasz z nich na warunkach ich licencji, a niektóre licencje nakładają konkretne obowiązki. Umowa powinna wymagać wykazu komponentów z licencjami i Twojej zgody na każdą licencję typu copyleft.

Każda współczesna aplikacja składa się w dużej części z cudzego kodu: frameworka, bibliotek, sterowników do bazy. Licencja GPL v3 opisuje ten mechanizm wprost: przy każdym przekazaniu objętego nią utworu odbiorca automatycznie otrzymuje licencję od pierwotnych licencjodawców. Klauzula o przeniesieniu „wszystkich praw do aplikacji” tych elementów nie obejmuje, a wykonawca powinien je wskazać.

Kod bez żadnej licencji nie jest darmowy. Dokumentacja GitHuba przypomina, że bez licencji obowiązują zwykłe przepisy prawa autorskiego: autor zachowuje wszystkie prawa i nikt nie może kopiować, rozpowszechniać ani tworzyć utworów zależnych. Fragment skopiowany z publicznego repozytorium bez licencji nie powinien trafić do Twojej aplikacji bez zgody autora.

Wykaz komponentów nie wymaga specjalnych narzędzi. Na GitHubie każdy, kto widzi repozytorium, może wyeksportować z grafu zależności zestawienie oprogramowania, czyli SBOM, w formacie SPDX, z wersjami, licencjami i informacjami o prawach autorskich. W projekcie opartym na npm podobny przegląd zrobisz poleceniem npm query, które czyta pole license z package.json każdej zależności. To przegląd deklaracji autorów pakietów, a nie opinia prawna, i nie obejmuje fontów, obrazów ani zależności spoza npm.

Osobna sprawa to kod pisany z pomocą modeli AI. Dobrze to widać na przykładzie GitHub Copilota, bo jego dokumentacja opisuje mechanizm wprost. Przy podpowiedziach w edytorze Copilot porównuje proponowany fragment, razem z około 150 znakami otaczającego kodu, z indeksem publicznych repozytoriów w GitHubie. Zależnie od zasad ustawionych dla konta albo organizacji pasującą sugestię blokuje albo pokazuje z informacją o zgodnym kodzie: adresem pliku i licencją, jeśli ją wykrył. Ten filtr ma luki: sprawdza tylko sugestie przyjęte bez zmian, nie obejmuje kodu z prywatnych repozytoriów ani spoza GitHuba, a indeks jest odświeżany okresowo, więc może nie znać kodu dodanego niedawno.

Czy fragment wygenerowany przez model w ogóle jest utworem, ustawa wprost nie rozstrzyga: definiuje utwór jako przejaw działalności twórczej o indywidualnym charakterze (art. 1 ust. 1). Dlatego poproś wykonawcę o informację, z jakich narzędzi AI korzysta i jak ma ustawione dopasowania do publicznego kodu, a ocenę ryzyka dla Twojego projektu zostaw prawnikowi.

# Zależności produkcyjne z licencją z rodziny GPL (GPL, LGPL, AGPL)
npm query '.prod[license*=GPL]' | jq -r '.[] | "\(.name)@\(.version)  \(.license)"'

# Zależności produkcyjne bez tekstowego pola license w package.json
npm query '.prod:not([license])' | jq -r '.[] | "\(.name)@\(.version)"'

# Ile pakietów ma daną licencję
npm query '.prod' | jq -r '.[] | .license | tostring' | sort | uniq -c | sort -rn

Najczęstsze licencje open source w aplikacjach webowych i ich główne obowiązki, na podstawie tekstów licencji. Uproszczenie do decyzji biznesowej, nie opinia prawna.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Czy możesz zmieniać kod i co z prawami osobistymi programisty?

Zmieniać kod możesz, jeśli umowa przenosi prawo do zmian z art. 74 ust. 4 pkt 2 i wprost obejmuje prawa zależne, a prawa osobiste programisty przy programie ograniczają się do autorstwa i oznaczenia nazwiskiem. Bez zapisu o prawach zależnych twórca zachowuje wyłączne prawo zezwalania na ich wykonywanie (art. 46).

Art. 46 mówi, że jeśli umowa nie stanowi inaczej, twórca zachowuje wyłączne prawo zezwalania na wykonywanie zależnego prawa autorskiego, nawet gdy zbył całość praw majątkowych. Prawo zależne to rozporządzanie i korzystanie z opracowania, które wymaga zezwolenia twórcy utworu pierwotnego (art. 2 ust. 2). Wersja aplikacji przerobiona przez inną firmę może być takim opracowaniem, dlatego zapisz w umowie, że przechodzi na Ciebie także prawo do wykonywania i zezwalania na wykonywanie praw zależnych.

Ustawa daje legalnemu użytkownikowi wąską furtkę. Zwielokrotnianie i zmiany nie wymagają zgody uprawnionego, jeżeli są niezbędne do korzystania z programu zgodnie z jego przeznaczeniem, w tym do poprawiania błędów, chyba że umowa stanowi inaczej (art. 75 ust. 1). Wolno też sporządzić kopię zapasową, jeśli jest niezbędna do korzystania z programu (art. 75 ust. 2 pkt 1). To wystarcza do naprawy usterki, ale nie do rozwijania produktu o nowe funkcje.

Autorskie prawa osobiste chronią nieograniczoną w czasie i niepodlegającą zrzeczeniu się lub zbyciu więź twórcy z utworem (art. 16), więc nie przejdą na Ciebie żadną umową. Przy programach są jednak węższe niż przy innych utworach: art. 77 ust. 1 wyłącza art. 16 pkt 3–⁠5, czyli prawo do nienaruszalności treści i formy, do decydowania o pierwszym udostępnieniu i do nadzoru nad sposobem korzystania. Programiście zostaje prawo do autorstwa i do oznaczenia programu swoim nazwiskiem lub pseudonimem albo udostępnienia go anonimowo. Ten sam przepis wyłącza art. 49 ust. 2, który przy innych utworach zabrania następcy prawnemu zmian bez zgody twórcy.

Polecam zapisać w umowie, czy i gdzie autorzy mają być wymienieni. Najprostszy układ: autorstwo dokumentuje historia zmian w repozytorium, a w interfejsie aplikacji nazwisk nie ma, chyba że strony ustalą inaczej. Taki zapis zamyka temat, zanim ktokolwiek o niego zapyta.

Depozyt kodu źródłowego (escrow): kiedy ma sens?

Depozyt kodu źródłowego, czyli escrow, ma sens wtedy, gdy nie dostajesz kodu na bieżąco, na przykład przy licencji na produkt wykonawcy, a od aplikacji zależy działanie firmy. Kod trafia do zaufanej strony trzeciej i jest Ci wydawany, gdy zajdą warunki opisane w umowie, na przykład upadłość wykonawcy albo zaprzestanie wsparcia.

W Polsce depozytariuszem może być notariusz: Prawo o notariacie wymienia wśród czynności notarialnych przyjmowanie na przechowanie dokumentów i danych na informatycznym nośniku danych (art. 79 pkt 6, tekst jednolity Dz.U. z 2026 r. poz. 614). Depozyt kodu oferują też wyspecjalizowane firmy; jeśli wybierasz taką, zapytaj, czy sprawdza, że zdeponowany kod da się zbudować.

Sam depozyt niczego nie załatwia, jeśli zdeponowana wersja ma rok i nie da się jej zbudować. Umowa depozytu powinna mówić, jak często wykonawca aktualizuje depozyt, kto i jak sprawdza, że kod się buduje, kiedy dokładnie depozyt jest wydawany i jakie prawa dostajesz do wydanego kodu. Samo przekazanie nośnika praw autorskich nie przenosi (art. 52 ust. 1 ustawy o prawie autorskim).

Przy aplikacji pisanej na Twoje zamówienie, z repozytorium na Twoim koncie od pierwszego dnia i przeniesieniem praw etapami, escrow zwykle niczego nie dodaje, bo kod masz na bieżąco. Wtedy lepiej przeznaczyć te pieniądze na dokumentację i próbę odtworzenia środowiska przez kogoś spoza zespołu.

• Warunki wydaniaUmowa wymienia konkretne zdarzenia, na przykład ogłoszenie upadłości, likwidację, brak reakcji na zgłoszenie krytycznego błędu w ustalonym terminie albo zakończenie wsparcia dla wersji.
• Aktualizacja depozytuNowa wersja trafia do depozytu po każdym wydaniu albo w stałym rytmie, razem z dokumentacją budowania.
• WeryfikacjaKtoś niezależny co jakiś czas buduje aplikację ze zdeponowanego kodu. Bez tego wiesz tylko, że w depozycie leży jakiś nośnik.
• Prawa do wydanego koduUmowa mówi, na jakich polach eksploatacji możesz korzystać z kodu po wydaniu, bo nośnik sam w sobie praw nie daje.

Kiedy potrzebny jest prawnik?

Przy umowie, od której zależy własność głównego produktu firmy, tak: prawnik oceni zapisy pod Twój model biznesowy i całą umowę, nie tylko część o prawach autorskich. Programista pomoże w części technicznej, czyli w wykazie komponentów, opisie przekazania kodu i kryteriach odbioru.

Ten przewodnik opisuje przepisy i praktyczne pułapki, ale nie zastąpi oceny konkretnej umowy. Prawnik sprawdzi też rzeczy, których tu nie omawiam: odpowiedzialność i kary umowne, gwarancję, poufność, powierzenie przetwarzania danych osobowych i prawo właściwe, gdy wykonawca działa za granicą.

Najlepiej działa podział pracy: prawnik pisze część prawną, a załącznik techniczny powstaje razem z programistą. W załączniku są etapy i protokoły, lista elementów, które przechodzą na Ciebie, wykaz komponentów na cudzych licencjach, zasady prowadzenia repozytorium i lista kont. Taki załącznik łatwo sprawdzić przy odbiorze, bo każdą pozycję da się odhaczyć.

Buduję aplikacje webowe na zamówienie firm. Jeśli zamawiasz aplikację albo masz kod od innego wykonawcy i chcesz wiedzieć, czy da się przejąć jego rozwój, napisz mi, jaki proces obsługuje aplikacja, jak często ludzie z niej korzystają, z jakimi systemami się łączy i czy masz umowę oraz dostęp do repozytorium. Przejrzę część techniczną i powiem, czego brakuje, a część prawną zostawię prawnikowi. Odpowiadam w ciągu jednego dnia roboczego; pracuję jednoosobowo z Mikołowa, zdalnie w całej Polsce.

Pytania i odpowiedzi