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
- zasady 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.
Globalny oraz wystandaryzowany charakter umów typu ELA, EA, OLA, EULA, IPLA itp. powoduje, że zamawiający w praktyce nie mają możliwości negocjowania ich treści. Często pozostaje im jedynie zaakceptowanie (lub nie) treści takiej umowy w kształcie zaproponowanym przez producenta. Jest to o tyle problematyczne, że niejednokrotnie w grę wchodzi podstawowe oprogramowanie, które jest kluczowe z punktu widzenia funkcjonowania zamawiającego (trudno bowiem wyobrazić dzisiaj sobie istnienie urzędu bez odpowiedniej infrastruktury IT, np. bez systemu operacyjnego lub oprogramowania biurowego).
Jedynie nieliczni zamawiający, ze względu na ogromną skalę albo niestandardowy rodzaj zamówienia (np. oprogramowanie służące do celów wojskowych), mogą sobie pozwolić na indywidualne podejście ze strony producentów i negocjowanie warunków umowy licencyjnej (np. w zakresie przenoszalności licencji, sublicencjonowania, kar umownych czy audytów licencyjnych). Jest to zjawisko o tyle warte zauważenia, że zamawiający publiczni przyzwyczajeni są do tego, że proponowane przez nich w SIWZ warunki umów mają charakter nienegocjowalny. To zamawiający „dyktuje warunki”, a wykonawca może się na nie zgodzić lub nie musi składać oferty, ewentualnie może zadać zamawiającemu pytania we właściwym trybie albo – w przypadku skrajnych nadużyć pozycji zamawiającego – wnieść odwołanie od treści SIWZ. Nierówność stron, gorsza pozycja wykonawcy i rola zamawiającego jako strażnika interesu publicznego były przedmiotem szeregu wypowiedzi doktryny oraz wyroków Krajowej Izby Odwoławczej, a każdy przypadek musi być oceniany odrębnie, jednak generalnie można stwierdzić, że o ile zamawiający przestrzega elementarnych zasad, o tyle adhezyjny charakter umów o zamówienia publiczne (umowa, którą należy w całości przyjąć lub odrzucić, niepodlegająca negocjacjom – red.) jest powszechnie akceptowany. Wykonawca musi zaakceptować fakt, że to zamawiający jest dysponentem postępowania i powinien dbać nie tylko o swój interes, lecz także o dobro publiczne, więc warunki umowy mogą być narzucone przez zamawiającego.
!Co do zasady duzi międzynarodowi producenci oprogramowania nie dostosowują swoich standardowych warunków licencyjnych do zamawiającego publicznego.
Nierówność stron występuje również przy umowach licencyjnych, lecz w drugą stronę. To zamawiający musi zdać sobie sprawę z tego, że żaden duży, międzynarodowy producent oprogramowania w 99 proc. przypadków nie będzie nawet podejmował próby dostosowania swoich standardowych warunków licencyjnych do wymagań nawet największego zamawiającego publicznego. Owszem zdarzają się wyjątki oraz sytuacje, w których producenci wyciągają wnioski z pewnych zjawisk i dostosowują swoje modele do realiów rynkowych (tego rodzaju działania miały miejsce np. w Wielkiej Brytanii przy kształtowaniu się modelu G-Cloud), jednak regułą będzie całkowita odporność producentów oprogramowania na wszelkie wymagania zamawiającego. Tym razem to zamawiający muszą więc stanąć przed prostym wyborem – kupić to, co jest dostępne, czy nie kupować.
Trudna konstrukcja
Z reguły przedmiotem zamówienia nie jest samo udzielenie licencji, lecz jej „zapewnienie” albo „zapewnienie udzielenia”, czyli swego rodzaju usługa pośrednictwa zbliżona do umowy agencyjnej. Polega ona na tym, że wykonawca, który wygrywa przetarg, umożliwia zawarcie umowy licencyjnej między licencjobiorcą (zamawiającym, np. JST) a licencjodawcą (najczęściej producentem oprogramowania). Taka konstrukcja wynika z tego, że z reguły producenci oprogramowania (w szczególności ci najwięksi) nie oferują swoich produktów bezpośrednio na rynku. Zamiast tego korzystają z lokalnych kanałów dystrybucji, czyli wspomnianych wcześniej partnerów i współpracowników. To oni mają status wykonawcy umowy o zamówienie publiczne. Przedmiotem tej umowy jest natomiast wyłącznie usługa polegająca na doprowadzeniu do zawarcia umowy licencyjnej (np. przez przekazanie kluczy licencyjnych do oprogramowania).
Do zawarcia właściwej umowy licencyjnej (oraz umów typu ELA, EA, OLA, EULA, IPLA itp.) między zamawiającym a producentem z reguły dochodzi dopiero później. Często zdarza się również, że umowy te zawierane są oddzielnie – w oderwaniu od zamówienia na konkretne licencje lub pakiety oprogramowania. [schemat]
Model zawierania umów licencyjnych
Na marginesie zwracamy również uwagę, że możliwy jest także scenariusz, w którym zamawiający zawiera umowę o zamówienie publiczne bezpośrednio z producentem. Jest to jednak model stosunkowo rzadki. Zdarza się głównie w przypadku większych przetargów z udziałem polskich producentów albo przy specjalistycznym oprogramowaniu. W takim wypadku z reguły razem z produktem jest zawierana umowa regulująca zasady korzystania z niego.
Model licencyjny zakładający udział partnerów lub dystrybutorów (z którymi zamawiający zawiera umowę o zamówienie publiczne) niesie za sobą wiele konsekwencji dla zamawiających. Pierwszą jest to, że umowy licencyjne oraz umowy ELA, EA, OLA, EULA, IPLA itp., które zamawiający podpisują z producentami oprogramowania, pozostają de facto wyjęte z systemu zamówień publicznych. Trudno bowiem uznać je za umowy w sprawie zamówienia publicznego. Takimi, zgodnie z art. 2 pkt 13 ustawy z 29 stycznia 2004 r. – Prawo zamówień publicznych (tj. Dz.U. z 2019 r. poz. 1843), mogą bowiem być tylko umowy odpłatne zawierane między zamawiającym a wykonawcą, których przedmiotem są usługi, dostawy lub roboty budowlane. O ile nie powinno budzić wątpliwości, że w przypadku licencji mamy do czynienia z umowami (nawet, jeśli mają one postać wzorca umownego akceptowanego jednostronnie przez zamawiającego), których przedmiotem są dostawy (częściej) lub usługi (rzadziej), o tyle trudno dopatrzyć się w nich elementu odpłatności, a w producencie oprogramowania – wykonawcy wyłonionego w postępowaniu o udzielenie zamówienia publicznego.
Nieodpłatny charakter umów typu ELA, EA, OLA, EULA, IPLA itp. wynika z tego, że zamawiający z reguły płaci za nabywane licencje nie producentowi oprogramowania będącego stroną takiego kontraktu, lecz jego dystrybutorowi, z którym łączy go umowa o zamówienie publiczne. To, czy i na jakich zasadach wynagrodzenie to trafi następnie do producenta, zależy wyłącznie od umowy łączącej producenta z jego lokalnym dystrybutorem. Na podstawie umowy z dystrybutorem (de facto zamówienie wykonawcze) jednostka zamawia konkretne licencje. Z kolei zawierając umowy typu ELA, EA, OLA, EULA, IPLA itp. poza p.z.p., określa swoją sytuację prawną, a potem na jej podstawie tylko domawia produkty, które musi używać zgodnie z określonymi w nich warunkami licencyjnymi. Tym samym choć zamawiający uzyskuje przysporzenie gospodarcze w postaci możliwości korzystania z oprogramowania, to nie jest zobowiązany do świadczenia wzajemnego (czyli bezpośredniej zapłaty) na rzecz producenta (schemat). W świetle orzecznictwa TSUE (sprawa C-451/08, pkt 48) wyklucza to zatem możliwość uznania takiej umowy za zamówienie publiczne.
Drugim, oprócz braku odpłatności, argumentem przemawiającym za tym, że umowy typu ELA, EA, OLA, EULA, IPLA itp. nie są umowami o zamówienie publiczne, jest to, że nie są one zawierane z wykonawcami ani nawet z podwykonawcami zamówienia publicznego. Praktyka rynkowa pokazuje bowiem, że producenci oprogramowania standardowego, do którego nabywane są licencje (w szczególności największe firmy zagraniczne), nie są zainteresowani bezpośrednim udziałem w polskich przetargach. Wynika to po części z uwarunkowań formalnoprawnych polskiego systemu zamówień publicznych (raczej trudno sobie wyobrazić, by np. członkowie zarządów największych spółek z doliny krzemowej byli skłonni do przedstawiania swoich zaświadczeń o niekaralności albo zaświadczeń o niezaleganiu ich firm w płatności podatków i składek na ubezpieczenia społeczne). Jednocześnie taki stan rzeczy jest konsekwencją modeli biznesowych przyjętych przez zagraniczne firmy informatyczne, zakładających komercjalizację ich produktów za pośrednictwem lokalnych dystrybutorów. W tym kontekście nasuwa się jednak pytanie, czy producenci oprogramowania nie powinni być jednak wskazywani jako podwykonawcy w ofertach swoich dystrybutorów (z czym może się wiązać np. obowiązek złożenia przez te podmioty formularza jednolitego europejskiego dokumentu zamówienia)? Wydaje się jednak, że na tak postawione pytanie należy udzielić odpowiedzi przeczącej. W przypadku dostawy oprogramowania standardowego, któremu nie towarzyszą żadne dedykowane świadczenia dodatkowe (np. usługi serwisowe albo rozszerzenia), mamy bowiem do czynienia z gotowym produktem, który może być przedmiotem obrotu na rynku bez udziału producenta. Mało tego, nie można wykluczyć, że przedmiotem oferty będzie oprogramowanie używane (used software). Handlowanie takim oprogramowaniem zostało dopuszczone przez TSUE jedynie pod pewnymi warunkami (sprawy C-128/11 i C-166/15). Z kolei wyłączenie możliwości oferowania używanego oprogramowania w postępowaniu o udzielenie zamówienia publicznego zostało uznane za nieuzasadnione ograniczenie konkurencji i tym samym sprzeczne z krajowym i europejskim prawem zamówień publicznych (patrz: wyrok z 1 marca 2016 r. niemieckiego sądu zamówień publicznych w Münster (sygn. VK 1-2/16). Należy zatem sądzić, że w przypadku zamówienia na licencje oprogramowania standardowego jego producent z reguły nie będzie podwykonawcą w rozumieniu art. 2 pkt 9b p.z.p. Ciężko też w takiej konstrukcji dopatrywać się obejścia prawa polegającego np. na tym, że zamawiający zapłatę za licencję przekazuje podmiotowi innemu niż ten, który tej licencji udziela. Obejście musi mieć charakter intencjonalny i służyć osiągnięciu celu sprzecznego z prawem za pomocą konstrukcji poprawnej formalnie. W omawianym przypadku zamawiający, zawierając umowę bezpośrednio z producentem, nie działają w celu obejścia prawa zamówień. Przeciwnie, zawarcie takiej umowy jest konsekwencją przeprowadzonego konkurencyjnego postępowania, a zapłata bezpośrednio na rzecz producenta jest konsekwencją całkowicie niezależnego od zamawiającego modelu dystrybucyjnego.
Stwierdzenie, że umowa licencyjna zawarta przez zamawiającego z producentem oprogramowania w większości przypadków nie będzie umową o zamówienie publiczne w rozumieniu p.z.p., ma znaczenie nie tylko teoretyczne. Z praktycznego punktu widzenia oznacza to, że umowa:
- nie wymaga formy pisemnej pod rygorem nieważności (lub formy elektronicznej z kwalifikowanym podpisem elektronicznym);
- może być właściwie w dowolny sposób zmieniania (nie muszą zostać spełnione przesłanki zmiany umowy wymienione w art. 144 p.z.p.), o ile zmiana nie doprowadzi do zaistnienia takiego zdarzenia gospodarczego, które samodzielnie powinno być potraktowane jako zamówienie publiczne;
- nie mają do niej zastosowania regulacje p.z.p. dotyczące czasu, na jaki może zostać zawarta oraz zasady jej wypowiadania, odstąpienia i rozwiązania;
- może podlegać obcemu prawu.
Nie zawsze kot w worku
Zamawiający kupujący standardowe oprogramowanie komputerowe w praktyce są więc skazani na warunki licencyjne producenta. W zdecydowanej większości przypadków nie mają oni żadnego wpływu na treść takich warunków – w szczególności, jeśli po drugiej stronie spotykają największych zagranicznych dostawców. Skutkuje to tym, że opisując przedmiot zamówienia na licencje oprogramowania, bardzo często ograniczają się do prostego stwierdzenia, że przedmiotem zamówienia są określone licencje (wymienione z nazwy), czemu towarzyszy sformułowanie „lub równoważne”. W ten sposób oddają pole dostawcom oprogramowania, którzy wobec braku jakichkolwiek wymagań licencyjnych stawianych przez zamawiających zachowują prawie całkowitą dowolność w ich kształtowaniu. Ale nawet gdyby zamawiający zdecydował się takie wymagania licencyjne postawić, to i tak zapewne nie byłyby one wiążące dla producenta oprogramowania, gdyż – tak jak pisaliśmy wcześniej – umowa o zamówienie publiczne (której takie wymagania stałyby się częścią) łączy wyłącznie zamawiającego z wykonawcą, którym z reguły jest partner lub dystrybutor producenta oprogramowania, a nie zamawiającego z producentem.
Nie oznacza to jednak, że zamawiający pozostają w takiej sytuacji całkowicie bezbronni. Sporządzając dokumentację przetargową (w szczególności opis przedmiotu zamówienia i wzór umowy), mogą postawić wymagania dotyczące tych obszarów licencji, które z ich perspektywy są najbardziej krytyczne. W pozostałym zakresie, który nie ma dla zamawiającego aż tak dużego znaczenia, dokumentacja przetargowa może natomiast dopuszczać warunki licencyjne producenta. Istotne jest przy tym to, aby wymagania licencyjne stawiane przez zamawiających zostały ustalone z uwzględnieniem realiów rynkowych i modeli licencyjnych producentów. Nieodzownym elementem przy formułowaniu takich wymagań jest więc ich dokładne poznanie – zamawiający musi być świadom nie tylko własnych potrzeb, lecz także tego, jak są skonstruowane modele licencyjne dostępnych produktów. W przeciwnym przypadku postawienie zbyt wysokich i nierynkowych wymagań licencyjnych będzie zapewne skutkowało tym, że żaden z dostawców nie będzie zainteresowany złożeniem oferty. Jak już zaznaczyliśmy, wymagania licencyjne stawiane przez zamawiających wiązałyby jedynie partnera lub dystrybutora oprogramowania, a nie jego producenta. Dla zamawiającego byłoby to i tak duże zabezpieczenie. Po pierwsze w sytuacji, gdyby z SIWZ wynikał obowiązek dołączenia warunków licencyjnych producenta oprogramowania do oferty składanej przez dostawcę zamawiający mógłby porównać je z tymi, które zostały sformułowane przez niego w specyfikacji, zaś w przypadku ewentualnych rozbieżności mógłby on odrzucić ofertę wykonawcy – jako niezgodną z SIWZ. W takim przypadku dołączenie warunków licencyjnych producenta do oferty miałoby jeszcze ten skutek, że stałyby się one częścią umowy o zamówienie publiczne pomiędzy zamawiającym a dostawcą. Każda zmiana tych warunków przez producenta (co w praktyce może zdarzać się bardzo często, np. przy aktualizacji oprogramowania) musiałaby być zatem dokonywana zgodnie z procedurą zmiany umowy o zamówienie publiczne określoną w art. 144 p.z.p. Zamawiający decydując się na taki wariant, musiałby więc odpowiednio uelastycznić umowę o zamówienie publiczne zawieraną z dostawcą, np. przez wprowadzenie do niej odpowiednich klauzul zmiany umowy. Poza tym w przypadku zmiany warunków licencyjnych przez producenta oprogramowania w trakcie obowiązywania umowy o zamówienie publiczne z dostawcą – w taki sposób, że byłyby one niezgodne z wymaganiami określonymi pierwotnie w SIWZ – zamawiający mógłby wystąpić z roszczeniem do dostawcy (np. o zapłatę kary umownej albo odszkodowanie z tytułu nienależytego wykonania umowy). Treścią zobowiązania dostawcy byłoby bowiem zapewnienie licencji o parametrach przewidzianych w SIWZ.
Jednocześnie modele licencyjne stosowane przed producentów oprogramowania niejednokrotnie mogą okazać się dla zamawiających bardzo ciekawą i wartościową inspiracją. Szereg przewidzianych w nich rozwiązań może znacząco uelastycznić umowę oraz zwiększyć efektywność realizacji zamówienia publicznego. Jest to szczególnie istotne w kontekście nowego p.z.p., które zacznie obowiązywać od 1 stycznia 2021 r. (Dz.U. z 2019 r. poz. 1843). Jego art. 17 ust. 1 pkt 2 wprost wymienia efektywność zamówienia jako jedną z podstawowych zasad udzielania zamówień publicznych. Przykładem takich rozwiązań są m.in. modele rozliczeń stosowane przez producentów oprogramowania wykorzystujące tzw. mechanizmy true-up oraz true-forward. Pierwszy z nich polega na tym, że zamawiający, zawierając umowę licencyjną z producentem oprogramowania, na wstępie deklaruje przewidywaną liczbę licencji, z których będzie korzystał (z reguły jest ona identyczna z liczbą licencji, na którą udzielił on zamówienia publicznego). Jeżeli jednak w trakcie umowy z producentem okaże się, że zamawiający wykorzystał większą liczbę licencji niż pierwotnie zadeklarował, producent naliczy z tego tytułu odpowiednią opłatę wsteczną oraz zaktualizuje deklarowaną liczbę wykorzystywanych licencji na przyszłość, co przełoży się na wyższą opłatę.
Jeszcze ciekawszym rozwiązaniem jest drugi z wymienionych mechanizmów, true-forward. Konstrukcyjnie jest on bardzo podobny do mechanizmu True-Up, jednak różnica polega na tym, że w przypadku True-Forward producent nie nalicza opłaty wstecznej. Zamawiający nie zapłaci więc za nadliczbowe licencje wygenerowane w danym roku rozliczeniowym. Zostaną one doliczone do pierwotnie zadeklarowanej liczby licencji i będą opłacane dopiero od kolejnego roku rozliczeniowego. Oznacza to więc, że zamawiający mógłby korzystać z określonej puli licencji całkowicie za darmo przez określony czas.
Oba te mechanizmy są stosowane na rynku prywatnym. Nie ma jednak przeszkód, aby z takim samym powodzeniem były wykorzystywane na rynku publicznym. To co jest w tym wypadku kluczowe, to odpowiednie skonstruowanie zamówienia publicznego. Prawo zmówień publicznych – zarówno w obecnym, jak i nowym kształcie – daje zamawiającym wiele narzędzi, które mogą okazać się pomocne (m.in. prawo opcji, umowa ramowa, możliwość zwiększenia wynagrodzenia wykonawcy o 10 proc. etc.). Dużo zależy więc od kreatywności i odwagi zamawiających.