Umowa z software house’em: kiedy firma naprawdę nabywa prawa do kodu, który zamówiła?

Firma, która zamawia i finansuje projekt informatyczny, nie nabywa automatycznie praw do powstałego oprogramowania. Prawa autorskie przysługują twórcy — i pozostają przy nim, dopóki umowa wyraźnie, w wymaganej formie i z enumeracją pól eksploatacji, nie przeniesie ich na zamawiającego.

Przeniesienie autorskich praw majątkowych do kodu wymaga:

• pisemnej umowy z odręcznymi podpisami lub kwalifikowanymi podpisami elektronicznymi — e-mail, skan PDF i DocuSign bez kwalifikowanego podpisu nie spełniają wymogu i powodują nieważność (art. 53 pr. aut., t.j. Dz.U. 2025 poz. 24);
• wyraźnego wskazania pól eksploatacji odpowiadających rzeczywistemu modelowi biznesowemu zamawiającego — ogólna formuła „wszelkie prawa” jest prawnie ryzykowna (art. 41 ust. 2 pr. aut.);
• oświadczeń wykonawcy o oryginalności kodu, ujawnieniu komponentów open source i zakresie użycia narzędzi AI.

Umowy zawierane wyłącznie mailowo, protokoły odbioru i faktury nie przenoszą praw — nawet jeżeli wyraźnie tak stanowią.

Dlaczego zapłata za kod nie oznacza nabycia praw?

Prawo autorskie chroni twórcę, nie tego, kto zamówił lub sfinansował dzieło. Prawa majątkowe do programu komputerowego powstają po stronie osoby, która go stworzyła, i pozostają przy niej do momentu skutecznego przeniesienia na podstawie pisemnej umowy.

Wyjątek dotyczy wyłącznie pracowników. Autorskie 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 (art. 74 ust. 3 pr. aut.). Ta reguła nie obejmuje programistów współpracujących na podstawie umów B2B, kontraktów zlecenia ani umów o dzieło z osobami prowadzącymi działalność gospodarczą.

Faktura, akceptacja zakresu prac, protokół odbioru, dostęp do firmowego repozytorium GitHub czy GitLab — żadna z tych czynności nie przenosi praw autorskich. Dokumentują one historię prac i autorstwo poszczególnych zmian, ale nie zastępują umowy.

Forma umowy: co wystarczy, a co powoduje nieważność?

Umowa o przeniesienie autorskich praw majątkowych zawarta bez zachowania formy pisemnej jest nieważna z mocy prawa — niezależnie od treści, intencji stron i zapłaconego wynagrodzenia (art. 53 pr. aut.).

Forma pisemna w rozumieniu Kodeksu cywilnego oznacza własnoręczny podpis na papierowym dokumencie lub kwalifikowany podpis elektroniczny.

Forma pisemna NIE jest zachowana przez:

• wymianę e-maili, nawet ze sformułowaniem „przenoszę prawa autorskie”;
• przesłanie skanu podpisanego dokumentu w formacie PDF;
• podpis złożony przez DocuSign lub Autenti, jeżeli nie jest to kwalifikowany podpis elektroniczny;
• ustne ustalenia stron.

Aneks podpisany z opóźnieniem — np. rok po zakończeniu projektu — jest ważny i przenosi prawa na przyszłość, ale nie sanuje okresu wcześniejszego. Nieważna umowa przenosząca prawa autorskie nie powoduje przejścia autorskich praw majątkowych. W części orzecznictwa i doktryny przyjmuje się jednak, że w takiej sytuacji strony mogą być związane dorozumianą licencją niewyłączną odpowiadającą celowi zawartej umowy. Oznacza to możliwość korzystania z oprogramowania w zakresie wynikającym z uzgodnień stron, ale nie nabycie wyłącznych praw do programu ani możliwości ich dalszego przenoszenia lub udzielania licencji wyłącznych.

Zmiana przepisów w toku. W maju 2025 r. do Rządowego Centrum Legislacji (projekt nr 12397364) wpłynął projekt ustawy zakładający zastąpienie wymogu formy pisemnej formą dokumentową zarówno przy przeniesieniu praw (art. 53), jak i przy licencji wyłącznej (art. 67 ust. 5). Forma dokumentowa obejmuje e-mail, skan i podpisy niekwalifikowane. Projekt przewiduje 6-miesięczne vacatio legis i przepisy intertemporalne. Stan na 4 sierpnia 2026 r.: projekt nie został uchwalony. Art. 53 pr. aut. nadal wymaga formy pisemnej.

Odrębnego uregulowania wymaga prawo do wykonywania praw zależnych — tworzenia opracowań i modyfikacji kodu. Odrębnego uregulowania wymaga również możliwość wykonywania i wykorzystywania opracowań programu. Choć ustawa przewiduje określony zakres zmian programu niezbędnych do korzystania z niego zgodnie z przeznaczeniem, brak odpowiednich postanowień umownych może istotnie ograniczyć możliwość komercyjnego rozwijania, modyfikowania i dalszego wykorzystywania zamówionego oprogramowania.

Kod generowany przez narzędzia AI: nowe ryzyko w umowach IT

Jeżeli kod nie spełnia przesłanek utworu w rozumieniu prawa autorskiego, nie ma czego przenosić — a firma płaci za oprogramowanie, do którego nie nabywa żadnych wyłącznych praw.

W badaniu GitHub przeprowadzonym przez Wakefield Research wśród 500 programistów zatrudnionych w dużych przedsiębiorstwach w USA 92% respondentów zadeklarowało korzystanie z narzędzi AI podczas tworzenia oprogramowania (GitHub/Wakefield Research, 2023). Zgodnie z dominującym obecnie poglądem w doktrynie prawa autorskiego polskie prawo autorskie chroni wyłącznie wytwory działalności twórczej człowieka. Program wygenerowany automatycznie, bez istotnego twórczego wkładu człowieka, nie stanowi utworu w rozumieniu art. 1 ust. 1 pr. aut. Konsekwencja: brak ochrony prawnoautorskiej, brak możliwości przeniesienia praw majątkowych, brak możliwości udzielenia licencji wyłącznej.

Granica jest płynna. W większości obecnych scenariuszy — gdy programista weryfikuje, modyfikuje i łączy sugestie narzędzia, podejmując twórcze decyzje — twórczy wkład człowieka jest wystarczający Według badań GitHub i Accenture programiści akceptują około 30% sugestii GitHub Copilot. Jednocześnie około 88% zaakceptowanego kodu pozostaje w projekcie po dalszych pracach programistycznych (GitHub & Accenture, 2024).W sytuacjach granicznych, gdy narzędzie generuje kompletny moduł funkcjonalny na podstawie prostego polecenia, a programista jedynie uruchamia test, kwalifikacja jest niepewna.

Co zamawiający powinien zabezpieczyć w umowie.

Umowa z software house’em powinna zobowiązywać wykonawcę do:

• ujawnienia zakresu i rodzaju narzędzi AI używanych przy realizacji zamówienia;
• wskazania, czy narzędzia są używane w ramach licencji korporacyjnej (np. GitHub Copilot Business lub Enterprise), która zwykle wiąże się z dodatkowymi gwarancjami umownymi i mechanizmami ochronnymi oferowanymi przez dostawcę narzędzia, w szczególności dotyczącymi sposobu przetwarzania danych i odpowiedzialności kontraktowej;
• oświadczenia, że w procesie tworzenia kodu twórczy wkład człowieka był decydujący;
• przeniesienia odpowiedzialności na wykonawcę, jeżeli oświadczenie okaże się nieprawdziwe.

Dla projektów o dużej wartości lub planowanych do odsprzedaży warto rozważyć obowiązek prowadzenia przez wykonawcę dokumentacji procesu twórczego.

Umowa z software house’em powinna zobowiązywać wykonawcę do dostarczenia wykazu komponentów open source wraz z ich licencjami oraz do oświadczenia, że żaden komponent nie objął całości projektu obowiązkiem ujawnienia kodu.

Oświadczenia wykonawcy i prawa osobiste

Oświadczenia wykonawcy o tytule do kodu, które nie odpowiadają rzeczywistości, przenoszą odpowiedzialność na wykonawcę — ale nie rozwiązują problemu zamawiającego wobec osób trzecich.

Dobrze skonstruowana umowa zawiera oświadczenia wykonawcy obejmujące: wyłączne autorstwo przekazywanego kodu lub ujawnienie zakresu komponentów cudzych; brak naruszenia praw osób trzecich; ujawnienie zakresu użytych narzędzi AI oraz potwierdzenie istotnego twórczego wkładu człowieka; wykaz komponentów open source z oznaczeniem ich licencji; zobowiązanie do niezwłocznego powiadomienia o każdym późniejszym odkryciu naruszenia.

Autorskich praw osobistych — prawa do autorstwa i prawa do integralności utworu — nie można przenieść. Pozostają przy twórcy bezterminowo, niezależnie od treści umowy (art. 16 pr. aut.). Standardem w umowach IT jest dlatego klauzula non-assertion: wykonawca zobowiązuje się do niewykonywania autorskich praw osobistych wobec zamawiającego i jego klientów w zakresie niezbędnym do korzystania z oprogramowania zgodnie z umową.

Moment przejścia praw i skutki opóźnienia

Prawa autorskie powinny przejść w chwili możliwej do jednoznacznego udokumentowania. Najczęściej stosowane rozwiązania: odbiór całości dzieła, odbiór konkretnego etapu (sprintu, modułu) albo wpłata określonej transzy wynagrodzenia.

Przeniesienie praw z mocą wsteczną jest w prawie autorskim niedopuszczalne — umowa przenosi prawa od chwili jej zawarcia, nie od chwili powstania kodu. Prawa do kodu wytworzonego przed podpisaniem umowy lub jej aneksu muszą być przeniesione odrębnym postanowieniem z zachowaniem formy pisemnej.

Co sprawdzić przed podpisaniem umowy i przy due diligence

Zamawiający przed podpisaniem umowy – 9 punktów kontrolnych:

1. Czy umowa wprost przenosi autorskie prawa majątkowe (nie tylko udziela licencji)?
2. Czy umowa jest podpisana w formie pisemnej — odręcznie lub kwalifikowanym podpisem elektronicznym?
3. Czy wymieniono pola eksploatacji odpowiadające planowanemu modelowi biznesowemu?
4. Czy umowa przyznaje prawo do wykonywania praw zależnych (modyfikacje, rozbudowa)?
5. Czy określono jednoznaczny i dokumentowalny moment przejścia praw?
6. Czy wykonawca złożył oświadczenia o oryginalności kodu i braku naruszenia praw osób trzecich?
7. Czy umowa reguluje zakres komponentów open source i wymaga wykazu z licencjami?
8. Czy umowa wymaga ujawnienia zakresu i trybu licencyjnego użytych narzędzi AI?
9. Czy zawiera klauzulę non-assertion dotyczącą autorskich praw osobistych?

Przy transakcji M&A lub DD inwestorskim – co bada prawnik po stronie kupującego:

• Forma umów: Czy każda umowa z developerami zewnętrznymi spełnia wymóg formy pisemnej? Czy podpisy są kwalifikowane?
• Pola eksploatacji: Czy pola odpowiadają aktualnemu modelowi biznesowemu spółki? Czy działa dziś w modelu SaaS, a umowy nie przewidują udostępniania przez sieć?
• Kod AI: Czy spółka wie, jakie narzędzia AI stosowali jej developerzy lub zewnętrzni wykonawcy? Czy istnieje dokumentacja procesu twórczego?
• Open source: Czy spółka prowadzi rejestr komponentów OS? Czy żaden komponent GPL lub AGPL nie objął produktu obowiązkiem ujawnienia kodu?
• Kontrahenci B2B: Czy kod wytworzony przez B2B-kontraktorów jest objęty pisemnymi umowami przeniesienia praw?
• Moment przejścia praw: Czy prawa przeszły przed wdrożeniem produktu u klientów lub pozyskaniem poprzedniego inwestora?

Najczęstsze pytania (FAQ)