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.