Cel zleceniodawcy – co chcesz realnie zabezpieczyć
Zleceniodawca, który angażuje software house, ma trzy główne cele: uzyskać działający system, mieć prawo do korzystania i dalszego rozwijania oprogramowania oraz ograniczyć ryzyka sporów i uzależnienia od jednego dostawcy.
Umowa z software house powinna więc zabezpieczać nie tylko termin i budżet, ale przede wszystkim prawa autorskie do oprogramowania, zasady licencjonowania oraz dostęp do kodu źródłowego i dokumentacji.
Kontekst współpracy z software house’em – o jakie ryzyka chodzi
Projekt szyty na miarę a produkt pudełkowy
W relacjach z software house’ami można wyróżnić dwa skrajne modele: tworzenie oprogramowania „pod klienta” oraz licencjonowanie gotowego produktu (tzw. pudełkowego lub SaaS).
W pierwszym modelu zamawiasz dedykowany system, np. specyficzny CRM, platformę B2B czy aplikację produkcyjną. Takie oprogramowanie jest ściśle dopasowane do procesów w firmie i często stanowi element przewagi konkurencyjnej. Ryzyko: bez jasnego uregulowania przeniesienia autorskich praw majątkowych lub właściwej licencji, możesz być tylko „użytkownikiem” bez realnego wpływu na rozwój.
W drugim modelu kupujesz licencję na gotowy produkt (on-premise lub w chmurze). Tu zwykle nie ma opcji przeniesienia praw – dostajesz licencję na określonych warunkach. Ryzyko pojawia się, gdy software house dorabia do tego produktu dedykowane moduły lub integracje i w umowie nie jest rozdzielone, co jest „produktem”, a co „utworem tworzonym na zamówienie”.
Najczęstsze ryzyka po stronie klienta biznesowego
Bez dobrze skonstruowanej umowy z software house może dojść do sytuacji, w której:
- klient nie ma praw do kodu, mimo że zapłacił za jego stworzenie,
- zakres licencji jest zbyt wąski (np. tylko dla jednej spółki, jednego kraju, bez prawa modyfikacji),
- o kluczowych sprawach decydują ogólne warunki umów lub regulamin, którego nikt nie czytał,
- brakuje zapisów o przekazaniu kodu źródłowego, dostępu do repozytorium i dokumentacji,
- firma jest całkowicie uzależniona od jednego wykonawcy – nie może łatwo zmienić dostawcy lub przenieść rozwoju do wewnętrznego działu IT.
Ryzyka te materializują się zazwyczaj po 1–3 latach, kiedy trzeba większej rozbudowy systemu, zmiany architektury lub migracji do innego dostawcy.
Usługa IT a przeniesienie praw do programu – dwie różne rzeczy
Software house zwykle sprzedaje „usługi IT”: analiza, projektowanie, programowanie, wdrożenie, support. Prawo autorskie traktuje efekt tych usług (program komputerowy, dokumentacja) jako odrębny przedmiot obrotu. To, że płacisz za usługę, nie oznacza jeszcze przejścia autorskich praw majątkowych.
Umowa powinna rozróżniać te dwa poziomy: z jednej strony zakres i rozliczenie usług (dni robocze, sprinty, fixed price), z drugiej – kwestię przeniesienia praw lub udzielenia licencji na oprogramowanie. Brak wyraźnego rozdzielenia kończy się sporami typu „przecież zapłaciłem, więc to jest moje”, na co wykonawca odpowiada „zapłacił Pan za usługę zaprogramowania, nie za pełne prawa”.
Krótki przykład z praktyki
Średnia firma handlowa zleciła budowę systemu B2B do obsługi kontrahentów. Umowa mówiła tylko o „wykonaniu i wdrożeniu systemu” oraz „przekazaniu kodu źródłowego”, ale nie zawierała klauzul o przeniesieniu autorskich praw majątkowych ani o licencji.
Po dwóch latach firma chciała zlecić rozwój systemu innemu software house’owi. Poprosiła o wydanie kodu z repozytorium. Wykonawca odmówił, twierdząc, że kod jest jego własnością, a klient ma jedynie prawo korzystania w formie dostępu do gotowego systemu. Spór skończył się negocjacjami i dodatkowymi kosztami za wykup praw. Taki scenariusz można było wyeliminować jedną, dobrze napisaną sekcją o prawach autorskich i kodzie źródłowym.
Podstawy prawne – co regulują przepisy, a czego nie
Program komputerowy jako utwór
W polskim prawie program komputerowy jest traktowany jako utwór w rozumieniu ustawy o prawie autorskim. To oznacza, że automatycznie – z chwilą stworzenia – powstaje ochrona autorska, bez potrzeby rejestracji.
Ochroną objęty jest przede wszystkim kod źródłowy, ale także dokumentacja techniczna, struktura bazy danych, interfejsy (w określonym zakresie) i inna twórcza część projektu. Sam pomysł na system (np. „portal do obsługi zgłoszeń”) nie jest chroniony, lecz konkretny sposób jego realizacji już tak.
Autorskie prawa majątkowe i osobiste – istotna różnica
Autorskie prawa osobiste są niezbywalne – twórca zawsze pozostaje autorem. Dotyczą m.in. prawa do autorstwa i oznaczenia utworu imieniem i nazwiskiem, integralności utworu czy nadzoru nad sposobem korzystania.
Autorskie prawa majątkowe to prawo do korzystania z utworu i rozporządzania nim na określonych polach eksploatacji oraz prawo do wynagrodzenia. To właśnie one mogą być przenoszone lub licencjonowane. Przy umowie z software house chodzi przede wszystkim o te prawa.
Dlatego w umowie trzeba jasno wskazać, czy następuje przeniesienie autorskich praw majątkowych, czy udzielana jest licencja na oprogramowanie. Bez tego domyślne regulacje nie zapewniają klientowi kontroli nad systemem.
Domyślny stan bez umowy lub przy umowie niedoprecyzowanej
Jeżeli program tworzy pracownik w ramach stosunku pracy, co do zasady autorskie prawa majątkowe przechodzą na pracodawcę w zakresie wynikającym z celu umowy o pracę i zamiaru stron. W relacjach B2B / zlecenie takie domniemanie nie działa.
W modelu współpracy z software house’em, gdzie developerzy są zatrudnieni przez wykonawcę, a nie przez klienta, twórcą jest programista (lub zespół), a prawa majątkowe z reguły przysługują software house’owi. Klient nie staje się „z automatu” właścicielem praw. Bez wyraźnej klauzuli o przeniesieniu praw lub licencji klient zyskuje najwyżej domyślne, wąskie uprawnienie do korzystania z przekazanego mu egzemplarza oprogramowania, co dla biznesu jest dalece niewystarczające.
Dlaczego klauzula „klient ma pełne prawa” nie wystarcza
W prawie autorskim liczą się konkrety. Zapis typu „klient ma pełne prawa do oprogramowania” jest zbyt ogólny. Ustawa wymaga, aby umowa szczegółowo określała pola eksploatacji, na których przenoszone są prawa lub udzielana jest licencja.
Bez katalogu pól eksploatacji przeniesienie praw może zostać uznane za nieważne w tej części lub bardzo ograniczone. Skutek: klient będzie przekonany, że „ma wszystko”, a w razie sporu sąd będzie interpretował umowę wąsko, po stronie twórcy. To najczęstsza pułapka w źle skonstruowanych umowach IT.
Model własności: przeniesienie praw czy licencja – który wariant wybrać
Kiedy dążyć do przeniesienia autorskich praw majątkowych
Przeniesienie autorskich praw majątkowych ma sens, gdy oprogramowanie jest kluczowe dla biznesu i ma charakter unikalny. Dotyczy to szczególnie:
- systemów stanowiących przewagę konkurencyjną (np. algorytmy wyceny, silniki rekomendacji, dedykowane ERP),
- oprogramowania wbudowanego w produkt fizyczny (np. elektronika przemysłowa),
- platform, które będą dalej komercjalizowane przez klienta (white-label, franczyza, licencjonowanie innym podmiotom).
Przeniesienie praw daje pełnię kontroli: możliwość modyfikacji, sublicencjonowania, odsprzedaży, a także swobodę zmiany wykonawcy. Zazwyczaj wiąże się to z wyższą ceną i twardym negocjowaniem pól eksploatacji oraz zakresu „przenoszonego” kodu.
Licencja wyłączna a licencja niewyłączna – praktyka
Gdy software house używa własnych frameworków, modułów lub tworzy elementy, które planuje wykorzystywać także u innych klientów, często nie zgodzi się na pełne przeniesienie praw. Wtedy w grę wchodzi licencja.
Licencja wyłączna daje klientowi wyłączność korzystania z utworu na określonych polach eksploatacji w danym zakresie. Wykonawca zobowiązuje się, że nie udzieli takiej licencji innym podmiotom. Często stosowana przy krytycznych systemach, gdy software house nie chce oddać praw, ale jest gotowy zagwarantować, że nie wdroży identycznego rozwiązania u konkurencji.
Licencja niewyłączna to standard przy typowych produktach i modułach wielokrotnego użytku. Klient może korzystać z oprogramowania, ale nie ma wyłączności, a wykonawca może oferować ten sam kod innym. Taki model jest tańszy, ale oznacza mniejszą kontrolę nad oprogramowaniem.
Modele mieszane – kiedy część kodu na własność, a część „wspólna”
Najczęściej spotykanym w praktyce rozwiązaniem jest model mieszany. Polega on na tym, że:
- elementy stworzone pod konkretnego klienta (np. integracje z jego systemami, specyficzne moduły biznesowe) są przenoszone na niego lub licencjonowane wyłącznie,
- elementy reusable (frameworki, silniki workflow, komponenty UI) pozostają własnością software house’u i są licencjonowane niewyłącznie.
Model mieszany trzeba jasno opisać w umowie. Pomaga rozdzielenie na: komponenty dedykowane, komponenty wspólne oraz komponenty zewnętrzne (third-party). Każda kategoria powinna mieć osobny zestaw postanowień dotyczących praw autorskich i licencji.
Wpływ modelu na cenę, elastyczność i możliwość zmiany wykonawcy
Pełne przeniesienie praw zazwyczaj podnosi cenę. Software house oddaje bowiem możliwość wtórnego zarabiania na tym samym kodzie, więc rekompensuje to jednorazowym wynagrodzeniem. Z drugiej strony zapobiega to późniejszym konfliktom i kosztom wykupu praw.
Licencja, zwłaszcza niewyłączna, jest tańsza, ale może ograniczać elastyczność rozwoju. Jeżeli licencja nie reguluje wyraźnie prawa do modyfikacji przez inne podmioty, klient zostaje praktycznie związany z jednym wykonawcą. To też należy uwzględnić w negocjacjach.
Jak jasno nazwać i opisać model w umowie
Umowa z software house powinna używać precyzyjnych sformułowań, np.:
- „Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do Utworów, o których mowa w §…, na następujących polach eksploatacji: …”
- „Wykonawca udziela Zamawiającemu licencji wyłącznej/niewyłącznej do korzystania z Modułów Wspólnych, na polach eksploatacji: …, na czas …, na terytorium …”
Nie wystarczy jedno zdanie „klient ma licencję na oprogramowanie”. Trzeba wskazać rodzaj licencji, pola eksploatacji, terytorium, okres, wynagrodzenie, dopuszczalne modyfikacje i prawo do dalszego licencjonowania.
Przedmiot umowy i zakres prac – jak opisać, co właściwie jest tworzone
Dokładny opis przedmiotu: specyfikacja, backlog, dokumentacja
Solidny opis przedmiotu umowy to podstawa, aby później nie było sporu, czego dotyczą prawa autorskie i licencja. Najczęściej wykorzystuje się:
- specyfikację funkcjonalną – opis funkcji systemu, user stories, wymagania biznesowe,
- backlog produktowy – listę zadań/sprintów w metodyce Agile,
- makiety i prototypy – wizualizacje ekranów, przepływów,
- dokumentację techniczną – architektura, diagramy, opis API.
Te elementy mogą być załącznikami do umowy. Kluczowe jest, aby umowa odwoływała się do nich w sposób jednoznaczny (np. numer wersji dokumentu, data, repozytorium). Inaczej każda zmiana backlogu może rodzić pytanie, czy jest jeszcze w zakresie umowy, czy już poza nią.
Iteracyjność (Agile) a przenoszenie praw i odbiory
W projektach Agile zakres zmienia się w czasie. Tu ważne jest powiązanie odbioru sprintów z momentem przejścia praw lub momentem udzielenia licencji. Można to uregulować np. tak:
- po odbiorze każdego sprintu dochodzi do przeniesienia praw do utworów wykonanych w tym sprincie,
- zapłata za sprint jest wynagrodzeniem za przeniesienie praw/licencję,
- w protokołach odbioru wskazuje się, jakie moduły i pliki są objęte przekazaniem.
Dzięki temu nie trzeba czekać do końca całego projektu, aby uregulować prawa. Jednocześnie sprinty stają się kamieniami milowymi, co porządkuje zarówno kwestie rozliczeń, jak i własności kodu.
Rozdzielenie kodu, dokumentacji, konfiguracji i narzędzi
Przedmiot umowy nie powinien ograniczać się do „systemu”. Dobrze rozróżnić:
- kod źródłowy (aplikacja, skrypty, testy automatyczne),
Elementy niematerialne, które łatwo „wypadają” z zakresu
Poza samym kodem źródłowym w projekcie powstaje sporo utworów, o których umowy milczą. To m.in.:
- dokumentacja użytkownika (instrukcje, help online, artykuły w bazie wiedzy),
- dokumentacja analityczna (diagramy BPMN, UML, specyfikacje integracji),
- materiały UX/UI (design system, biblioteki komponentów, ikony),
- testy (scenariusze testowe, testy automatyczne),
- skrypty narzędziowe (migracje, deploy, CI/CD).
Umowa powinna wymieniać te elementy z nazwy i przesądzać, czy są objęte przeniesieniem praw lub licencją, na jakich zasadach i w jakich formatach są przekazywane. Inaczej kończy się sytuacją, w której klient ma system, ale nie ma dokumentacji ani testów i każda zmiana trwa dwa razy dłużej.
Zmiany zakresu: change request i wpływ na prawa
Przy dłuższych wdrożeniach zakres rzadko zostaje niezmieniony. Jeżeli zmiany są wprowadzane na podstawie change requestów, w umowie warto określić prostą regułę:
- każdy zaakceptowany change request jest załącznikiem do umowy,
- utwory powstałe w jego wyniku są obejmowane tym samym reżimem praw autorskich, co reszta projektu, chyba że strony wyraźnie postanowią inaczej,
- w razie innego modelu (np. wyłączna licencja tylko do części) trzeba to wpisać w treść change requestu.
Bez takiego mechanizmu część modułów może „wypaść” poza uzgodniony model praw, bo powstawała już po podpisaniu umowy i nie została nigdzie doprecyzowana.
Prawa autorskie i pola eksploatacji – zapisy, bez których umowa jest pusta
Jak opisać pola eksploatacji dla oprogramowania
Pola eksploatacji nie mogą być przepisanym z ustawy ogólnikiem. Dla oprogramowania przydaje się katalog dostosowany do realnego użycia, np.:
- utrwalanie i zwielokrotnianie w pamięci komputerów, urządzeń mobilnych i serwerów (w tym w środowiskach chmurowych),
- wprowadzanie do obrotu i użyczanie w ramach usług świadczonych przez klienta,
- wprowadzanie do pamięci urządzeń końcowych użytkowników końcowych (jeżeli jest aplikacja mobilna / desktop),
- publiczne udostępnianie w sieci (SaaS, dostęp przez WWW, API),
- tłumaczenie, modyfikacja, dekompilacja w zakresie koniecznym do utrzymania i rozwoju,
- tworzenie i eksploatacja utworów zależnych (forki, modyfikacje, rozszerzenia, pluginy).
Lista powinna być dostosowana do modelu biznesowego. SaaS ma inne potrzeby niż system wewnętrzny działający tylko w sieci lokalnej.
Uprawnienie do modyfikacji i utworów zależnych
Bez wyraźnego uprawnienia do tworzenia utworów zależnych (modyfikacji) klient może mieć problem z zaangażowaniem innego wykonawcy do rozwoju systemu. Software house będzie mógł wtedy argumentować, że tylko on ma prawo zmieniać kod.
Bezpieczny zapis powinien:
- przy przeniesieniu praw – potwierdzać, że klient może dowolnie modyfikować i rozwijać oprogramowanie, a prawa do modyfikacji przysługują jemu,
- przy licencji – przyznawać licencjobiorcy prawo modyfikacji przez siebie i przez osoby trzecie (podwykonawców, inne software house’y).
W projektach produktowych sensowne bywa rozróżnienie: klient ma pełne prawa do modyfikacji komponentów dedykowanych, ale w komponentach wspólnych może tylko proponować zmiany lub rozwijać je w forku, który będzie wykorzystywał wyłącznie u siebie.
Terytorium i czas trwania – drobne słowa, duże konsekwencje
Jeżeli umowa milczy o terytorium, domyślnie zakłada się je wąsko (najczęściej domyślne regulacje krajowe). Dla większości biznesów, zwłaszcza działających globalnie lub w modelu SaaS, to za mało.
Najprostszy i zazwyczaj bezpieczny zapis to terytorium: „cały świat”. Ograniczenia geograficzne mogą mieć sens jedynie w specyficznych relacjach partnerskich (np. resellerzy na konkretne kraje).
Przy czasie trwania:
- przy przeniesieniu praw – wskazuje się, że następuje ono na cały okres trwania autorskich praw majątkowych,
- przy licencji – konieczne jest wskazanie, czy jest ona czasowa (na określony okres) czy bezterminowa.
Licencja na czas określony bez szczegółowego mechanizmu przedłużania i zasad po wygaśnięciu to częsty powód nerwowych negocjacji tuż przed końcem okresu umowy.
Wynagrodzenie a przeniesienie praw lub licencja
W polskim prawie przyjmuje się, że wynagrodzenie za przeniesienie praw lub udzielenie licencji powinno być wyodrębnione, chociażby w sposób pośredni. W praktyce można zastosować różne modele:
- wyraźne rozbicie: X zł za wykonanie usługi + Y zł za przeniesienie praw/licencję,
- jedna kwota z klauzulą, że „wynagrodzenie obejmuje również wynagrodzenie z tytułu przeniesienia autorskich praw majątkowych/