Umowa B2B z programistą lub software house’em – jak zabezpieczyć prawa do kodu?

Zapłata za kod nie oznacza automatycznego nabycia praw

Prawo własności do komputera, dostęp do repozytorium i autorskie prawa majątkowe to odrębne kwestie. Samo opłacenie faktury ani odebranie plików nie przesądza, że zamawiający może modyfikować program, udzielać licencji klientom, łączyć go z innymi produktami albo sprzedać prawa inwestorowi.

Jeżeli umowa nie zawiera wyraźnego postanowienia o przeniesieniu praw, ustawa przyjmuje co do zasady, że twórca udzielił licencji. Jej rzeczywisty zakres może jednak nie odpowiadać modelowi biznesowemu zamawiającego.

Wyjątek pracowniczy nie obejmuje automatycznie współpracy B2B

Majątkowe prawa do programu stworzonego przez pracownika w ramach obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej. Reguła ta nie powinna być automatycznie przenoszona na kontrakt z programistą prowadzącym działalność gospodarczą albo zewnętrznym software house’em.

W modelu B2B potrzebna jest wyraźna podstawa nabycia praw albo odpowiednio szeroka licencja. Jeżeli kod tworzy kilka osób, trzeba prześledzić cały łańcuch praw od poszczególnych autorów do wykonawcy, a następnie do klienta.

Najpierw rozdziel kod dedykowany od istniejących komponentów

Umowa powinna odróżniać elementy tworzone specjalnie dla klienta od narzędzi, bibliotek, frameworków, modułów i know-how, które wykonawca posiadał wcześniej albo rozwija dla wielu klientów. Próba przeniesienia praw do całego środowiska wykonawcy może być nierealna, a zbyt ogólne wyłączenie pozostawi klienta bez praw do kluczowej części produktu.

Dla kodu dedykowanego można przewidzieć przeniesienie praw. Dla komponentów standardowych właściwsza bywa licencja zapewniająca używanie, modyfikację, integrację, udostępnianie podmiotom z grupy oraz korzystanie przez następców i dostawców utrzymania.

Zakres powinien obejmować również dokumentację, projekty interfejsu, testy, modele danych, skrypty wdrożeniowe i inne rezultaty, jeżeli są potrzebne do samodzielnego rozwoju systemu.

Przeniesienie praw czy licencja?

Przeniesienie praw daje zamawiającemu pozycję właściciela autorskich praw majątkowych w uzgodnionym zakresie. Licencja pozostawia prawa przy wykonawcy, ale może pozwalać klientowi na szerokie korzystanie z programu. Wybór zależy od tego, czy oprogramowanie jest kluczowym aktywem firmy, czy standardowym narzędziem używanym w jej działalności.

Przy produkcie technologicznym rozwijanym dla wielu klientów przeniesienie wszystkich praw może być nieuzasadnione. Z kolei startup budujący własną platformę zwykle potrzebuje praw, które nie ograniczą przyszłej rundy, white-labelingu, udzielania sublicencji ani sprzedaży przedsiębiorstwa.

Licencja powinna określać wyłączność, czas, terytorium, możliwość sublicencjonowania i przeniesienia na następcę. Bez odmiennego postanowienia ustawowe reguły dotyczące czasu lub zakresu licencji mogą dać wynik inny niż zakładany przez strony.

Pola eksploatacji i forma umowy muszą być prawidłowe

Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności. Tego samego wymaga licencja wyłączna. Zwykła wiadomość e-mail, akceptacja w komunikatorze lub skan podpisu mogą nie spełniać tego wymagania. Przy podpisaniu elektronicznym należy użyć formy równoważnej pisemnej, jeżeli dokument ma wywołać taki skutek.

Przeniesienie praw albo licencja obejmują tylko pola eksploatacji wyraźnie wskazane w umowie. W przypadku programu trzeba uwzględnić w szczególności jego zwielokrotnianie, wprowadzanie, wyświetlanie, przechowywanie, modyfikowanie, tłumaczenie, łączenie z innymi systemami oraz rozpowszechnianie programu lub jego kopii w zakresie potrzebnym dla danego produktu.

Umowa może dotyczyć tylko pól znanych w chwili jej zawarcia. Nieważne jest także zobowiązanie obejmujące wszystkie przyszłe utwory danego twórcy lub wszystkie przyszłe utwory określonego rodzaju. Rezultaty powinny być więc opisane w powiązaniu z konkretną współpracą.

Software house powinien wykazać łańcuch praw

Klient zawiera umowę z jedną spółką, ale kod mogą tworzyć jej pracownicy, współpracownicy B2B i dalsi podwykonawcy. Zapewnienie, że software house ma prawa do rezultatów, powinno być poparte obowiązkiem zawierania odpowiednich umów z każdą osobą zaangażowaną w projekt.

Umowa może wymagać prowadzenia listy autorów i podwykonawców, udostępnienia potwierdzeń nabycia praw w razie audytu oraz naprawienia szkody, jeżeli osoba trzecia zgłosi roszczenie. Trzeba jednak rozsądnie ustalić procedurę obrony, kontrolę nad ugodą i limit odpowiedzialności.

Jeżeli klient akceptuje podwykonawców, powinien wiedzieć, czy oznacza to jedynie zgodę organizacyjną, czy również zmianę standardu bezpieczeństwa, lokalizacji przetwarzania danych albo odpowiedzialności wykonawcy.

Open source i komponenty osób trzecich wymagają kontroli

Oprogramowanie niemal zawsze korzysta z bibliotek lub narzędzi osób trzecich. Nie oznacza to automatycznie ryzyka, ale warunki ich licencji mogą wpływać na sposób dystrybucji produktu, obowiązki informacyjne, udostępnienie kodu albo możliwość komercyjnego korzystania.

Umowa powinna określać, czy wykonawca może używać komponentów open source bez zgody, które licencje są niedopuszczalne oraz jak dokumentuje zależności i ich wersje. Przy istotnym produkcie warto wymagać aktualnej listy komponentów i informacji o znanych podatnościach.

Osobno należy uregulować korzystanie z płatnych bibliotek, API, modeli AI, danych treningowych, stocków i usług chmurowych. Klient powinien znać koszty, ograniczenia licencyjne oraz ryzyko utraty dostępu po zakończeniu współpracy.

Repozytorium, dokumentacja i konta powinny być pod kontrolą klienta

Prawo do kodu nie pomoże, jeśli jedyna aktualna wersja znajduje się na prywatnym koncie programisty. Umowa powinna określać miejsce prowadzenia repozytorium, częstotliwość przekazywania zmian, zasady przeglądu kodu oraz uprawnienia klienta do pobrania kompletnej wersji.

Klient powinien mieć dostęp do dokumentacji technicznej, instrukcji wdrożenia, konfiguracji środowisk, kopii zapasowych i informacji o zależnościach. Konta domenowe, chmurowe, sklepowe i analityczne warto od początku zakładać na dane klienta albo zapewnić ich sprawne przeniesienie.

W projektach krytycznych można rozważyć depozyt kodu źródłowego, ale często lepszą ochronę daje bieżący dostęp do repozytorium i infrastruktury zamiast przekazania nieaktualnej kopii dopiero po wystąpieniu problemu.

Odbiór, błędy i prawa autorskie to odrębne mechanizmy

Odbiór powinien opierać się na uzgodnionych wymaganiach i testach, a nie na ogólnym stwierdzeniu, że system ma działać prawidłowo. Warto rozróżnić błędy blokujące, istotne i drobne oraz ustalić terminy ich usuwania.

Moment przejścia praw może być powiązany z odbiorem, powstaniem rezultatu albo zapłatą. Każdy wariant ma inne konsekwencje. Jeżeli prawa przechodzą dopiero po pełnej płatności, klient potrzebuje co najmniej prawa do korzystania z przekazanych wersji w czasie trwania sporu. Jeżeli przechodzą zbyt wcześnie, wykonawca powinien mieć inne zabezpieczenie wynagrodzenia.

Usuwanie wad w ramach odpowiedzialności za wykonanie projektu należy odróżnić od późniejszego utrzymania, rozwoju i SLA. Brak tego podziału prowadzi do sporu, czy nowa funkcja jest poprawką, czy pracą dodatkową.

Bezpieczeństwo, dane i narzędzia AI

Umowa powinna określać minimalne wymagania bezpieczeństwa, zarządzanie dostępami, zgłaszanie incydentów i sposób postępowania z danymi klienta. Jeżeli wykonawca przetwarza dane osobowe w imieniu zamawiającego, potrzebne mogą być postanowienia dotyczące powierzenia przetwarzania.

Warto ustalić zasady używania narzędzi generatywnej AI. Wklejenie kodu, danych albo niepublicznej dokumentacji do zewnętrznego narzędzia może naruszać poufność lub zasady bezpieczeństwa. Umowa może wymagać zgody na określone narzędzia, wyłączenia trenowania na danych klienta oraz weryfikacji wygenerowanego kodu pod kątem bezpieczeństwa i praw osób trzecich.

Zakończenie współpracy powinno umożliwić przejęcie projektu

Plan wyjścia powinien obejmować wydanie aktualnego kodu, dokumentacji, danych, kluczy i dostępów, przekazanie otwartych zadań oraz rozsądne wsparcie nowego zespołu. Trzeba wskazać, które działania mieszczą się w wynagrodzeniu, a które będą rozliczane dodatkowo.

Umowa powinna również regulować usunięcie kopii danych, dalsze obowiązywanie poufności, zakończenie licencji narzędziowych i przeniesienie kont. Przy wieloletnim projekcie warto okresowo sprawdzać, czy dokumentacja i dostęp rzeczywiście pozwalają innej osobie uruchomić system.

Braki w prawach do kodu wychodzą na jaw podczas due diligence

Inwestor albo kupujący spółkę zwykle bada, kto stworzył kluczowe oprogramowanie, na jakiej podstawie spółka nabyła prawa, jakie komponenty osób trzecich wykorzystuje produkt oraz czy umowy pozwalają na zmianę kontroli i dalszy rozwój.

Brak podpisanej umowy z jednym z pierwszych programistów może wpłynąć na wycenę, wymagać dodatkowych oświadczeń albo opóźnić transakcję. Uporządkowanie łańcucha praw jest znacznie łatwiejsze na początku współpracy niż kilka lat później, gdy autorzy nie pracują już przy projekcie.