Rozwiązania typu Software as a Service stały się codziennością w biznesie. Korzystają z nich biura rachunkowe, sklepy internetowe, działy sprzedaży, firmy logistyczne, zespoły projektowe oraz podmioty świadczące usługi online. Warto zwrócić uwagę, jakie znaczenie mają prawa autorskie w przypadku korzystania z tych rozwiązań. W modelu SaaS przedsiębiorca najczęściej nie kupuje programu. Uzyskuje dostęp do aplikacji, która działa w chmurze i jest utrzymywana przez dostawcę.
Z perspektywy biznesowej jest to wygodne. Nie trzeba tworzyć własnej infrastruktury, samodzielnie instalować programu ani zarządzać jego bieżącym utrzymaniem. System może zostać wdrożony szybciej, a jego rozwój pozostaje zwykle po stronie dostawcy.
Szczególne znaczenie SaaS ma w branży e-commerce. Sklep internetowy rzadko działa dziś jako jeden samodzielny system. Zwykle korzysta równolegle z platformy sprzedażowej, systemu płatności, narzędzi marketingowych, programu magazynowego, CRM oraz aplikacji kurierskich. Żeby cały ten system działał sprawnie, często potrzebne są dodatkowe API, pluginy, moduły lub integracje. Wtedy pojawia się pytanie: komu przysługują prawa autorskie do oprogramowania i rozwiązań tworzonych wokół systemu SaaS? Czy pozostają one przy dostawcy platformy, przysługują wykonawcy integracji, czy może należą do przedsiębiorcy, który zapłacił za ich przygotowanie?
Z artykułu dowiesz się:
- dlaczego korzystanie z SaaS nie oznacza własności oprogramowania,
- komu przysługują prawa autorskie do oprogramowania, API, pluginów, modułów i integracji,
- kiedy zapłata za wdrożenie nie przenosi praw autorskich,
- jak zabezpieczyć możliwość dalszego rozwoju i przeniesienia integracji.
SaaS i prawa autorskie do oprogramowania – dostęp nie oznacza własności
Najczęstsze nieporozumienie przy SaaS polega na założeniu, że skoro firma korzysta z systemu i płaci abonament, to ma do niego prawa podobne do właścicielskich. Tak jednak zwykle nie jest. W typowym modelu SaaS przedsiębiorca otrzymuje dostęp do aplikacji, a nie fizycznej kopii programu. Nie dostaje też kodu źródłowego ani prawa do samodzielnego zainstalowania systemu na własnym serwerze. Korzysta z narzędzia w takim zakresie, w jakim przewiduje to umowa lub regulamin.
W praktyce oznacza to, że przedsiębiorca może logować się do systemu, przetwarzać dane, wykonywać określone operacje, korzystać z panelu użytkownika albo z API. Nie oznacza to jednak nabycia praw do samego oprogramowania. Kod źródłowy, architektura systemu, dokumentacja techniczna i inne elementy platformy pozostają zazwyczaj przy dostawcy albo innym podmiocie uprawnionym.
W umowach SaaS często pojawia się słowo „licencja”. Nie zawsze należy je rozumieć jako klasyczną licencję do programu komputerowego. W wielu przypadkach chodzi jedynie o zgodę na korzystanie z usługi w określonym zakresie. Dostawca dopuszcza klienta do platformy, ale jednocześnie wyłącza możliwość kopiowania programu, modyfikowania go, odtwarzania kodu lub przenoszenia systemu na własną infrastrukturę.
Jeżeli przedsiębiorca chce uzyskać dalej idące uprawnienia, powinny one zostać wyraźnie wpisane do umowy. Dotyczy to zwłaszcza dodatkowych rozwiązań tworzonych wokół SaaS. Integracja z magazynem, plugin do sklepu internetowego albo dedykowane API mogą mieć realną wartość gospodarczą. Nie powinno się więc zakładać, że skoro zostały opłacone, to automatycznie należą do zamawiającego.
API, plugin i integracja – co podlega ochronie?
Punktem wyjścia jest art. 1 ust. 1 ustawy o prawie autorskim i prawach pokrewnych (dalej: „p.a.p.p.”). Zgodnie z tym przepisem przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci. Programy komputerowe zostały wprost wymienione w art. 1 ust. 2 pkt 1 p.a.p.p. jako przykład utworów chronionych prawem autorskim.
Nie oznacza to jednak, że ochrona obejmuje każdy pomysł techniczny. Sam pomysł na integrację, ogólna funkcja programu albo zasada działania systemu nie stanowią jeszcze przedmiotu prawa autorskiego. Wynika to z art. 1 ust. 2¹ p.a.p.p., zgodnie z którym ochroną nie są objęte odkrycia, idee, procedury, metody i zasady działania.
Chroniony może być natomiast konkretny sposób wyrażenia rozwiązania. W przypadku SaaS, API, pluginów i integracji mogą to być np. kod źródłowy, kod wynikowy, twórcze elementy interfejsu, grafiki, dokumentacja techniczna albo indywidualnie przygotowany układ określonych elementów. Nie każde rozwiązanie techniczne będzie jednak utworem. Proste komendy, typowe mechanizmy i standardowe rozwiązania mogą nie mieć samodzielnego charakteru twórczego.
Autorskie prawa osobiste i majątkowe – jak je rozróżnić?
Warto też rozróżniać autorskie prawa osobiste i majątkowe. Prawa osobiste chronią więź twórcy z utworem. Obejmują m.in. prawo do autorstwa, oznaczenia utworu nazwiskiem lub pseudonimem, nienaruszalności treści i formy utworu oraz decydowania o jego pierwszym udostępnieniu. Są niezbywalne, więc nie można ich skutecznie przenieść na inny podmiot.
Inaczej jest z autorskimi prawami majątkowymi. To one mają podstawowe znaczenie ekonomiczne. Mogą zostać przeniesione albo objęte licencją. Pozwalają korzystać z utworu, rozporządzać nim na określonych polach eksploatacji i pobierać wynagrodzenie za korzystanie z niego przez inne podmioty.
Przy programach komputerowych szczególne znaczenie ma art. 74 p.a.p.p. Autorskie prawa majątkowe do programu obejmują m.in.:
- jego trwałe lub czasowe zwielokrotnianie,
- tłumaczenie,
- przystosowywanie,
- zmianę układu,
- dokonywanie innych zmian oraz rozpowszechnianie, w tym użyczenie lub najem programu albo jego kopii.
Te uprawnienia powinny być w umowie opisane możliwie precyzyjnie.
Trzeba też pamiętać o art. 75 p.a.p.p. Ustawa przewiduje sytuacje, w których zgoda uprawnionego nie jest wymagana. Dotyczy to m.in. czynności koniecznych do korzystania z programu zgodnie z jego przeznaczeniem, w tym poprawiania błędów przez osobę, która legalnie weszła w posiadanie programu. Dopuszczalne może być również sporządzenie kopii zapasowej, jeśli jest ona niezbędna do korzystania z programu.
Użytkownik może także obserwować, badać i testować działanie programu, aby poznać jego idee i zasady. W wyjątkowych przypadkach możliwe jest powielenie kodu lub tłumaczenie jego formy, ale tylko wtedy, gdy jest to potrzebne do połączenia niezależnie stworzonego programu z innym oprogramowaniem. Nie daje to jednak swobody kopiowania cudzego rozwiązania. Informacje uzyskane w ten sposób nie mogą być wykorzystane do stworzenia podobnego, konkurencyjnego programu ani do innych działań naruszających prawa autorskie.
Kto ma prawa do rozszerzeń tworzonych na potrzeby korzystającego?
Odpowiedź zależy od tego, kto stworzył dane rozwiązanie i na jakiej podstawie. Inaczej należy oceniać kod napisany przez pracownika, inaczej przez freelancera, a jeszcze inaczej przez software house realizujący zlecenie.
Jeżeli program komputerowy został stworzony przez pracownika w ramach obowiązków pracowniczych, zastosowanie ma art. 74 ust. 3 p.a.p.p. Zgodnie z tym przepisem autorskie prawa majątkowe do programu komputerowego stworzonego przez pracownika przysługują pracodawcy, chyba że umowa stanowi inaczej.
Warto jednak zadbać, aby zakres obowiązków pracownika rzeczywiście obejmował tworzenie oprogramowania, modułów, pluginów, integracji lub dokumentacji. Pozwala to ograniczyć późniejsze spory o to, czy dane rozwiązanie powstało w ramach stosunku pracy, czy poza nim.
Freelancer albo software house, zapłata to nie zawsze nabycie praw
Przy umowach cywilnoprawnych sytuacja jest mniej automatyczna. Jeżeli rozszerzenie, plugin albo integrację tworzy freelancer lub software house, samo zapłacenie wynagrodzenia nie oznacza jeszcze nabycia autorskich praw majątkowych. Potrzebne jest wyraźne postanowienie umowne.
Umowa powinna wskazywać, czy dochodzi do przeniesienia praw, czy tylko do udzielenia licencji. Powinna też określać pola eksploatacji oraz moment przejścia praw. Może to być np. chwila zapłaty, odbioru prac, podpisania protokołu albo przekazania kodu do repozytorium.
Biblioteki, komponenty i narzędzia wykonawcy
W praktyce oprogramowanie rzadko powstaje całkowicie od zera. Programiści korzystają z bibliotek open source, gotowych komponentów lub własnych narzędzi używanych w wielu projektach. Prawa do takich elementów nie przechodzą automatycznie na zamawiającego. Wykonawca powinien więc wskazać, jakie komponenty zostały użyte i na jakich zasadach mogą być wykorzystywane.
Znaczenie może mieć również współautorstwo. Zgodnie z art. 9 ust. 1 p.a.p.p. współtwórcom przysługuje prawo autorskie wspólnie. Przy projektach programistycznych nad jednym rozwiązaniem często pracuje kilka osób. Jeżeli wkłady tych osób tworzą jedną całość, ustalenie udziałów może być trudne. Z tego powodu już w umowie warto przesądzić, kto odpowiada za nabycie praw od osób uczestniczących w projekcie i jakie prawa finalnie otrzymuje zamawiający.
Co warto rozdzielić w umowie?
Najbezpieczniej jest wyraźnie rozdzielić trzy grupy elementów. Pierwsza to platforma SaaS, która zwykle pozostaje przy dostawcy. Druga to komponenty, biblioteki i narzędzia wykonawcy. Trzecia to rozwiązania stworzone specjalnie dla korzystającego, np. dedykowana integracja albo plugin.
Bez takiego podziału przedsiębiorca może zapłacić za rozwiązanie, którego później nie będzie mógł swobodnie rozwijać ani przenieść do innego systemu.
Jak zabezpieczyć prawa do integracji e-commerce w umowie?
W umowach SaaS zwykle znajdziemy postanowienia ograniczające sposób korzystania z systemu. Dostawca najczęściej zastrzega, że użytkownik nie może odtwarzać kodu źródłowego, obchodzić zabezpieczeń, kopiować funkcji platformy ani przekazywać danych logowania innym osobom. Z jego perspektywy jest to zrozumiałe – chroni w ten sposób oprogramowanie, know-how i model działania usługi.
Nie należy jednak wyciągać z tego wniosku, że połączenie SaaS z innymi narzędziami jest z góry zakazane. W e-commerce integracje są często warunkiem normalnego działania sklepu. System sprzedażowy musi przecież wymieniać dane z bramką płatniczą, magazynem, CRM, narzędziami marketingowymi albo aplikacją kurierską. Dlatego w umowie powinno być jasno napisane, czy korzystający może używać API, tworzyć połączenia z innymi systemami i powierzyć wykonanie takiej integracji zewnętrznemu wykonawcy.
W praktyce najważniejsze jest rozdzielenie dwóch rzeczy: praw do samej platformy oraz praw do rozwiązań przygotowanych specjalnie dla danego przedsiębiorcy. Platforma SaaS, jej kod, architektura, dokumentacja i infrastruktura najczęściej pozostają przy dostawcy. Inaczej można natomiast uregulować dedykowaną integrację, plugin albo moduł stworzony na potrzeby konkretnego sklepu internetowego.
W tym zakresie nie warto zostawiać miejsca na domysły. Umowa powinna przesądzać, czy przedsiębiorca nabywa autorskie prawa majątkowe, czy otrzymuje tylko licencję. Powinna też odpowiadać na kilka praktycznych pytań: czy przedsiębiorca otrzyma kod źródłowy, czy dostanie dokumentację techniczną, czy będzie mógł zlecić dalszy rozwój integracji innemu wykonawcy i czy wolno mu korzystać z niej po zakończeniu współpracy z dostawcą.
Dobrze napisana umowa SaaS powinna więc rozdzielać co najmniej trzy kategorie: podstawową platformę dostawcy, komponenty zewnętrzne lub narzędzia wykonawcy oraz elementy stworzone specjalnie dla klienta. Dopiero taki podział realnie zabezpiecza przedsiębiorcę. W przeciwnym razie może się okazać, że zapłacił za rozwiązanie, którego nie może samodzielnie rozwijać, przenieść do innego środowiska ani używać po zmianie dostawcy.
Podsumowanie
W modelu SaaS samo korzystanie z systemu nie oznacza nabycia praw do oprogramowania. Przedsiębiorca najczęściej otrzymuje jedynie dostęp do usługi na zasadach określonych w umowie lub regulaminie. Dotyczy to także wielu rozwiązań tworzonych wokół systemu, takich jak API, pluginy, moduły czy integracje.
Dlatego przy wdrożeniach SaaS kluczowe jest ustalenie, komu przysługują prawa autorskie do oprogramowania oraz do jego poszczególnych elementów. Inaczej należy traktować samą platformę dostawcy, inaczej komponenty open source lub narzędzia wykonawcy, a jeszcze inaczej rozwiązania stworzone specjalnie dla konkretnego klienta.
Największym błędem jest założenie, że zapłata za wykonanie integracji automatycznie przenosi autorskie prawa majątkowe na zamawiającego. Tak nie jest. Jeżeli przedsiębiorca chce swobodnie rozwijać, modyfikować, przenosić albo zlecać dalszą obsługę takiego rozwiązania innemu podmiotowi, powinno to wyraźnie wynikać z umowy.
Dobrze przygotowana umowa SaaS lub umowa wdrożeniowa powinna więc precyzyjnie określać zakres licencji albo przeniesienia praw, pola eksploatacji, moment przejścia praw, zasady dostępu do kodu źródłowego, możliwość korzystania z dokumentacji oraz prawa do dalszego rozwoju integracji.
W praktyce to właśnie te postanowienia decydują o tym, czy przedsiębiorca rzeczywiście kontroluje rozwiązanie, za które zapłacił, czy jedynie czasowo z niego korzysta na warunkach narzuconych przez dostawcę lub wykonawcę.
Masz wdrożony system SaaS, integrację, plugin albo dedykowany moduł i nie masz pewności, kto ma do niego prawa?
Warto zweryfikować umowę, regulamin oraz dokumentację techniczną, zanim pojawi się spór z dostawcą, wykonawcą albo software house’em. Kancelaria Prawna ANSWER pomaga analizować i przygotowywać umowy SaaS, umowy wdrożeniowe, umowy licencyjne oraz postanowienia dotyczące praw autorskich do oprogramowania.
Skontaktuj się z nami, jeżeli chcesz zabezpieczyć prawa do rozwiązań technologicznych tworzonych dla Twojej firmy.
I czytaj nasze publikacje na LinkedIn, gdzie regularnie omawiamy praktyczne problemy prawne dotyczące nowych technologii, e-commerce, SaaS, własności intelektualnej i umów IT.
