Przeniesienie autorskich praw majątkowych vs licencja na oprogramowanie – co wybrać w umowie IT?

Kupno domu czy wynajem mieszkania? Istota sporu między przeniesieniem praw a licencją

Dwie umowy, dwa zupełnie różne poziomy kontroli

W umowie IT pytanie „czy klient dostaje prawa do oprogramowania?” bywa zadawane zbyt ogólnie. Prawidłowe pytanie brzmi raczej: czy klient ma stać się nabywcą autorskich praw majątkowych do stworzonego kodu, czy jedynie otrzymać prawo do korzystania z niego na określonych zasadach?

Najprościej porównać te modele do nieruchomości. Przeniesienie autorskich praw majątkowych przypomina kupno domu: nabywca może nim rozporządzać, przebudowywać go, sprzedać, wynająć albo przekazać innemu podmiotowi, o ile umowa nie wprowadza szczególnych ograniczeń wynikających z innych przepisów lub praw osób trzecich. Licencja na oprogramowanie jest bliższa najmu mieszkania: korzystający może używać lokalu w ustalonym zakresie, ale nie staje się jego właścicielem.

Ta analogia nie jest idealna, ponieważ kod źródłowy, dokumentacja, grafiki, modele danych i integracje mogą mieć odrębny status prawny. Dobrze jednak pokazuje podstawową różnicę biznesową. Przy przeniesieniu praw klient kupuje szeroką kontrolę nad rezultatem pracy. Przy licencji dostawca zachowuje prawa, a klient uzyskuje uprawnienie do korzystania.

Co obejmują autorskie prawa majątkowe do programu komputerowego

Program komputerowy jest utworem chronionym prawem autorskim, jeśli ma twórczy i indywidualny charakter. Ochroną może być objęty między innymi kod źródłowy, kod wynikowy, określone elementy dokumentacji, architektura rozwiązania wyrażona w konkretny twórczy sposób czy indywidualne elementy interfejsu. Nie każda funkcja systemu, reguła biznesowa albo pomysł na aplikację jest jednak automatycznie chroniona tak samo jak konkretny kod.

Autorskie prawa majątkowe dotyczą przede wszystkim korzystania z utworu i rozporządzania nim na określonych polach eksploatacji. W odniesieniu do programu komputerowego znaczenie mają zwłaszcza: zwielokrotnianie programu, trwałe lub czasowe kopiowanie, wprowadzanie zmian, tłumaczenie, adaptacja, przystosowywanie do innych środowisk, rozpowszechnianie, używanie w modelu SaaS oraz udostępnianie podmiotom powiązanym lub klientom końcowym.

W praktyce nie wystarczy więc lakoniczne zdanie: „wykonawca przekazuje wszelkie prawa do aplikacji”. Umowa IT powinna opisywać, do jakich konkretnie rezultatów odnoszą się prawa, na jakich polach eksploatacji oraz od jakiego momentu następuje ich przejście albo udzielenie licencji.

Forma umowy ma znaczenie, nie jest formalnością

Przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności. To istotna różnica w porównaniu z wieloma codziennymi ustaleniami projektowymi prowadzonymi e-mailem, w komunikatorze czy w systemie do zarządzania zadaniami. Sam zapis w ofercie, faktura lub ogólne potwierdzenie współpracy nie muszą wystarczyć do skutecznego nabycia praw.

Również licencja wyłączna wymaga formy pisemnej pod rygorem nieważności. Licencja niewyłączna może co do zasady zostać udzielona w bardziej elastycznej formie, lecz przy istotnym projekcie nie powinno to skłaniać stron do rezygnacji z precyzyjnej umowy. Brak jasnych postanowień często nie daje „elastyczności”, lecz zostawia pole do konfliktu.

W branży IT szczególnie ryzykowne jest założenie, że skoro klient zapłacił za wytworzenie systemu, to automatycznie nabył pełne prawa autorskie do kodu. Zapłata za usługę programistyczną nie zastępuje prawidłowego postanowienia o przeniesieniu praw albo licencji. Wynagrodzenie i prawa do rezultatu to dwa powiązane, ale odrębne elementy umowy.

Dlaczego wybór wpływa na cenę i dalszy rozwój produktu

Dostawca, który przenosi autorskie prawa majątkowe, rezygnuje zwykle z możliwości ponownego wykorzystania stworzonego rozwiązania w innych projektach. Może więc wycenić pracę inaczej niż w modelu licencyjnym. Z perspektywy klienta wyższa cena początkowa może oznaczać większą niezależność w przyszłości, zwłaszcza gdy system jest kluczowy dla działalności przedsiębiorstwa.

Licencja często zmniejsza koszt wejścia, ponieważ wykonawca zachowuje własność intelektualną i może rozwijać produkt dla wielu odbiorców. Ten model bywa rozsądny w przypadku gotowego systemu CRM, platformy e-commerce, narzędzia księgowego czy rozwiązania SaaS. Problem pojawia się wtedy, gdy klient kupuje licencję do rozwiązania silnie dopasowanego do własnego biznesu, a po kilku latach nie może swobodnie zmienić dostawcy.

Wybór między przeniesieniem praw a licencją nie powinien być automatyczny. Najpierw trzeba ustalić, czy powstaje dedykowany produkt strategiczny, czy raczej wdrażane jest standardowe oprogramowanie dostawcy. Inne potrzeby ma firma budująca własną platformę sprzedażową, a inne organizacja kupująca dostęp do gotowego narzędzia do obsługi zgłoszeń.

Wariant 1: przeniesienie autorskich praw majątkowych – pełna kontrola nad kodem

Na czym polega całkowite zbycie praw

Przeniesienie autorskich praw majątkowych oznacza, że twórca lub podmiot uprawniony przekazuje nabywcy prawa do korzystania z utworu i rozporządzania nim w zakresie wskazanym w umowie. Nie jest to jednak „przeniesienie wszystkiego” w absolutnym sensie. Prawa osobiste twórcy, takie jak prawo do autorstwa utworu, co do zasady pozostają przy twórcy i nie podlegają zbyciu.

W praktyce klient, który nabył prawa majątkowe do dedykowanej aplikacji, może zlecić dalszy rozwój innemu software house’owi, wewnętrznemu zespołowi IT albo niezależnym programistom. Może także wdrożyć program w spółkach z grupy, sprzedać część biznesu wraz z oprogramowaniem czy połączyć kod z innymi systemami. Zakres tych możliwości nadal zależy od jakości umowy oraz od tego, czy wykonawca rzeczywiście dysponował prawami do wszystkich elementów rozwiązania.

Nie można skutecznie przenieść więcej praw, niż posiada zbywca. Jeżeli dostawca korzystał z pracy podwykonawców, zewnętrznych grafików, programistów B2B albo komponentów kupionych na ograniczonej licencji, klient powinien otrzymać jasność, co faktycznie wchodzi do pakietu przenoszonych praw.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Licencjonowanie pluginów OBS Studio – open source plus płatne dodatki.

Kiedy ten model ma najwięcej sensu

Przeniesienie autorskich praw majątkowych jest zwykle uzasadnione, gdy oprogramowanie ma być ważnym aktywem przedsiębiorstwa. Dotyczy to na przykład systemu obsługującego unikalny proces produkcyjny, autorskiej platformy marketplace, rozwiązania wspierającego działalność regulowaną albo narzędzia stanowiącego przewagę konkurencyjną firmy.

Ten wariant dobrze sprawdza się również wtedy, gdy klient z góry zakłada rozwój systemu przez różne zespoły. Jeśli wykonawca ma stworzyć pierwszą wersję aplikacji, ale jej dalsze utrzymanie ma przejąć dział IT klienta albo inny dostawca, nabycie praw znacząco ogranicza ryzyko sporu o możliwość modyfikacji kodu.

Wyobraźmy sobie przedsiębiorstwo, które zamawia system do wyceny usług oparty na własnych, niepublicznych zasadach kalkulacji. Jeżeli rozwiązanie ma rozwijać się przez lata i być częścią modelu biznesowego, licencja ograniczona do korzystania z aktualnej wersji może być niewystarczająca. W takim przypadku przeniesienie praw do elementów dedykowanych bywa racjonalniejsze niż uzależnienie przyszłości produktu od jednego wykonawcy.

Zalety dla zamawiającego

• Większa swoboda rozwoju: klient może zlecić modyfikacje innemu podmiotowi, o ile posiada odpowiedni zakres praw i dostęp do materiałów technicznych.
• Możliwość rozporządzania rozwiązaniem: w zależności od umowy może sprzedać system, wnieść go do spółki, udostępnić partnerowi biznesowemu albo wykorzystać w nowym przedsięwzięciu.
• Ograniczenie vendor lock-in: zmiana dostawcy jest łatwiejsza, choć sama cesja praw nie rozwiązuje problemu braku dokumentacji, środowiska wdrożeniowego lub wiedzy o systemie.
• Lepsza pozycja przy inwestycji lub sprzedaży biznesu: inwestorzy i nabywcy często analizują, kto posiada prawa do kluczowego oprogramowania.

Wady i pułapki przeniesienia praw

Najczęstszym błędem jest przekonanie, że przeniesienie praw automatycznie zapewnia klientowi samowystarczalność. Nawet jeśli prawa autorskie przechodzą skutecznie, klient nadal może potrzebować kodu źródłowego, instrukcji wdrożenia, haseł do środowisk, konfiguracji chmury, dokumentacji API, listy bibliotek, kluczy licencyjnych oraz wiedzy o sposobie utrzymania systemu.

Drugą pułapką jest zbyt szerokie żądanie przeniesienia praw do każdego elementu użytego przez dostawcę. Software house może rozwijać własne frameworki, moduły wielokrotnego użycia, narzędzia administracyjne albo biblioteki pomocnicze. Przeniesienie ich wszystkich może być niepotrzebne, kosztowne albo niemożliwe z biznesowego punktu widzenia. Rozsądna umowa oddziela elementy dedykowane dla klienta od komponentów bazowych dostawcy.

Trzecim problemem jest nabycie praw bez odpowiednich pól eksploatacji. Ogólnikowe sformułowania bywają później interpretowane restrykcyjnie. Jeżeli klient ma korzystać z programu w modelu SaaS, udostępniać go użytkownikom zewnętrznym, instalować w spółkach zależnych albo oferować w ramach własnego produktu, powinno to wynikać wprost z umowy.

Wariant 2: licencja na oprogramowanie – prawo korzystania bez zmiany właściciela

Jak działa licencja w umowie IT

Licencja na oprogramowanie daje licencjobiorcy prawo do korzystania z programu w granicach określonych umową. Właścicielem autorskich praw majątkowych pozostaje licencjodawca. To on może nadal rozwijać oprogramowanie, oferować je innym klientom, udzielać kolejnych licencji albo tworzyć kolejne wersje produktu, chyba że strony postanowią inaczej.

Zakres licencji może być bardzo szeroki lub bardzo wąski. Może obejmować korzystanie przez określoną liczbę użytkowników, w określonej lokalizacji, przez czas oznaczony, na konkretnym sprzęcie, w jednej spółce albo w całej grupie kapitałowej. Może też dotyczyć jedynie środowiska testowego, a nie produkcyjnego. Dlatego sama nazwa „licencja” nie mówi jeszcze, czy klient otrzymuje realnie użyteczne uprawnienia.

W relacjach B2B licencja może być odpłatna jednorazowo, abonamentowo, zależnie od liczby użytkowników, obrotu, liczby transakcji, wykorzystanych zasobów lub innych kryteriów. Nie każda licencja wiąże się z okresową opłatą, ale model abonamentowy jest szczególnie częsty w usługach chmurowych i oprogramowaniu rozwijanym jako produkt.

Licencja wyłączna a niewyłączna

Licencja niewyłączna pozwala licencjodawcy udzielać takich samych lub podobnych uprawnień innym podmiotom. Jest naturalna dla standardowego oprogramowania: dostawca systemu HR, programu księgowego czy narzędzia analitycznego sprzedaje dostęp wielu firmom.

Licencja wyłączna oznacza natomiast, że licencjodawca zobowiązuje się nie udzielać innym podmiotom licencji w zakresie objętym wyłącznością. Trzeba jednak bardzo dokładnie określić, czego dotyczy wyłączność. Może ona obejmować cały program, konkretną branżę, terytorium, określony sposób wykorzystania albo rozwiązanie stworzone dla jednego klienta.

Przykładowo dostawca może zachować prawo do oferowania swojej platformy innym firmom, ale udzielić klientowi wyłączności na wykorzystanie określonego modułu w sektorze medycznym. Inny wariant to wyłączność dotycząca konkretnej wersji lub funkcjonalności rozwiniętej na potrzeby zamawiającego. Bez takiego doprecyzowania pojęcie „wyłączności” może prowadzić do rozbieżnych oczekiwań.

Wyłączność nie musi oznaczać prawa do samodzielnej modyfikacji programu ani możliwości przekazania go innemu podmiotowi. Są to odrębne uprawnienia, które powinny zostać wyraźnie opisane. Klient może więc mieć zapewnienie, że konkurent nie otrzyma identycznego rozwiązania, ale jednocześnie nadal nie być uprawniony do ingerowania w kod lub korzystania z niego przez spółki z grupy.

Co powinna regulować dobra licencja

W umowie licencyjnej warto opisać nie tylko podstawowe prawo do używania programu, lecz także praktyczne sytuacje występujące podczas eksploatacji systemu. Szczególne znaczenie mają postanowienia dotyczące:

Dobrym uzupełnieniem tego tematu jest także poradnik: Co grozi za pirackie oprogramowanie: kary, kontrole i utrata reputacji.

• użytkowników i podmiotów uprawnionych – czy z programu może korzystać wyłącznie jedna spółka, czy również spółki zależne, pracownicy, współpracownicy, klienci lub partnerzy biznesowi;
• modyfikacji i integracji – czy klient może dostosowywać konfigurację, zlecać zmiany osobom trzecim oraz łączyć program z innymi systemami;
• środowisk technicznych – czy licencja obejmuje produkcję, testy, szkolenia, kopie zapasowe, środowisko developerskie i disaster recovery;
• aktualizacji – czy abonament obejmuje nowe wersje, poprawki bezpieczeństwa, usuwanie błędów i dostosowanie do zmian prawnych;
• czasu trwania – czy licencja jest terminowa, bezterminowa, odnawialna automatycznie, a także co dzieje się po jej wygaśnięciu;
• zakończenia współpracy – czy klient może wyeksportować dane, przez jaki czas ma dostęp do systemu i jakie wsparcie migracyjne zapewni dostawca.

W przypadku rozwiązania chmurowego szczególnie ważne jest odróżnienie licencji od usługi utrzymania. Klient może mieć szerokie uprawnienie do korzystania z aplikacji, ale bez gwarancji dostępności, kopii zapasowych, czasu reakcji na awarie czy pomocy przy odzyskaniu danych. Te kwestie powinny znaleźć się w postanowieniach dotyczących SLA, ochrony danych i zakończenia usługi.

Zalety licencji dla klienta

• Niższy koszt początkowy: klient zwykle nie finansuje pełnego wykupu praw do produktu, który dostawca może rozwijać także dla innych odbiorców.
• Dostęp do dojrzałego rozwiązania: standardowy produkt może być szybciej wdrożony niż system tworzony od zera.
• Aktualizacje i rozwój produktu: dostawca ma interes w rozwijaniu własnego oprogramowania, poprawianiu błędów oraz dostosowywaniu go do zmian technologicznych.
• Przewidywalny model korzystania: przy dobrze opisanej licencji klient wie, kto może używać systemu, w jakim zakresie i na jak długo.

Ograniczenia oraz ryzyka modelu licencyjnego

Najistotniejsze ryzyko pojawia się wtedy, gdy zakres licencji nie odpowiada rzeczywistemu sposobowi prowadzenia biznesu. Firma może kupić dostęp dla jednego podmiotu, a następnie odkryć, że nie może legalnie udostępnić systemu nowo utworzonej spółce, franczyzobiorcom, partnerom handlowym albo klientom końcowym.

Problemem bywa również zależność od dostawcy przy rozwoju rozwiązania. Jeżeli licencja nie pozwala na modyfikacje ani nie przewiduje współpracy z innymi wykonawcami, klient pozostaje uzależniony od harmonogramu, cennika i priorytetów licencjodawcy. Nie zawsze jest to wada: przy gotowym produkcie może być naturalną ceną za aktualizacje i jednolite utrzymanie. Staje się jednak ryzykowne, gdy oprogramowanie wspiera procesy niestandardowe lub krytyczne dla firmy.

Warto też zweryfikować mechanizm wypowiedzenia umowy. Licencja terminowa, która wygasa po zakończeniu abonamentu, może w praktyce oznaczać utratę dostępu do narzędzia niezbędnego do codziennej pracy. Przy systemach przetwarzających dane biznesowe umowa powinna określać co najmniej sposób ich wydania, format eksportu, termin migracji oraz obowiązki dostawcy po zakończeniu współpracy.

Wariant 3: model mieszany – prawa do części dedykowanej i licencja do technologii dostawcy

W wielu projektach najbardziej praktyczne rozwiązanie nie polega ani na pełnym przeniesieniu praw do całego systemu, ani na zwykłej licencji obejmującej wszystko. Strony mogą zastosować model mieszany: klient otrzymuje prawa albo szeroką licencję do rezultatów wykonanych specjalnie dla niego, natomiast dostawca zachowuje prawa do własnej technologii wykorzystywanej również w innych projektach.

Taki układ może dotyczyć na przykład wdrożenia platformy opartej na silniku dostawcy. Zamawiający może uzyskać szerokie uprawnienia do indywidualnych modułów, integracji z własnymi systemami, projektu interfejsu czy dedykowanych raportów. Jednocześnie rdzeń platformy, narzędzia administracyjne i uniwersalne biblioteki pozostają własnością dostawcy i są udostępniane na licencji.

Model mieszany wymaga szczególnej precyzji. Umowa powinna wskazywać, które materiały należą do każdej kategorii, jak klient może korzystać z całości rozwiązania oraz czy ma prawo zlecać rozwój części dedykowanej innemu wykonawcy. Sam podział nazwany ogólnie „kodem klienta” i „kodem dostawcy” może nie wystarczyć, zwłaszcza gdy oba elementy są technicznie ze sobą połączone.

Kiedy rozwiązanie hybrydowe jest rozsądne

Ten wariant sprawdza się, gdy klient potrzebuje funkcji tworzonych pod własny model działania, ale nie ma biznesowego uzasadnienia, aby nabywać prawa do całego technologicznego zaplecza dostawcy. Pozwala ograniczyć koszt i jednocześnie zabezpieczyć kluczowe elementy projektu.

Jest również użyteczny wtedy, gdy dostawca rozwija produkt dla wielu odbiorców, lecz realizuje dla klienta istotne prace wdrożeniowe. Zamiast żądać przeniesienia praw do całego produktu, strony mogą uzgodnić licencję o odpowiednio szerokim zakresie, obejmującą korzystanie przez grupę kapitałową, integracje, środowiska techniczne oraz dalsze używanie po zakończeniu usług utrzymaniowych.

Porównanie wariantów w umowie IT

Jak wybrać rozwiązanie odpowiednie dla projektu

Przy wyborze modelu warto zacząć nie od pytania, czy klient „chce mieć prawa”, lecz od analizy roli programu w biznesie. Im bardziej oprogramowanie odzwierciedla unikalne procesy, know-how lub przewagę konkurencyjną przedsiębiorstwa, tym silniejsze są argumenty za nabyciem praw do rezultatów dedykowanych albo przynajmniej za bardzo szeroką licencją z prawem rozwoju przez osoby trzecie.

Licencja będzie zwykle wystarczająca, gdy firma korzysta ze standardowego narzędzia, nie planuje budować na nim własnego produktu i akceptuje rozwój prowadzony przez producenta. W takim przypadku ważniejsze od nabycia praw może być zapewnienie odpowiedniego zakresu użytkowników, dostępności usługi, bezpieczeństwa danych, wsparcia technicznego i warunków zakończenia współpracy.

Jeżeli projekt łączy gotową technologię z rozbudowanym zakresem prac wykonywanych wyłącznie dla zamawiającego, najczęściej warto rozważyć model mieszany. Pozwala on zabezpieczyć indywidualne rezultaty bez prowadzenia sporu o technologie, których dostawca racjonalnie nie chce zbywać.

Kryteria, które warto ustalić przed podpisaniem umowy

• Czy program ma stanowić przewagę konkurencyjną lub samodzielny składnik majątku firmy?
• Czy klient będzie potrzebował zmian wykonywanych przez własny zespół albo innego dostawcę?
• Czy z rozwiązania mają korzystać spółki z grupy, partnerzy, klienci lub użytkownicy zewnętrzni?
• Czy po zakończeniu współpracy klient musi nadal korzystać z programu bez udziału obecnego dostawcy?
• Czy potrzebny jest dostęp do kodu źródłowego, dokumentacji, konfiguracji i środowisk technicznych?
• Czy rozwiązanie zawiera elementy objęte licencjami osób trzecich, w tym komponenty open source?
• Czy zakres uprawnień odpowiada planowanemu modelowi biznesowemu, także w perspektywie rozwoju firmy?

Najbezpieczniejsza rekomendacja nie brzmi więc „zawsze przeniesienie praw” ani „zawsze licencja”. Dla kluczowego, dedykowanego produktu należy dążyć do realnej możliwości jego dalszego używania i rozwijania, co może wymagać przeniesienia praw do części stworzonej dla klienta. Dla standardowego oprogramowania lepsza będzie dobrze skonstruowana licencja, która nie ogranicza przedsiębiorstwa bardziej, niż wynika to z rzeczywistych potrzeb projektu.