Scenka wyjściowa: przetarg, który utknął na „oprogramowaniu firmowym”
Urząd powiatowy ogłasza przetarg na „wdrożenie i utrzymanie systemu klasy XYZ firmy Y do obsługi mieszkańców”. Po tygodniu przychodzi odwołanie: konkurencyjny wykonawca twierdzi, że przetarg jest napisany pod jednego producenta i łamie zasadę uczciwej konkurencji. Posiedzenie zespołu projektowego zamienia się w gorącą dyskusję o tym, czy można było dopuścić rozwiązania open source, a jeżeli tak – to jak to zrobić, żeby nie narobić sobie kłopotów.
Informatyk broni zamkniętego systemu: „Przynajmniej wiemy, kto za to odpowiada, mamy jednego dostawcę, to bezpieczniejsze”. Prawnik rozkłada ręce: „Open source? Tysiąc licencji, żadnej gwarancji, a jak przyjdzie kontrola, to co im pokażemy?”. Po chwili ktoś z działu zamówień dodaje: „Może problem nie w tym, że wybraliśmy rozwiązanie firmy Y, tylko w tym, jak opisaliśmy nasze potrzeby w SIWZ?”.
Tu właśnie pojawia się prawdziwy punkt zapalny. Kłopot zaczyna się nie przy samej decyzji „open source czy rozwiązanie komercyjne”, ale wcześniej – przy sposobie formułowania wymagań, rozumieniu neutralności technologicznej i braku świadomości, jak w ogóle zapisywać w SIWZ kwestie dostępu do kodu, licencji i odpowiedzialności. Gdy ten fundament jest źle ułożony, każda technologia – otwarta czy zamknięta – będzie problematyczna.
Rozsądne podejście do open source w przetargach publicznych nie polega na ideologicznym „otwórzmy wszystko”, tylko na zaprojektowaniu takich wymagań i zapisów umownych, które dopuszczą różne modele (w tym otwarte), a jednocześnie zabezpieczą instytucję przed typowymi błędami: vendor lock-in, brakiem wsparcia, chaosem licencyjnym czy powielaniem tych samych wydatków w kolejnych jednostkach.
Podstawy: czym jest open source w kontekście zamówień publicznych
Open source, free software i „darmowe oprogramowanie” – porządek w pojęciach
W dyskusjach o przetargach publicznych często miesza się trzy różne światy: open source, free software i zwykłe oprogramowanie „darmowe” (freeware). Dla działu zamówień wszystko to bywa wrzucone do jednego worka „bezpłatne rozwiązania, na które nie ma faktury”. To prosta droga do kłopotów.
Open source to model licencjonowania, w którym kod źródłowy jest dostępny, a licencja daje określone prawa: uruchamiania programu, analizowania jego działania, modyfikacji i dalszego rozpowszechniania. Te prawa są uregulowane prawnie, a nie „na gębę”. W praktyce open source może być używany komercyjnie, w płatnych usługach, przez firmy i administrację publiczną.
Free software (w rozumieniu ruchu FSF) kładzie nacisk na wolność użytkownika, nie na cenę. Wolność do uruchamiania, studiowania, modyfikowania i rozpowszechniania. Większość licencji „free software” jest jednocześnie open source, ale nacisk jest inny – bardziej ideologiczny niż biznesowy. Dla przetargów publicznych ważniejsze jest, jakie konkretnie prawa i obowiązki daje licencja, niż to, czy spełnia wszystkie filozoficzne definicje wolności.
Darmowe oprogramowanie (freeware) to zupełnie inna kategoria: program może być darmowy do użycia, ale kod źródłowy jest zamknięty, a licencja zwykle nie pozwala na modyfikacje ani rozpowszechnianie. W przetargach często pojawia się pokusa, by „zaoszczędzić” na licencjach, wybierając coś darmowego, ale bez świadomości, że pod względem prawnym i ryzyk to nadal rozwiązanie zamknięte, bez kontroli nad rozwojem.
Kluczowa różnica: open source to nie brak licencji, tylko inny model licencjonowania. Każda biblioteka, każdy komponent ma swoją licencję, a nieprzestrzeganie jej warunków to normalne naruszenie prawa autorskiego, za które odpowiada także instytucja publiczna korzystająca z systemu.
Oprogramowanie open source a „rozwiązanie open source” w przetargu
Na poziomie zamówień publicznych trzeba rozróżnić dwie rzeczy:
- oprogramowanie open source – konkretny produkt, biblioteka, system (np. Linux, PostgreSQL, Drupal, Keycloak),
- rozwiązanie open source w przetargu – pakiet: oprogramowanie + usługa wdrożenia + konfiguracja + rozwój + wsparcie + (czasem) utrzymanie infrastruktury.
Dla instytucji najczęściej nie ma większego znaczenia, czy system rejestrów publicznych bazuje na PostgreSQL czy na komercyjnej bazie danych. Ważne jest, czy:
- będzie działał stabilnie i bezpiecznie,
- ktoś będzie go wspierał przez kolejne lata,
- da się go rozwijać i integrować z innymi systemami,
- nie zostanie zablokowany u jednego dostawcy na lata.
Dlatego w przetargu opisuje się rozwiązanie – usługi i wymagania funkcjonalne, niefunkcjonalne, licencyjne. To, że pod spodem wykorzystane zostaną komponenty open source, jest jednym z elementów układanki. Często najważniejszym dla działu IT, ale dla prawa zamówień publicznych istotne są przede wszystkim zasady konkurencji, równego traktowania i efektywnego wydatkowania środków.
Rozsądne podejście nie polega więc na wpisaniu w SIWZ „wymagane oprogramowanie open source”, tylko na zdefiniowaniu takich warunków, które pozwolą oferentom zaproponować zarówno rozwiązania otwarte, jak i zamknięte, przy zachowaniu tych samych celów biznesowych i bezpieczeństwa dla zamawiającego.
Jak prawo zamówień publicznych patrzy na open source
Polskie i unijne prawo zamówień publicznych opiera się na kilku kluczowych zasadach: uczciwej konkurencji, równego traktowania wykonawców, przejrzystości oraz neutralności technologicznej. To ostatnie pojęcie ma kluczowe znaczenie dla open source w przetargach.
Neutralność technologiczna oznacza, że zamawiający nie powinien faworyzować konkretnych technologii, marek czy producentów, chyba że jest to obiektywnie uzasadnione przedmiotem zamówienia i dobrze opisane. Od lat orzecznictwo KIO i wytyczne UE podkreślają, że specyfikacja nie może prowadzić do sytuacji, w której w praktyce tylko jeden producent jest w stanie złożyć ofertę.
Open source w zamówieniach publicznych jest więc traktowany jak jedna z opcji. Niedopuszczalne jest pisanie SIWZ „pod” konkretną licencję (np. „system musi być na licencji GPL”) bez wyraźnych, uzasadnionych powodów. Podobnie, nie można bezrefleksyjnie faworyzować wyłącznie rozwiązań komercyjnych, np. przez wymaganie przeniesienia pełni autorskich praw majątkowych do całości kodu bez dopuszczenia alternatywy w postaci korzystania z licencji open source.
Istotny mini-wniosek: open source jest neutralne prawnie. Prawo zamówień publicznych ani go nie promuje, ani nie blokuje. Ramy są takie same: trzeba opisać potrzeby w sposób niedyskryminujący, dający szansę różnym modelom biznesowym. Reszta zależy od tego, jak zostaną napisane wymagania w SIWZ i jaka będzie świadomość licencyjna po obu stronach.
Dlaczego w ogóle brać open source pod uwagę w przetargach publicznych
Unikanie vendor lock-in i zwiększanie konkurencyjności
Jednym z najczęściej przywoływanych argumentów za open source w administracji jest uniknięcie uzależnienia od jednego dostawcy (vendor lock-in). W praktyce wiele jednostek jest „uwiązanych” do jednego producenta systemu, bo:
- tylko on ma prawo rozwijać i modyfikować kod,
- dokumentacja jest niepełna lub zamknięta,
- formaty danych są niejawne lub zastrzeżone,
- umowa nie reguluje prawa do korzystania z kodu źródłowego czy dokumentacji w przypadku zmiany wykonawcy.
W rozwiązaniach open source kod źródłowy jest dostępny, więc teoretycznie każdy wykonawca z odpowiednimi kompetencjami może przejąć utrzymanie i rozwój. W praktyce oznacza to:
- łatwiejszą zmianę dostawcy w kolejnych przetargach,
- wzrost konkurencji – więcej firm może złożyć ofertę na utrzymanie istniejącego systemu,
- większą elastyczność w zakresie modyfikacji – nie trzeba czekać, aż „centralny producent” wprowadzi oczekiwaną funkcję.
To nie oznacza, że vendor lock-in znika całkowicie. Może on dotyczyć np. specyficznej konfiguracji, wiedzy domenowej czy integracji. Jednak mechanizm „zamykania” się na jeden podmiot jest znacznie słabszy, a przetargi na rozwój i utrzymanie z natury są bardziej konkurencyjne.
Mini-wniosek: open source nie gwarantuje automatycznie braku zależności od dostawcy, ale znacząco zwiększa możliwości zmiany wykonawcy i realnej konkurencji w kolejnych postępowaniach.
Potencjalne oszczędności i długoterminowa efektywność
Na poziomie pojedynczego projektu różnica cenowa między rozwiązaniem komercyjnym a open source nie zawsze jest spektakularna. Licencja to tylko część kosztów, często mniejsza niż wdrożenie, integracja i utrzymanie. Jednak w dłuższym horyzoncie i przy szerszej skali open source może przynieść wymierne korzyści finansowe.
Najważniejsze źródła oszczędności to:
- brak opłat licencyjnych per użytkownik – szczególnie ważne przy dużych systemach z tysiącami kont,
- możliwość współdzielenia rozwiązań między jednostkami – raz opracowany moduł może być użyty w innych instytucjach bez kolejnych opłat licencyjnych,
- tańsza zmiana dostawcy – jeżeli kod jest dostępny, przeniesienie systemu do innego wykonawcy jest łatwiejsze, więc oferty na utrzymanie mogą być niższe,
- uniknięcie nieprzewidzianych kosztów licencji – przy rozwoju systemu, dodawaniu nowych modułów, użytkowników czy środowisk testowych.
W praktyce dobrze zaprojektowany projekt open source w administracji pozwala uniknąć powielania tych samych wydatków przez wiele jednostek. Zamiast kupować dziesięć podobnych systemów od dziesięciu różnych dostawców, można rozwijać jedno wspólne rozwiązanie, które kolejne instytucje adaptują do swoich potrzeb.
Współdzielenie rozwiązań i efekt skali w sektorze publicznym
Jedną z największych przewag open source w zamówieniach publicznych jest możliwość ponownego wykorzystania (re-use). Kod raz wytworzony dla jednej jednostki może być legalnie udostępniony innym, pod warunkiem właściwego uregulowania kwestii praw autorskich i licencji.
Scenariusz idealny wygląda tak:
- Jednostka A zamawia system do obsługi określonego procesu (np. wnioski o dotacje). W SIWZ wymaga, by kod powstałych komponentów został udostępniony pod otwartą licencją (np. GPL, AGPL, EUPL) oraz opublikowany w repozytorium.
- Jednostka B organizuje przetarg na podobny system. Wymaga, by wykonawcy wzięli pod uwagę istniejący kod z repozytorium i, o ile to możliwe, wykorzystali go w rozwiązaniu, zamiast tworzyć wszystko od zera.
- Kolejni dostawcy rozwijają to samo rozwiązanie, naprawiają błędy, dodają funkcje – z korzyścią dla całej administracji.
Taki model wymaga koordynacji i zrozumienia kwestii licencyjnych, ale potencjał oszczędności i poprawy jakości jest ogromny. Szczególnie przy systemach, które nie są unikatowe dla jednej instytucji: portale, BIP, platformy konsultacji społecznych, systemy kolejkowe, moduły integracyjne.
Transparentność, bezpieczeństwo i audytowalność
Dostęp do kodu źródłowego oznacza nie tylko możliwość jego modyfikacji. To także większą przejrzystość działania systemu. W kontekście instytucji publicznych ma to kilka ważnych skutków:
- można zlecić niezależny audyt bezpieczeństwa – bez zdawania się tylko na zapewnienia producenta,
- łatwiej wychwycić błędy logiczne, potencjalne nadużycia czy „tylne furtki”,
- łatwiej udowodnić zgodność z wymogami prawnymi (np. RODO, ochrona danych), bo da się prześledzić ścieżki przetwarzania informacji,
- większa zaufalność systemu w oczach obywateli – szczególnie przy rozwiązaniach wrażliwych (głosowania elektroniczne, rejestry zdrowotne etc.).
Open source nie jest automatycznie bezpieczniejszy niż oprogramowanie zamknięte, ale daje narzędzia do niezależnej weryfikacji. W połączeniu z aktywną społecznością i szybkimi aktualizacjami może to być przewaga nad zamkniętymi systemami, gdzie tempo łatania luk zależy wyłącznie od jednego producenta.
Mini-wniosek: w sektorze publicznym, gdzie zaufanie i przejrzystość są kluczowe, dostępność kodu może być realnym atutem – oczywiście pod warunkiem, że instytucja lub jej partnerzy potrafią ten kod analizować i reagować na problemy.
Wsparcie dla lokalnego rynku i MŚP
Modele biznesowe wokół open source sprzyjają dywersyfikacji dostawców. Zamiast jednego globalnego producenta, który sprzedaje licencje, pojawia się przestrzeń dla wielu firm świadczących usługi:
- wdrożenie i konfiguracja systemu,
- dostosowanie do lokalnych procesów,
Budowanie kompetencji lokalnych zespołów IT
W jednym z urzędów marszałkowskich nowy dyrektor IT zorientował się, że na każdy drobny błąd w systemie trzeba czekać tygodniami – bo nawet poprawka jednego raportu wymagała zlecenia prac producentowi. Zespół wewnętrzny znał procesy biznesowe, ale nie miał żadnego wpływu na kod. Dopiero przejście na rozwiązanie open source otworzyło drogę do stopniowego budowania kompetencji po stronie urzędu.
Przy oprogramowaniu otwartym rola wewnętrznego działu IT może się istotnie zmienić – z „operatora umów serwisowych” w stronę świadomego właściciela rozwiązania. Kod jest dostępny, więc:
- można zlecać analizy, przeglądy i drobne poprawki również mniejszym, lokalnym firmom,
- część działań (np. proste modyfikacje konfiguracji, integracje przez API) może przejąć zespół wewnętrzny,
- łatwiej szkolić nowych pracowników – bazując na realnym kodzie, a nie tylko na slajdach producenta.
Dobrą praktyką jest stopniowe budowanie „pamięci technicznej” organizacji:
- utrzymywanie wewnętrznego repozytorium (np. mirror Git) z kodem systemów kluczowych,
- tworzenie krótkiej dokumentacji architektury (diagramy, główne moduły, punkty integracji),
- zapewnienie, aby przynajmniej jedna osoba po stronie zamawiającego rozumiała podstawowe założenia stosowanych licencji.
Mini-wniosek: open source pozwala zamawiającemu stać się faktycznym gospodarzem projektu IT – pod warunkiem, że inwestuje w kompetencje i dokumentację, a nie tylko w kolejne faktury serwisowe.
Ryzyka i wyzwania związane z open source w zamówieniach publicznych
Odpowiedzialność za utrzymanie i dług techniczny
W małym mieście wdrożono system open source do obsługi spraw mieszkańców. Początkowo wszystko działało świetnie, ale po kilku latach zmienił się wykonawca, a projekt w społeczności „przysiadł”. Zaczęły się problemy z aktualizacjami bezpieczeństwa, a urząd nie miał ani dokumentacji, ani planu utrzymania.
Oprogramowanie otwarte nie „utrzyma się samo”. Brak opłat licencyjnych łatwo bywa zjedzony przez rosnący dług techniczny, jeśli w SIWZ nie zaplanuje się:
- cyklicznych aktualizacji wersji (nie tylko łatek bezpieczeństwa),
- budżetu na refaktoryzację i modernizację komponentów,
- monitorowania zgodności z nowymi przepisami (np. zmiany w prawie podatkowym, archiwalnym).
W opisie przedmiotu zamówienia warto więc wyraźnie wskazać, że utrzymanie obejmuje również:
- śledzenie rozwoju projektu bazowego (głównego „upstreamu”),
- proponowanie aktualizacji większych wersji (np. przejście z wersji 3.x na 4.x) wraz z analizą wpływu,
- zarządzanie długiem technicznym – np. raport roczny z rekomendacjami porządkującymi.
Mini-wniosek: zysk z braku licencji pojawia się realnie tylko wtedy, gdy open source ma zapewnione świadome, zaplanowane utrzymanie – tak samo, jak produkty komercyjne.
Fragmentacja i brak standardów wewnętrznych
Instytucja centralna zleca rozwój trzech podobnych systemów w różnych departamentach. Każdy wykonawca sięga po inne biblioteki i frameworki open source, bez minimalnego katalogu standardów. Po kilku latach urząd ma trzy zupełnie różne stosy technologiczne do utrzymania – ani taniej, ani prościej.
Elastyczność open source sprzyja rozproszeniu technologii, jeżeli nie postawi się przemyślanych ograniczeń. W SIWZ można temu częściowo przeciwdziałać, np. poprzez:
- opis preferowanego stosu technologicznego (np. Java + Spring / Python + Django / .NET Core), z dopuszczeniem uzasadnionych odstępstw,
- wskazanie minimalnych standardów integracji (REST/JSON, OAuth2, OpenID Connect, standardy X-Road itp.),
- wymóg stosowania określonych formatów wymiany danych (np. XML/JSON w konkretnych schematach, a nie własne binarne protokoły).
Takie zapisy nie mają blokować konkurencji, tylko ograniczyć niepotrzebną fragmentację i ułatwić współdzielenie komponentów między jednostkami. Gdy kilka systemów korzysta z podobnego stosu, łatwiej przesuwać kompetencje między projektami oraz negocjować warunki z wykonawcami.
Mini-wniosek: open source nie zwalnia z myślenia o architekturze całej organizacji – wręcz przeciwnie, brak wspólnych standardów szybko mści się wyższymi kosztami utrzymania.
Kwestie licencyjne i „zaraźliwość” copyleft
W jednym przetargu wykonawca obiecał, że „cały kod będzie open source”. Dopiero na etapie odbioru okazało się, że część komponentów powstała jako modyfikacja bibliotek na licencji GPL, co wymuszało ujawnienie znacznie większej części kodu niż pierwotnie planował zamawiający. Spór o zakres udostępnienia trwał miesiącami.
Licencje open source różnią się znacznie co do skutków prawnych. W uproszczeniu:
- licencje copyleft (np. GPL, AGPL) wymagają, aby utwory zależne także były udostępniane na otwartej licencji – w określonym zakresie,
- licencje permissive (np. MIT, BSD, Apache 2.0) pozwalają łączyć komponenty otwarte z kodem zamkniętym bez obowiązku otwierania całości,
- licencje specyficzne dla administracji, jak EUPL, są projektowane z myślą o re-use w sektorze publicznym i interoperacyjności z innymi licencjami.
W SIWZ powinny znaleźć się konkretne wymagania licencyjne, np.:
- jakie typy licencji są dopuszczalne w zależnościach (bibliotekach, modułach, narzędziach),
- na jakiej licencji ma zostać udostępniony kod wytworzony w projekcie (np. EUPL, MIT, GPL, kombinacja),
- w jakim zakresie zamawiający oczekuje przeniesienia autorskich praw majątkowych, a w jakim wystarczy licencja.
Bez takich zapisów zamawiający może utknąć w niejasnej sytuacji: z jednej strony rozwój sfinansowany z pieniędzy publicznych, z drugiej – ograniczona możliwość dalszego współdzielenia rozwiązania, bo licencje komponentów wzajemnie się „gryzą”.
Mini-wniosek: open source nie „robi się samo” – świadome dobranie i opisanie licencji jest tak samo ważne, jak wybór technologii czy architektury.
Wsparcie techniczne i ciągłość usług
Mały urząd gminy zdecydował się na system open source bez komercyjnego wsparcia. Początkowo radził sobie sam, korzystając z forów i dokumentacji społeczności. Kiedy doszło do poważnej awarii, okazało się, że „czas reakcji społeczności” nie jest parametrem, który można zapisać w umowie.
Oparcie się wyłącznie na społeczności open source jest ryzykowne dla systemów krytycznych. Realistyczny model zamówienia powinien przewidywać:
- konkretnego wykonawcę lub konsorcjum odpowiedzialne za utrzymanie, z umownym SLA,
- opcję zmiany wykonawcy przy zachowaniu pełnego dostępu do kodu, dokumentacji, narzędzi CI/CD,
- możliwość zaangażowania drugiej firmy do audytu i konsultacji, gdy relacje z głównym wykonawcą się psują.
W opisie przedmiotu zamówienia dobrze jest wprost rozdzielać:
- wsparcie społecznościowe (fora, issue trackery, listy mailingowe) – jako element „nice to have”,
- wsparcie komercyjne – z gwarantowanymi terminami reakcji, utrzymaniem ciągłości działania, procedurami kryzysowymi.
Mini-wniosek: społeczność jest ogromnym atutem open source, ale w administracji nie zastąpi umowy serwisowej z jasno zdefiniowaną odpowiedzialnością.
Zarządzanie bezpieczeństwem i podatnościami
W jednym z resortów wykryto poważną lukę w bibliotece kryptograficznej używanej przez kilka systemów. Informacja o podatności pojawiła się publicznie, poprawka w repozytorium – po kilkunastu godzinach. Aktualizacja w systemach urzędowych zajęła… kilka tygodni, bo nikt nie miał formalnie przypisanej roli „opiekuna bezpieczeństwa open source”.
W środowisku otwartym informacje o podatnościach są szeroko komunikowane – co jest zaletą, ale i wyzwaniem. W SIWZ przy systemach korzystających z open source przydają się zapisy określające:
- kto (po stronie wykonawcy) monitoruje podatności w używanych komponentach,
- maksymalny czas reakcji na krytyczne luki (np. 24/48h od publikacji poprawki),
- procedurę awaryjną – np. czasowe wyłączenie modułu, wymuszenie aktualizacji, obejścia konfiguracyjne.
Dobrym rozwiązaniem bywa też wymóg stosowania narzędzi SCA (Software Composition Analysis) lub równoważnych, które automatycznie skanują zależności i raportują znane podatności. Zamawiający może oczekiwać okresowych raportów z takich narzędzi, przynajmniej dla kluczowych systemów.
Mini-wniosek: przy open source przewaga w postaci szybkich łatek bezpieczeństwa ujawni się tylko wtedy, gdy ktoś faktycznie śledzi podatności i ma mandat do szybkiego działania.
Praktyczne zapisy w SIWZ dotyczące open source
Opisywanie wymagań funkcjonalnych zamiast technologii
W pewnym przetargu na system obiegu dokumentów pojawił się zapis: „system musi być oparty na technologii X”. W efekcie oferty mogło złożyć kilku partnerów jednego producenta. Gdy zamawiający w kolejnym postępowaniu skupił się na wymaganiach funkcjonalnych i parametrach jakościowych, otworzył rynek także na rozwiązania open source oraz inne technologie komercyjne.
Przy pisaniu SIWZ przydatne są trzy proste zasady:
- Skoncentrować się na funkcjach i procesach, a nie na konkretnych produktach czy markach.
- Wymagać otwartych interfejsów i formatów danych, zamiast wskazywać konkretny system integrujący.
- Dopuszczać różne modele licencyjne (komercyjne, open source), pod warunkiem spełnienia wymogów prawnych i jakościowych.
Można wprost napisać, że zamawiający dopuszcza rozwiązania zarówno na licencjach otwartych, jak i komercyjnych, z określeniem minimalnych warunków dla obu (np. w zakresie prawa do modyfikacji i re-use). Taki zapis nie faworyzuje żadnej strony, a jednocześnie otwiera drzwi projektom open source.
Mini-wniosek: SIWZ powinno mówić „co” ma być zrobione i „jakie” parametry mają być spełnione, a nie „na czym” ma to działać – wtedy open source może konkurować na równych zasadach.
Regulowanie praw autorskich i licencji w sposób wielowarstwowy
W dużych projektach IT mieszają się różne kategorie kodu: komponenty bazowe open source, autorskie moduły wykonawcy, skrypty i konfiguracje specyficzne dla urzędu. Próba uregulowania wszystkiego jednym ogólnym zapisem o „przeniesieniu praw autorskich” zwykle kończy się niejasnościami i sporami.
Przejrzysty model można oprzeć na rozróżnieniu kilku warstw:
- kod zastany (third-party) – zewnętrzne biblioteki i projekty open source, używane na ich własnych licencjach; zamawiający otrzymuje prawo korzystania w takim zakresie, w jakim przewiduje to dana licencja,
- kod modyfikujący lub rozszerzający projekty open source – np. pluginy, moduły integracyjne; tu można wymagać określonej otwartej licencji (np. EUPL lub GPL), aby umożliwić re-use,
- kod ściśle specyficzny dla zamawiającego – np. integracja z lokalnymi rejestrami, skrypty migracji; często zasadne jest pełne przeniesienie majątkowych praw autorskich lub bardzo szeroka licencja wyłączna,
- artefakty pomocnicze – dokumentacja, szablony raportów, definicje procesów BPMN, schematy baz danych; dobrze, aby zamawiający miał do nich prawa na tyle szerokie, by móc je wykorzystać także przy innych systemach.
W SIWZ warto też wprost uregulować kwestię kontrybucji do projektów upstream. Jeżeli wykonawca wprowadza poprawki do zewnętrznego projektu open source, zasadne jest wymaganie, aby:
- wnosił je zgodnie z zasadami danej społeczności,
- informował zamawiającego o istotnych zmianach zwrotnych (np. przyjętych do głównego repozytorium),
- tam, gdzie to możliwe, dążył do minimalizacji „łat” utrzymywanych tylko lokalnie.
Mini-wniosek: porządek w prawach autorskich zaczyna się od rozróżnienia rodzajów kodu – dopiero wtedy ma sens dyskusja, co ma być otwarte, a co na wyłączność.
Wymagania dotyczące dokumentacji i repozytoriów
W jednej z agencji rządowych przekazanie systemu nowemu wykonawcy zajęło ponad pół roku, bo poprzedni dostawca trzymał kod w swoim prywatnym repozytorium, a dokumentacja ograniczała się do kilku plików Worda. Po zmianie podejścia do open source wprowadzono twardy wymóg: cały kod i dokumentacja muszą znajdować się w repozytoriach kontrolowanych przez zamawiającego.
Przy projektach opartych na open source kluczowe są dwa elementy:
Standardy prowadzenia repozytoriów i przekazania wiedzy
Nowy wykonawca wszedł do projektu pewnego ministerstwa z założeniem, że „kod mówi sam za siebie”. Po tygodniu okazało się, że bardziej mówi „uciekaj” – brakowało historii decyzji architektonicznych, opisów procesów wdrożeniowych i informacji, jak system utrzymać w ruchu po aktualizacji. Pierwsze miesiące współpracy zamiast na rozwoju, zeszły na archeologii cyfrowej.
Repozytorium kontrolowane przez zamawiającego to dopiero początek. Przy polityce otwartego oprogramowania sens mają precyzyjne wymagania co do jego zawartości i organizacji, np.:
- obowiązek trzymania całego kodu źródłowego (w tym skryptów migracyjnych, infrastruktury jako kodu, konfiguracji dla CI/CD) w repozytorium wskazanym przez zamawiającego,
- wymóg stosowania systemu kontroli wersji (Git lub równoważny) oraz określoną strategię gałęzi (np. trunk-based development, GitFlow) z opisem w pliku
CONTRIBUTING.md, - prowadzenie historii zmian w postaci dziennika (
CHANGELOG.md) obejmującego także zmiany konfiguracyjne i migracje danych, - utrzymywanie oddzielnych katalogów dla dokumentacji technicznej, użytkowej i operacyjnej, z jasnym wskazaniem, która jest referencyjna przy audytach i odebraniu prac.
Sam kod nie wystarczy, jeśli kolejny zespół nie rozumie, dlaczego coś zostało zrobione w określony sposób. Dlatego w SIWZ można domagać się co najmniej trzech klas dokumentów:
- architektura i decyzje projektowe – np. w formie krótkich kart ADR (Architectural Decision Record),
- procedury operacyjne – backup, odtwarzanie, eskalacja incydentów, proces wdrożenia na środowiska test/produkcyjne,
- instrukcje dla użytkowników i administratorów – zaktualizowane do wersji wdrożonej na produkcji.
Mini-wniosek: repozytorium to nie „szuflada na kod”, tylko centralny punkt wiedzy o systemie – bez standardów jego prowadzenia trudno mówić o realnej niezależności od wykonawcy.
Wymogi dotyczące środowisk, automatyzacji i odtwarzalności
W jednym z miast awaria zasilania unieruchomiła system obsługi mieszkańców. Gdy serwery ruszyły, okazało się, że konfiguracja środowiska była „w głowie admina” i częściowo na jego prywatnym pendrivie. Przy open source, gdzie wiele elementów jest dostępnych publicznie, szczególnie boleśnie widać brak porządku po stronie wdrożenia.
Przy przetargach, w których przewiduje się użycie open source, można oczekiwać wysokiego poziomu automatyzacji. Przekłada się to na konkretne zapisy, np.:
- wymóg stosowania infrastruktury jako kodu (np. Terraform, Ansible, równoważne) i przechowywania jej w repozytorium zamawiającego,
- dostarczanie skryptów instalacyjnych i aktualizacyjnych, które pozwalają odtworzyć środowisko od zera na bazie dokumentacji,
- opis minimalnych parametrów środowisk (testowe, przedprodukcyjne, produkcyjne) i procedur ich synchronizacji,
- wymóg możliwości powołania środowiska sandbox do testów nowych wykonawców lub zespołów wewnętrznych.
Coraz częściej administracja wymaga też, by rozwiązania dało się wdrożyć w modelu on-premise lub w chmurze spełniającej określone normy (np. lokalizacja danych, certyfikacje bezpieczeństwa). W przypadku open source daje to większą elastyczność, ale wymaga doprecyzowania w SIWZ:
- czy zamawiający oczekuje przenoszalności pomiędzy różnymi dostawcami infrastruktury,
- jakie zależności chmurowe są dopuszczalne (np. managed database, load balancer) i jak należy je zdefiniować, by ich zmiana była wykonalna,
- jak mają wyglądać kopie zapasowe i testy odtwarzania w akceptowalnym czasie (RTO/RPO).
Mini-wniosek: otwarty kod bez odtwarzalnego środowiska to połowa rozwiązania – pełna kontrola wymaga także „otwartej” infrastruktury opisanej jako kod i proces.
Transparentność, audytowalność i udział społeczności
W projekcie jednego z urzędów centralnych kod udostępniono publicznie w repozytorium, ale zamknięto zgłaszanie błędów i propozycji zmian z zewnątrz. Formalnie „mamy open source”, praktycznie – jednostronna publikacja, bez korzyści z szerszej społeczności.
Jeśli zamawiający chce wykorzystać potencjał otwartości, może w SIWZ wskazać minimalne zasady transparentności:
- publikację kodu w publicznym repozytorium (jeśli nie ma przeciwwskazań bezpieczeństwa lub tajemnicy państwowej),
- udostępnienie publicznego issue trackera dla części funkcjonalnej, z rozróżnieniem na zgłoszenia zewnętrzne i wewnętrzne,
- zasady przyjmowania zewnętrznych kontrybucji (kodeks postępowania, proces przeglądu, wymagania licencyjne do wkładów),
- publikację wybranych metryk rozwoju projektu (np. wydane wersje, główne zmiany, informacja o załatanych podatnościach).
W praktyce daje to dwa efekty. Po pierwsze, ułatwia niezależny audyt bezpieczeństwa i jakości kodu (np. przez inne jednostki, NASK, zewnętrznych ekspertów). Po drugie, zwiększa szanse na pozyskanie wsparcia ze środowiska – także nieodpłatnego, w postaci zgłoszeń błędów i drobnych poprawek.
Nie każda część systemu może być publiczna. W SIWZ warto więc podzielić rozwiązanie na:
- warstwę wspólną/ogólną – biblioteki, UI, warstwa integracji generująca standardowe formaty; ta może być otwarta i publiczna,
- warstwę wrażliwą – konfiguracje z danymi dostępowymi, reguły bezpieczeństwa, algorytmy antyfraudowe; ta pozostaje w repozytoriach zamkniętych, choć nadal może korzystać z licencji open source.
Mini-wniosek: otwartość nie musi oznaczać „wszystko na wierzchu” – mądrze zaprojektowana architektura pozwala łączyć publiczny kod z ochroną elementów krytycznych.
Kryteria oceny ofert uwzględniające dojrzałość open source
W jednym z przetargów dwie oferty miały zbliżoną cenę i podobny zakres funkcjonalny. Różniły się tym, że jedna opierała się na dojrzałych komponentach open source z wieloletnią historią, druga – na autorskim rozwiązaniu zamkniętym małego dostawcy. Brak kryteriów jakościowych związanych z otwartością sprawił, że jedynym rozstrzygającym czynnikiem okazała się symboliczna różnica w cenie.
Jeśli administracja traktuje open source jako realną opcję, może przenieść to na kryteria oceny ofert. Nie chodzi o „premiowanie open source za samo bycie open”, lecz o punktowanie cech typowo z nim związanych. W kryteriach pozacenowych można uwzględnić np.:
- dojrzałość komponentów – liczba lat rozwoju, aktywność społeczności, cykl wydawniczy stabilnych wersji,
- stopień otwartości rozwiązania – dostępność kodu źródłowego, dokumentacji, skryptów wdrożeniowych oraz możliwość re-use poza danym projektem,
- model utrzymania – liczba dostępnych na rynku podmiotów, które realnie znają daną technologię/projekt open source,
- strategia zarządzania podatnościami – proces monitorowania, czas reakcji, używane narzędzia, doświadczenia z poprzednich wdrożeń.
W SIWZ da się też opisać, jak wykonawca ma udokumentować dojrzałość proponowanych rozwiązań: linkami do publicznych repozytoriów, statystykami wydań, referencjami z innych projektów publicznych, opisem społeczności rozwijającej dany projekt.
Mini-wniosek: kryteria jakościowe ukierunkowane na dojrzałe otwarte rozwiązania pozwalają uniknąć sytuacji, w której zamawiający „zaoszczędzi” na starcie, a po kilku latach utknie w niszowej technologii jednego dostawcy.
Plan wyjścia, re-use i współdzielenie rozwiązań między jednostkami
Duże miasto zleciło budowę portalu mieszkańca jako rozwiązania dedykowanego. Po dwóch latach sąsiednia gmina zgłosiła chęć skorzystania z tego samego systemu. Okazało się, że w umowie nie przewidziano jasnego prawa do udostępnienia kodu innym jednostkom publicznym, a wykonawca zażądał pełnej stawki za „nowe wdrożenie”.
Open source jest jednym z najskuteczniejszych sposobów na przełamanie takich barier, ale wymaga zapisów umożliwiających re-use. Przy formułowaniu SIWZ można rozważyć m.in.:
- wprowadzenie prawa do udostępniania kodu innym podmiotom sektora finansów publicznych bez dodatkowych opłat licencyjnych,
- wymóg zastosowania licencji, która zezwala na ponowne użycie (np. EUPL, MIT, Apache 2.0) przy poszanowaniu praw twórców i obowiązków licencyjnych,
- opis procedury „pakowania” rozwiązania dla kolejnych jednostek (instrukcje wdrożeniowe, parametry konfiguracyjne, wymagania sprzętowe),
- możliwość utworzenia wspólnego repozytorium dla kilku urzędów, współfinansujących dalszy rozwój rozwiązania.
Plan wyjścia dotyczy również zakończenia współpracy z wykonawcą. Stąd w SIWZ przydatne są zapisy, że po wygaśnięciu umowy wykonawca:
- aktualizuje repozytorium zamawiającego o wszystkie najnowsze zmiany,
- przekazuje pełną dokumentację (także wewnętrzne procedury operacyjne używane dotąd wyłącznie przez jego zespół),
- wspiera proces przekazania wiedzy (np. warsztaty, shadowing) nowemu wykonawcy lub zespołowi wewnętrznemu,
- usuwa lub przekazuje wszelkie klucze i dostępy, dokumentując ten proces.
Mini-wniosek: prawdziwy potencjał open source ujawnia się nie przy pierwszym wdrożeniu, lecz przy drugim, trzecim, czwartym – pod warunkiem, że umowy od początku dopuszczają dzielenie się rozwiązaniem.
Kompetencje zamawiającego i zarządzanie cyklem życia rozwiązania
W jednym powiecie zamówiono system open source z pełnym kodem, dokumentacją i prawem do modyfikacji. Po trzech latach żaden z pracowników nie czuł się na siłach nawet zlecić modernizacji – brakowało osoby, która rozumiałaby podstawowe pojęcia techniczne i potrafiła rozmawiać z wykonawcami jak równy z równym.
Nawet najlepsze zapisy w SIWZ nie zastąpią minimalnych kompetencji po stronie urzędu. Przy planowaniu projektów opartych na open source przydaje się:
- wyznaczenie właściciela produktu po stronie zamawiającego – osoby odpowiedzialnej za wizję rozwoju systemu i zarządzanie backlogiem zmian,
- podniesienie kwalifikacji IT wewnętrznego w zakresie pracy z repozytoriami, systemami śledzenia zadań, podstawami licencji,
- zaplanowanie budżetu na utrzymanie i rozwój (nie tylko jednorazowe wdrożenie) oraz cykliczne przeglądy architektury,
- ustalenie mechanizmów priorytetyzacji zmian z udziałem użytkowników końcowych – aby rozwój nie był dyktowany wyłącznie przez wykonawcę.
W SIWZ można oczekiwać, że wykonawca nie tylko dostarczy system, ale również:
- przeprowadzi szkolenia techniczne i biznesowe dla kluczowych osób po stronie zamawiającego,
- przygotuje plan rozwoju na kolejne lata, z uwzględnieniem scenariusza zmiany wykonawcy lub przeniesienia części prac do zespołu wewnętrznego,
- pomoże zbudować proces zarządzania zmianą – od zgłoszenia potrzeby, przez analizę, aż po wdrożenie i dokumentację.
Mini-wniosek: open source daje administracji wolność, ale wymaga też odpowiedzialności – przede wszystkim inwestycji w ludzi, którzy będą tę wolność potrafili wykorzystać w praktyce.
Najczęściej zadawane pytania (FAQ)
Czy w SIWZ można wymagać konkretnego oprogramowania, np. systemu firmy X zamiast open source?
Scenariusz jest typowy: dział IT chce „sprawdzonego systemu firmy X”, bo już go zna, a SIWZ zaczyna przypominać ulotkę producenta. Taki opis szybko kończy się odwołaniem konkurencji i zarzutem naruszenia zasady uczciwej konkurencji.
Prawo zamówień publicznych co do zasady zakazuje wskazywania konkretnej marki, producenta czy produktu, chyba że jest to obiektywnie uzasadnione i nie da się inaczej opisać przedmiotu zamówienia. Zamiast pisać „system firmy X”, należy określić wymagania funkcjonalne i niefunkcjonalne, a także warunki licencyjne (np. dostęp do kodu, prawa do modyfikacji). Wtedy w przetargu mogą wystartować zarówno dostawcy rozwiązań komercyjnych, jak i open source.
Czym różni się open source od „darmowego oprogramowania” w kontekście przetargu publicznego?
Na etapie planowania zamówienia często wrzuca się do jednego worka wszystko, za co nie ma faktury: Linuxa, mały darmowy program z internetu i biblioteki „znalezione w Google”. To rodzi chaos – szczególnie gdy przychodzi kontrola i pyta o licencje.
Open source to model licencjonowania z jasno określonymi prawami: uruchamiania, analizowania, modyfikacji i dalszego rozpowszechniania kodu źródłowego. Darmowe oprogramowanie (freeware) jest zwykle bezpłatne do użycia, ale zamknięte, bez prawa modyfikacji i udostępniania. W przetargu oznacza to, że użycie freeware nie rozwiązuje problemu vendor lock-in ani braku kontroli nad rozwojem, natomiast poprawnie użyte komponenty open source mogą dać instytucji znacznie większą swobodę i elastyczność.
Czy prawo zamówień publicznych dopuszcza wymaganie oprogramowania open source w SIWZ?
Gdy pojawia się pomysł „zapiszmy w SIWZ, że system ma być open source”, prawnik często reaguje alergicznie, a wykonawcy dzielą się na entuzjastów i przeciwników. Problem w tym, że z punktu widzenia prawa kluczowa jest neutralność technologiczna.
Specyfikacja co do zasady nie powinna faworyzować ani open source, ani rozwiązań zamkniętych. Można natomiast formułować wymagania, które otwierają drogę dla modeli otwartych, np. wymagać: dostępu do kodu źródłowego, prawa do modyfikacji i korzystania przez inne jednostki sektora publicznego, zgodności z określonymi standardami czy braku dodatkowych opłat licencyjnych przy skalowaniu. Wtedy wykonawcy mogą zaproponować zarówno system zbudowany na open source, jak i rozwiązanie komercyjne, o ile spełni te warunki.
Jak opisać w SIWZ kwestie licencji i kodu źródłowego przy rozwiązaniach open source?
Typowy dylemat: „Chcemy open source, ale boimy się, że zgubimy się w licencjach i ktoś zarzuci nam naruszenie praw autorskich”. To ryzyko da się dobrze poukładać, jeśli świadomie opisze się przedmiot zamówienia.
W SIWZ można m.in. zażądać, aby wykonawca: wskazał wszystkie wykorzystane komponenty open source wraz z ich licencjami, zapewnił zgodność sposobu użycia z tymi licencjami, przekazał kod źródłowy części wytworzonych w ramach zamówienia wraz z dokumentacją oraz udzielił zamawiającemu określonych praw (np. prawo do modyfikacji, prawo sublicencjonowania do innych jednostek). Dobrą praktyką jest też wymóg dostarczenia „bill of materials” – listy komponentów open source wchodzących w skład rozwiązania.
Jak open source pomaga uniknąć vendor lock-in w administracji publicznej?
Wiele urzędów odkrywa, że ich kluczowe systemy „należą” w praktyce do jednego dostawcy: tylko on zna kod, tylko on ma dokumentację, a każda zmiana to negocjacje z pozycji siły. Kolejny przetarg na utrzymanie wygrywa więc ten sam podmiot, bo inni nie mają jak wejść.
Przy rozwiązaniach open source kod jest dostępny, a więc utrzymanie i rozwój może przejąć inny wykonawca, o ile ma odpowiednie kompetencje. Warunkiem jest jednak odpowiedni zapis w umowie i SIWZ: dostęp do repozytorium kodu, prawo korzystania z kodu również przez innych wykonawców, rzetelna dokumentacja i opis interfejsów. Open source sam z siebie nie gwarantuje braku vendor lock-in, ale znacząco ułatwia zmianę dostawcy, jeśli instytucja zadba o to na poziomie zapisów kontraktowych.
Czy korzystanie z open source w projekcie publicznym oznacza brak wsparcia i gwarancji?
Często pojawia się obawa: „Open source to wolontariusze z internetu, a my potrzebujemy numeru telefonu, pod który zadzwonimy, gdy system padnie”. Tu trzeba oddzielić oprogramowanie od usługi.
W przetargu zamawiający kupuje rozwiązanie: wdrożenie, konfigurację, rozwój i wsparcie, a nie sam „goły” kod z repozytorium. Wykonawca może oferować komercyjne wsparcie dla komponentów open source, z gwarantowanymi czasami reakcji (SLA), helpdeskiem i obowiązkiem usuwania błędów. W SIWZ warto więc jasno określić wymagane poziomy usług serwisowych, a nie zakładać, że open source z definicji oznacza brak odpowiedzialności po stronie dostawcy.
Jak neutralność technologiczna wpływa na ocenę ofert z rozwiązaniami open source?
Komisja przetargowa nie ocenia „ideologii”, tylko to, czy oferta spełnia wymagania i jest najkorzystniejsza. Jeśli kryteria są źle ustawione, łatwo niechcący wypchnąć z rynku rozwiązania open source lub je uprzywilejować.
Neutralne podejście polega na tym, że kryteria odnoszą się do efektu, a nie etykietki technologii. Można więc punktować np.: łatwość zmiany wykonawcy, otwarte formaty danych, brak dodatkowych opłat za licencje przy zwiększaniu liczby użytkowników, dostępność dokumentacji czy możliwość ponownego wykorzystania rozwiązania przez inne jednostki sektora publicznego. Oferty oparte na open source często wypadają w takich kryteriach dobrze, ale konkurują na równych zasadach z rozwiązaniami zamkniętymi.
