Czyj jest Twój kod? Własność IP — klauzula, którą founderzy pomijają

„Zapłaciliśmy, więc jest nasze" — zwykle nieprawda

Większość founderów zakłada, że opłacenie faktury przenosi własność oprogramowania. Prawnie — często nie. W polskim prawie autorskim majątkowe prawa do kodu przysługują domyślnie twórcy, a nie zamawiającemu, dopóki umowa wyraźnie ich nie przeniesie. Opłacona faktura kupuje Ci najczęściej licencję na korzystanie z efektu — co jest czymś zupełnie innym niż własność.

Ta luka nie ujawnia się przy udanym projekcie. Ujawnia się, gdy chcesz zmienić agencję, pozyskać inwestora, sprzedać firmę albo po prostu przenieść repozytorium — i okazuje się, że dźwignia nigdy nie była po Twojej stronie.

Co realnie musi obejmować „własność"

Prawdziwa własność to nie jedno zdanie „całość IP należy do Klienta". To lista konkretnych aktywów, które muszą być nazwane i przekazane:

Kod źródłowy i pełna historia Git — nie zip z finalnym buildem, lecz repozytorium z commitami.
Pliki projektowe — źródła Figma, nie tylko wyeksportowane PNG.
Infrastruktura i konta — domena, DNS, hosting, baza danych, pipeline'y CI/CD, zmienne środowiskowe, klucze API — zarejestrowane na Twoją organizację.
Licencje zewnętrzne — fonty, media stockowe, płatne biblioteki: co jest Twoje, a co jest placeholderem demo agencji do podmiany.
Brak praw rezydualnych — agencja nie zachowuje wyłącznego prawa do utrzymania, hostingu ani blokowania Cię przed zatrudnieniem kogoś innego.

Jeśli któregokolwiek z tych elementów brakuje, nie jesteś pełnym właścicielem produktu. Jesteś właścicielem zależności od ludzi, którzy go zbudowali.

Czerwone lampki do wyłapania przed podpisem

Szukaj w umowie konkretnie tych zapisów:

IP „przechodzi z chwilą zapłaty końcowej" — w porządku, ale upewnij się, że „końcowa" jest jasno zdefiniowana, a nie otwarta w nieskończoność.
„Agencja udziela Klientowi licencji" — licencja to nie własność. Chcesz zapisu o przeniesieniu praw majątkowych (wraz z prawami zależnymi).
„Autorski framework" / „wewnętrzny boilerplate" agencji — sprawdź, czy Twój produkt nie zależy od kodu, którego nie wolno Ci zabrać.
Kod źródłowy przekazywany „na życzenie" lub „po zakończeniu projektu" — powinien być w Twoim repozytorium od pierwszego dnia.
Brak słowa o przekazaniu infrastruktury — najczęstszy sposób, w jaki klient zostaje uwiązany mimo „własności" kodu.

To decyzja biznesowa, nie prawniczy przypis

Własność IP wprost zmienia wartość tego, co budujesz:

Inwestorzy i due diligence: fundusze sprawdzają, kto jest właścicielem kodu. Niejasne IP spowalnia transakcję albo obniża wycenę.
Niezależność od dostawcy: czysta własność = możesz zmienić partnera bez przepisywania od zera. Siła negocjacyjna po Twojej stronie, nie ich.
Ciągłość: jeśli agencja zniknie, produkt działa dalej, bo to Ty masz klucze.

Gotowy SaaS daje szybkość, ale nigdy własności. Software dedykowany jest aktywem strategicznym tylko wtedy, gdy własność jest realna. Inaczej zapłaciłeś customową cenę za czarną skrzynkę, której nie umiesz otworzyć.

Jak robimy to w OKSoftware

Traktujemy własność jako standard, nie usługę dodatkową. Repozytorium jest w Twojej organizacji od pierwszego commita. Infrastruktura i konta zakładane na Twoje dane. Przy oddaniu dostajesz pełny kod, historię i dokumentację — i nie ma żadnego proprietary lock-inu, który blokowałby kontynuację bez nas. Wynajmujesz moc inżynierską; aktyw zostaje u Ciebie.

Jeśli zamawiasz teraz oprogramowanie, zrób jedno przed podpisem: poproś dostawcę na piśmie o wylistowanie każdego aktywa, które staje się Twoje, i dokładnie kiedy. Partner budujący czyste, przenaszalne systemy odpowie w jednym akapicie. Wahanie to też odpowiedź.

Planujesz dedykowany projekt albo chcesz audyt istniejącego? Porozmawiaj z Lead Engineerem — bez handlowców, konkretne odpowiedzi o architekturze i własności.