Jeśli program komputerowy tworzony jest od podstaw na zamówienie przedsiębiorcy, najkorzystniejszym rozwiązaniem dla niego będzie przejęcie autorskich praw majątkowych. Najczęściej, zlecając napisanie takiego oprogramowania, firma zawiera umowę o dzieło.
O ile sama w sobie nie wymaga ona jakiejkolwiek szczególnej formy, o tyle jeśli ma dotyczyć przeniesienia autorskich praw majątkowych, to wymagane jest już zachowanie formy pisemnej pod rygorem nieważności.
Jeżeli w umowie strony wyraźnie nie stwierdziły, że doszło do przeniesienia autorskich praw majątkowych, domniemywa się, że strony zawarły umowę licencyjną.
W umowie o dzieło przedsiębiorca powinien najbardziej precyzyjnie, jak to jest możliwe, określić cechy zamawianego programu komputerowego (jego funkcjonalność, cele, zakres współpracy z innymi oprogramowaniami itp.).
Im dokładniejsze określenie jego parametrów, tym mniejsza swoboda przyjmującego zamówienie i większa szansa na skuteczne dochodzenie przez zamawiającego swych praw, w razie gdyby oprogramowanie nie spełniało jego wymagań.
Oprócz określenia funkcjonalności programu wykonawca powinien szczegółowo poznać środowisko informatyczne zamawiającego, aby dostosować tworzoną aplikację do istniejących uwarunkowań technicznych lub określić zakres wymagań sprzętowych dla prawidłowego funkcjonowania oprogramowania.
[srodtytul]Moment przejęcia praw [/srodtytul]
Umowa powinna precyzyjnie określać moment przejścia własności stworzonego programu i praw z nim związanych. Najkorzystniejsze dla przedsiębiorcy wydaje się wpisanie postanowienia, zgodnie z którym własność programu i wszelkie prawa, o których mowa w umowie, przejdą na przedsiębiorcę z chwilą przyjęcia dzieła.
Będzie to moment, w którym zamawiający będzie miał możliwość zapoznania się z gotowym produktem. W praktyce strony często w kontrakcie przewidują odpowiedni okres i zakres testów zakończony podpisaniem protokołu przyjęcia albo protokołu wad, których usunięcie jest niezbędne do przyjęcia oprogramowania i zapłaty wynagrodzenia.
Uwaga! Przeniesienie całości autorskich praw majątkowych na zamawiającego nie powoduje automatycznie przejścia na nabywcę prawa zezwalania na wykonywanie zależnego prawa autorskiego, np. wprowadzania do niego zmian. Jeśli więc zamawiającemu zależy na takich uprawnieniach, powinien wpisać do umowy odpowiednie postanowienia.
[srodtytul]Pola eksploatacji[/srodtytul]
Kluczowym elementem umowy o przeniesienie autorskich praw majątkowych do programu jest określenie pól eksploatacji, które wskazują, w jakim obszarze zamawiający nabywa te prawa.
W przepadku programów komputerowych będą to najczęściej: prawo do korzystania; do zwielokrotniania (np. więcej niż jeden użytkownik może korzystać z oprogramowania jednocześnie); tłumaczenia; zmian układu; rozpowszechniania itp.
By prawidłowo opisać pola eksploatacji, przedsiębiorca musi odpowiedzieć sobie na pytanie, w jaki sposób będzie chciał korzystać z zamówionego programu, np. przerabiać go, rozpowszechniać, użyczać, kopiować etc. Ustalone obszary korzystania z programu stanowią właśnie pola eksploatacji, które należy precyzyjnie opisać w umowie.
Z punktu widzenia przedsiębiorcy oczywiście korzystne jest wskazanie w umowie jak największej liczby pól eksploatacji, nawet potencjalnych. Należy przy tym pamiętać, że umowa może dotyczyć tylko tych pól eksploatacji, które są znane w chwili jej zawierania.
Za wykonanie dzieła oraz za przeniesienie majątkowych praw autorskich do programu przedsiębiorca będzie musiał zapłacić odpowiednie wynagrodzenie. W umowie warto wyraźnie wskazać, że zapłata dotyczy także przeniesienia majątkowych praw autorskich. W przeciwnym razie, jeśli dojdzie do sporu, sąd może uznać, że za przeniesienie autorskich praw majątkowych twórcy będzie się należało odrębne wynagrodzenie.
[srodtytul]Gwarancja i wady fizyczne[/srodtytul]
Zgodnie z prawem autorskim, gdy program komputerowy zawiera usterki, zamawiający ma prawo od umowy odstąpić, jeżeli w wyznaczonym terminie wykonawca ich nie usunie. Zamawiający może także żądać stosownego obniżenia wynagrodzenia.
W praktyce strony wprowadzają do umów postanowienia szczegółowo regulujące roszczenia gwarancyjne poprzez określenie terminu gwarancji (długość uzależniona jest często od skomplikowania oprogramowania, jego wartości i poziomu istotności dla zamawiającego), warunki skorzystania z gwarancji itp.
Jeżeli strony umowy będące przedsiębiorcami nie wyłączą wyraźnie stosowania rękojmi (art. 558 k.c.) za wady fizyczne i prawne, zamawiającemu będą także przysługiwały, oprócz gwarancji, roszczenia z tego tytułu.
Nie należy uprawnień z tytułu gwarancji mylić z zawieraną często umową serwisową. Ta druga jest zwykle odpłatna. Natomiast w ramach gwarancji twórca oprogramowania powinien usuwać istniejące usterki i błędy bez konieczności ponoszenia dodatkowego wynagrodzenia.
W praktyce należy określić: sposób zgłaszania usterek (telefonicznie, e-mailowo), czas, w którym twórca oprogramowania powinien zareagować na zgłoszenie, oraz czas, w którym powinien usterkę lub błąd usunąć.
Najczęściej ustala się odrębne czasy naprawy dla różnych kategorii błędów i usterek. Brak reakcji lub naprawy w wyznaczonym terminie pociąga za sobą zwykle konieczność zapłaty kar umownych.
Podobne postanowienia znajdują się w umowach serwisowych, z tym że opieka serwisowa jest płatna, np. w formie miesięcznego ryczałtu.
[b]Uwaga![/b] Niezależnie od powyższego strony w umowie powinny przewidzieć procedurę testową oprogramowania, zanim zostanie ono komercyjnie wykorzystane. Testy parokrotnie zakończone stwierdzeniem usterek lub błędów powinny skutkować możliwością odstąpienia przez zamawiającego od umowy.
[srodtytul]Harmonogram prac[/srodtytul]
Dość często umowa o dzieło będące oprogramowaniem komputerowym, w szczególności jeżeli jest dedykowana zamawiającemu, zakłada współdziałanie obu stron i pewien harmonogram, w którym poszczególne elementy oprogramowania komputerowego będą powstawać.
Z jednej strony powinien on być tak precyzyjny, jak to możliwe, bo pociąga za sobą odpowiedzialność stron za terminowe wykonywanie dzieła, z drugiej jednak skomplikowane programy tworzone są wspólnie przez zamawiającego i wykonawcę i mogą podlegać ewolucji w trakcie ich tworzenia (zmiana oczekiwać, wymagań, środowiska IT, zmiany w technologii itp.).
Stąd konieczność także pewnej elastyczności w podejściu do harmonogramu. Najczęściej tę elastyczność wprowadza się poprzez możliwość mniej sformalizowanego wprowadzania zmian do harmonogramu i zakresu prac nad oprogramowaniem.
Należy pamiętać, że większość sporów związanych z tworzeniem programów komputerowych wynika właśnie z niedotrzymania harmonogramu z przyczyn leżących po jednej lub drugiej stronie.
[srodtytul]Odpowiedzialność wykonawcy[/srodtytul]
Co do zasady wykonawca odpowiada za należytą staranność w wykonaniu dzieła. Umowa może rozszerzać jego odpowiedzialność np. na najwyższą staranność.
Nie ma przeszkód, aby strony szczegółowo odkreśliły także inne parametry odpowiedzialności, np. że dzieło zostanie wykonane zgodnie z obecnie obowiązującymi standardami technicznymi na świecie lub że osoby pracujące nad dziełem będą miały najwyższe kwalifikacje i nie będą zmieniać się w trakcie wykonywania projektu.
Zwykle wykonawcy dążą do ograniczenia swojej odpowiedzialności do pewnej kwoty, np. określonej procentowo wartości wynagrodzenia i tylko za szkody rzeczywiste (z wyłączeniem utraconych korzyści). Jest to pewien standard na rynku, lecz można próbować negocjować nieograniczoną odpowiedzialność, np. za wady prawne utworu, naruszenie danych osobowych itp.
[ramka][b]Roszczenia osób trzecich[/b]
Program komputerowy oprócz usterek fizycznych może również zawierać wady prawne. Oznacza to, że narusza prawa osób trzecich, np. wykonawca oprogramowania nie nabył praw autorskich od swoich podwykonawców, wykonawcy oprogramowania skorzystali z fragmentów oprogramowania należących do osób trzecich bez ich zgody itp.
W takim wypadku zamawiający program będzie korzystał z niego, naruszając prawa innego podmiotu, nawet jeżeli działa w dobrej wierze, nie wiedząc nic o naruszeniu. Brak winy po stronie przedsiębiorcy może mieć jedynie wpływ na obniżenie ewentualnego odszkodowania. Nie chroni jednak przed roszczeniami.
Co do zasady przyjmujący zamówienie odpowiada za wady prawne dzieła, dzięki czemu w razie ewentualnej konieczności zapłaty odszkodowania zamawiający program przedsiębiorca będzie mógł żądać od przyjmującego zamówienie – w ramach roszczenia regresowego – naprawienia szkody poniesionej wskutek istnienia wad prawnych dzieła.
Niemniej jednak, w celu zwiększenia bezpieczeństwa przedsiębiorcy, w umowie o napisanie programu komputerowego można zamieścić następujące postanowienia:
- oświadczenie twórcy, że stworzył dzieło samodzielnie lub nabył prawa do jego elementów od podwykonawców i że dzieło nie narusza praw osób trzecich (np. patentów);
- zobowiązanie twórcy, że w przypadku roszczeń osób trzecich skierowanych przeciwko zamawiającemu dołoży wszelkich starań, aby zapewnić zmawiającemu możliwość niezakłóconego korzystania z oprogramowania (dostarczenie oprogramowania bez wad, zawarcie ugody z pierwotnie uprawnionym), ale także udzielić wszelkiej pomocy w przygotowaniu strategii obrony przed roszczeniami i prowadzeniu postępowania;
- zobowiązanie twórcy do zwrotu wszelkich kwot zasądzonych lub które zamawiający zapłacił (np. w ugodzie), w tym także kosztów pomocy prawnej poniesionych przez zamawiającego.
W przypadku niedających się usunąć wad prawnych zamawiający powinien mieć prawo do odstąpienia od umowy i żądania zwrotu zapłaconego wynagrodzenia za program.[/ramka]
[i]Agnieszka Wiercińska-Krużewska jest adwokatem i partnerem w kancelarii WKB Wierciński, Kwieciński, Baehr
Aleksandra Politańska jest prawnikiem w tej kancelarii[/i]
[i][b]Czytaj także:[/b]
[link=http://www.rp.pl/artykul/596583.html]O czym pamiętać, spisując umowę licencyjną na oprogramowanie[/link][/i]