Odpowiedzialność za wady systemu | cz.1

prawo-autorskie-blog.pl 6 lat temu

The Ancients | Jakub Różalski

Dość duża część mojej praktyki zawodowej opiera się na obsłudze przedsiębiorców z branży IT.

Tym samym, jako osoba zajmująca się obsługą wykonawców w branży IT dość często spotykam się z kwestią odpowiedzialności za wady programów komputerowych, rzekome albo rzeczywiste. Sytuacje są różne, ale w dużym uproszczeniu można je sprowadzić do dwóch schematów: albo jest to faktyczny problem zgłoszony przez zamawiającego, albo jest to tzw. miękka metoda negocjacji warunków zamówienia (czyli pokazujemy problem ale z drugiej strony negocjujemy np. nowe warunki zamówienia). Tak czy owak, temat niezwykle ciekawy, i mam nadzieję, iż wiedza przekazana na moim blogu pomoże Ci kiedyś w kryzysowej sytuacji.

W dzisiejszym wpisie, przedstawię Ci jak wygląda kwestia odpowiedzialności wykonawcy na gruncie ustawy o prawie autorskim i prawach pokrewnych.

Odpowiedzialność za wady systemu a prawo autorskie.

Punktem wyjścia jest analiza przepisu art. 55 PrAut, którego ustęp 1 brzmi następująco:

Jeżeli zamówiony utwór ma usterki, zamawiający może wyznaczyć twórcy odpowiedni termin do ich usunięcia, a po jego bezskutecznym upływie może od umowy odstąpić lub żądać odpowiedniego obniżenia umówionego wynagrodzenia, chyba iż usterki są wynikiem okoliczności, za które twórca nie ponosi odpowiedzialności. Twórca zachowuje w każdym razie prawo do otrzymanej części wynagrodzenia, nie wyższej niż 25% wynagrodzenia umownego.

W ustępie 1 jest mowa o zamówionym utworze. Tutaj pojawiają się schody, otóż nigdzie w ustawie nie znajdziemy definicji zamówionego utworu. Pytanie więc czy przepis ten stosujemy do:

utworów przyszłych i zamówionych, czy może też / lub do
utworów już istniejących ?

Ratio legis tego przepisu wskazuje, iż raczej mowa w tym przypadku o opcji a) czyli oprogramowaniu które dopiero ma powstać. Jest to poniekąd logiczne biorąc pod uwagę fakt iż tworzymy coś pod klienta, na jego potrzeby, zamówienie zaś jest poprzedzone audytem potrzeb klienta i stosowną analizą. Nie chodzi więc o masowe rozwiązanie boxowe. Do kategorii utworów przyszłych zaliczamy także modyfikacje już istniejących programów komputerowych, które na zamówienie są następnie modyfikowane bądź tworzy się moduły dodatkowe do już istniejącego produktu ? tego typu sytuacja jest częsta we wdrożeniach CRM, np. SugarCRM.

Od razu jednak trzeba wyjaśnić iż ta kwestia tj do jakich utworów (przyszłych czy istniejących) ma zastosowanie przepis art. 55 ust.1 PrAut jest sporna. Możesz znaleźć głosy za 1 i 2 opcją. Cóż, życie. Każdy przypadek należy rozpatrywać osobno, gdyż zdarza się iż per analogia stosujemy do utworów już istniejących przepis art. 55. Ust. 1 PrAut.

Kolejną kwestią przy analizie tego przepisu a tym samym przy ustaleniu podmiotu ponoszącego odpowiedzialność za wady systemu jest fakt, iż musimy zwrócić uwagę na problemy związane z definicją twórcy w rozumieniu ww. przepisu. Jest to dość istotne jeżeli spojrzymy na kwestie związane z ustaleniem podmiotu ponoszącego odpowiedzialność za wady oprogramowania. Oczywiście mowa tu o projektach dość złożonych, nie o prostym zamówieniu gdzie za powstanie systemu odpowiada 1 osoba.

Na czym polega problem? Twórcą może być:

zarówno osoba faktycznie tworząca software,
pracodawca,
licencjobiorca który następnie dostosowuje lub dodaje coś do licencjonowanego produktu,
lub też w końcu może być to pochodny nabywca oprogramowania.

Analizując natomiast zapisy ustawy o prawie autorskim, to twórcą sensu stricte może być oczywiście jedynie osoba lub osoby fizyczne. Siłą rzeczy tego statusu nie posiadają osoby prawne, choćby jeżeli to one finansują lub organizują cały proces tworzenia oprogramowania.

Rynek jednak i rzeczywistość branży IT wygląda w ten sposób, iż zamawiający z reguły zawierają jednak umowy z osobami prawnymi, a więc większymi podmiotami które mają odpowiednie zaplecze finansowe, kadrowe i technologiczne by sprostać zamówieniu.

Ja szczerze mówiąc, nie widzę innej możliwości niż takiej by za twórcę w rozumieniu tego przepisu uznać również do umów zawartych z podmiotem praw autorskich a nie tylko z rzeczywistym fizycznym twórcą.

Z punktu widzenia praktyki i wykładni pojęcia twórcy w rozumieniu art. 55 ust. 1. PrAut możemy rozróżnić dwie najczęściej występujące sytuacje:

do zawarcia umowy dochodzi z pracodawcą twórcy/twórców
do zawarcia umowy dochodzi z podmiotem współpracującym z twórcami na innych zasadach niż w oparciu o umowy o pracę.

Wykonanie systemu w ramach stosunku pracy

Tutaj sytuacja jest bardziej klarowna. A więc mowa o najczęstszej sytuacji kiedy zamawiający zawiera umowę o stworzenie systemu z np. osobą prawną.

Zgodnie z art. 74 ust. 3 pr aut autorskie prawa majątkowe do programu komputerowego nabywa pracodawca twórcy, jeżeli do powstania programu doszło w związku z wykonywaniem obowiązków ze stosunku pracy. Nabycie jest tutaj automatyczne w tym znaczeniu, iż nie jest wymagana żadna aktywność pracodawcy, złożenie oświadczenia czy cokolwiek innego.

Z praktycznego punktu widzenia zwrócić należy uwagę na fakt, iż bardzo dużą wagę należy przyłożyć do precyzyjnego określenia zakresu obowiązków wynikających ze stosunku pracy. Musi z niego wynikać obowiązek tworzenia oprogramowania. Te kwestie wykładane są bowiem w sporach sądowych bardzo wąsko, tym samym próby udowodnienia iż mimo braku stosownych wpisów w umowie o prace albo innych dokumentach związanych ze stosunkiem pracy, iż dany pracownik jednak tworzył też software jest skazane na niepowodzenie. Sam biorę udział w takim procesie, gdzie powód miał dwojakiego rodzaju relację ze swoim pracodawcą, strony zawarły bowiem umowę o pracę ale także pracownik wykonywał na rzecz pracodawcy inne czynności w ramach prowadzonej działalności gospodarczej. Ostatecznie stronie pozwanej nie udało się wykazać, iż nabyła autorskie prawa majątkowe do wytworzonego oprogramowania.

Powyższe plus fakt, iż autorskie prawo osobiste do integralności utworu w przypadku programów komputerowych zostało przekształcone w autorskie prawo majątkowe (na co wskazuje art. 74 ust. 4 pkt 2 PrAut), powoduje, ze pracodawca jest uprawniony do usuwania usterek programu komputerowego bez konieczności uzyskiwania zgody twórcy a więc swojego pracownika.

Wykonanie systemu w ramach innych stosunków prawnych

Inaczej sytuacja wygląda gdy faktycznym twórcą lub twórcami systemu są osoby wykonujące pracę dla wykonawcy, ale nie na podstawie stosunku pracy ale na innej podstawie. W kontekście sytuacji na rynku pracy w branży IT, są to sytuacje raczej rzadsze niż częstsze, niemniej jednak występują one w rzeczywistości.

Tutaj sytuacja wykonawcy się komplikuje. Tym samym wykonawca powinien pamiętać o następujących kwestiach:

należy zwrócić uwagę na zakres nabywanych praw majątkowych. Otóż w dobrze pojętym interesie wykonawcy jest by w umowie ze swoimi współpracownikami nabył prawa majątkowe w całym zakresie art. 74 ust. 4 pkt 1-3. Wynika to z faktu, iż dokonywanie zmian w oprogramowaniu jest związane z jego zwielokrotnianiem, a o tym często się zapomina,
po drugie, w sytuacji kiedy zmiany w oprogramowaniu mają charakter twórczy to pojawia się problem z tzw. opracowaniem utworu, a w tym zakresie rozporządzanie i korzystanie z takiego utworu zależnego wymaga już zgody twórcy systemu pierwotnego. Tym samym wykonawca w umowie ze swoim współpracownikiem powinien dążyć do jak najszerszego nabycia w jak najszerszym zakresie zezwolenia od twórcy na wykonywanie prawa zależnego. Tego problemu nie ma w sytuacji gdy zmiany w oprogramowaniu nie mają charakteru twórczego.

W następnym wpisie będę kontynuował ten wątek, jak widzisz temat jest bardzo obszerny, a ledwie rozpoczęliśmy

Więcej o IT na blogu możesz poczytać w poniższych linkach: