Sama zapłata nie przesądza, komu przysługują prawa
Faktura za „wykonanie dodatkowego modułu” nie zastępuje ustaleń o prawach do oprogramowania. Klient może finansować przyspieszenie rozwoju produktu, konfigurację pod swoje potrzeby albo stworzenie rozwiązania, do którego ma otrzymać określone prawa. Każdy z tych modeli wymaga innych ustaleń.
Dlatego zaczynam od całego porozumienia: umowy głównej, zamówienia, zaakceptowanej oferty, specyfikacji i korespondencji. Przy wykładni umowy znaczenie mają także okoliczności jej zawarcia, zgodny zamiar stron i cel współpracy. Sam tytuł dokumentu nie wystarcza.
Nie oznacza to, że korespondencja zawsze skutecznie przenosi prawa. Przeniesienie autorskich praw majątkowych oraz licencja wyłączna wymagają formy pisemnej pod rygorem nieważności. Brak wyraźnego postanowienia o przeniesieniu prawa prowadzi, zgodnie z art. 65 prawa autorskiego, do przyjęcia licencji. Z kolei licencja bez zastrzeżenia wyłączności jest niewyłączna. Nie wolno jednak z tych reguł wyciągać wniosku, że inne uzgodnione ograniczenia przestają Cię wiązać.
Prawo autorskie chroni kod, nie samą funkcjonalność
Ochronie może podlegać twórczy, indywidualny sposób wyrażenia programu, w tym jego kod. Sama funkcjonalność, idea lub zasada działania programu nie jest objęta taką ochroną. To rozróżnienie ma znaczenie, gdy klient oczekuje, że finansując funkcję, uzyska wyłączność na każdy sposób osiągnięcia tego samego rezultatu.
Nie znaczy to, że możesz skopiować dowolny kod albo zignorować umowę. Prawa do konkretnej implementacji i zobowiązanie, aby nie oferować podobnego rozwiązania innym, wymagają odrębnej oceny.
Jak ten problem wygląda w praktyce
Przykład hipotetyczny.
Klient finansuje integrację Twojego SaaS z popularnym systemem księgowym. Już w zamówieniu ustalacie, że płaci za wcześniejsze wdrożenie, prawa do nowego kodu pozostają przy Tobie, a integrację możesz udostępniać innym bez danych, indywidualnych ustawień i poufnych schematów rozliczeń klienta. Gdy zgłasza się drugi klient, możesz zaoferować mu integrację w tych granicach. Gdybyś jednak zobowiązał się nie oferować takiej funkcji innym, samo napisanie nowego kodu nie wystarczyłoby do ominięcia zakazu.
Oddziel nowy moduł od rdzenia swojego SaaS
Zanim uzgodnisz prawa, opisz, co rzeczywiście powstanie w ramach zamówienia. Nowa funkcja może korzystać z istniejącego systemu logowania, modelu danych, bibliotek i mechanizmów przetwarzania. Nie stają się one automatycznie elementami stworzonymi dla klienta tylko dlatego, że są potrzebne do działania modułu.
Proponuję rozdzielić wcześniejszy produkt, nowy kod wykonywany w ramach zamówienia, zmiany wspólne dla całego SaaS oraz materiały dostarczone przez klienta. Specyfikacja powinna pozwalać ustalić granice tych elementów także po kolejnych aktualizacjach. Samo określenie „wszelkie rezultaty współpracy” zwykle nie wyjaśnia, jak traktować rozwijany równolegle produkt.
Sprawdź też zależności od cudzych bibliotek i systemów. Możesz obiecać klientowi tylko takie prawa, którymi możesz rozporządzać. Jeżeli przenosisz prawa do modułu, potrzebujesz odpowiedniej podstawy do dalszego korzystania z niego w zakresie niezbędnym do świadczenia usługi i utrzymania SaaS. Sam obowiązek serwisowania nie powinien pozostawiać tej kwestii niedopowiedzianej.
Prawa do kodu i wyłączność biznesowa to różne ustalenia
Przeniesienie autorskich praw majątkowych dotyczy oznaczonego utworu i pól eksploatacji wyraźnie wskazanych w umowie. Licencja wyłączna nie przenosi tych praw, ale zastrzega wyłączność korzystania w uzgodnionym zakresie. Trzeba przy tym rozstrzygnąć, jakie uprawnienia zachowujesz Ty jako dostawca.
Osobnym ustaleniem może być Twoje zobowiązanie, że przez określony czas nie zaoferujesz podobnej funkcji innym odbiorcom. Takie ograniczenie może sięgać dalej niż ochrona konkretnego kodu. Napisanie innej implementacji nie usuwa wtedy automatycznie problemu.
Nie wystarczy więc wpisać, że „prawa pozostają przy dostawcy”, jeżeli inne postanowienie blokuje sprzedaż podobnych rozwiązań. W drugą stronę: samo przekazanie praw do określonego kodu nie jest równoznaczne z wyłącznością klienta na każdą funkcję o takim działaniu. Dopuszczalność i skutki ograniczeń trzeba ocenić w konkretnej umowie, z uwzględnieniem ustawowych granic swobody umów.
Wyznacz granice wyłączności, zanim ustalisz cenę
Najpierw ustal, czego klient chce uniknąć. Czy chodzi o udostępnienie konkretnego modułu, podobnej funkcji, czy rozwiązania wykorzystującego jego poufne założenia? Słowo „podobny” bez doprecyzowania może objąć znacznie więcej, niż zakładasz przy wycenie.
Następnie określ odbiorców i rynek objęty ograniczeniem. Wyłączność dla jednej spółki nie musi oznaczać ochrony całej jej grupy. Zakaz oferowania funkcji „konkurentom” wymaga ustalenia, jak ich identyfikować i co dzieje się po zmianie profilu działalności klienta. Znaczenie mogą mieć także branża i terytorium.
Cena samej pracy programistycznej nie pokazuje kosztu rezygnacji z przyszłych zamówień. Uwzględnij również utrzymywanie osobnej wersji, dodatkowe testy i ograniczenia dalszego rozwoju.
Koniec subskrypcji nie musi oznaczać końca wyłączności
Ustal początek i koniec ograniczenia oraz jego związek z abonamentem. Nie zakładaj, że zakończenie subskrypcji automatycznie usuwa wszystkie zobowiązania wynikające z zamówienia rozwoju. Również wygaśnięcie biznesowej wyłączności samo w sobie nie powoduje powrotnego przeniesienia praw autorskich.
Osobno uzgodnij sytuację istniejących klientów i wcześniejszych wersji produktu. Czy możesz nadal świadczyć im usługę, usuwać błędy i dostarczać aktualizacje? Czy ograniczenie obejmuje nowe wdrożenia, czy również rozwój już działających? Odpowiedzi powinny odpowiadać temu, co rzeczywiście potrafisz utrzymać technicznie.
Określ także zasady utrzymania modułu dla zamawiającego i finansowania zmian wymaganych przez system, z którym się integruje. Jednorazowa opłata za stworzenie funkcji nie wyjaśnia, kto będzie odpowiadał za jej rozwój i koszty w kolejnych latach. Te ustalenia powinny być spójne z zakresem praw oraz terminami wyłączności.
Ponowne wykorzystanie wymaga też sprawdzenia poufności
Nawet jeśli zachowujesz prawa do kodu i nie przyjmujesz wyłączności, sprawdź, jakie informacje wykorzystujesz. Dane klienta, niepubliczne procesy, reguły rozliczeń czy dokumentacja mogą być objęte zobowiązaniem do poufności. Nie każda informacja jest tajemnicą przedsiębiorstwa: znaczenie mają między innymi jej wartość gospodarcza, niepubliczny charakter i działania podjęte dla zachowania poufności.
Umowa może obejmować poufnością także informacje, które nie spełniają wszystkich ustawowych przesłanek tajemnicy przedsiębiorstwa. Dlatego nie traktuję ogólnego zastrzeżenia prawa do korzystania z „wiedzy i doświadczenia” jako zgody na dowolne wykorzystanie materiałów klienta.
Rozwijając funkcję dla kolejnych odbiorców, oddziel ogólne rozwiązanie techniczne od cudzych chronionych materiałów i poufnych informacji. Napisanie kodu od nowa nie wystarczy, jeżeli nadal wykorzystujesz informacje wbrew obowiązującym Cię ograniczeniom.
Podstawy prawne
- Ustawa o prawie autorskim i prawach pokrewnych: art. 1 ust. 2¹, art. 41 ust. 2, art. 53, art. 65, art. 67 ust. 2 i 5 oraz art. 74 ust. 2 i 4.
- Kodeks cywilny: art. 65 i art. 353¹.
- Ustawa o zwalczaniu nieuczciwej konkurencji: art. 11.
Materiał ma charakter ogólny i nie stanowi porady prawnej w konkretnej sprawie. Właściwe rozwiązanie zależy od stanu faktycznego, dokumentów i celu biznesowego.
Podsumowanie
O możliwości oferowania zamówionej funkcji innym klientom decydują prawa do konkretnego rozwiązania, treść umowy oraz ograniczenia dotyczące informacji. Sama faktura nie daje odpowiedzi. Przed przyjęciem zamówienia warto wiedzieć, co finansuje klient, które prawa otrzymuje i jak dokładnie ma działać ewentualna wyłączność.