Odpowiedzialność za wady oprogramowania | cz.1

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ę, że 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.

The Ancients | Jakub Różalski

Odpowiedzialność za wady oprogramowania 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 że 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:

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

Ratio legis tego przepisu wskazuje, że 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 że 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ć że 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ę że 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 oprogramowania jest fakt, że musimy zwrócić uwagę na problemy związane z definicją twórcy w rozumieniu ww. przepisu.

Jest to dość istotne jeśli 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 oprogramowania 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, nawet jeśli to one finansują lub organizują cały proces tworzenia oprogramowania.

Rynek jednak i rzeczywistość branży IT wygląda w ten sposób, że 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 oprogramowania w ramach stosunku pracy

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

Zgodnie z art. 74 ust. 3 pr aut autorskie prawa majątkowe do programu komputerowego nabywa pracodawca twórcy, jeśli do powstania programu doszło w związku z wykonywaniem obowiązków ze stosunku pracy. Nabycie jest tutaj automatyczne w tym znaczeniu, że 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, że 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 że mimo braku stosownych wpisów w umowie o prace albo innych dokumentach związanych ze stosunkiem pracy, że 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ć, że nabyła autorskie prawa majątkowe do wytworzonego oprogramowania.

Powyższe plus fakt, że 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 oprogramowania w ramach innych stosunków prawnych 

Inaczej sytuacja wygląda gdy faktycznym twórcą lub twórcami oprogramowania są osoby wykonujące pracę dla wykonawcy, ale nie na podstawie stosunku pracy lecz 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:

1. 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, że dokonywanie zmian w oprogramowaniu jest związane z jego zwielokrotnianiem, a o tym często się zapomina,
2. 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 oprogramowania 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:

• umowy o stworzenie oprogramowania
• elementy oprogramowania
• SaaS a prawa autorskie
• Fixed Price a Time & Material
• Specyfikacja wymagań użytkownika.

Tak jak zauważyłeś dzisiejszy wpis firmuje świetny obraz Jakuba Różalskiego pt The ancients pochodzący ze strony Jakuba.

Robert Ratajczak
adwokat

***

Licencja GNU GPL ? o czym musisz pamiętać korzystając z oprogramowania open source

GNU General Public License jest licencją o największym znaczeniu dla licencji typu open source, jest też najczęściej stosowaną licencją stosowaną ws programów komputerowych.

Nie jest tajemnicą, że większość z nas korzysta z oprogramowania typu open source, tym samym z pewnością prędzej niż później będziesz miał do czynienia z licencją GNU GPL.

Dlatego chciałbym byś wiedział z czym masz do czynienia, co wolno a czego nie [Czytaj dalej…]

Podobne artykuły

• Sapkowski v CD PROJEKT mamy porozumienie
• Forma pisemna umów autorskich
• SaaS a prawa autorskie
• NFZ a prawa autorskie
• Umowa przenosząca autorskie prawo majątkowe a umowa licencyjna cz.2