MSA software house’u. Jak połączyć zamówienia, rozliczenia i IP?

Klient chce zacząć od dwóch developerów, potem zlecić integrację za stałą cenę i zostawić utrzymanie w rozliczeniu miesięcznym. Jeśli za każdym razem trzeba negocjować całą umowę od nowa, sprzedaż i delivery szybko zaczną się wzajemnie blokować.

MSA, czyli Master Services Agreement, to umowa ramowa ustalająca wspólne zasady współpracy. Konkretne prace opisujesz w zamówieniach, często nazywanych SOW (Statement of Work). Dobrze ułożony zestaw pozwala przyjmować kolejne zlecenia, rozliczać je według właściwego modelu i przekazywać klientowi uzgodnione prawa bez każdorazowego otwierania całych negocjacji.

Czego dowiesz się z tego tekstu?

Co trafia do MSA, a co do zamówienia?

W MSA ustal zasady składania zamówień, poufność, odpowiedzialność, podstawowy mechanizm płatności i IP oraz sposób rozwiązywania sporów. Zamówienie powinno konkretyzować usługę: zakres, zespół, terminy, cenę, model rozliczeń, kryteria odbioru i odstępstwa od ramy.

Ustal także hierarchię dokumentów. Jeżeli SOW może zmienić MSA, określ, jak wyraźnie trzeba wskazać zmianę i kto może ją zatwierdzić. W przeciwnym razie przypadkowa uwaga w zamówieniu może stać się przedmiotem sporu o odpowiedzialność za cały projekt.

Wspólne zasady nie oznaczają identycznej treści każdego zlecenia. Załóżmy, że software house rozwija aplikację godzinowo, a osobną integrację dostarcza za ustaloną kwotę. Oba zamówienia mogą korzystać z jednej MSA, ale powinny inaczej opisywać rozliczenie i odbiór.

T&M, fixed price i udostępnianie zespołu potrzebują różnych ustaleń

W modelu time and materials (T&M) wynagrodzenie opiera się zwykle na uzgodnionych stawkach i faktycznie wykonanej pracy. Opisz raportowanie czasu, akceptację zestawień, limity budżetu i osoby uprawnione do zlecania zadań. Określ, czy estymacja jest orientacyjna, czy stanowi wiążący limit.

Przy fixed price cena dotyczy ustalonego zakresu. Potrzebujesz granic tego zakresu, kryteriów odbioru, zależności od klienta oraz sposobu wyceny zmian. Bez tego każdy nowy pomysł na funkcję może wrócić jako twierdzenie, że przecież „miał być w cenie”.

Przy udostępnianiu zespołu, często nazywanym body leasingiem, ustal, kto zarządza zadaniami, jak zapewniacie dostępność osób, co dzieje się przy zastępstwie i za co odpowiada dostawca. Sama nazwa modelu nie przesądza kwalifikacji prawnej ani obowiązków stron. Faktyczny sposób kierowania pracą wymaga też oceny od strony prawa pracy, w tym ewentualnych regulacji pracy tymczasowej.

Płatność nie powinna utknąć w niekończącym się odbiorze

Ustal podstawę wystawienia faktury i termin zgłoszenia konkretnych zastrzeżeń. W T&M może to być raport wykonanej pracy, a w zamówieniu rezultatu przekazanie uzgodnionego etapu i procedura odbioru. Podpis klienta pod protokołem nie powinien pozostawać jedynym mechanizmem, jeśli umowa nie wyjaśnia, co następuje przy jego milczeniu.

Rozdziel błąd od nowego wymagania. Opisz, co musi zawierać zgłoszenie, które wady blokują odbiór i jak rozliczacie część prac, której klient nie kwestionuje. Przy współpracy godzinowej samo użycie nazwy T&M nie zwalnia z należytego wykonywania uzgodnionych obowiązków.

Wróćmy do integracji za stałą cenę. Klient ma dostarczyć dostęp do API i dane testowe, ale robi to z opóźnieniem. Zamówienie powinno określać wpływ takiej zależności na harmonogram i ewentualne koszty gotowości zespołu. Sama data końcowa pozostawiona bez tych ustaleń przenosi dyskusję o organizacji pracy na spór o zwłokę.

IP musi odpowiadać temu, co faktycznie powstaje

Rozdziel rezultaty tworzone dla klienta, własne narzędzia i biblioteki dostawcy oraz komponenty zewnętrzne. Klient może potrzebować praw pozwalających rozwijać i sprzedawać produkt, a software house zachowania możliwości używania własnego frameworka przy następnych projektach. To da się pogodzić, jeśli umowa dokładnie opisuje granice.

Wskaż, które rezultaty obejmuje przeniesienie praw, kiedy ono następuje i jak identyfikujecie przekazane wersje. Jeśli wiążesz transfer z zapłatą, ustal również korzystanie z kodu przed rozliczeniem oraz skutki częściowej płatności. Repozytorium, release i raport prac powinny pomagać ustalić, czego dotyczy rozliczenie.

W polskim prawie przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności, a pola eksploatacji trzeba wyraźnie wymienić (art. 41 i 53 prawa autorskiego). Zwykły e-mail z zamówieniem lub samo kliknięcie „approve” nie zastąpią wymaganej formy. Mechanizm przyszłych zamówień i identyfikacji utworów trzeba z nią pogodzić. Więcej o dokumentach w całym łańcuchu praw przeczytasz w checkliście IP przed due diligence.

Nie obiecuj przeniesienia praw do open source ani cudzych komponentów tak, jakby były własnym kodem. Określ zasady ich użycia i przekazania klientowi informacji o licencjach. Osobno sprawdź, czy prawa otrzymane od podwykonawców wystarczają do spełnienia obietnic z MSA.

Odpowiedzialność sprawdź razem z resztą umowy

Limit odpowiedzialności może wyglądać rozsądnie, a tracić znaczenie przez szerokie wyjątki, kumulację kar i dodatkowe zobowiązania w załączniku bezpieczeństwa. Zestaw te postanowienia ze sobą oraz z wartością i rodzajem zamówień.

W polskim prawie swoboda umów ma granice, a odpowiedzialności za szkodę wyrządzoną umyślnie nie można skutecznie wyłączyć (art. 353¹ i 473 § 2 Kodeksu cywilnego). Nie istnieje więc jeden limit pasujący do każdego kontraktu. Jeżeli wchodzą w grę utrzymanie lub bezpieczeństwo, połącz odpowiedzialność z SLA i kryteriami bezpiecznego odbioru.

Co dzieje się z zamówieniami po wypowiedzeniu MSA?

Ustal, czy zakończenie ramy zamyka także aktywne zlecenia, czy wyłącznie możliwość składania następnych. Opisz przekazanie prac, dostępów i dokumentacji oraz rozliczenie etapów w toku. Uwzględnij, jakie prawa i obowiązki pozostają po zakończeniu współpracy.

Dla software house’u oznacza to możliwość zaplanowania zespołu i odzyskania należnych płatności. Dla klienta to możliwość przejęcia rezultatów i kontynuowania projektu bez sporu o każdy dostęp oraz plik.

W skrócie

• MSA ustala zasady wspólne, a SOW konkretny zakres, cenę i model współpracy.
• T&M, fixed price i udostępnianie zespołu potrzebują dopasowanych reguł raportowania, odbioru i odpowiedzialności.
• Połącz fakturę z udokumentowaną pracą i określoną procedurą zgłaszania zastrzeżeń.
• Rozdziel IP klienta, własne komponenty i elementy zewnętrzne; dopilnuj formy przeniesienia praw.
• Zakończenie ramy i zakończenie zamówienia opisz osobno.

W przykładzie współpracy z dostawcą IT podpisana umowa pozwoliła prowadzić płatne prace z uzgodnionymi zasadami zlecania, rozliczeń i IP. Takie powiązanie biznesu z kontraktem jest punktem wyjścia naszego wsparcia prawnego firm IT.