statystyki

Zakup oprogramowania dla administracji. Zadanie z przeszkodami, ale do wykonania

autor: Marcin Maruta, Bartłomiej Wachta, Dr Jakub Krysa15.01.2020, 09:57; Aktualizacja: 15.01.2020, 10:02
Zamawiający, który chce nabyć oprogramowanie licencjonowane w jakimś konkretnym modelu, na początek będzie musiał odpowiedzieć sobie na pytanie, czy powinien ten model opisać i wskazać tym samym pośrednio na to, jaki produkt chce kupi

Zamawiający, który chce nabyć oprogramowanie licencjonowane w jakimś konkretnym modelu, na początek będzie musiał odpowiedzieć sobie na pytanie, czy powinien ten model opisać i wskazać tym samym pośrednio na to, jaki produkt chce kupiźródło: ShutterStock

Prawo zamówień publicznych nie jest instrumentem idealnym dla kupowania rozwiązań informatycznych, a zamawiający w zderzeniu z producentami oprogramowania stoją na zdecydowanie słabszej pozycji. Odpowiednio przygotowana dokumentacja przetargowa może jednak pomóc zabezpieczyć ich interesy oraz zwiększyć efektywność zamówienia.

Jedną z fundamentalnych zasad systemu zamówień publicznych jest konkurencyjność, która jest wyrażona w szczególności w przepisach dotyczących opisywania przedmiotu zamówienia. A ponieważ wykluczają one preferowanie w specyfikacji istotnych warunków zamówienia (SIWZ) konkretnego produktu, powstaje trudne pytanie, w jaki sposób jednostka samorządu terytorialnego lub administracji, która chce kupić nowe oprogramowanie albo dokonać upgrade’u (czyli ulepszenia) już posiadanego rozwiązania, np. Oracle, SAP czy Microsoft, ma opisać przedmiot zamówienia. Przy czym celowo posługujemy się konkretnymi nazwami producentów, ponieważ zamawiający właśnie z takim wyzwaniem się mierzą: jak ma np. kupić upgrade Oracle’a, a nie rozszerzenia abstrakcyjnego rozwiązania informatycznego. Oczywiście zawsze można powiedzieć, że zgodnie z zasadą konkurencyjności należy pomyśleć, czy przypadkiem zamiast rozwijać istniejące rozwiązanie, nie lepiej byłoby kupić nowe. Tu jednak zasada konkurencyjności spotyka się często z zasadą efektywności ekonomicznej, bowiem wdrożenie – zwłaszcza dużego i skomplikowanego rozwiązania informatycznego w organizacji – jest zawsze sporym wyzwaniem i wiąże się z poważnymi kosztami zarówno czysto finansowymi, jak i organizacyjnymi. Trwa też zazwyczaj od kilku miesięcy do nawet kilku lat i na pewno nie jest procesem, który odpowiedzialna jednostka chciałaby powtarzać co cztery lata. Stąd chęć nabycia konkretnego rozwiązania może więc być w pełni uzasadniona.

Jak wiadomo, producenci stosują różne modele licencjonowania swoich produktów. Z kolei zamawiający, który chce nabyć oprogramowanie licencjonowane w jakimś konkretnym modelu, na początek będzie musiał odpowiedzieć sobie na pytanie, czy powinien ten model opisać i wskazać tym samym pośrednio na to, jaki produkt chce kupić. Kolejne wyzwanie dotyczy tego, że zamawiający powinni dążyć do jak najszerszego zabezpieczenia swoich interesów w kontekście przyszłych zakupów i ich otwarcia na konkurencję. Wskazane jest więc takie zdefiniowanie zakresu swoich uprawnień, by dalsze funkcjonowanie danego oprogramowania bez przeszkód prawnych mogło być zapewnione przez dowolny podmiot, a nie tylko przez tego dostawcę, który go dostarczył.

(Nie)równość stron

Zamówienia publiczne w sektorze IT obejmują często prace nad rozbudową i modyfikacją systemów informatycznych oraz usługi, oprogramowanie lub sprzęt niezbędny do utrzymywania infrastruktury informatycznej. Zamawiający może wybrać między dedykowanymi systemami informatycznymi (zbudowanymi na wyłączne zamówienie oraz cechującymi się unikatowością rozwiązań technicznych, sposobem i zasadami działania) a systemami standardowymi, zapewniającymi jednocześnie szerokie możliwości konfiguracji i dostosowania do potrzeb zamawiającego, np. systemy klasy ERP). Przy czym w obu przypadkach, aby móc korzystać, utrzymywać lub rozwijać swój system informatyczny, musi zapewnić sobie do niego prawa. Najczęściej dzieje się to na dwa sposoby:

  • przez umowne przeniesienie autorskich praw majątkowych do kupowanego oprogramowania,
  • udzielenie przez producenta licencji obejmującej określony zakres uprawnień (zwanych polami eksploatacji).

Istotą tych umów jest – w pierwszym przypadku – wyzbycie się praw po stronie twórcy, w tym drugim – wyłącznie upoważnienie danego podmiotu do korzystania z utworu, bez naruszenia praw twórców. Nie jest przy tym prawdą, że tylko przeniesienie autorskich praw majątkowych najlepiej zabezpiecza interesy zamawiającego (np. chroniąc go przed uzależnieniem od dostawcy, tzw. vendor lock-in). Oczywiście w przypadku sprzedaży praw z reguły umowa obejmuje wszystkie pola eksploatacji, a licencje często są ograniczone do zwielokrotnienia kodu źródłowego. To jednak tylko praktyka rynku. Jeżeli celem jednostki jest zapewnienie sobie praw do modyfikacji i swobodnego rozwoju oprogramowania, odpowiednio ukształtowana licencja jest wystarczająca i z reguły znacznie tańsza od przeniesienia praw. Nabycie praw autorskich ma natomiast większy sens przy kluczowych, dedykowanych systemach informatycznych. Jest ono również dość powszechne w umowach z pracownikami czy zleceniobiorcami przy opracowywaniu własnych produktów. Zdarza się także przy tworzeniu dedykowanych dla danego zamawiającego rozszerzeń rozwiązań standardowych

Skupmy się jednak na przypadkach najbardziej typowych, czyli takich, w których zamawiający kupuje gotowy, standardowy produkt. W takich transakcjach najczęściej stosowanym przez producentów rozwiązaniem jest odpowiednio ukształtowany model licencyjny. Jego podstawą jest ramowe porozumienie z producentem określające zasady korzystania z oprogramowania (ELA, EA, OLA, EULA, IPLA itp.). Zasady te w przypadku największych, globalnych firmy z branży IT są z reguły uniwersalne dla wszystkich klientów, niezależnie od państwa, w którym nabywają oni licencje. Mogą się one jednak różnić, np. w zależności od tego, czy klientem jest podmiot korporacyjny czy indywidualny oraz czy jest to klient publiczny (administracyjny lub samorządowy) czy prywatny. W sprzedaży oprogramowania najczęściej pośredniczą lokalni dostawcy powiązani z producentem umowami współpracy lub partnerstwa. Tu także mogą pojawić się różnice w oferowanych warunkach licencyjnych. Producenci oprogramowania proponują bowiem swym kontrahentom różne poziomy partnerstwa, które przekładają się następnie np. na odmienne zakresy uprawnień licencyjnych, ceny oraz modele rozliczeń uwzględniające ewentualne upusty lub świadczenia dodatkowe dla klienta (np. dodatkowe funkcjonalności). Z reguły umowy typu ELA, EA, OLA, EULA, IPLA itp. zawierane są bezpośrednio z producentem oprogramowania, a nie z jego pośrednikiem (np. na zasadzie sublicencji). Mają one przy tym charakter ramowy i często są zawierane niezależnie od zamówienia na licencje i właściwej umowy licencyjnej. [ramka]

Elementy, jakie powinny się znaleźć umowie z producentem

  • z asady i ograniczenia dotyczące korzystania z oprogramowania
  • warunki audytów licencyjnych
  • kwestie z zakresu przetwarzania danych
  • ewentualne sankcje za niedotrzymanie warunków licencji
  • kwestie związane z odpłatnością (rzadko) – mogą się one jednak pojawić w przypadku przekroczenia umówionej liczby wykorzystywanych licencji albo obowiązku zapłaty kar umownych za naruszenie warunków licencji.


Pozostało 65% tekstu

Prenumerata wydania cyfrowego

Dziennika Gazety Prawnej
9,80 zł
cena za dwa dostępy
na pierwszy miesiąc,
kolejny miesiąc tylko 79 zł
Oferta autoodnawialna
KUPUJĘ

Pojedyncze wydanie cyfrowe

Dziennika Gazety Prawnej
4,92 zł
Płać:
KUPUJĘ
Materiał chroniony prawem autorskim - wszelkie prawa zastrzeżone. Dalsze rozpowszechnianie artykułu tylko za zgodą wydawcy INFOR Biznes. Kup licencję

Polecane

Reklama

Twój komentarz

Zanim dodasz komentarz - zapoznaj się z zasadami komentowania artykułów.

Widzisz naruszenie regulaminu? Zgłoś je!

Redakcja poleca

Galerie

Wyszukiwarka kancelarii

Szukaj

Polecane