Twój największy problem: płacisz za stronę, której technicznie nie posiadasz
Zlecasz wykonanie serwisu, przelewasz ostatnią transzę i myślisz, że sprawa jest zamknięta. Tymczasem przy próbie przeniesienia hostingu lub zmiany programisty nagle słyszysz od agencji: „Kod źródłowy należy do nas, Państwo mają jedynie licencję na użytkowanie”. To najgorszy scenariusz, w którym stajesz się zakładnikiem wykonawcy, a każda zmiana w kodzie wymaga ich zgody i opłacenia kolejnej faktury. Jeśli w Twojej umowie nie ma wyraźnego zapisu o przeniesieniu autorskich praw majątkowych, to z mocy prawa właścicielem kodu pozostaje jego twórca, czyli agencja lub konkretny programista. Problem ten dotyczy nie tylko małych wizytówek, ale przede wszystkim rozbudowanych systemów e-commerce i portali, gdzie koszt wytworzenia oprogramowania idzie w dziesiątki tysięcy złotych. Bez formalnego przekazania praw, inwestujesz w cudze aktywa, budując wartość firmy, która w każdej chwili może odciąć Ci dostęp do Twojego najważniejszego narzędzia sprzedażowego.
Domyślne prawo autorskie, czyli pułapka na nieświadomego klienta
Wielu przedsiębiorców żyje w błędnym przekonaniu, że skoro zapłacili za „produkt”, to ten produkt jest ich własnością w całości. Prawo autorskie w Polsce działa jednak inaczej. Odróżnia ono egzemplarz utworu (to, co widzisz w przeglądarce) od prawa do jego powielania, modyfikowania i dalszej sprzedaży (kod źródłowy). Bez precyzyjnej umowy kupujesz tylko prawo do wyświetlania strony pod konkretnym adresem. Warto tu przywołać analogię do zakupu książki w księgarni – stajesz się właścicielem papierowego egzemplarza, ale nie masz prawa do drukowania jego kopii, zmieniania zakończenia czy wydawania go pod własnym nazwiskiem. W świecie IT ta różnica jest jeszcze bardziej bolesna, ponieważ strona internetowa, w przeciwieństwie do książki, wymaga ciągłych aktualizacji i zmian, aby zachować bezpieczeństwo i funkcjonalność.
Wyobraź sobie sytuację: zamawiasz dedykowany system rezerwacji. Po roku chcesz dodać nową funkcjonalność, ale agencja podniosła stawki o 300%. Chcesz iść do konkurencji, ale okazuje się, że nie możesz legalnie przekazać im kodu do edycji, bo nie masz do niego praw majątkowych. Agencja może Cię pozwać za naruszenie ich własności intelektualnej. To nie jest teoria – to realne straszaki stosowane w sporach biznesowych, by zablokować migrację klienta. W skrajnych przypadkach, jeśli agencja udowodni, że bezprawnie zmodyfikowałeś ich kod za pomocą innego programisty, może żądać dwukrotności, a nawet trzykrotności stosownego wynagrodzenia tytułem odszkodowania. To pułapka, z której wyjście jest kosztowne i stresujące.
Przeniesienie praw vs. Licencja – różnica warta tysiące złotych
Podpisując dokumenty, musisz szukać konkretnych sformułowań. Agencje często stosują wybieg polegający na udzieleniu „niewyłącznej, nieograniczonej czasowo licencji”. Brzmi to dobrze, prawda? W praktyce oznacza to jednak, że nadal nie jesteś właścicielem. Licencja pozwala Ci korzystać ze strony, ale zazwyczaj zabrania jej odsprzedaży lub – co gorsza – dokonywania modyfikacji przez osoby trzecie. Oznacza to, że jeśli zdecydujesz się na sprzedaż swojej firmy (exit), strona internetowa jako składnik majątku może być bezużyteczna, bo licencja nie przechodzi automatycznie na nabywcę bez zgody pierwotnego twórcy.
Dlaczego agencje wolą licencje?
- Model subskrypcyjny: Trzymają Cię przy sobie, bo tylko oni mogą legalnie grzebać w kodzie. Każda, nawet najmniejsza poprawka w stylu CSS czy dodanie przycisku musi przejść przez ich biurko i ich cennik.
- Multiplikacja zysku: Ten sam silnik lub moduł sprzedają dziesięciu innym klientom. Jeśli przeniosą na Ciebie pełne prawa, tracą możliwość legalnego sprzedania dokładnie tego samego rozwiązania konkurencji.
- Wartość firmy: Portfel praw autorskich podnosi wycenę agencji, a Ty zostajesz z pustymi rękami. Agencja z 500 aktywnymi licencjami jest warta dla inwestora znacznie więcej niż agencja, która oddała prawa swoim klientom.
Twoim celem jest zawsze całkowite przeniesienie autorskich praw majątkowych na wszystkich polach eksploatacji. Tylko to daje Ci status „właściciela” w pełnym tego słowa znaczeniu. Pamiętaj, że takie przeniesienie musi być sporządzone w formie pisemnej pod rygorem nieważności. E-mail z treścią „tak, kod jest Pana” nie ma żadnej mocy prawnej w sądzie. Dokument musi jasno określać, co jest przedmiotem przeniesienia i na jakich polach zamawiający może z tego utworu korzystać. Brak formy pisemnej to najczęstszy powód, dla którego klienci przegrywają procesy o własność oprogramowania.
Pola eksploatacji – techniczny żargon, który musisz znać
W umowach o przeniesienie autorskich praw majątkowych kluczowym terminem są „pola eksploatacji”. Jest to prawny wykaz sposobów, w jakie możesz korzystać ze swojej strony. Jeśli umowa nie wymienia konkretnego pola, to prawo do niego pozostaje przy agencji. To jeden z najczęstszych błędów – podpisanie ogólnego zdania „prawa przechodzą na klienta” bez doprecyzowania zakresu. W dobie dynamicznie zmieniających się technologii, brak precyzji może uniemożliwić Ci np. przerobienie strony na aplikację mobilną lub wykorzystanie grafiki ze strony w drukowanych materiałach reklamowych.
Dobrze skonstruowana umowa powinna wymieniać przynajmniej te pola eksploatacji:
- Utrwalanie i zwielokrotnianie: Prawo do robienia kopii zapasowych, instalowania strony na różnych serwerach (np. testowym i produkcyjnym) oraz przechowywania kodu na dowolnych nośnikach danych.
- Obieg oryginału lub egzemplarzy: Możliwość wprowadzenia strony do obrotu, co jest kluczowe przy sprzedaży całego biznesu lub samej domeny wraz z zawartością.
- Rozpowszechnianie: Publiczne wystawienie, wyświetlenie, a przede wszystkim udostępnianie strony w Internecie tak, aby każdy mógł mieć do niej dostęp w wybranym miejscu i czasie.
- Modyfikacja i adaptacja: Prawo do zmiany kodu, naprawiania błędów, dodawania nowych funkcji przez dowolnego programistę, a nie tylko przez pierwotnego wykonawcę.
Bez wymienienia pola „modyfikacja”, każda ingerencja w kod przez zewnętrznego specjalistę może zostać uznana za naruszenie autorskich praw osobistych twórcy. Dlatego tak ważne jest, aby nie pozwalać agencji na wykreślanie tych punktów z projektu umowy.
Co dokładnie musi znaleźć się w Twojej umowie?
Nie daj się zbyć ogólnikami. Solidna umowa powinna precyzować, kiedy prawa przechodzą na Ciebie (zazwyczaj w momencie zapłaty pełnej kwoty) oraz jakie elementy strony obejmują. W branży IT często mamy do czynienia z „miksem” różnych praw, co agencje uwielbiają wykorzystywać do zaciemniania obrazu. Należy rozróżnić warstwę wizualną (design), strukturę bazy danych, teksty oraz sam kod logiki biznesowej. Każdy z tych elementów powinien być objęty transferem praw.
W profesjonalnej realizacji, jaką oferuje np. Webiso Kraków, kwestie własności są zazwyczaj klarowne, ale zawsze warto sprawdzić szczegóły dotyczące tzw. komponentów firm trzecich. Jeśli Twoja strona korzysta z płatnych wtyczek (np. WP Rocket w WordPressie) lub gotowych bibliotek, agencja nie może przenieść na Ciebie praw do czegoś, czego sama nie posiada. W takim przypadku powinieneś otrzymać informację, jakie licencje musisz opłacać samodzielnie, by zachować ciągłość działania serwisu. Ważne jest, aby agencja dostarczyła listę wszystkich użytych komponentów komercyjnych wraz z kluczami licencyjnymi przypisanymi do Twojej firmy, a nie do konta agencji.
Checklista kluczowych zapisów:
- Wyraźne wskazanie, że wykonawca przenosi na zamawiającego autorskie prawa majątkowe do kodu źródłowego, grafiki i baz danych.
- Wymienienie pól eksploatacji (m.in. utrwalanie, zwielokrotnianie, wprowadzanie do pamięci komputera, modyfikacja, rozpowszechnianie).
- Zapis o przeniesieniu praw zależnych – to absolutnie kluczowe! Bez tego nie masz prawa do robienia przeróbek (tłumaczeń, zmian w designie, dopisywania modułów) bez zgody pierwotnego autora.
- Moment przejścia praw (najlepiej z datą zapłaty faktury końcowej) – unikaj zapisów o „protokole odbioru”, jeśli agencja może go wstrzymywać w nieskończoność.
- Oświadczenie agencji, że kod jest wolny od wad prawnych i nie narusza praw osób trzecich (np. że nie ukradli fragmentów kodu innej firmie).
Kod źródłowy vs. Kod wynikowy – co faktycznie dostajesz?
Wielu klientów nie zdaje sobie sprawy z technicznej różnicy między tym, co widzi przeglądarka, a tym, co widzi programista. Kod wynikowy to przetworzona, często zminimalizowana wersja strony, która jest trudna do edycji. Kod źródłowy to „czyste” pliki, na których pracował programista. Jeśli w umowie nie zaznaczysz, że przedmiotem wydania jest pełny kod źródłowy w wersji edytowalnej, agencja może przekazać Ci paczkę plików, których żaden inny programista nie będzie w stanie zrozumieć ani zmodyfikować. To forma technicznego sabotażu, która formalnie spełnia wymogi umowy, ale w praktyce czyni Cię bezbronnym.
Przykładem takiej praktyki jest tzw. „obfuskacja kodu” – celowe zaciemnianie skryptów, aby stały się nieczytelne dla człowieka, choć nadal działają dla serwera. Jeśli agencja stosuje takie metody bez Twojej wiedzy, prawdopodobnie chce zablokować Ci możliwość odejścia do konkurencji. Solidna umowa powinna zawierać zapis, że kod źródłowy zostanie dostarczony w formie umożliwiającej jego dalszy rozwój, wraz z dokumentacją techniczną i instrukcją kompilacji (jeśli jest wymagana). Bez tego, nawet posiadając prawa majątkowe, możesz stanąć przed koniecznością przepisania strony od nowa, ponieważ stary kod jest czarną skrzynką, której nikt nie chce dotknąć.
Kwestia Open Source – czy WordPress jest Twój?
To najczęstszy punkt zapalny. Jeśli Twoja strona opiera się na silniku WordPress, PrestaShop czy Magento, to nikt (ani Ty, ani agencja) nie jest właścicielem samego silnika. Jest on dostępny na licencjach typu GNU GPL. Właścicielami jesteście jedynie w zakresie autorskich motywów (szablonów) i dedykowanych wtyczek napisanych specjalnie dla Was. Problem pojawia się, gdy agencja twierdzi, że skoro używa WordPressa, to nie może przenieść praw do całości. Musisz być czujny – to prawda tylko w odniesieniu do rdzenia systemu (core), ale kłamstwo w odniesieniu do Twojego unikalnego wyglądu i funkcjonalności.
Często agencje próbują argumentować: „Nie możemy oddać praw, bo to WordPress”. To bzdura. Mogą i powinny oddać prawa do wszystkiego, co zostało wytworzone unikalnie na Twoje zlecenie – czyli plików CSS, autorskiego motywu PHP, unikalnych grafik i struktury bazy danych. Jeśli agencja twierdzi inaczej, prawdopodobnie chce ukryć fakt, że sprzedała Ci gotowy szablon za 50 dolarów jako „dedykowany projekt”. W takim przypadku agencja sama nie posiada praw do tego szablonu, więc nie może ich na Ciebie przenieść. To klasyczny przypadek wprowadzania klienta w błąd, który wychodzi na jaw dopiero przy próbie głębszej przebudowy serwisu.
Czerwone flagi podczas negocjacji umowy
Jako praktyk widziałem setki umów, które miały na celu uwiązanie klienta. Zwróć uwagę na te sygnały ostrzegawcze, zanim przelejesz zaliczkę:
- Brak definicji „kodu źródłowego”: Jeśli umowa mówi tylko o „stronie internetowej”, agencja może twierdzić, że kod źródłowy (wersja edytowalna) nie był przedmiotem sprzedaży, a jedynie pliki wynikowe. Zawsze żądaj dopisania, że przez „utwór” rozumie się pełną strukturę plików źródłowych wraz z komentarzami programistycznymi.
- Zakaz modyfikacji przez osoby trzecie: To jasny sygnał, że agencja chce mieć monopol na Twoją obsługę. Taki zapis jest często ukryty pod hasłem „dbałości o spójność kodu” lub „gwarancji”, która wygasa przy jakiejkolwiek ingerencji. Gwarancja może wygasnąć, ale prawo do modyfikacji musi zostać przy Tobie.
- Wymóg hostowania tylko na serwerach agencji: Często wiąże się to z brakiem dostępu do FTP/SSH, co uniemożliwia jakąkolwiek niezależną kontrolę nad kodem. Agencja staje się wtedy jedynym strażnikiem dostępu do Twoich danych i Twojego biznesu.
- Opłata za wydanie kodu: Niektóre firmy żądają np. 5000 zł netto za „przygotowanie paczki z kodem” przy rozwiązaniu umowy. To ukryty koszt, który powinien być wynegocjowany na początku. Przekazanie plików po zakończeniu współpracy powinno być bezpłatnym obowiązkiem wykonawcy.
Ile kosztuje „wykupienie” praw po czasie?
Jeśli już popełniłeś błąd i podpisałeś niekorzystną umowę, odzyskanie pełnej kontroli będzie kosztować. Agencje wiedzą, że koszt budowy nowej strony od zera jest wysoki, więc za aneks przenoszący prawa dyktują kwoty rzędu 20-50% wartości pierwotnego zlecenia. Jest to rodzaj „okupu”, który klienci płacą za święty spokój i możliwość dalszego rozwoju biznesu bez strachu przed pozwem. Czasami agencja zgadza się na przekazanie praw w zamian za podpisanie długoterminowej umowy na pozycjonowanie lub inne usługi marketingowe, co jest kolejną formą uzależnienia klienta.
Widełki cenowe zależą od kilku czynników:
- Unikalność rozwiązania: Im więcej autorskich algorytmów, tym wyższa cena za prawa. Jeśli strona posiada unikalny konfigurator produktu lub skomplikowany system integracji z ERP, agencja będzie bronić praw do tych modułów znacznie zacieklej.
- Relacje biznesowe: Jeśli odchodzisz w konflikcie, cena wzrośnie lub agencja w ogóle odmówi sprzedaży. Wiele sporów o prawa autorskie kończy się w sądzie tylko dlatego, że strony nie potrafiły się porozumieć na poziomie emocjonalnym.
- Potencjał komercyjny: Jeśli Twoja strona zarabia miliony, agencja może chcieć udziału w sukcesie. Choć z punktu widzenia prawa jest to trudne do wyegzekwowania bez wcześniejszych zapisów, w negocjacjach agencje często używają argumentu o „wzroście wartości dzieła”.
W sytuacjach patowych taniej bywa... przepisać front-end strony od zera z nowym wykonawcą, wykorzystując jedynie starą strukturę bazy danych, niż walczyć o prawa do starego, często niechlujnego kodu. Jest to jednak rozwiązanie ostateczne, które wiąże się z przestojami w działaniu serwisu.
Odpowiedzialność za błędy a własność kodu
Częstym argumentem agencji przeciwko przenoszeniu praw jest kwestia gwarancji. Twierdzą one: „Jeśli damy Panu kod na własność i ktoś inny w nim pogrzebie, nie będziemy mogli odpowiadać za błędy”. To logiczne, ale nie powinno być powodem do zatrzymania praw majątkowych. Rozwiązaniem jest rozdzielenie tych dwóch kwestii w umowie. Można zapisać, że prawa przechodzą na klienta, ale każda modyfikacja dokonana przez podmiot inny niż agencja zdejmuje z niej odpowiedzialność z tytułu gwarancji na dany moduł.
Warto również zadbać o zapis dotyczący tzw. „rękojmi za wady prawne”. Jeśli okaże się, że agencja wykorzystała w Twoim projekcie fragmenty kodu, do których sama nie miała praw (np. ukradła kod innej agencji), to Ty jako właściciel strony możesz mieć kłopoty. Umowa musi jasno stanowić, że w takim przypadku agencja bierze na siebie pełną odpowiedzialność finansową i prawną, w tym koszty zastępstwa procesowego. Własność kodu to nie tylko przywileje, ale i ryzyka, które profesjonalna umowa powinna mitygować.
Jak przejąć kod w 4 krokach (praktyczna procedura)
Załóżmy, że kończysz współpracę. Nie rób tego na emocjach. Najpierw zabezpiecz zasoby, potem wypowiadaj umowę. Wiele firm popełnia błąd, wysyłając wypowiedzenie w momencie, gdy jedyny dostęp do plików ma agencja. W odpowiedzi mogą usłyszeć o „awarii serwera” lub „przypadkowym usunięciu bazy”, co stawia klienta w tragicznej sytuacji negocjacyjnej.
- Uzyskaj dostęp do repozytorium (np. GitHub/GitLab): Poproś o dostęp administracyjny „w celu wykonania audytu bezpieczeństwa” lub kopii zapasowej. Gdy masz kod na własnym koncie w chmurze, masz fizyczną przewagę. Jeśli agencja odmawia dostępu do Git-a, żądaj pełnej paczki .zip z kodem źródłowym wysłanej na niezależny serwer.
- Sprawdź kompletność: Upewnij się, że w paczce są pliki źródłowe (np. pliki SASS/SCSS, nie tylko skompilowany CSS), grafiki w wektorach i zrzut bazy danych. Sprawdź, czy w paczce nie brakuje plików konfiguracyjnych, bez których strona nie ruszy na innym serwerze.
- Podpisz protokół zdawczo-odbiorczy: Musi w nim widnieć zapis, że wraz z odbiorem dzieła przechodzą na Ciebie autorskie prawa majątkowe zgodnie z paragrafem X umowy. To kropka nad „i”, która potwierdza fakt wykonania transferu praw w świecie rzeczywistym.
- Zmień klucze dostępu: Po potwierdzeniu, że wszystko działa, odetnij dostęp pracownikom agencji do serwera, panelu CMS, kont wtyczek i narzędzi analitycznych. Zmień hasła do bazy danych i klucze API. Dopiero wtedy możesz czuć się bezpieczny.
Najczęstsze błędy: Czego unikać jak ognia?
Jeden z najgłupszych błędów to akceptowanie regulaminu świadczenia usług (SaaS) zamiast podpisania umowy o dzieło z przeniesieniem praw. W modelu SaaS (np. popularne kreatory stron) nigdy nie będziesz właścicielem kodu – po prostu wynajmujesz miejsce w czyimś systemie. Gdy przestaniesz płacić abonament, Twoja strona znika, a Ty nie możesz jej przenieść nigdzie indziej. Model ten jest świetny na start dla małych firm, ale dla rosnącego biznesu staje się szklanym sufitem i ogromnym ryzykiem operacyjnym.
Kolejny błąd to brak weryfikacji, kto faktycznie pisał kod. Jeśli agencja korzystała z podwykonawców (freelancerów) i nie zadbała o przeniesienie praw od nich na siebie, to Twoja umowa z agencją może być wadliwa. Warto dodać do umowy zapis, że wykonawca gwarantuje, iż posiada pełnię praw do dysponowania kodem i bierze na siebie odpowiedzialność za ewentualne roszczenia osób trzecich. Wymagaj oświadczenia, że wszyscy pracownicy i współpracownicy agencji podpisali stosowne umowy o przeniesieniu praw na agencję, co daje Ci pewność, że nikt w przyszłości nie zapuka do Twoich drzwi z roszczeniami o „niezapłacony kod”.
FAQ – Krótko i na temat
Czy muszę płacić dodatkowo za przeniesienie praw?
To zależy od ustaleń. W dobrych agencjach cena projektu zawiera już przeniesienie praw. W tanich ofertach „po kosztach” agencja często odbija sobie stratę, zatrzymując prawa u siebie, by zarabiać na serwisie. Zawsze pytaj o to na etapie wyceny, a nie przy podpisywaniu umowy końcowej.
Co jeśli agencja zbankrutuje, a ja nie mam praw?
To sytuacja krytyczna. Bez syndyka lub likwidatora trudno będzie legalnie „wyciągnąć” prawa. Jeśli kod znajduje się na serwerze agencji, która przestała płacić za hosting, Twoja strona może zniknąć z dnia na dzień. Dlatego tak ważne jest, by prawa przechodziły na Ciebie automatycznie po zapłacie, a pliki znajdowały się na Twoim hostingu.
Czy mogę sprzedać stronę innemu podmiotowi bez zgody agencji?
Tylko jeśli masz przeniesione autorskie prawa majątkowe. Jeśli masz tylko licencję, zazwyczaj jest ona „niezbywalna”, co oznacza, że przy sprzedaży firmy musiałbyś pytać agencję o zgodę na cesję licencji (i pewnie za to zapłacić). Posiadanie praw majątkowych czyni stronę Twoim aktywem, który możesz dowolnie zbywać, zastawiać czy wnosić aportem do innej spółki.
Niuanse, o których nikt nie mówi: Biblioteki współdzielone
Musisz wiedzieć, że agencje często budują strony w oparciu o swój „wewnętrzny framework” – zbiór gotowych funkcji, które wkładają do każdego projektu. Żadna szanująca się agencja nie odda Ci wyłącznych praw do swojego frameworka, bo musiałaby zamknąć firmę. Rozwiązaniem jest zapis, w którym otrzymujesz wyłączność na warstwę wizualną i specyficzną logikę biznesową Twojej strony, natomiast na „podstawowe biblioteki wykonawcy” otrzymujesz licencję wieczystą, nieograniczoną, niewypowiadalną i z prawem do udzielania dalszych licencji (sublicencji).
To uczciwy kompromis, który pozwala Ci na swobodne przenoszenie strony i jej edycję przez innych programistów, jednocześnie chroniąc know-how agencji. Kluczem jest tutaj prawo do „sublicencjonowania” – bez niego nowy programista, którego zatrudnisz, technicznie nie mógłby legalnie pracować na bibliotekach starej agencji. Upewnij się, że umowa rozróżnia te dwa rodzaje kodu, abyś nie obudził się z prawami do „pustego pudełka”, którego serce (framework) jest dla Ciebie niedostępne prawnie.
Zawsze pytaj: „Która część kodu jest pisana pod nas, a co jest Waszym standardowym modułem?”. Brak odpowiedzi lub kręcenie to sygnał, że w przyszłości pojawią się schody. Dobry wykonawca bez problemu wykaże różnicę i zaproponuje zapisy w umowie chroniące obie strony. Jeśli jednak agencja upiera się, że nawet prosty kod HTML/CSS jest ich tajemnicą i nie masz do niego praw – uciekaj. W dzisiejszym internecie elastyczność i kontrola nad własnym zasobem są warte więcej niż niska cena wdrożenia. Pamiętaj, że strona internetowa to serce Twojego biznesu online – nie pozwól, aby ktoś inny trzymał na nim rękę, mając możliwość odcięcia dopływu krwi w dowolnym momencie.
