Czy licencjobiorca może odstąpić od umowy na oprogramowanie jeśli licencjodawca nie chce wprowadzić niezbędnych poprawek?

A teraz coś z nieco innej beczki: czy jest dopuszczalne odstąpienie od umowy licencyjnej ze względu na usterki oprogramowania — oraz czy licencjobiorca może żądać wprowadzenia do zamówionego i zaakceptowanego programu komputerowego niezbędnych z jego punktu widzenia poprawek? (wyrok SA w Warszawie z 3 czerwca 2016 r., sygn. akt I ACa 1198/15).

Spór dotyczył żądania dostosowania licencjonowanego programu komputerowego do potrzeb licencjobiorcy: po kilkunastu tygodniach testów (testy obejmowały pełen pakiet, tj. ze wszystkimi modułami) przedsiębiorca zamówił oprogramowanie wspierające zarządzanie przedsiębiorstwem, aby po zawarciu umowy licencyjnej zauważyć, że system nie obejmuje wszystkich niezbędnych funkcjonalności (np. brak obsługi kodów kreskowych, brak obsługi wielu cenników, etc.). Licencjodawca odmówił dostosowania oprogramowania do wymagań klienta, wskazując, iż zawarta umowa licencyjna nie była umową o dzieło, lecz dotyczyła udostępnienia konkretnego produktu.

Skoro zatem oprogramowanie nie spełniało wymagań, klient odstąpił od zawartej umowy oraz wniósł pozew o zwrot należności.

art. 55 ust. 1 ustawy o prawie autorskim i prawach pokrewnych
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.

Sąd prawomocnie oddalił roszczenia licencjobiorcy: strony zawarły umowę licencyjną na określony, gotowy produkt. Program nie był stworzony lub modyfikowany na zamówienie klienta, który mógł wyłącznie wybrać określone moduły spośród oferowanych przez licencjodawcę. Warunki umowy zostały sprecyzowane w ofercie, zaś powód — znając funkcjonalności oraz listę modułów — zaakceptował warunki umowy licencyjnej.
Oznacza to, iż między stronami nie doszło do zawarcia umowy o dzieło, albowiem system został już wcześniej przygotowany, zaś klienci mogli zdecydować się na jego zakup. Nie ma także dowodów, iżby pozwana zobowiązała się do wprowadzenia jakichkolwiek poprawek; ba, nawet świadek (informatyk pracujący dla powoda) powiedział, że nikt nie zapewniał, że program gwarantuje spełnienie wszystkich oczekiwań.

Licencjodawca nie ponosi odpowiedzialności za to, że program komputerowy nie spełnia oczekiwań klienta, nawet jeśli okoliczności te wyszły na jaw podczas wdrożenia oprogramowania. Powód testował software przez dłuższy czas, miał także możliwość zamówić usługę analizy wdrożeniowej — decyzja o samodzielnym sprawdzeniu funkcjonalności systemu czyni powoda wyłącznie odpowiedzialnym za porażkę.

Oznacza to, że utwór nie posiadał usterek, zatem licencjobiorca nie mógł skorzystać z uprawnienia do odstąpienia od umowy i żądać zwrotu opłaty licencyjnej (art. 55 ust. 1 pr.aut.) — program był zgodny z warunkami zamówienia oraz zaakceptowaną umową licencyjną, działał prawidłowo, funkcjonalności były zgodne z wersją testową — zaś pozwany nie zobowiązał się do wdrożenia jakichkolwiek zmian.

13 comments for “Czy licencjobiorca może odstąpić od umowy na oprogramowanie jeśli licencjodawca nie chce wprowadzić niezbędnych poprawek?

  1. b52t
    8 grudnia 2017 at 07:36

    Clickbait! ;-)
    Tytuł sugerował (mnie) coś więcej niż jest w treści omówki.

    • 8 grudnia 2017 at 09:19

      Odpowiedź na pytania zadawane w tytułach nie zawsze jest „tak” ;-)

      • b52t
        8 grudnia 2017 at 09:55

        Zakładałem bardziej złożony stan faktyczny, nie gotowe produkt a program pisany pod zamawiającego.

        • 8 grudnia 2017 at 10:14

          Na szczęście dla przeciętnego (nie ujmując nikomu) P.T. Czytelnika nawet oczywiste oczywistości mogą być nowością :)

          • b52t
            8 grudnia 2017 at 10:32

            To prawda (w całości).

    • Usher
      8 grudnia 2017 at 19:55

      Nie coś więcej, tylko coś innego…
      Poprawka w przypadku nieistniejącej funkcji oznacza, że producent deklarował jej istnienie bezpośrednio (np. w opisie na stronie www) lub pośrednio (np. zapewniając o pełnej zgodności ze standardem) bądź wynikało ono z budowy programu (np. w menu czy w opcjach konfiguracji znajdowały się pozycje wskazujące na istnienie funkcji – typowe dla wersji alfa/beta).
      W przypadku funkcji istniejącej w ograniczonym zakresie zaczynają się problemy, bo producent mógł deklarować taką funkcję ogólnikowo, więc klientowi nie przyszło do głowy, aby zadać od razu np. takie pytania:
      – Czy obsługa wielu cenników oznacza możliwość wyboru poziomu cen w ogóle czy też możliwość zdefiniowania odrębnych cenników dla różnych grup klientów?

      – Czy obsługa kodów kreskowych oznacza obsługę kodów innych niż EAN? Czy obejmuje również również obsługę kodów QR?
      Dalej – odpowiadając na takie pytania producent programu mógł deklarować możliwość rozbudowy istniejących modułów lub opracowania nowych modułów na życzenie klienta bez wyraźnego zaznaczenia oczywistego faktu, że to oznacza dodatkową opłatę (np. mówiąc „To da się zrobić”).

      Z omówienia wynika, że testy mogła przeprowadzać niewłaściwa osoba (szef nie zawsze zna wszelkie szczegóły) lub że już po zakupie licencji oprogramowania zmieniły się warunki pracy przedsiębiorcy (bo np. dział handlowy obiecał klientom elastyczne cenniki i zróżnicowane kody paskowe). W takich okolicznościach przedsiębiorca może wolał rżnąć głupa wobec producenta programu niż wyjść na głupca przed własnymi pracownikami czy klientami.

      • 9 grudnia 2017 at 08:52

        Testy przeprowadzał informatyk, który pozytywnie rekomendował zakup programu, a później zeznał w sposób, który sąd ocenił tak:

        z twierdzeń i zeznań tych wynikało jednoznacznie, że to powód nie sprawdził programu przed jego nabyciem w sposób rzetelny i prawidłowy, pomimo posiadania wersji testowej przez ponad trzy miesiące, a nieadekwatność programu do potrzeb powoda okazała się dopiero po jego nabyciu.

        • Usher
          9 grudnia 2017 at 13:37

          Stwierdzenie sądu „to powód nie sprawdził” jednak nie określa jednoznacznie, czy chodzi o przedsiębiorcę osobiście jako osobę fizyczną, czy o przedsiębiorstwo jako zbiorowość ludzi. W poprzednim komentarzu skupiłem się bardziej na pierwszej możliwości (szef widzi co chce i rozumie jak chce, a nie jak jest) i stwierdzeniu nieadekwatności po nabyciu, które mogło wynikać ze zmiany/sprecyzowania wymagań już po zakończeniu testów.

          Druga możliwość oznacza wskazanie na winę dowolnego pracownika, w tym informatyka (zwalającego błędną decyzję na szefa), albo bardziej ogólnie – brak komunikacji międzyludzkiej i niekompetencję informatyka (ladmina), który tę komunikację powinien wymusić.
          Sposób rzetelny i prawidłowy wymagałby uwzględnienia poniższych faktów:.
          Po pierwsze, informatyk powinien wiedzieć, że spece od marketingu lubią obiecywać niestworzone rzeczy, więc mógł się domagać od pracowników różnych działów listy wymagań na piśmie. Sam zapewne mógł też sporządzić własną listę na podstawie znanych mu problemów z działaniem dotychczasowego systemu.
          Po drugie, mając do dyspozycji aż 3 miesiące informatyk powinien tylko nadzorować testy, które przeprowadzić powinni potencjalni użytkownicy programu (pracownicy działu sprzedaży/marketingu, księgowość, szef itd.) lepiej znający potrzeby swoich działów niż informatyk.
          I tyle, bo można by tak ciągnąć w nieskończoność, dorzucać fakty jak @disqus_oIa8FsY15b:disqus, a w końcu i tak dojść do wniosków jak @PiotrK w komentarzu obok: https://czasopismo.legeartis.org/2017/12/odstapienie-umowy-usterki-oprogramowania.html#comment-3653061938

  2. mall
    8 grudnia 2017 at 11:24

    Akapit o braku dowodów wygląda jak opis niezrozumienia stron z rozmowy sprzed zakupu, która mogła wyglądać tak:
    licencjobiorca: czy możecie wprowadzić zmiany A, B i C do programu?
    licencjodawca: zobaczymy co da się zrobić.

    Jedna strona nic nie potwierdziła nie chcąc zrażać klienta, a druga strona optymistycznie uznała, że da się zrobić.

    • 8 grudnia 2017 at 12:05

      Nawet jeśli taka była gadka, to z uzasadnienia wynika, że treść zamówienia była jasna — produkt jest z półki, testy obejmowały wszystkie możliwe moduły.

  3. Mariusz H
    8 grudnia 2017 at 15:57

    Sprawa wydaje się prosta tylko na pierwszy rzut oka. W rzeczywistości często wygląda to tak, że przedstawia się produkt, który spełnia „wszystkie funkcje” potrzebne do czegośtam. Pokazuje się demo i często odbiorca nie ma możliwości przetestowania wszystkich funkcji, bo do tego program musiałby być chociaż wstępnie wdrożony. Jednak podpisuje umowę, a po wdrożeniu słyszy, że to nie będzie działać, tego się nie da, itp. Okazuje się, że odczyt kodów kreskowych to „dodatkowa funkcjonalność”, a nie coś, co jest i powinno być standardem. Potem są problemy, bo w magazynie każdy produkt trzeba wklepywać ręcznie, co kilkukrotnie przedłuża czas pracy nawet bez tego programu. I, jak widać, odbiorca nie ma żadnych sposobów na uzyskanie programu, który potrzebuje tylko dostaje program który „odpowiada wszystkim” czyli tak naprawdę nikomu, bo nie spotkałem jeszcze oprogramowania, które w 100% zapewnia wszystkie funkcjonalności w każdej firmie, bo nie jest to technicznie możliwe. Dlatego jest proces wdrożenia, który pozwala na dostosowanie programu do potrzeb – kody kreskowe, inne drukarki, inny rodzaj wydruków, inna komunikacja z magazynami, inne statystyki, itp. Pytanie na ile te pierwsze testy były robione rzetelnie (często jest to – panie Maćku, ma pan tu program, proszę sprawdzić czy działa) i czy rzeczywiście wyszły wtedy inne potrzeby, bo jeśli tak to nie powinni podpisywać umowy bez zaznaczenia dostosowania programu. Howk.

    • PiotrK
      8 grudnia 2017 at 19:59

      Kluczowe jest ostatnie zdanie pierwszego akapitu, który napisałeś.

      Przeważnie gdy klient ma coś po swojej stronie zweryfikować, to robi cokolwiek (niewiele). Następnie odbiera, podpisuje, kwituje. A potem przychodzi życie i się zaczynają, pretensje, żale i pozwy. Bo łatwiejsza dla wielu jest prokrastynacja i działanie przez gaszenie pożarów niż faktyczne współdziałanie.

      • Mike
        9 grudnia 2017 at 14:42

        Inna sprawa, że danie programu do testów Pani Zosi, która ma górę swoich obowiązków nie jest najlepszą metodą sprawdzania funkcjonalności. A tak często bywa…- Pani odpali ten program w wolnej chwili…

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.